Share via

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.