Getting Microsoft’s Active Directory to communicate with anything not built by Microsoft can be a real challenge. This guide will tell you how to configure and use the OpenLDAP tools, such as ldapsearch, to communicate with an Active Directory (AD) server over Secure Sockets Layer (SSL). It does not address performing any kind of synchronization with OpenLDAP’s server (slapd). Once you have gotten this set up properly, though, you can use the resulting configuration to get things like pam_ldap and nss_ldap (in our CNS product) to work with Active Directory.

Process Overview

In order to set up basic SSL communication it is only necessary to have a copy of the CA certificate on each client that wants to communicate with the server.

In this guide I will show you how to perform the following tasks:

1. Set up the Certificate Authority on the AD server.
2. Export the AD server’s CA certificate.
3. Convert the certificate to PEM format.
4. Install the certificate where needed.
5. Test using ldapsearch command.
6. Troubleshooting

The steps below assume that you have a working OpenLDAP installation on a supported platform such as Linux, SunOS, HP-UX, or AIX. If you do not have such an installation, you are welcome to download one of our CDS Silver OpenLDAP distributions from our website:

http://www.symas.com

.

Step-by-Step Guide[/b]

1. Enable Secure Socket Layer over LDAP (ldaps) communication on the Windows Domain Controller:

Install an Enterprise Certificate Authority on a Windows server that has Active Directory enabled. All Domain Controllers in the forest will automatically enroll for and install the appropriate certificate. I did it this way on my Windows 2000 server, and the process is similar for most other Windows servers:

Choose Start->Settings->Add/Remove Software
Select the Add or Remove Windows Components icon
Check the box marked "Windows Certification Authority"
Click OK
Follow the instructions and answer the questions to complete the setup.


Once you have completed the setup, Active Directory begins to listen on the LDAP over SSL port, port 636.

2. Export a copy of the server CA certificate from the AD server:

Open the CA application (actually an MMC snapin) (Programs ->Administrative Tools->Certification Authority).
Right-click on the CA and choose “Properties” from the context pane. This opens the property page for the CA.

Click on the “View Certificate” button to bring up the Certificate page. Click on the “Details” tab and click on the “Copy to File…” button. This brings up the Certificate Export Wizard.

Click the “Next” button. to switch to the Export File Format page of the Export Wizard. Select the “Base-64 Encoded X.509 (.cer) format”.

Click the “Next” button and choose a file name for the exported certificate. It is a good idea to use the server name with the .cer extension. As an example, for a server named “tungsten”, the I would enter “tungsten.cer”. In order to make sure you know where the file actually ends up, I recommend using the “Browse” button and choosing the name and location of the file using the supplied “Save As” dialog.

Click the “Next” button, and then click the “Finish” button. This creates the exported copy of the server certificate.

3. Convert the certificate from .cer format to .pem format:

Using FTP, or some other file copying application, copy the server certificate file you just created over to a system on which you have installed the OpenSSL Certificate Authority software. Symas supplies this software in the package called “cpksca”.

Log into the system where you copied the certificate and run the following command:

/opt/symas/bin/openssl x509 -in <AD certificate name> -out <OpenLDAP certificate name>

For example, using our example for the “tungsten” server:

/opt/symas/bin/openssl x509 -in tungsten.cer -out tungsten.pem

This creates the .pem-formatted certificate that OpenLDAP needs.

4. Install the certificate:

Place the .pem certificate file on each of the systems that is going to communicate with Active Directory. If you are using CDS, we recommend putting them in the directory “/opt/symas/ssl/certs”. Since the contents of this file are not sensitive, but the origin of the file is, the permissions for it should be world-readable and root-writable.

Edit the “ldap.conf” file and add the following line to the file:

TLS_CACERT <complete pathname of LDAP certificate name>


For example, in CDS the “ldap.conf” file is located in the directory “/opt/symas/etc/openldap”, and using the “tungsten” server example, the line would read as follows:

TLS_CACERT /opt/symas/ssl/certs/tungsten.pem

5. Test the connection:

It should now be possible to perform an ldapsearch to Active Directory from the system where you installed the certificate. Running the following command should demonstrate this:

ldapsearch -x -H ldaps://<AD DNS name>/ -D <Administrator's DN> -W -b <search base>


In our “tungsten” example, this would like:

/opt/symas/bin/ldapsearch -x -H ldaps://tungsten.symas.net/ -D cn=administrator,cn=users,dc=tungsten,dc=net -W -b dc=tungsten,dc=net


If you got everything else right, then you should get back a complete listing of the objects in the AD directory tree, each entry having the general form of the following example:

# fredm, Users, symas.net
dn: CN=fredm,CN=Users,DC=symas,DC=net
memberOf: CN=Users,CN=Builtin,DC=symas,DC=net
accountExpires: 0
badPasswordTime: 0
badPwdCount: 0
codePage: 0
cn: matth
countryCode: 0
description: A Nice Guy
displayName: Fred Mertz
instanceType: 4
lastLogoff: 0
lastLogon: 127572210726923952
logonCount: 46
logonHours:: ////////////////////////////
distinguishedName: CN=fredm,CN=Users,DC=symas,DC=net
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=symas,DC=net
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
objectGUID:: 45SM/RbomkW93qPmSY3RuA==
objectSid:: AQUAAAAAAAUVAAAAofQEYhbA6jL4n7R06wMAAA==
primaryGroupID: 513
pwdLastSet: 126950288196235312
name: matth
sAMAccountName: fredm
sAMAccountType: 805306368
userAccountControl: 66048
uSNChanged: 1415
uSNCreated: 1415
whenChanged: 20050404220535.0Z
whenCreated: 20050404220535.0Z


