April 11, 2024
Everyone knows that SSL is vulnerable and we should therefore use TLS. What isn’t well understood is the options presented for Binding (authentication) when using the Generic LDAP Connector with AADConnect or the Generic LDAP ECMA 2.x with MIM.
We are presented 5 options:
- Anonymous
- Basic
- Kerberos
- SSL
- TLS
When we tested we could get the SSL option to work over port 636, and we could get the TLS option to work on port 389 but we couldn’t get the TLS option to work over port 636. Using a protocol analyzer we confirmed that both ways were using TLS 1.2.
Some web searching turned up the following on the website doc of a competing Identity product on how they connectto LDAP:
-
Use SSL
- SSL/TLS encrypted is used to establish a connection. Variable: CP_UseSsl
-
Use StartTLS
- StartTLS is used for encryption. Variable: CP_UseStartTls
So it occurred to me that SSL really means SSL/TLS and that TLS really means StartTLS.
So then I started reading about StartTLS vs LDAPS:
Please note there is a difference between ldaps and start-TLS for ldap. start-TLS uses port 389, while ldaps uses port 636. ldaps has been deprecated in favour of start-TLS for ldap. Both encrypted (start-TLS ldap) and unencrypted ldap (ldap) run on port 389 concurrently.
Errors encountered are generally due to misunderstanding how to implement TLS-encrypted ldap
There is a clue to this is in the LDAP Connector doc:
The connector uses the port number specified in the configuration, which by default is 389 for LDAP and 636 for LDAPS.
For LDAPS, you must use SSL 3.0 or TLS. SSL 2.0 is not supported and cannot be activated.
So the last two options should really be labelled:
- SSL/TLS –SSL/TLS depending on what your server is configured to use
- StartTLS – talk over the normally unecrypted port and then use StartTLS to encrypt everything.