Configure LDAPs an Active Directory Domain Controller for LDAP over SSL Connections

I recently had to configure a Directory Sync feature between a cloud based SPAM filtering service and a client’s Active Directory and came across the option of either syncing via regular LDAP port 389 (unecrypted) or LDAPS over SSL port 636.  While the service account the cloud based SPAM filtering service only requires a regular user account with no administrative permissions, I didn’t feel too comfortable with having the service sync via regular LDAP 389 over the internet with the login credentials being sent in clear text.  Yes, I’ve been told that we can lock the traffic down by source IP but I’m sure we all know how that isn’t exactly bulletproof.  So from here, I began configuring the domain controllers with an internal Microsoft Certificate Authority issued certificate to encrypt the traffic.  As I browsed through some old notes I had as I haven’t configured this in a while, I realized that I haven’t written a blog post about it so thought it would be a good idea to do so now so I have something to reference to in the future.  Note that I am configuring all of this on a Windows Server 2012 domain controller and certificate authority.  Both roles are installed onto the same server but I do not recommend doing so as I never liked installing CA services on a DC but this environment I configured this on recently only had 2 servers.

Step #1 – Create a new certificate template for LDAPS

Begin by creating a new certificate template on your internal Microsoft Certificate Authority to issue the certificate that will be used for LDAPS.  Launch the Certificate Authority management console, right-click on the Certificate Templates node and client on Manage:

In the Certificate Templates window, locate the Kerberos Authentication template, right click on it and click on Duplicate Template:

 

Click on the General tab and change the following fields:

Template display name: <Enter a name for the certificate>

Validity period: <Enter the number of years you want an issued certificate to be valid for>

Publish certificate in Active Directory: <I usually check this for convenience purposes so the certificate is displayed when a domain joined member is requesting a certificate>

In the Cryptography tab, enter a value for the Minimum key size. I usually enter at least 2048 as that seems to be the minimum size for public CAs these days and is a minimum requirement for Lync 2010/2013 deployments.

Navigate to the Subject Name tab and configure the following:

Build from this Active Directory information: Check

Subject name format: None

DNS Name: Check

Service principal name (SPN): Check

Lastly, navigate to the Request Handling tab and check the Allow private key to be exported option.  While this is optional, I usually enable it in case you ever need to export and reimport the certificate:

Click OK to create the new template and ensure it is now listed in the Certificates Templates:

Step #2 – Issue the new Certificate Template

With the new template created, navigate back to the Certificate Authority management console, right click on Certificate Templates, select New and click on Certificate Template to Issue:

Select the new certificate that was created and click OK:

Ensure that the new certificate is now listed in the Certificate Templates:

Step #3 – Request certificate for LDAPS over SSL on a Domain Controller

With the certificate created and published, proceed by navigating to a domain controller, open MMC and add the Certificates snap-in under the Computer account context:

Navigate to Certificates (Local Computer) –> Personal –> Certificates then right click on Certificates –> All Tasks –> Request New Certificate…:

Follow through the wizard:

Select Active Directory Enrollment Policy:

Check the new certificate template that was created:

Clicking on the Details button would show the following:

Click Enroll to request and retrieve the certificate:

Note that a new certificate should now be displayed with the following Intended Purposes properties:

• KDC Authentication
• Smart Card Logon
• Server Authentication
• Client Authentication

 

——————————————————————————————————————————————————————–

**Note I’ve had a few colleagues ask me why they can’t use the default domain controller policy as shown here:

… and my response is that I was never able to get it to work even though most articles appear to suggest the Server Authentication is required for the Enhanced Key Usage properties.

——————————————————————————————————————————————————————–

With the new certificate on the domain controller, hop onto another member server, launch LDP and try connecting to the DC via port 636 with SSL checked:

Hitting the OK button should show that you are now able to connect:

Repeat Step #3 for other domain controllers as necessary.

Hope this helps anyone looking for instructions on how to set this up.