How-To: Use LDAP Over SSL to Lock Down AD Traffic

The standard protocol for reading data from and writing data to Active Directory (AD) domain controllers (DCs) is LDAP. AD LDAP traffic is unsecured bydefault, which makes it possible to use network-monitoring software to view the LDAP traffic between clients and DCs. This security problem alsoapplies to the LDAP subprotocols, such as LDAP bind, that applications, services, or users use to transport credentials and authenticate against aWindows DC.

Organizational security policies typically require that all client/server communication is encrypted. In addition, applications that integrate with ADmight require encrypted LDAP communication.

To make LDAP traffic secure, you can use the Secure Sockets Layer/Transport Layer Security (SSL/TLS) protocols; this combination is referred to as LDAPover SSL -- or LDAPS. To ensure that no one else can read the traffic, SSL/TLS establishes an encrypted tunnel between an LDAP client and a Windows DC.In this article, I explain how to set up LDAPS on the DCs in your Windows Server 2008 AD infrastructure.

LDAPS Server Certificate Requirements

LDAPS requires a properly formatted X.509 certificate on all your Windows DCs. This certificate lets a DC's LDAP service listen for and automaticallyaccept SSL connections for both LDAP and Global Catalog (GC) traffic. The server certificate is used for authenticating the DC to the client during theLDAPS setup and for enabling the SSL communication tunnel between the client and the server after setup. As an option, you can use LDAPS for clientauthentication -- but doing so requires that you also install a client authentication certificate on each of your clients.

In the next section, I explain in detail how you can obtain an LDAPS server certificate for your DCs -- but first, let's look at what rules thiscertificate should adhere to.

The LDAPS certificate and its associated private key must be stored in the DC's Personal certificate store (also referred to as the MY certificate store). To view the content of your DC's certificate store, follow these steps:

1.     On the DC, click Start, type mmc, and click OK.

2.     Click the File menu option, then click Add/Remove Snap-in.

3.     Click Certificates, Add.

4.     In the Microsoft Management Console (MMC) Certificates snap-in dialog box, select Computer account and click Next.

5.     In Select Computer, select Local computer and click Finish.

6.     In Add or Remove Snap-ins, click OK.

7.     In the console tree, expand Certificates (Local Computer), then the Personal container, and finally the Certificates container.

8.     In the right-hand pane of the Certificates snap-in you'll see a list of all the certificates that are stored in your DC's Personal certificate store, as Figure 1 shows.

Figure 1: Certificates in a DC's Personal certificate store

The LDAPS certificate must meet the following X.509 certificate extension requirements:

You can easily check the content of a certificate's X.509 extensions from the Windows Certificate Viewer, which you can also access from theCertificates snap-in. Double-click a certificate in the right-hand pane of the Certificates snap-in, then click the Details tab, as Figure 2 shows.

Figure 2: Certificate extensions in the Details tab of the Certificate Viewer

As for any certificate, the LDAPS certificate must have been issued by a Certification Authority (CA) that the DC and the LDAPS clients trust. Trust isestablished by configuring the clients and the server to trust the issuing CA's certificate (in a one-tier CA setup) or the certificate of the root CAto which the issuing CA of the LDAPS certificate chains (in a multi-tier CA setup).

You can find a list of all trusted CA certificates in the Trusted Root Certification Authorities container of a machine's certificate store. This storecontains the certificates of CAs that you or your domain administrator consider trustworthy and that Windows can use as a trust anchor for validatingother certificates. The CA certificates of CAs installed on machines that are part of your AD infrastructure are automatically added to clientmachines' certificate stores through the Group Policy Object (GPO) update mechanism. If the CA certificate of the CA that issued the LDAPS certificateisn't present in the Trusted Root CA Certification Authorities container, you can manually import it using the Import option that's available from thiscontainer's context menu.

Another important condition is that not only the LDAPS certificate but also a private key that matches the certificate is present in the DC'scertificate store. To check whether the DC certificate store holds a matching private key for a given LDAPS certificate, you can use the General tab ofthe Certificate Viewer, as Figure 3 shows. If the correct private key is present, the bottom of this dialog box should show a key symbol and the textYou have a private key that corresponds to this certificate.

Figure 3: Private key properties in the General tab of the Certificate Viewer

The private key should also not have strong private key protection enabled -- which means that Windows shouldn't prompt for a password each time thekey is accessed. Strong private key protection is never enabled by default in Windows, which also applies to LDAPS certificates.

To validate whether your DC has a valid certificate from the command line, you can use the certutil utility as follows:

certutil -verifyStore MY 

For more information about how to leverage the output of this command for troubleshooting LDAPS certificates, see the Microsoft TechNet article"Troubleshooting LDAP Over SSL."

Obtaining a Server LDAPS Certificate

