Configuring OpenLDAP pass-through authentication to Active Directory

Article
04/25/2012

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at https://www.microsoft.com/info/cpyright.htm

From OpenLDAP 2.4 Administration guide , “Since OpenLDAP 2.0 slapd has had the ability to delegate password verification to a separate process. This uses the sasl_checkpass function so it can use any back-end server that Cyrus SASL supports for checking passwords. The choice is very wide, as one option is to use saslauthd(8) which in turn can use local files, Kerberos, an IMAP server, another LDAP server, or anything supported by the PAM mechanism”.

This particular functionality of OpenLDAP should be of special interest for environments where long term co-existence between OpenLDAP and Active Directory is required. By establishing pass-through authentication the following advantages could be achieved:

Great end-user experience. No need to remember multiple passwords
Increased security, due to the reduction of the attack surface (one less password store in the environment)
Single password policy

The rest of the post will expand on the instructions provided by the OpenLDAP 2.4 Administration guide on establishing pass-through authentication from OpenLDAP to Active Directory. Specifically, will will leverage the capability of SASL to use LDAP as an authentication back-end. In our case, Active Directory will play a role of such authentication back-end.

Lab environment used for documenting the steps

OpenLDAP version of 2.4.25 running on Ubuntu Server 11
OpenLDAP was installed and configured using Ubuntu OpenLDAP Server documentation page
Active Directory on Windows Server 2008 R2

Active Directory Configuration

In order to secure authentication requests coming from OpenLDAP to Active Directory we need to ensure that LDAPS (Secure LDAP) is enabled on Active Directory Domain Controllers.

If you already established Windows based PKI, specifically Active Directory Enterprise CA, your Domain Controllers are already listening on LDAPS port. This occurs automatically, via auto-enrollment process.

You can confirm check whether your Domain Controllers are listening on LDAPS port by:

1. Checking local certificate store on a domain controller, and ensuring that there is a certificate with the template of DomainController.

2. Launching lpd.exe, and choosing SSL option

In case of a successful connection you should see output similar to this

For details on configuring PKI on Windows Server 2008 see Technet documentation

If you leverage PKI on a non-Windows based platform, see this article on how to enable LDAPS using 3rd party certificates on Active Directory Domain Controllers.

Building CA trust to Active Directory CA

LDAP client on the OpenLDAP server will need to validate the chain of trust of the certificates utilized by the Domain Controllers.

To be more specific the TLS_CACERT directive in the /etc/ldap/ldap.conf needs to point to a certificate of a CA, which signed the SSL certificates for the Active Directory Domain Controllers. If a multi-tiered CA structure is utilized, then all certificates of the CAs in the chain need to be included in the PEM encoded certificate.

In this walkthrough I will assume that OpenLDAP is utilizing an SSL certificates signed by a CA, different from the CA utilized in the Active Directory environment. TLS_CACERT directive points to a certificate of this CA utilized in the Unix environment.

To accommodate this scenario, we need to make the LDAP client on the OpenLDAP server trust both CAs: the one which singed the certificate for the OpenLDAP server, and the CA which singed the certificates for the Domain Controllers. We will leverage the fact that PEM encoded certificates can contain multiple entries.

Exporting Active Directory Root CA certificate and making it available on the OpenLDAP server

1. Locate the certificate of the CA which signed the SSL certificates of the Domain Controller.

2. Export it in Base-64 encoded format

3. Save the certificate

4. Copy the certificate to the OpenLDAP server. I used WinSCP to accomplish this.

5. Concatenate the two certificates into a new joined one.

In this example /etc/ssl/certs/cacert.pem is the certifcate of the CA which signed the SSL cert for OpenLDAP and ad.cer is the certificate we copied in the previous step.

If you open the resulting PEM file in a text editor you should see two sections of “BEGIN CERTIFICATE”

5. Update TLS_CACERT directive to point to the new “joined” certificate

6. At this stage you should be able to issue a query over SSL to a Domain Controller.

The example above assumes that DNS resolution works across Windows and Unix environments. Remember that SSL certificates are sensitive to host names, hence the name of the host (-H parameter in the query) should match the subject name in the certificate

Configure SASLAUTHD

1. Install SASL command-line tools. Other components of SASLAUTHD are installed as part of OpenLDAP installation.

Configure SASLAUTHD via /etc/default/saslautd

Set automatic start of the SASLAUTHD service

Enable LDAP authentication mechanism

Give OpenLDAP service account access to SASLAUTHD service

1. To determine the account under which SLAPD is running check SLAPD_USER parameter in /etc/default/slapd

2. Add OpenLDAP service account to the sasl group

Setup up connection and search parameters to Active Directory for SASLAUTHD

Create and edit /etc/saslauthd.conf

In this above sample configuration:

tfs.fabrikam.com is an Active Directory domain controller. Multiple ldaps urls could be specified.
sAMAccountName is an Active Directory attribute guaranteed to be unique in an Active Directory domain.
- sAMAccountName = %u, could be expanded to read sAMAccountName = UID.
- Essentially, this directive specifies how objects will be linked across two systems. In this particular example, we assume that UID and sAMAccounName attributes, for a specific user, will have the same value, hence provide the mapping. This consistency should either be enforced procedurally or via a synchronization service (ex. Forefront Identity Manager)
- sAMAccountName attribute was chosen arbitrarily, any other unique attribute could be utilized.

cn=saslauthd,cn=Users,dc=fabrikam,dc=com is a DN of an Active Directory account, in which context SASLAUTHD will perform queries against Active Directory. This account does not require any special privileges.

Let’s look at the sequence of events which would take place while performing authentication for the query below, based on the configuration directives in our sample /etc/saslauthd.conf

SLAPD locates the object with DN of cn=johnd,ou=People,dc=fabrikam,dc=com

If the object with this DN has value of {SASL}johnd@fabrikam.com in the userPassword property, SLAPD will hand over authentication to SASLAUTHD (pass-through authentication).

SASLAUTHD will query Active Directory for an object which sAMAccountName value equals to johnd (value of UID attribute in OpenLDAP).

If such object is found, SASLAUTHD will attempt to authenticate against Active Directory using the DN and password of the located object (password was provided by the end-user in the query).

If authentication to Active Directory is successful, user is automatically authenticated against OpenLDAP.