Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    LDAPS authentication issue with Active Directory

    OpenVPN
    6
    7
    3.9k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • T
      TheIlleist
      last edited by

      Hi,

      I'm having an issue getting LDAP authentication to work over SSL (it is working fine over 389, so its its solely an SSL issue). I have read the following link, implemented the patch and checked the log file but it is not accumulating anything even though I can see the packets hitting the Active Directory server in a wireshark capture:
      https://doc.pfsense.org/index.php/LDAP_Troubleshooting

      The Wireshark cap on the AD server is telling me that the pfSense FW is responding with:

      FW_IP	16637	SERVER_IP	636	TLSv1.2				Alert (Level: Fatal, Description: Unknown CA)

      The specific response being:

      Description: Unknown CA (48)

      I believe I have successfully exported the required CA cert from the AD server (from 'Trusted Root Certification Authorities') and:

      • Imported it successfully it on the pfSense box via System > Cert Manager > CAs > Pasted Cert Data into 'Certificate data'

      • Selected to use the imported CA for LDAPS via System > User Manager > Servers > (My_LDAP_Auth_Server_) > 'Peer Certificate Authority'

      Note: The CA cert I imported is the one that was used to generate the self signed certificate which the AD server responds with when queried. Below is a query to said AD Server on port 636:

      openssl s_client -showcerts -connect AD_SERVER:636
      CONNECTED(00000003)
      depth=0 CN = CN_OF_AD_SERVER
      verify error:num=20:unable to get local issuer certificate
      verify return:1
      depth=0 CN = CN_OF_AD_SERVER
      verify error:num=27:certificate not trusted
      verify return:1
      depth=0 CN = CN_OF_AD_SERVER
      verify error:num=21:unable to verify the first certificate
      verify return:1

      Certificate chain
      0 s:/CN=CN_OF_AD_SERVER
        i:/CN=AD_SERVER_CA

      (AD_SERVER_CA being the certificate that I exported and then imported into the CAs on the pfsense)

      I'm guessing all the 'verify error' lines thrown in response to the OpenSSL query are the reason the pfSense box is unhappy about using an SSL connection, but I'm not sure what else to do about it….any suggestions?
      Either that, or I have missed a step and I need to import the certificate of AD server into the certificates on the pfSense, rather than just the CA used to generate the AD servers certificate....

      1 Reply Last reply Reply Quote 0
      • jimpJ
        jimp Rebel Alliance Developer Netgate
        last edited by

        You only need to import the CA Cert, that should be fine, so long as it can verify everything. More often than not these issues come down to something else not verifying properly (e.g. LDAP server set for an IP address instead of a hostname, or the hostname doesn't match the CN of the server certificate)

        Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

        Need help fast? Netgate Global Support!

        Do not Chat/PM for help!

        1 Reply Last reply Reply Quote 0
        • T
          TheIlleist
          last edited by

          Okay, thanks jimp. I've tried both the IP and hostname (as per the cn on the certificate) for the server, but get the same result. I'm starting to think there is something mysterious within Active Directory rather than the pfSense so I will keep looking into it.

          1 Reply Last reply Reply Quote 0
          • DerelictD
            Derelict LAYER 8 Netgate
            last edited by

            In order to have s_client perform a validation you need local copy of the CA certificate/chain and give it to s_client's -CAfile option.

            Chattanooga, Tennessee, USA
            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
            Do Not Chat For Help! NO_WAN_EGRESS(TM)

            1 Reply Last reply Reply Quote 0
            • L
              Leva
              last edited by

              Hi,

              I have the exact same problem. I have two pfsense boxes (one is version 2.2.5, the other one is newer 2.3) for two separate domains (better say forests) and both are set to auth against the belonging domain over LDAPS.

              Both pfsenses have a self-signed root CA, and the DCs have the server certs issued by these pfsense CAs, CAs are also imported into the DC's Trusted Root CAs store. So far LDAPS works as expected when pfsense is authenticating against the DC for which the cert and root CA was created by the very same pfsense.

              However when I want a (sort of a) cross domain auth over LDAPS, meaning that I export the root CA from the second pfsense and import that into the first one, and set a new auth server to point to the second domain's DC, the authentication just fails with the standard error saying: "Could not connect to the LDAP server. Please check your LDAP configuration."
              I did some wireshark which revealed the same "Description: Unknown CA (48)" error, so basically it seems to me that pfsense fails comparing the root CA provided by the authentication server against the imported CA.

              Unfortunately I cannot support this theory with logs, as I'm not a unix-bsd guru, so don't know where to look exactly, but what I think is:

              • Either pfsense modifes somewhat the CA when it is imported to its store.
              • or it just fails to compare the CA provided by the auth servers against the locally stored (imported) one.

              The DCs also show "schannel" errors with the same error code 48, so it has to do something with the way pfsense handles the imported CAs. But I have an idea, if I could figure out where pfsense stores the imported CAs I could manually place/copy the CA there instead of importing it from the webGUI, so at least I could either confirm or exclude the first option that pfsense modifies the CAs content during the import.

              Nevertheless, any ideas are welcome, as I'm stuck with this.

              H 1 Reply Last reply Reply Quote 0
              • Y
                ya.asoloviev
                last edited by

                @Leva Hi. Any ideas on this issue? I have the same error 48.

                1 Reply Last reply Reply Quote 0
                • H
                  hrx @Leva
                  last edited by

                  @Leva We're seeing the exact problem here. Running pfsense+ 24.03.

                  Did some research on the net in the meantime - there's a related post on Reddit (https://www.reddit.com/r/PFSENSE/comments/dc5mv8/pfsense_active_directory_authentication_using/).

                  I've also opened a support ticket with Netgate (#2887255105) and hope we'll get this up and running finally.

                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post