LDAPS authentication issue with Active Directory

  • 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:

    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
    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

    (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....

  • Rebel Alliance Developer Netgate

    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)

  • 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.

  • LAYER 8 Netgate

    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.

  • 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.

Log in to reply