Your DCs will automatically receive a valid LDAPS certificate when you install an enterprise root CA (i.e., an AD-integrated CA) on one of your domainservers or DCs. However, this certainly isn't the most secure or most flexible option for providing certificate services to your users. Mostorganizations that want to bring a higher level of security and flexibility to their certificate services opt for a multi-tier Windows CA hierarchythat consists of a root CA and different issuing CAs. If your organization has created or plans to create a Windows CA hierarchy, I advise you tofollow my instructions in this section for creating LDAPS certificates for your DCs. LDAPS certificates can also be issued by a non-Microsoft CA. (Fordetailed instructions, see the Microsoft article "How to enable LDAP over SSL with a third-party certification authority" atsupport.microsoft.com/kb/321051.)

When you have a multi-tier Windows public key infrastructure (PKI) hierarchy, you must first create a custom certificate template for LDAPScertificates in AD, then enable this custom template on all your issuing CAs, and finally manually enroll all DCs for an LDAPS certificate that's basedon this custom template.

To create a custom certificate template for LDAPS certificates in AD, open the MMC Certificate Templates snap-in on one of your enterprise(AD-integrated) CAs. (Click Start, type mmc, and click OK. Click the File menu option, then click Add/Remove Snap-in. Click CertificateTemplates, Add, OK.) In the Certificate Templates snap-in, expand Certificate Templates, right-click a template in the right-hand pane (e.g., theKerberos Authentication template), and select Duplicate Template. Note that you can also duplicate another template (e.g., the Domain ControllerAuthentication template) as long as the template has the Server Authentication OID in its Extended Key Usage certificate extension.

In the Duplicate Template dialog box, leave the default Windows Server 2003 Enterprise option selected and click OK. This will make the properties ofthe new template appear, as Figure 4 shows.

Figure 4: Certificate Templates properties

You should pay special attention to the following properties of the new template:

Finally, click OK to close the template properties and complete the new template customization.

To enable your issuing CAs to issue certificates based on the new LDAPS template, you must add the new template to the CA's Certificate Templatescontainer. To do so, start the MMC Certification Authority snap-in on one of your enterprise CAs, expand the CA container, right-click the CertificateTemplates container, and select New, Certificate Template to Issue. In the Enable Certificate Templates dialog box, which Figure 5 shows, youcan then select the name of the newly created template. To close the dialog box, click OK.

Figure 5: The Enable Certificate Templates dialog box

As a last step, you must request LDAPS certificates for each of the DCs that requires LDAPS connections. To do so, perform the following steps on allaffected DCs.

1. From the MMC Certificates snap-in, open the Personal container of the machine's certificates store, as I explained in the previous section on theLDAPS server certificate requirements.

2. Right-click the Certificates container and select All Tasks, Request New Certificate. This action will launch the Certificate Enrollment wizard.Click Next.

3. On the Select Certificate Enrollment Policy page of the wizard, leave the default of Active Directory Enrollment Policy and click Next.

4. Select the LDAPS certificate template and click Enroll.

5. Ensure that the enrollment succeeds and verify the properties of the new LDAPS certificates using the View Certificate option in the Detailssection.

6. Click Finish to close the wizard.

Windows Server 2008 provides a new option that lets you store the LDAPS certificate of a DC in AD's Personal certificate store on the DC. This is agood option if your DCs have multiple certificates with the Server Authentication OID in their Local Machines Personal store. In that case, it'sdifficult to predict which certificate AD will pick for LDAPS authentication. The new Windows Server 2008 logic makes AD first look for serverauthentication certificates in the AD certificate store. Therefore, this new feature can force AD to use the server authentication certificate that yougenerated using your custom LDAPS template. For more information about how to add the certificate to the AD service's Personal certificate store (alsoreferred to as the NTDS certificate store), see the Microsoft TechNet article "Event ID 1220 -- LDAP over SSL."

Verifying LDAPS Connectivity

To verify that LDAPS is configured successfully on your DCs, you can use the LDP tool. LDP is installed by default on a Windows Server 2008 DC. OnWindows Server 2008 member servers, Windows 7 machines, or Windows Vista machines, you must install Microsoft Remote Server Administration Tools (RSAT)to obtain access to LDP.

To open LDP, click Start and type ldp in the Search box. Click the Ldp Connection menu options, and then click Connect. In the Server field, enter theFQDN of the DC to which you want to connect. Ensure that the port is set to Port 636 (which is the default LDAPS port), that the Connectionless checkbox is cleared, and that the SSL check box is selected; then click OK. If LDAPS is configured properly, the LDP command output should displayHost supports SSL, as in Figure 6.

Figure 6: Verifying LDAPS connectivity using LDP

Click the Connection menu option again, select Bind, and click OK. If LDAPS is configured properly, the LDP command output should display the usernameand domain name that you used for authenticating with LDP to AD.

Closing Another AD Gate

Even though Microsoft doesn't provide a specific configuration interface, securing the LDAP traffic to your AD DCs using SSL/TLS technology isrelatively easy. In this article, I explained how to enable LDAPS by installing a properly formatted certificate on your DCs. With LDAPS, you can lockdown an important AD authentication and directory access gate. The two other main AD authentication protocols -- Kerberos and NTLM -- both leverageremote procedure calls (RPCs) for transport and have proper security and encryption mechanisms that are enabled by default.