Active Directory Password Cache

[Sebastian Hetze <s.hetze@linux-ag.de>]

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.

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.


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.

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.