Enabling LDAPS on Active Directory Domain Controllers

This document describes 2 approaches on how to set-up domain controllers in AD to listen for SSL-wrapped LDAP connections on port 636; One using the UW-IST certificate authority, the other using Active Directory's built-in certificate services. It also describes what is needed on the client side (in this case, openssl on Linux), to talk to the LDAPS service on a domain controller. This document assumes you are using Windows Server 2003, however I followed instructions from Microsoft for Windows 2000.

Using the UW/IST Certificate Authority

References

http://support.microsoft.com/default.aspx?scid=kb;en-us;321051

On each Domain Controller

Configure the Domain Controller to trust the UW/IST Certificate Authority

• In IE, go to the URL http://ist.uwaterloo.ca/security/IST-CA/cacert.der
• Save the certificate to the hard disk. The file will be named cacert.cer
• Run mmc and add the Certificates snap-in (Computer Account/Local Computer)
• Navigate to Trusted Root Certification Authorities
• Right-click on Certificates, and select All Tasks->Import
• Import the cacert.cer file that you saved previously
• The UW/IST Certificate Authority should now show-up in the list

Generate a certificate request

• First you need to create a request.inf file that gets used in the certificate request:

[Version]
Signature="$Windows NT$"

[NewRequest] 
Subject = "CN=dc-hostname.subdomain.uwaterloo.ca"
; 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

[EnhancedKeyUsageExtension] 
OID=1.3.6.1.5.5.7.3.1
; this is for Server Authentication

[RequestAttributes]
CertificateTemplate=DomainController

• Next, run certreq -new request.inf request.req at the command line.
• Take the request.req file, and mail it to ist-ca@ist.uwaterloo.ca.

Install/Accept the issued certificate

• IST will send you a base64 encoded file
• Save the file as certnew.cer.
• Run the command certreq -accept certnew.cer
• Run mmc with the Certificates snap-in (Computer Account/Local Computer)
• Navigate to Personal->Certificates and you should see the installed certificate to your domain controller issued by the UW/IST CA.

On the Linux Client

• Get the UW/IST CA certificate by running:

wget http://ist.uwaterloo.ca/security/IST-CA/cacert.der

• Run openssl x509 -inform DER -outform PEM -in cacert.der -out cacert.pem
• Edit either the system ldap.conf or your .ldaprc file and set the following:

TLS_CACERT full-path-to-cacert.pem

• Test by running something like

ldapsearch -L -Hldaps://junius.dragonfly.cs.uwaterloo.ca/ -x -W -D "cn=YOUR NAME HERE,CN=Users,dc=dragonfly,dc=cs,dc=uwaterloo,dc=ca" \ 
  -b "dc=dragonfly,dc=cs,dc=uwaterloo,dc=ca" "cn=*" cn

Using AD's Built-in Certification Services

Below are the steps I followed to first get LDAPS working in AD.

On the AD Domain Controller Side

You need to be an Enterprise Administrator to do this stuff. I did this in an AD forest containing a single domain with a single domain controller, so YMMV.

Set-up a Certificate Authority (on a DC in the forest root?)

• Control Panel -> Add/Remove Programs -> Add/Remove Windows Components
• Select Certifificate Services
• Of course you're not going to rename your AD domain, are you crazy?
• Click-click through the wizard
• Select Enterprise root CA
• I named mine "EnterpriseCA", creative eh?
• I didn't bother storing in a shared area

Detailed instructions here:

http://www.microsoft.com/windows2000/techinfo/planning/security/casetupsteps.asp

Verify and Export the root CA certificate

Now that that root CA is created, you should make sure it's there and export it for future use (using openssl on Linux)

• From the Start menu, run Programs -> Administrative Tools -> Certification Authority
• In the left pane, I have my "EnterpriseCA" there. Right click on it.
• Select Properties.
• Click on View Certificate.
• Select the Details pane
• Click on Copy to File
• Next
• Choose "Base64 encoded file", then Next
• name the file (mine is named trustedCA.pem)
• Finish the wizard, exit from the utility.
• Copy the binary der file your linux client for later use.

Arrange for domain controllers to request certificates

Once your certification authority is up, you need to configure the domain controllers to request certificates (automatically). The whole request-issue process is automatic once you make a simple edit to the default domain GPO. This must be done in each domain where certificates are to be distributed. Once the domain controllers have a certificate, LDAPS should start working. There might be other ways of doing this, but this is the most straight forward to me:

• Startup the Active Directory Users and Computers utitlity
• Right-click on the domain, and select Properties
• Select the Group Policy Tab
• Edit the default domain policy
• Navigate to Computer Configuration -> Windows Settings -> Security Settings -> Public Key Policies -> Automatic Certificate Request Settings
• Right click and select New -> Automatic Certificate Request
• You want one for a domain controller

When the GPO gets refreshed on the domain controller, you can verify that it's there by running mmc with the Certificates snap-in (Computer account). It should be there under Certificates -> Personal. Another way to verify is to run the Certification Authority utility (aka mmc with the snap-in) to see that the DC certificates are found under Issued Certificates.

Grant Domain Controllers and Domain Admins the Right to Request Certificates

• Membership in the CERTSVC_DCOM_ACCESS group for the domain where new CA is located.
  • This group is created when the new CA is created should it not already exist.
• Grant Request Certificates rights for the new CA in the Certificate Authority snap-in.
  • Look under Security tab for new CA Properties.

Grant the CA Server the Right To Distribute Certificates to Other Forest Domains

• CA server must be a member of Cert Publishers group in each domain.

And One More Thing: DCOM Security Configuration

You may need to run the following command on the CA server:
certutil -setreg SetupStatus -SETUP_DCOM_SECURITY_UPDATED_FLAG

On the Linux or Solaris Client

Test the SSL connection by running something like:

openssl s_client -CAfile trustedCA.pem -connect junius:636

To tell the openldap client to make use of the trustedCA.pem file, stick the directive

TLS_CACERT full-path-to-trustedCA.pem

in your ldap.conf or user's .ldaprc file.

The final test, is to fire-up Ethereal, and run a query like this:

ldapsearch -L -Hldaps://junius.dragonfly.cs.uwaterloo.ca/ -x -W -D "cn=YOUR NAME HERE,CN=Users,dc=dragonfly,dc=cs,dc=uwaterloo,dc=ca" \ 
  -b "dc=dragonfly,dc=cs,dc=uwaterloo,dc=ca" "cn=*" cn

The result was what I expected, and all Ethereal saw was SSL!

-- JasonTestart - 24 Nov 2005 -- ClaytonTucker - 24 Jan 2008

http://enterprise.linux.com/article.pl?sid=05/10/18/1732231&from=rss has info on doing LDAPS on a Linux host using a self-signed CA.