The standard protocol for reading data from and writing data to Active Directory (AD) domain controllers (DCs) is LDAP. AD LDAP traffic is unsecured by default, which makes it possible to use network-monitoring software to view the LDAP traffic between clients and DCs. This security problem also applies to the LDAP subprotocols, such as LDAP bind, that applications, services, or users use to transport credentials and authenticate against a Windows DC.
Organizational security policies typically require that all client/server communication is encrypted. In addition, applications that integrate with AD might 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 LDAP over 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 automatically accept SSL connections for both LDAP and Global Catalog (GC) traffic. The server certificate is used for authenticating the DC to the client during the LDAPS setup and for enabling the SSL communication tunnel between the client and the server after setup. As an option, you can use LDAPS for client authentication -- 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 this certificate 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.
The LDAPS certificate must meet the following X.509 certificate extension requirements:
- The Extended Key Usage certificate extension must include the Server Authentication Object Identifier (OID): 188.8.131.52.184.108.40.206.1.
- The AD Fully Qualified Domain Name (FQDN) of the DC (e.g., mydomaincontroller.company.net) must appear in either the Common Name (CN) of the Subject field certificate extension or in the DNS entry of the Subject Alternative Name (SAN) certificate extension.
You can easily check the content of a certificate's X.509 extensions from the Windows Certificate Viewer, which you can also access from the Certificates 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.
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 is established 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 CA to 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 store contains the certificates of CAs that you or your domain administrator consider trustworthy and that Windows can use as a trust anchor for validating other certificates. The CA certificates of CAs installed on machines that are part of your AD infrastructure are automatically added to client machines' certificate stores through the Group Policy Object (GPO) update mechanism. If the CA certificate of the CA that issued the LDAPS certificate isn't present in the Trusted Root CA Certification Authorities container, you can manually import it using the Import option that's available from this container'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's certificate store. To check whether the DC certificate store holds a matching private key for a given LDAPS certificate, you can use the General tab of the 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 text You have a private key that corresponds to this certificate.
The private key should also not have strong private key protection enabled -- which means that Windows shouldn't prompt for a password each time the key 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 domain servers or DCs. However, this certainly isn't the most secure or most flexible option for providing certificate services to your users. Most organizations that want to bring a higher level of security and flexibility to their certificate services opt for a multi-tier Windows CA hierarchy that 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 to follow my instructions in this section for creating LDAPS certificates for your DCs. LDAPS certificates can also be issued by a non-Microsoft CA. (For detailed instructions, see the Microsoft article "How to enable LDAP over SSL with a third-party certification authority" at support.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 LDAPS certificates in AD, then enable this custom template on all your issuing CAs, and finally manually enroll all DCs for an LDAPS certificate that's based on 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 Certificate Templates, Add, OK.) In the Certificate Templates snap-in, expand Certificate Templates, right-click a template in the right-hand pane (e.g., the Kerberos Authentication template), and select Duplicate Template. Note that you can also duplicate another template (e.g., the Domain Controller Authentication 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 of the new template appear, as Figure 4 shows.
You should pay special attention to the following properties of the new template:
- On the General tab: Enter a template display name (e.g., "LDAPS"), set the validity and renewal periods (ensure that they're set according to your organization's certificate policy), and specify whether you want to publish the certificate in AD (select the Publish certificate in Active Directory check box).
- On the Request Handling tab: Ensure that the minimum key size is set according to your organization's certificate policy, and select whether the private key must be marked as exportable (select the Allow private key to be exported check box). You must mark the private key as exportable if you want to import the certificate into the AD NTDS certificate store, as I explain later.
- On the Subject Name tab: Ensure that the DNS name and Service Principal Name (SPN) are selected.
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 Templates container. To do so, start the MMC Certification Authority snap-in on one of your enterprise CAs, expand the CA container, right-click the Certificate Templates container, and select New, Certificate Template to Issue. In the Enable Certificate Templates dialog box, which Figure 5 shows, you can then select the name of the newly created template. To close the dialog box, click OK.
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 all affected 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 the LDAPS 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 Details section.
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 a good option if your DCs have multiple certificates with the Server Authentication OID in their Local Machines Personal store. In that case, it's difficult to predict which certificate AD will pick for LDAPS authentication. The new Windows Server 2008 logic makes AD first look for server authentication certificates in the AD certificate store. Therefore, this new feature can force AD to use the server authentication certificate that you generated using your custom LDAPS template. For more information about how to add the certificate to the AD service's Personal certificate store (also referred 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. On Windows 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 the FQDN 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 check box is cleared, and that the SSL check box is selected; then click OK. If LDAPS is configured properly, the LDP command output should display Host supports SSL, as in Figure 6.
Click the Connection menu option again, select Bind, and click OK. If LDAPS is configured properly, the LDP command output should display the username and 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 is relatively easy. In this article, I explained how to enable LDAPS by installing a properly formatted certificate on your DCs. With LDAPS, you can lock down an important AD authentication and directory access gate. The two other main AD authentication protocols -- Kerberos and NTLM -- both leverage remote procedure calls (RPCs) for transport and have proper security and encryption mechanisms that are enabled by default.