On Monday 06 August 2007 13:34:27 Sebastian Hetze wrote:

Hi *,

in the contrib section of the OpenLDAP tracking system I've uploaded a piece of software that you might find useful. I've also uploaded an additional patch.

ftp://ftp.openldap.org/incoming/Sebastian-Hetze-pgk-070712.tgz ftp://ftp.openldap.org/incoming/Sebastian-Hetze-070630.patch

It is registered in the issue tracking as ITS#5042.

To enter the contrib section of OpenLDAP, the overlay module requires some testing from the community. I have developed the overlay for Debian GNU/Linux and it works pretty well for me. However, I did not test it in other environments. I would very much like to know how good it works and what improvements you suggest.

To give you an overview what the module does, here is what the README says:

Active Directory Password Cache

Active Directory does not provide any means to read user credentials on any public API. It is possible, to install additional libraries as password sniffer to catch and forward cleartext passwords on changes. In case you cannot or simply dont want to install such libraries, the Active Directory Password Cache overlay is your option.

The Active Directory Password Cache overlay allows to mirror user account credentials without any modification on the AD server. It only takes one occasional simple bind authentication against the OpenLDAP server.

If the credential has not been mirrored yet, the overlay uses the krbPrincipalName and the password provided by the user to perform a Kerberos init against the Active Directory. A successful Kerberos init guarantees a correct password for this principal, and therefor the bind finally succeeds.

Within this overlay operation, the password gets encrypted with the default OpenLDAP hash alorithm and stored as userPassword attribute. There is an option to update the sambaNTPassword also (using code borrowed from Howard Chu's smbk5pwd overlay). All following simple bind authentications will first try these cached credentials, making the OpenLDAP server independent from AD.

Would it not be better to just use the smbk5pwd overlay as well ?

In case the user changes its password on the Active Directory server, the old password stays valid in OpenLDAP until the user first presents the new password for an simple bind. Within this bind operation, the overlay performs another Kerberos init and updates the cached credentials in OpenLDAP.

Would it be possible to apply password expiry (using the local password policy via ppolicy) as well ?

Installation

The adpwc overlay is developed for openldap-2.30. If you unpack the sources in contrib/slapd-modules/adpwc it should compile with a simple make.

You need to copy and link the module adpwc.so-2.3.so.0.2.18 to your modulepath dir, /usr/lib/ldap for example. Additionally, you need some Kerberos schema. We use the Novell schema for MIT kerberos, Heimdal works as well.

# cp adpwc.so-2.3.so.0.2.18 /usr/lib/ldap # ln -s /usr/lib/ldap/adpwc.so-2.3.so.0.2.18 /usr/lib/ldap/adpwc.so

In /etc/ldap/slapd.conf the following lines must be inserted:

    # includes:
    include         /etc/ldap/schema/kerberos.schema

    # before backend definition:
    modulepath      /usr/lib/ldap
    moduleload      adpwc.so

    # in backend section:
    overlay adpwc
    adpw-cache-mode user

That's it. Given that your Kerberos client configuration is correct, simple bind operations for all users that have valid krbPrincipanName attributes will be forwarded to Kerberos/Active Directory if the local backend bind fails for whatever reason.

Correct Kerberos client configuration is: you have your default_realm set to the Active Directory realm and provide a [realm] section pointing to the kdc in /etc/krb5.conf. You should be able to perform a kinit from your Linux/Unix command line prompt, using the krbPrincipalName.

Would it not be possible to use a non-default realm ?

Security/Riscs

Simple bind authentication is risky in general. You should use SSL encryption to protect cleartext password on the wire. (This is totally independent from adpwc overlay.)

The current implementation of adpwc does not use server authentication.

The overlay uses krbPrincipalName to perform the Kerberos init. It is neccesary to protect this attribute from unauthorized modification. In case this attribute does not belong to the appropriate AD account, simple bind authentication might be directed to another existing AD account.

This overlay is interesting to me, but some assumptions don't apply in my environment.

I am planning to use Heimdal with hdb_ldap for our own realm, but I would like to authenticate selected users from the AD realm against AD (but without a full trust). But, since both AD and our (current, simple-only LDAP accounts) have (and require) password expiry, the default password policy in the directory matches the default policy in AD, so using ppolicy would be sufficient.

Finally, would it be possible to provide any information on what is required on the AD side for this to work (I assume some account for the OpenLDAP server to use)?

Regards, Buchan