On 25/02/13 15:17, Dan White wrote:
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?
Hi Dan,
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?
Possibly - and for password handling I prefer kerberos to remain authoritative and running on it's own backend. I've had good milage with MIT kerberos before (10 years of happiness) and I feel I understand it.
For my users, LDAP will be a read only directory of basic posix account data. We're not needing anything very clever.
I *could* tell them to use kpasswd (and switch PAM so passwd goes direct to kerberos) when the switch is made, but it would make the transition a little easier if LDAP EXOPS could be routed through. Well, they can - it's just that the password change breaks the passthrough directive in userPassword.
Cheers, Tim
====== 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.
-- Tim WattsPersonal Blog: http://www.dionic.net/tim/
"History will be kind to me for I intend to write it."