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.
Requirements for an LDAPS certificate
To enable LDAPS, you must install a certificate that meets the
- The LDAPS certificate is located in the Local Computer's
Personal certificate store (programmatically known as the computer's MY
- A private key that matches the certificate is present in
the Local Computer's store and is correctly associated with the certificate.
The private key must not have strong private key protection enabled.
- The Enhanced Key Usage extension includes the Server
Authentication (220.127.116.11.18.104.22.168.1) object identifier (also known as
- The Active Directory fully qualified domain name of the
domain controller (for example, DC01.DOMAIN.COM) must appear in one of the
- The Common Name (CN) in the Subject field.
- DNS entry in the Subject Alternative Name
- The certificate was issued by a CA that the domain
controller and the LDAPS clients trust. Trust is established by configuring the
clients and the server to trust the root CA to which the issuing CA chains.
- You must use the Schannel cryptographic service provider (CSP) to generate the key.
For more information about establishing trust for certificates,
see the "Policies to establish trust of root certification authorities" topic
in Windows 2000 Server Help.
Creating the certificate request
Any utility or application that creates a valid PKCS #10 request can be used to form the SSL certificate request. Use Certreq to form the request.Note
The commands that are used in this article rely on the 2003 version of Certreq. In order to use the steps in this article on a Windows 2000 server, copy certreq.exe and certcli.dll from a Windows 2003 server into a temporary directory on the Windows 2000 server.
Certreq.exe requires a text instruction file to generate an
appropriate X.509 certificate request for a domain controller. You can create
this file by using your preferred ASCII text editor. Save the file as an .inf
file to any folder on your hard drive.
To request a Server
Authentication certificate that is suitable for LDAPS, follow these steps:
- Create the .inf file. Following is an example .inf
file that can be used to create the certificate request.
;----------------- request.inf -----------------
Cut and paste the sample file into a new text file named Request.inf.
Provide the fully qualified DNS name of the domain controller in the
Subject = "CN=<DC fqdn>" ; replace with the FQDN of the DC
KeySpec = 1
KeyLength = 1024
; Can be 1024, 2048, 4096, 8192, or 16384.
; Larger key sizes are more secure, but have
; a greater impact on performance.
Exportable = TRUE
MachineKeySet = TRUE
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0
OID=22.214.171.124.126.96.36.199.1 ; this is for Server Authentication
Note Some third-party certification
authorities may require additional information in the Subject parameter.
information includes an e-mail address (E), organizational unit (OU),
organization (O), locality or city (L), state or province (S), and country or
region (C). You can append this information to the Subject name (CN)
the Request.inf file. For example: Subject="Efirstname.lastname@example.org, CN=<DC
fqdn>, OU=Servers, O=Contoso, L=Redmond, S=Washington, C=US."
- Create the request file. To do this, type the following
command at the command prompt, and then press ENTER:
certreq -new request.inf request.reqA new file called Request.req is created. This is the
base64-encoded request file.
- Submit the request to a CA. You can submit the request to a
Microsoft CA or to a third-party CA.
- Retrieve the certificate that is issued, and then save the
certificate as Certnew.cer in the same folder as the request file. To do this,
follow these steps:
Note The saved certificate must be encoded as base64. Some third-party
CAs return the issued certificate to the requestor as base64-encoded text in an
- Create a new file called Certnew.cer.
- Open the file in Notepad, paste the encoded certificate
into the file, and then save the file.
- Accept the issued certificate. To do this, type the
following command at the command prompt, and then press ENTER:
certreq -accept certnew.cer
- Verify that the certificate is installed in the computer's
Personal store. To do this, follow these steps:
A new certificate should exist in the Personal store. In the
Certificate Properties dialog box, the intended purpose
displayed is Server Authentication. This certificate is issued
to the computer's fully qualified host name.
- Start Microsoft Management Console (MMC).
- Add the Certificates snap-in that manages certificates
on the local computer.
- Expand Certificates (Local Computer),
expand Personal, and then expand
- Restart the domain controller.
For more information about creating the certificate request,
see the following Advanced Certificate Enrollment and Management white paper.
To view this white paper, visit the following Microsoft Web site:
Verifying an LDAPS connection
After a certificate is installed, follow these steps to verify
that LDAPS is enabled:
- Start the Active Directory Administration Tool
Note This program is installed in the Windows 2000 Support
- On the Connection menu, click
- Type the name of the domain controller to which you want to
- Type 636 as the port
- Click OK.
should print in the right pane, indicating a successful connection.
- Start TLS extended request
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. Windows 2000 does not support the Start TLS extended-request
- Multiple SSL certificates
Schannel, the Microsoft SSL provider, selects the first
valid certificate that it finds in the local computer store. If there are
multiple valid certificates available in the local computer store, Schannel may
not select the correct certificate.
- Pre-SP3 SSL certificate caching issue
If an existing LDAPS certificate is replaced with another
certificate, either through a renewal process or because the issuing CA has
changed, the server must be restarted for Schannel to use the new certificate.
The SSL provider in Windows 2000 caches the LDAPS certificate and does not
detect the change until the domain controller is restarted. This has been
corrected in Service Pack 3 for Windows 2000.
Windows Server 2008 improvements
The original recommendation in this article was to put certificates in the Local Machine's Personal store. Although this option is supported, you can also put certificates in the NTDS Service's Personal certificate store on Windows Server 2008 and on later versions of Active Directory Domain Services (AD DS). For more information about how to add the certificate to the NTDS service's Personal certificate store, visit the following Microsoft TechNet Web site:
AD DS preferentially looks for certificates in this store over the Local Machine's store. This makes it easier to configure AD DS to use the certificate that you want it to use. This is because there might be multiple certificates in the Local Machines Personal store, and it can be difficult to predict which one is selected.
AD DS detects when a new certificate is dropped into its certificate store and then triggers an SSL certificate update without having to restart AD DS or restart the domain controller.
A new rootDse operation that is named renewServerCertificate
can be used to manually trigger AD DS to update its SSL certificates without having to restart AD DS or restart the domain controller. This attribute can be updated using adsiedit.msc
, or by importing the change in LDAP Directory Interchange Format (LDIF) using ldifde.exe
. For more information on using LDIF to update this attribute, visit the following Microsoft MSDN Web site:
Finally, if a Windows Server 2008 or a later version domain controller finds multiple certificates in its store, it automatically selects the certificate whose expiration date is furthest in the future. Then, if your current certificate is approaching its expiration date, you can drop the replacement certificate in the store, and AD DS automatically switches to use it.
All these work for Windows Server 2008 AD DS and for 2008 Active Directory Lightweight Directory Services (AD LDS). For AD LDS, put certificates into the Personal certificate store for the service that corresponds to the AD LDS instance instead of for the NTDS service.
Article ID: 321051 - Last Review: April 14, 2011 - Revision: 20.1
- Windows Server 2008 Standard
- Windows Server 2008 Datacenter
- Windows Server 2008 Enterprise
- Windows Server 2008 Standard without Hyper-V
- Windows Server 2008 Datacenter without Hyper-V
- Windows Server 2008 Enterprise without Hyper-V
- Microsoft Windows Server 2003, Standard Edition (32-bit x86)
- Microsoft Windows Server 2003, Datacenter Edition (32-bit x86)
- Microsoft Windows Server 2003, Enterprise Edition (32-bit x86)
- Microsoft Windows 2000 Server
- Microsoft Windows 2000 Advanced Server
|kbproductlink kbinfo KB321051|