Congratulations! You’ve now gotten your system connected to Active Directory! You can now proceed to installing and configuring other products, like CNS, Symas’s implementation of pam_ldap and nss_ldap.

Troubleshooting:

The most common problem that crops up when setting up SSL connections is that ldapsearch displays the message “Can’t contact server (81)”. Most often, this indicates a problem with the certificate. The best way to approach this is to first test the SSL connection itself,
and then move on to the LDAP connection.

Using the OpenSSL “s_client” command to troubleshoot the SSL connection:

The openssl “s_client” command is very useful in troubleshooting SSL commands. While it won’t perform any LDAP operations, it does go through the complete SSL session establishment process, so you can be sure that once the command completes successfully, that the SSL portion of your setup is correct.

Although the command’s output may seem cryptic at first, it is fairly easy to figure out what’s going on through careful examination of the output.

Here’s the invocation to use for testing an SSL connection to an AD server:

openssl s_client -connect <dns name of AD server:port> -CAfile <path to CA cert>


using our “tungsten example, here is a sample invocation of the s_client command, along with output from a successful connection:

/opt/symas/bin/openssl s_client -connect tungsten.symas.net:636 -CAfile /opt/symas/ssl/certs/tungsten.pem

CONNECTED(00000003)
depth=1 /emailAddress=info@symas.com/C=US/ST=California/L=Tarzana/O=Symas Corporation/OU=Development/CN=Symas Keymaster
verify return:1
depth=0 /CN=lead.symas.net
verify return:1
—
Certificate chain
0 s:/CN=tungsten.symas.net
i:/emailAddress=info@symas.com/C=US/ST=California/L=Tarzana/O=Symas Corporation/OU=Development/CN=Symas Keymaster
—
Server certificate
—–BEGIN CERTIFICATE—–
KoZIhvcNAQEFBQADQQCf2JPFD1SYRyXu8oC56MbQol7kQOph5eB2ZZGbbgx95ZXP
[ lots of base 64 encoded certificate stuff]
F2K0wHhfrAYXUDThBZ2LeRq585rDGBikPbHRq1IF
—–END CERTIFICATE—–
subject=/CN=lead.symas.net
issuer=/emailAddress=info@symas.com/C=US/ST=California/L=Tarzana/O=Symas Corporation/OU=Development/CN=Symas Keymaster
—
Acceptable client certificate CA names
/C=US/O=VeriSign, Inc./OU=Class 1 Public Primary Certification Authority – G2/OU=(c) 1998 VeriSign, Inc. – For authorized use only/OU=VeriSign Trust Network
/C=US/O=VeriSign, Inc./OU=Class 4 Public Primary Certification Authority – G2/OU=(c) 1998 VeriSign, Inc. – For authorized use only/OU=VeriSign Trust Network
/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting/OU=Certification Services Division/CN=Thawte Personal Freemail CA/emailAddress=personal-freemail@thawte.com
/emailAddress=info@symas.com/C=US/ST=California/L=Tarzana/O=Symas Corporation/OU=Development/CN=Symas Keymaster
/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting/OU=Certification Services Division/CN=Thawte Personal Premium CA/emailAddress=personal-premium@thawte.com
/C=US/O=First Data Digital Certificates Inc./CN=First Data Digital Certificates Inc. Certification Authority
/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting/OU=Certification Services Division/CN=Thawte Personal Basic CA/emailAddress=personal-basic@thawte.com
/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
/C=US/O=VeriSign, Inc./OU=Class 2 Public Primary Certification Authority
/O=Symantec Corporation/CN=Symantec Root CA
/C=US/O=VeriSign, Inc./OU=Class 1 Public Primary Certification Authority
/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority – G2/OU=(c) 1998 VeriSign, Inc. – For authorized use only/OU=VeriSign Trust Network
/C=US/O=GTE Corporation/CN=GTE CyberTrust Root
/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root
/OU=Copyright (c) 1997 Microsoft Corp./OU=Microsoft Corporation/CN=Microsoft Root Authority
/C=US/O=VeriSign, Inc./OU=Class 2 Public Primary Certification Authority – G2/OU=(c) 1998 VeriSign, Inc. – For authorized use only/OU=VeriSign Trust Network
/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Root
—
SSL handshake has read 4123 bytes and written 342 bytes
—
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 1024 bit
SSL-Session:
Protocol : TLSv1
Cipher : RC4-MD5
Session-ID: B106000081A00AC4F9E73059FF3C90116F1D19C425D5ABB71474C587FF4C94C0
Session-ID-ctx:
Master-Key: 647A807E7A01F1CAFAEFE136C28B451BD48ED5DF5194879A3906A7C3CC07DF0B97F1FD3069FA64E406EA8E6E25349C45
Key-Arg : None
Start Time: 1113251455
Timeout : 300 (sec)
Verify return code: 0 (ok)
—
<ctrl-d>

DONE