On 29.05.2012 08:46, Tim Watts wrote:
On 29/05/12 00:00, Bernd May wrote:
> On 05/28/2012 10:25 PM, Tim Watts wrote:
>> 1) Rig OpenLDAP so all password changes get sent to the kerberos
>> server but do not use it for authentication. In the meantime we will
>> continue authenticate with the SSHA1 hashes in the user's LDAP
> The usual way to do this on most *nix systems is to actually 'rig' the
> PAM. In debian for example you setup your /etc/pam.d/common-password to
> contain something like:
> password sufficient pam_krb5.so ignore_root
> password required pam_unix.so nullok obscure min=4 max=8 sha256
> this sets up most of your tools to use the right modules when changing
> the password, e.g. 'passwd'.
Thanks for the reply.
Unfortunately there's a problem with that - the user would need their
old kerberos password before they could initiate a change and in this
case, their old kerberos password is unknown because Kerberos has only
> I do not know if you could do something like 'referring' a password
> change request from the OpenLDAP server to the kerberos server but since
> this would be an invitation von mitm attacks I doubt it.
It will be a bit of a pity in this case if it's not possible :(
When using password hashes in the user entry, does slapd receive the
plaintext password or does the client generate the hash?
If slapd does not have a mechanism specifically for forcing (priming)
kerberos servers, does it have a password change hook?
Otherwise, I am going to have to provide a special password change
service somewhere - probably web based or something.
Or crack all the LANMan hashes I found in the original LDAP server!
what Kerberos implementation are you using? If it's Heimdal and if it
uses your OpenLDAP server as its storage backend, you can use the
smbk5pwd overlay to set the Kerberos password along with a regular
If your distro doesn't ship it with OpenLDAP or as a seperate package,
you can build it from source. It's in the tarball under