LDAPS Question

Security
1

Hello Everyone. I am sending this message as I am a little doubtful about a situation I have.
I need a better understanding of the requirements for LDAPS communication on Anyconnect VPN authorization checks for 9.14 release codebases and above on the ASA platform. During prior upgrades, we have hit a number of cross-incompatibilities with different components of the ASA system, most recently with enforcement of secure communication in a stricter manner post upgrading the codebase.

A rollback was performed, but based on the issue presentation, I wanted to ensure the certificate for import to establish a trust relationship was correctly understood. Is it the case that for LDAPS to function for Authorization WITH secure enforcement on, we simply need to import the Intermediate (or other components of chain) certificate which signed the certificate of the endpoint we are attempting to connect to, similar to a trustpoint for the frontend communication with VPN clients? Otherwise, would there be any other requirements to ensure LDAPS protocol is able to adequately fetch the authorization information from the directory server?

This was where we were curious if the 9.12 hotfixed code would behave the same way as the earlier 9.12 version we are on now, as this has a desireable behavior to run encrypted LDAP, but without hard enforcement of the trusted state of the server certificate (which does not persist when stepping to 9.14 - changed to hard enforcement). Otherwise, on 9.14 (including the .23 revision), I was curious if there was a way to run a non-validated LDAPS communication in the same manner, or if a plaintext scenario might still be safe, given it is internal only traffic on the customer environment

2

Hello Johan

Thanks for sharing your situation with us. What you’re describing is a relatively specialized case, however I will do my best to address all the points you shared.

In the 9.14 release for ASA, LDAPS communication will indeed require stricter enforcement of secure communication. This means that for LDAPS to function for Authorization with secure enforcement on, you will need to import the certificate which signed the certificate of the endpoint you are attempting to connect to. This is similar to setting up a trustpoint for frontend communication with VPN clients.

However, it’s important to note that not just the intermediate certificate, but the entire certificate chain (root, intermediate, and server) should be imported to ensure proper trust establishment. The ASA needs to trust the certificate chain from the LDAPS server to function correctly.

Regarding your question about the 9.12 hotfixed code, it’s hard to say without knowing the exact details of the hotfix. However, the general rule is that if the hotfix doesn’t specifically address this issue, then it’s likely that the behavior will remain the same as in the original 9.12 version.

As for running a non-validated LDAPS communication on 9.14, I would not recommend this. The whole point of using LDAPS is to ensure secure communication. If you’re not validating the certificates, then you’re potentially exposing your network to man-in-the-middle attacks.

If your traffic is internal only, you might consider using plaintext LDAP. However, this should only be a temporary measure while you work on getting your LDAPS setup correctly. Even internal traffic can be vulnerable to attacks, so it’s always best to use secure protocols whenever possible.

Let us know how you get along, I’d be interested in hearing about any developments in your implementation.

I hope this has been helpful!

Laz