Integrate Active Directory and OpenLDAP

Both Active Directory (AD) and Open- LDAP play important roles in the enterprise. In fact, within the same company you’ll find the UNIX group using OpenLDAP and the LAN and Windows administrators using AD. However, most people are unable to fully access the AD schema via OpenLDAP.

OpenLDAP and AD can peacefully coexist— the key is finding the best way to allow LDAP operations to cross the boundaries between AD and OpenLDAP deployments. One way to make that happen is to use Open- LDAP’s proxy service. To demonstrate this proxy service, I’ll walk you through the steps to make AD’s cn=Users container, which by default contains all user objects, part of an OpenLDAP directory.

Terms and Versions
Before moving on, let’s define terminology. First, an LDAP server is actually what is known as a Directory Service Agent (DSA). Second, a DSA manages either part or all of a Directory Information Tree (DIT). Several DSAs may be deployed to manage an entire DIT as well as to allow for replication and high availability. The portion of the DIT that a DSA manages is known either as a partition or database. I use the term database.

To produce the examples in this article, I used CentOS 4.3, OpenLDAP 2.2.13, and AD running on Windows Server 2003 R2. Later in the article, I’ll show you a limitation in the commonly deployed OpenLDAP 2.2, which you can solve by installing OpenLDAP 2.3 on CentOS 4.3.(For CentOS 4.3, I use the RPMS found at dev.centos.org/centos/4/testing/ i386/RPMS/.) See the sidebar “Upgrading OpenLDAP on CentOS,” for installation instructions.

Starting the OpenLDAP Server Process
The OpenLDAP server process is named slapd, which stands for “stand-alone LDAP daemon.” It provides almost all of the Open- LDAP server functionality, including the ability to accept connections from LDAP clients, process queries and updates, and implement the ACLs that restrict access to confidential information within the directory. Notably, in OpenLDAP, replication is handled by another process entirely and is beyond the scope of this article.

Let’s start off with a sample slapd configuration that brings up a basic DIT with no ACLs or any other special capabilities. On the OpenLDAP server, configuration starts with the slapd.conf file shown in Listing 1. In this configuration, slapd manages a database for the directory tree dc=testcorp,dc=com.

To start slapd, type the following:

# service ldap start

and load the initial entries into the database.

To load the entries, first enter the information from Listing 2 into a file named dir. ldif. These entries will define a very simple tree which has a suffix (aka root) of dc=testcorp, dc=com and two branches that are ou=People and ou=Groups. Now, load the entries using ldapadd:

 # ldapadd -x -h localhost -D cn=manager,dc=testcorp,
dc=com -W -f dir.ldif
Enter LDAP Password: <value-of-rootpw>
adding new entry “dc=testcorp,dc=com”
adding new entry “ou=People,
 dc=testcorp,dc=com”
adding new entry “ou=Groups,
  dc=testcorp,dc=com”

The –x option specifies that ldapadd should use simple authentication instead of Simple Authentication and Security Layer (SASL). With simple authentication, the LDAP client (in this case, ldapadd) sends the credentials in plaintext. Even if you use LDAP over SSL (LDAPS) or LDAP StartTLS, you’re still using simple authentication, but the tunnel being used for communication is encrypted (and far more secure).

We can test that our entries loaded properly by using ldapsearch

# ldapsearch -LLL -x -h localhost -b ‘dc=testcorp,dc=com’

which performs a query to find all entries below the root of the tree. Figure 1, page 48, shows the results. As expected, ldapsearch returns the three entries that we originally imported via ldapadd. We are now ready to begin working with referrals.

A Caveat to Using Referrals
You saw how easy it is to view entries that OpenLDAP manages by using a simple ldapsearch command on our client—but what about viewing entries that AD manages? For that to happen, you need to direct either the LDAP client or the LDAP server (i.e., OpenLDAP) to AD.

An obvious choice is to use referrals, which is a way for a DSA to forward—or refer—an LDAP request to another DSA. However, while referrals are both powerful and flexible (both for managers and application developers), keep in mind an important caveat: How a client handles a referral is entirely dependent on implementation. For example, OpenLDAP’s ldapsearch can chase referrals when used with the -C option, but only anonymously—ldapsearch doesn’t try to authenticate against the second DSA.

If you did create a referral in OpenLDAP to AD, ldapsearch (as well as other OpenLDAP binaries such as ldapadd) would return output containing the following: “In order to perform this operation a successful bind must be completed on the connection.” This statement simply means that ldapsearch chased the referral to a domain controller (DC) and the operation was rejected because ldapsearch didn’t try to authenticate.

Continue to Page 2