title: SSL Enabling Active Directory link: https://onemoretech.wordpress.com/2007/06/12/ssl-enabling-active-directory/ author: lembobro description: post_id: 688 created: 2007/06/12 17:48:00 created_gmt: 2007/06/12 17:48:00 comment_status: open post_name: ssl-enabling-active-directory status: publish post_type: post

SSL Enabling Active Directory

This is an article from my old personal site.

There are several ways to do this. The easiest is to enable an Enterprise CA and let auto-enrollment propagate SSL certificates to all domain controllers (DC’s). This is Microsoft’s preference. Most Active Directory (AD) administrators are loathe to go along with this. First, because they believe SSL is an evil virus created by Netscape, and second, because they’re afraid to alter the shipping configuration of AD in any way. From their point of view AD is already complicated enough without mucking things up with some Internet standard protocol functionality. As a result of this, most real-world LDAP admins compromise on getting at least one DC enabled for SSL. The most non-intrusive way to do this is to use a 3rd party certificate authority (CA) to sign an appropriately formed certificate request. The resulting certificate is then imported, along with the CA’s own certificate, into the target DC’s local certificate store.

Official Documentation

How to enable LDAP over SSL with a third-party certification authority

Best Practices for Implementation of a Microsoft Windows Server 2003 Public Key Infrastructure

The first article listed above is the official “how to” from Microsoft on using a 3rd party CA to SSL enable AD. It is written by someone who’s obviously done this many times, and because of that is not a very good beginner’s guide. Reading through all of the articles linked in the second reference will give you most of what you need. Still, I found that there was no substitute for building my own test AD domain controller and diving right in to the deep end of the pool. Your mileage may vary (please keep in mind that I first “cut my teeth” on Windows NT 3.51 in an enterprise environment over 10 years ago, and had an MCSE number in the low thousands). Even so, on my first go around, I installed Windows 2003 in a VMware Server virtual machine. Happiness is being able to roll back to the last snapshot when bad things happen.

Prerequisites

You’ll need a working AD environment, in which all services (especially DNS) are properly configured. You’ll also need a 3rd party CA. In my case this was an OpenSSL CA I’d set up on a Linux box.

Generating the Certificate Request

To do this you need to follow the instructions set out in the first article cited above exactly, but for one major bit of misinformation.

In describing the request.inf file used with the certreq utility to generate the request, the article adds a caveat to the effect that some CA’s might require additional elements in the “Subject” line — such as e-mail address, organization name, etc. Adding these elements, however, will guarantee that you won’t be able to successfully import the signed certificate. The reason? Because the local computer certificate store (a/k/a the “MY” certificate store) will not have any of these elements and so the distinguished name will not match that of the machine.

Here is the actual request.inf I used to generate my request. Note that the values I used for the different elements should be changed to match your environment:

;----------------- request.inf ----------------- [Version] Signature="$Windows NT$ [NewRequest] Subject = "CN=dc01.test.mydomain.com" KeySpec = 1 KeyLength = 1024 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

Once you have your request.inf file, you must run the following command to generate the request. Do this while logged in as the machine Administrator (cn=Administrator, cn=Users, dc=test, dc=domain,dc=com or [email protected]):

certreq -new request.inf newreq.pem

The resulting request file, newreq.pem can now be submitted to a 3rd party CA for signing.

Signing the Request

To sign the certificate request using OpenSSL, you need to transfer the file to where your “demoCA” has been set up. In my case this is at /export/CA on a CentOS Linux box. I like the CA script for this kind of work. It expects the request file to be named newreq.pem by default. As root, I use the following command after changing to /export/CA and making sure that newreq.pem is located there:

/usr/share/ssl/misc/CA -sign

After supplying the CA’s secret (password), I accept the defaults and the new signed certificate, by default named newcert.pem is created alongside the newreq.pem file. I usually rename the certificate file to something more unique, in this case dc01.cer.

Importing the Certificate(s)

A careful reader will notice I add a “(s)” to the end of this section title. That is because to make this all work you need to import into Active Directory not only your newly signed certificate, but also the certificate for the CA that signed it. The procedure for importing these certificates differs. Make sure to do it exactly as described. You can use the Certificates Snap-in to import the server certificate, but it will not report some kinds of errors. To be safe, use the command line tool. First transfer the certificate to the DC filesystem, and then, while logged in as Administrator, run the following command:

certreq -accept dc01.cer

Now add the Certificates (not the Certification Authority) Snap-in to your Administrative Tools menu (run mmc, add the snap-in and save as a new console object), being careful to specify that it will manage certificates for the “Computer Account”. Use the snap-in to verify that the new server certificate exists under Certificates/Personal/Certificates. At this point the new certificate will be considered suspect, since the system will not recognize the signing CA. To cure this, transfer the CA’s public certificate (without the key) to the DC filesystem and import it into the “Third Party Root Certificate Authorities” container using the Certificates Snap-in.

Effect and Verify the Change

Once the above steps are completed, reboot the DC system to make the change effective and enable the LDAPS (LDAP over SSL) listener on the DC. To verify that it is now working, use the ldp.exe from the Windows Support Tools to connect to the local AD instance, by checking off “SSL” and changing the port number to 636.

You can also test the SSL connection using the ldapsearch utility. Before doing this, copy the CA’s certificate to the local filesystem (I use a system-wide location of /etc/ssl, you could also use the default /etc/openldap/cacerts) and configure ldap.conf to include the full path to this cert in the TLS_CACERT directive (e.g. TLS_CACERT /etc/ssl/myca.pem). Once you’ve disposed of these preliminaries, try the following command:

` ldapsearch -x -H ldaps://dc01.test.mydomain.com
-D "cn=administrator,cn=users,dc=test,dc=mydomain,dc=com

Copyright 2004-2019 Phil Lembo