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.