Integrate Active Directory and OpenLDAP

To solve this problem, you could write your own LDAP clients (e.g., using Perl’s Net::LDAP), use another vendor’s toolset, or bypass this issue entirely and use Open- LDAP’s proxy service. I’ll show you the third option.

Using OpenLDAP as a Proxy
OpenLDAP can provide a proxy for connections to AD on behalf of a client. Simply put, OpenLDAP will work with AD for you whenever necessary. The benefit of this approach is that you don’t have to rely on the behavior of the LDAP client—the server, OpenLDAP, will be configured to chase referrals for you so that you don’t have to depend on client behavior, which may or may not work as you want.

With an OpenLDAP proxy, all operations are routed through slapd, even though some need to be performed within AD. For routing through slapd to work, you configure slapd-ldap, the proxy back end for the slapd daemon. You could use other back ends such as slapd-meta, which provides even more features such as naming context rewriting, but slapd-ldap is the simplest to configure during initial testing.

Let’s add a slapd-ldap configuration to slapd.conf. Listing 3 shows the code. In it, you can see several changes:

database ldap. We have defined a new back end by using slapd-ldap, which will be our proxy service.

subordinate. Without this keyword, slapd searches only the database specified by the search base (e.g., if dc=testcorp,dc=com were the specified search base, then cn=users,dc=testcorp,dc=com would never be examined because it’s a different slapd database).

rebind-as-user. This option tells slapd to bind to the remote DSA with the credentials supplied by the client; the credentials must be valid in AD.

Uri. This specifies the remote LDAP server, which in this case is the AD DC. Notice that we aren’t using SSL here—in the real world, you would configure SSL for security.

chase-referrals. This option specifies that slapd will chase any referrals automatically.

What’s interesting is that AD is using the same suffix of dc=testcorp, dc=com as Open- LDAP. Often both UNIX and AD administrators bring up a directory service with the same standard suffix (i.e., naming context), and only later do they find that they need to provide for better integration.

Now, restart slapd and run ldapsearch again:

# ldapsearch -x -h localhost
 -LLL -b dc=testcorp,dc=com -D cn=dpuryear,cn=users,
 dc=testcorp,dc=com -W ‘(cn=dpuryear)’ cn
Enter LDAP Password:

In this example, the ldapsearch command searches against cn = users, dc = testcorp, dc=com, which slapd should map to CN=Users in AD. And slapd does map it, as you can see by the output below:

dn: CN=dpuryear,CN=Users,DC=t
 estcorp,DC=com
cn: dpuryear

which shows the entry CN=dpuryear, CN=Users, DC=testcorp, DC=com— the account for dpuryear in the AD CN=Users container. slapd now knows that any operation against cn=users,dc=testcorp,dc=com (which is our superior in the directory tree), actually requires these steps:

1. Open an LDAP connection to ldap:// dc1.testcorp.com/.
2. Bind with the credentials supplied by the client.
3. Perform the operation.
4. Return the results to the client.

But there’s a problem: We don’t have access to all of the data in AD. To see what I mean, try to return the attribute sAMAccountName, which is specific to the AD schema. When I type

# ldapsearch -x -h localhost -LLL -b
 dc=testcorp,dc=com -D cn=dpuryear,cn=users,dc=testcorp,
 dc=com -W ‘(cn=dpuryear)’ cn sAMAccountName
Enter LDAP Password:

slapd returns only attributes defined in the schema known to OpenLDAP and nothing more:

dn: CN=dpuryear,CN=Users,DC=testcorp,D
 C=com
cn: dpuryear

Notice that sAMAccountName is not shown, even though it exists in AD and was requested in our ldapsearch command. To access all of the data in AD, you need to install the most recent version of OpenLDAP, OpenLDAP 2.3, which can transparently pass unknown schema, albeit with some minor syntax rules applied so that it can perform filtering.

Using OpenLDAP 2.3 to Pass Unknown Schema
You can install OpenLDAP 2.3 either by compiling the source, or, far easier, by installing it from RPM Package Manager (RPM). After installation, the only configuration change required is to modify pidfile and argsfile because the newer OpenLDAP RPM assumes a different location for those files. Listing 4 shows the code for this.

Now, restart slapd and try ldapsearch again—first using the “cn” in your filter

# ldapsearch -x -h localhost -LLL -b
 dc=testcorp,dc=com -D cn=dpuryear,cn=users,dc=testcorp,
 dc=com -W ‘(cn=dpuryear)’ cn sAMAccountName
Enter LDAP Password:

and then the AD-only sAMAccountName:

# ldapsearch -x -h localhost -LLL -b
 dc=testcorp,dc=com -D cn=dpuryear,cn=users,dc=testcorp,
 dc=com -W ‘(sAMAccountName=dpuryear)’ cn
 sAMAccountName
Enter LDAP Password:

Success! As you can see from the following output, ldapsearch queried slapd, which in turn queried AD for us:

dn: cn=dpuryear,cn=Users,dc=testcorp,
 dc=com
cn: dpuryear

SAMACCOUNTNAME: dpuryear

The key difference here is that we now have access to the complete AD schema, including sAMAccountName.

Seamless Access to AD
You should now be able to attach AD to any part of your OpenLDAP directory. You can authenticate your AD users in LDAP applications that use OpenLDAP or even provide access to multiple ADs in your network if they aren’t all part of a larger forest already.