Forum Discussion
mousumimukherjee
Apr 21, 2022Copper Contributor
LDAP SSL client affects with LDAP Signing/SASL?
Hi All,
I am currently working in my organisation, recently we got to configure LDAP Signing and Channel Binding for our LDAP Server and Clients. We have many client server and in house application that is using our LDAP bind for authentication and mostly using secure SSL (LDAPS). But I am not getting enough confident that how enabling LDAP Signing and Channel binding affects our client application that are connecting over LDAP SSL bind.
I am struggling with this for a long time. If any one can help me with confirmation that would be great
PS: Enabling the signing policy would not negatively impact a Windows client.
You'd have to be talking about a client that simply is not capable of negotiating any one of the authentication protocols before you'd run into a failure scenario (for the most part.)
As per the GPO setting's explanation, the policy has no effect if LDAPS over TLS is being used. This is because the process has already been secured via TLS.
The policy only relates to non-TLS connections, where it effectively says, "Hey, client! You need to negotiate securely or I'm not talking to you!" So, with the policy enabled, you couldn't successfully perform a simple bind over a non-TLS-protected (aka unencrypted) connection.
Cheers,
Lain
- LainRobertsonSilver Contributor
This simple explanation (probably a bit over-simplified but it'll do) is this:
SASL
- The LDAP connection itself is not encrypted;
- The chosen authentication scheme/package provides its own encryption/securing of the logon credentials. For example, if Kerberos is selected then Kerberos-specific methods are used to secure the authentication process.
LDAP over TLS
- The LDAP connection itself is encrypted;
- Nobody cares about the authentication scheme because the session was already set up as encrypted. Okay, I jest, we do care, but in principle it shouldn't really matter (unless you're running susceptible ciphers and whatnot.)
So, SASL secures the authentication process subject to the limitations of the package (for example Kerberos does a better job of securing thing than NTLMv1).
TLS sets up security first, meaning what comes (i.e. authentication) after doesn't really matter.
Understandable explanations
Understanding LDAP Security Processing - Microsoft Tech Community
LDAP session security settings and requirements after ADV190023 - Windows Server | Microsoft Docs
Technical explanations
[MS-ADTS]: Using SSL/TLS | Microsoft Docs
[MS-ADTS]: SASL Authentication | Microsoft Docs
The important thing is that both provide security to the authentication (i.e. your credentials passing over the wire) process to a varying extents.
Cheers,
Lain
- LainRobertsonSilver Contributor
PS: Enabling the signing policy would not negatively impact a Windows client.
You'd have to be talking about a client that simply is not capable of negotiating any one of the authentication protocols before you'd run into a failure scenario (for the most part.)
As per the GPO setting's explanation, the policy has no effect if LDAPS over TLS is being used. This is because the process has already been secured via TLS.
The policy only relates to non-TLS connections, where it effectively says, "Hey, client! You need to negotiate securely or I'm not talking to you!" So, with the policy enabled, you couldn't successfully perform a simple bind over a non-TLS-protected (aka unencrypted) connection.
Cheers,
Lain