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 http://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

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.

image

2. Launching lpd.exe, and choosing SSL option

image

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

image

 

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.

image

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.

image

2. Export it in Base-64 encoded format

image

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.

image

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

image

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

image

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

image

image

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

image

Configure SASLAUTHD

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

image

Configure SASLAUTHD via /etc/default/saslautd

Set automatic start of the SASLAUTHD service

image

Enable LDAP authentication mechanism

image

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

image

2.  Add OpenLDAP service account to the sasl group

image

Setup up connection and search parameters to Active Directory for SASLAUTHD

Create and edit /etc/saslauthd.conf

image

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.

        imageimage

  • 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

image

  1. SLAPD locates the object with DN of cn=johnd,ou=People,dc=fabrikam,dc=com
  2. 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).
  3. SASLAUTHD will query Active Directory for an object which sAMAccountName value equals  to johnd (value of UID attribute in OpenLDAP).
  4. 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).
  5. If authentication to Active Directory is successful, user is automatically authenticated against OpenLDAP.

Test SASLAUTHD

Successful test.

image

For the –u parameter specify a valid sAMAccountName value in Active Directory.

Unsuccessful test, wrong password provided.

image 

If you run into issues with this test, see the troubleshooting section at the end of this post.

Configure SLAPD to utilize SASLAUTHD

Now we need to tell SLAPD to utilize SASLAUTHD for authentication. This is accomplished by creating and editing /etc/ldap/sasl2/slapd.conf

image

Setup default REALM in SLAPD cn=config

image

Provide olcSaslRealm directive

image

Configure user object to be authenticated via SASL

 

image

Troubleshooting

If things go wrong, several log files and debug options could help.

1. Checking /var/log/auth.log. Here you will find details on the LDAP authentication failures

image

2. Checking  SASLAUTHD error messages in /var/log/syslog

image

Running ldapsearch with debug option, may help when troubleshooting certificate trust chain validation.

image