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 InfrastructureThe 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.
PrerequisitesYou'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 RequestTo 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 Administrator@test.domain.com):
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 RequestTo 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 -signAfter 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.cerNow 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 ChangeOnce 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 -w mypass \
-b "dc=example,dc=com" -s base "objectclass=*"
