[Date Prev][Date Next]
Re: Active Directory Password Cache
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.
> 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
> 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
Would it be possible to apply password expiry (using the local password policy
via ppolicy) as well ?
> 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 ?
> 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
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
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)?