Configuring Active Directory for LDAPS (LDAP over SSL)
2011-10-01 Reformatted for clarity
2009-01-13 Initial post
BACKGROUND
By default, Kerberos will encrypt the LDAP authentication only, but not the actual LDAP traffic. You can enable LDAPS (LDAP over SSL) to encrypt the entire LDAP session in Windows AD.
Below are the ports that are used during standard LDAP/GC traffic and with LDAPS enabled.
- Standard LDAP port: 389
- LDAPS LDAP port: 636
- Standard GC port: 3268
- LDAPS GC port: 3269
From http://support.microsoft.com/kb/321051/en-us on 2009-01-13:
The Lightweight Directory Access Protocol (LDAP) is used to read from and write to Active Directory. By default, LDAP traffic is transmitted unsecured. You can make LDAP traffic confidential and secure by using Secure Sockets Layer (SSL) / Transport Layer Security (TLS) technology. You can enable LDAP over SSL (LDAPS) by installing a properly formatted certificate from either a Microsoft certification authority (CA) or a non-Microsoft CA according to the guidelines in this article.
There is no user interface for configuring LDAPS. Installing a valid certificate on a domain controller permits the LDAP service to listen for, and automatically accept, SSL connections for both LDAP and global catalog traffic. . .
LDAPS communication occurs over port TCP 636. LDAPS communication to a global catalog server occurs over TCP 3269. When connecting to ports 636 or 3269, SSL/TLS is negotiated before any LDAP traffic is exchanged.
CONFIGURING LDAPS ON A WINDOWS SERVER 2003 ACTIVE DIRECTORY DOMAIN CONTROLLER
This is one topic that doesn’t seem to have a lot of information in one easy to follow document. The process to get this up and running is not that difficult, but I had to refer to several articles. Here are my notes in a nutshell. These steps should be loosely applicable to Windows Server 2008 also.
In setting this up, all the issues that took me a lot of time to troubleshoot were related to the fact that I used my own CA. If I had used a mutually trusted external CA, I would have gotten all this to work a lot sooner, but using an external CA would cost extra money.
- You can use either an external or internal CA to generate the server cert for the DC. I set up an internal stand-alone MS CA for this purpose.
- The server’s FQDN must be in the SAN section along with any other aliases. For example, your DC’s FQDN is dc-1.corp.ad and for external LDAPS connections you have a DNS A record for ldaps-1.corp.com. In that case, you’ll need to have both dc-1.corp.ad and ldaps-1.corp.com listed in the SAN section. The internal FQDN must be listed first.
- If you want to allow external parties to connect to your LDAPS server, such as the case when integrating with some hosted e-mail filtering or helpdesk systems, you’ll need to set up your firewall to forward all external ldaps-1.corp.com:636 traffic to internal dc-1.corp.ad:636. You should limit the external IP addresses that can connect to your LDAPS server for added security.
- In the DC’s Directory Service log in Event Viewer, look for event 1221, “LDAP over Secure Sockets Layer (SSL) is now available.” If LDAPS isn’t working, you’ll see event 1220, “LDAP over Secure Sockets Layer (SSL) will be unavailable at this time because the server was unable to obtain a certificate.”
- I used the MS CA in stand-alone mode and connected to it from the DC to request a certificate. After I received the certificate, I installed it into the DC’s Local Computer store --> Personal --> Certificates.
- I also had to import the MS CA cert into the DC’s Local Computer store --> Trusted Root Certification Authorities --> Certificates. What’s odd is that when I did that, it actually placed it into Intermediate Certification Authorities Certificates --> Certificates. After finding that, I just cut and pasted it into the correct store.
- You must restart the DC.
- If you’re using your own CA, any clients connecting to your DC via LDAPS must trust your CA, so install the CA cert in each client computer’s Trusted Root Certification Authorities --> Certificates. I missed this step during testing and should have checked the client’s event log which would have pinpointed the issue. The client would have event 36882 (this was on Windows XP/Server 2003), “The certificate received from the remote server was issued by an untrusted certificate authority. Because of this, none of the data contained in the certificate can be validated. The SSL connection request has failed. The attached data contains the server certificate.”
- If you're setting up LDAPS to integrate with an externally hosted service, that service should have an option for you to upload your cert chain so that it will trust your certs. This will avoid any issues with the service not trusting your internal CA.
ADDITIONAL RESOURCES
Refer to the articles below for more details. “Troubleshooting LDAP Over SSL” was the most helpful regarding the issues I had with using my own CA.
• How to enable LDAP over SSL with a third-party certification authority: http://support.microsoft.com/kb/321051/en-us
• Configuring Microsoft Active Directory for SSL Access: http://wiki.service-now.com/index.php?title=Configuring_Microsoft_Active_Directory_for_SSL_Access
• How to add a Subject Alternative Name to a secure LDAP certificate: http://support.microsoft.com/kb/931351
• Troubleshooting LDAP Over SSL: http://blogs.technet.com/askds/archive/2008/03/13/troubleshooting-ldap-over-ssl.aspx
Tags: Configure, how to, install, LDAP security, Secure LDAP, LDAP security, set up
