Implementing LDAPS (LDAP over SSL)

LDAP over SSL (LDAPS) is becoming an increasingly hot topic - perhaps it is because Event Viewer ID 1220 is catching people's attention in the Directory Service Log or just that people are wanting the client to server LDAP communication encrypted. The quick summary of what this is all about is that when an LDAP client accesses an LDAP server, the information is transferred by default in clear text. The event warns IT Professionals of the potential for communications between clients and servers of being sniffed. Considering this issue, people often wonder if Active Directory replication is done in clear text and that is NOT the case. Active Directory replication uses Kerberos and so do client password changes. Therefore, you need not worry about full database sniffing during replication to a new domain controller or getting passwords when clients are changing their domain passwords. So, only when a client computer is querying an LDAP server [Active Directory Domain Services (AD DS) or Active Directory Lightweight Directory Services (AD LDS)/Active Directory Application Mode (ADAM)] the network communication is done in clear text unless you implement LDAP over SSL. An article on how to implement LDAP over SSL is posted to the TechNet Wiki and when it is fleshed out to an appropriate degree it will be imported into the TechNet Library (and noted on the TechNet Wiki article).

=====

I've tried to respond to the comment below multiple times, but my replies are not getting posted for some reason. I have already updated the article on the TechNet Wiki to discuss these items, but it makes sense to also address them here briefly.

1. LDAPS is best used to protect credentials during a simple LDAP bind. This is when a user name and password could be exposed.
2. MMC snap-ins use sign and seal.
3. There is no way to make clients prefer LDAPS because the type of connection depends on the application that is running on the client computer. For example, I wrote out steps on how to verify the connection using port 636 in ADSIEdit, but that would not stop you from typing 389 or trying any other port for that matter. The application has to support it and you would have to enable it in the application or in some cases the applications require it and that causes people to realize they need to enable it on their LDAP server (domain controller or AD LDS/ADAM).
4. Blocking port 389 is a typical thing to do on an external firewall, but is not something you would do on a domain controller. The Active Directory Domain Service administration tools still use port 389, but they are protected by the sign and seal binding.

Comments

• Anonymous
  June 02, 2011
  Thanks for the article on how to enable optional LDAP over SSL at the controller.  But how can we force all clients to only use LDAPS?  Can we block TCP 389 now?  Will all Microsoft clients automatically prefer LDAPS?  Is there a client-side registry value which can be set to prefer/require LDAPS?  How can we realistically force all non-Microsoft LDAP clients to use LDAPS, assuming they support SSL, other than blocking TCP port 389?  Do all the "Active Directory *" mmc snap-ins prefer SSL whenever it's available?  Thank You!

• Anonymous
  July 15, 2011
  To the previous commenter: Most msft clients don't need to use LDAPS, they use integrated authentication which is encrypted and then, for many apps, the LDAP traffic itself is sealed via kerberos or NTLM. LDAPS is going to be primarily used for for non-msft clients.

• Anonymous
  January 05, 2016
  The comment has been removed

• Anonymous
  January 05, 2016
  The comment has been removed

• Anonymous
  May 12, 2018
  https://community.spiceworks.com/topic/1513319-implementing-ldaps