Configuring Secure LDAP using a 3rd party Certificate Authority

Some of the documentation that is available out there for configuring Secure LDAP on a Windows server is rather sketchy at best, or in some cases, it’s just really old and doesn’t necessarily apply to newer Microsoft Server operating systems.  

The following information below can be used on a Windows 2012 R2 server for configuring Secure LDAP using a 3rd party Certificate Authority (in this particular case, we are using a well known 3rd party Certificate Authority, Thawte, for the certificate).

LDAP with SSL security should be used whenever possible to encrypt the communication channel between your LDAP server and whatever device/vendor is requesting the information.  Regular LDAP, by default, isn’t secured and utilizes port 389.  Secure LDAP is secured/encrypted and utilizes port 636.  Using LDAP with SSL security is especially important when the information requested is being sent over the Internet, in an effort to help protect your Active Directory data and user account information.  Please note that all the steps provided below will be performed on the designated Domain Controller that will be used for providing future Secure LDAP lookups.

Generating the certificate for configuring secure LDAP.

Open Notepad and paste the following information from below (including the leading and trailing header information)

;----------------- request.inf -----------------

[Version]

Signature="$Windows NT$"

[NewRequest]

Subject = "C=YY, S=XX, L=mycity, O=myorg, CN=secureldap.mydomain.com"
KeySpec = 1
KeyLength = 2048
Exportable = TRUE
MachineKeySet = TRUE
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0

[EnhancedKeyUsageExtension]

OID=1.3.6.1.5.5.7.3.1 ; this is for Server Authentication

;-----------------------------------------------

Be sure to make the necessary adjustments to the 2-digit Country Code (C), 2-digit State code (S), Location name (L), organizational name (O), and FQDN name (CN) and save the Notepad file as c:\temp\request.inf

Now it’s time to create the actual certificate request file that we will send on to Thawte, which is the 3rd party Certificate Authority we are using for creating the certificate to use with Secure LDAP. Enter the following command at a command prompt: certreq -new c:\temp\request.inf c:\temp\cert-request.txt

Navigate to www.thawte.com and purchase a SSL123 certificate (3 year certificates are generally preferred to minimize time spent doing future renewals).

Once your SSL123 certificate has been purchased, submit your certificate request (c:\temp\cert-request.txt) to Thawte. This is usually done by copying/pasting the contents of the cert-request.txt file from Notepad to the 3rd party Certificate Authority’s website during the submit process.

At this time, your 3rd party Certificate Authority will generate the certificate for you (assuming approval for the SSL certificate has been granted by your domain’s administrative/technical contact).

Accepting/Importing the certificate for Secure LDAP

Retrieve the newly created certificate file from Thawte (or whatever 3rd party CA you are using).

Open the downloaded PKCS#7 certificate (it may be in a .zip archive) in Notepad and re-save it as c:\temp\newcert.cer

Now you have to accept that certificate using the certreq command. Enter the following command at a command prompt: certreq -accept c:temp\newcert.cer
Verify the new secureldap.mydomain.com certificate is properly installed in the Personal Store of your server.

•  Open the MMC console
•  Add in the Certificates snap-in to manage Local certificates
•  Expand the Personal store

Make sure the Thawte certificate is installed and shows Server Authentication

(Please note: If you are using any server based certificates with your Network Policy Server (NPS) for purposes of 802.1X authentication, please check whether any of those previously created NPS policies automatically switched from the previously selected server certificate to the new secureldap.mydomain.com certificate you just installed. If so, please re-adjust accordingly or your NPS policies may end up broken!)

Verification of Secure LDAP process

Verify that you created an “A record” entry on your local DNS server for secureldap.mydomain.com (or the specific FQDN used on your certificate request).

At this time you will need to reboot your server where the certificate was installed. Once rebooted, you should be able to open a command prompt and issue a ldp.exe command. Verify Secure LDAP connectivity over port 636 by selecting Connection -> Connect and entering the FQDN (secureldap.mydomain.com) that you used on your certificate. The port should be 636, and make sure the SSL checkbox is Enabled.

Failure to reboot your Domain Controller will likely result in Secure LDAP not working properly during testing of the ldp.exe command. If a popup message appears saying “Cannot open connection” followed by “Error : Fail to connect to secureldap.mydomain.com” in the main ldp.exe Window, you probably haven’t rebooted your Domain Controller as expected. Normally SSL certificates do NOt require a reboot, but this will as the certificate is a Server Authentication type for the Enhanced Key Usage parameter, which is slightly different than usual.