On 02/25/13 14:53 +0000, Tim Watts wrote:
I have slapd 2.4.23 working with passthrough to MIT kerberos via saslauthd. I use smbkrb5pwd (a hack on smbk5pwd) to pass password changes through to kerberos (creating or modifying the target principle as required)
To enable a particular user to bind to slapd with their kerberos password, I'm setting:
userPassword: {SASL}myuid@MY.KERBEROS.REALM.EXAMPLE.COM
This works *very nicely*. Except one thing...
Using passwd via pam_ldap or ldappasswd directly smashes userPassword: and replaces the value with the password hash. Both machanisms are doing EXOP password changes.
Is there any way to stop this happening when the mechanism in userPassword is {SASL} ?
Or maybe there is another way to enable global SASL password passthroughs?
What is the reason for keeping SASL pass-through after a password change? Why not allow the exop operation to proceed normally, which should write the correct password hash into your userPassword attribute (by way of your olcPasswordHash config)?
Do you expect to make kerberos password changes outside of an ldap exop operation?
======
I'm in a transition phase. I need to import the slapcat output from the old LDAP server to my new one. At this point, all authentication should be done with the existing userPassword hash. Password changes should update this hash and create/modify principles on the kerberos server.
3 months later, I want to switch the auth mechanism on all accounts to passthrough to kerberos, at which point, ldappasswd should still work but via smbkrb5pwd updating kerberos.
Perhaps a better approach would be to place your kerberos store within LDAP, and handle password changes with smbk5pwd.