Hi All,
Hello,
Sure everyone's familiar with...
2020 LDAP channel binding and LDAP signing requirement for Windows
https://support.microsoft.com/en-gb/help/4520412/2020-ldap-channel-binding-and-ldap-signing-requirement-for-windows
From what I can tell, LDAP connections will be made secure;
- LDAP signing
or - LDAPS
Current Windows computers are capable of LDAP signing. But non-Windows computers may not be; instead, they should use STARTTLS to switch to LDAPS.
The domain controllers I am looking at are already listening on TCP/636;
Get-ADDomainController -filter * | select name,ldapport,sslport name ldapport sslport ---- -------- ------- [redacted] 389 636 [redacted] 389 636 [redacted] 389 636 [redacted] 389 636 [redacted] 389 636
If a computer isn't capable of LDAP signing [typically, non-Windows], then it should use the STARTTLS to use LDAP channel binding.
That's where the fun begins!
LDAPS is LDAP over TLS.
TLS requires a certificate.
Where should this certificate come from?
Should it be from an internal certification authority, which won't be trusted by [non-Windows domain member] LDAP clients by default. But internal hosts can check the certification authority CRLs.
Or, should it be from an public certification authority (https://letsencrypt.org/ might do!)
BUT if I use a public certification authority, then do my LDAP clients now need to be able to examine the public certification authorities certificate revocation list or OCSP? That may not always be possible.
How to enable LDAP over SSL with a third-party certification authority
https://support.microsoft.com/en-gb/help/321051/how-to-enable-ldap-over-ssl-with-a-third-party-certification-authority
Kind regards,
Anwar