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 (5)
  1. When will the client use LDAPS? says:

    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!

  2. Joe says:

    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.

  3. brianw says:

    Since I almost went crazy trying to get LDAPS via ADAM working I’m posting my steps that worked. These came from googling everywhere and eventually opening a ticket with Microsoft. Hopefully this will help someone. This assumes you are using NETWORK SERVICE
    with your ADAM instance.

    a. Create a new cert template off of the Microsoft Web Server template
    i. Windows Server 2003 Enterprise as the type
    ii. Request Handling – Allow private key to be exported – checked
    iii. Subject Name – Build from this Active Directory information
    1. Subject name format = common name
    2. Uncheck all boxes for Include this information in alternate subject name
    iv. Security – Add Read and Enroll for the users and computers that will use the template
    b. Issue the new template on the CA if you just created it. Then stop and start the CA to publish it.
    c. Install new cert in computer personal store
    d. Export cert with the private key from computer personal store to a .pfx file
    i. Uncheck "Include all certificates in the certification path if possible"
    ii. Enter a .pfx password of your choosing
    e. Import cert to AD LDS instance personal store by adding the ADLDS service to the Certificates MMC.
    f. Grant Network Service: Read & execute, List folder contents, Read (ie. the default read permissions) to C:ProgramDataMicrosoftCryptoRSAMachineKeys
    g. Delete cert from computer personal store
    h. Dump the contents of the LDS service certificate store
    i. Open an administrative cmd prompt
    ii. certutil -verifystore -service -service ADAM_My
    iii. Make note of the value for Unique container name for the LDS cert (at least the first 4 chars)
    iv. The Unique container name value is the name of the file for the LDS cert
    i. Grant the service account running the LDS instance read rights to read the cert
    i. Go to C:ProgramDataMicrosoftCryptoKeys
    ii. Grant the NETWORK SERVICE local service account Read access to the file that matches the Unique container name
    j. Check the cert with LDP
    i. Adminstrator CMD prompt
    ii. ldp.exe
    iii. Connect to localhost with port 636. Bind with current credentials.
    k. Restart the service that runs the LDS instance on the server.
    l. Use ADSIEDIT and bind to the LDS instance on 636 to confirm it is working.

  4. brianw says:

    the certutil line was chopped off when I posted. After the second -service entry you need the name of your ADAM instance. For example, if LDS1 is the name of your ADAM instance use -service ADAM_LDS1My.

Comments are closed.

Skip to main content