Hi Howard,
Thanks for taking the time to reply to my stupid questions ;-o
On 25/02/13 15:37, Howard Chu wrote:
Tim Watts wrote:
Hi folks,
I hope this is a quick and easy one :)
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)
I haven't seen smbkrb5pwd but, as the author of smbk5pwd,
Ah ha :)
it sounds like the hack is inadequate.
It's the one forked from smbk5pwd by opinsys.fi, tweaked slightly by me to add a default kerberos policy to principle creation requests.
smbk5pwd provides the {K5KEY} password hash mechanism, so you can use the Kerberos password directly, and you don't need {SASL} at all.
Does smbk5pwd now support MIT? I bypassed it because I thought it only supported Heimdall.
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} ?
That causes a spurious error at the ldapasswd client end: ================ Result: Other (e.g., implementation specific) error (80) Additional info: scheme provided no hash function ================
However, the kerberos principle does get updated - and userPassword is left alone.
Is that error message expected?
Cheers,
Tim