[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: smbk5pwd: pass change exop works, {K5KEY} check doesn't

Kris Maglione wrote:
 I posted this along with another (solved) problem a few weeks back.

 I have smbk5pwd with Samba 3 and heimdal 0.6.2 and openldap 2.2.26.
 smbk5pwd.c is revision 1.6

I just now tested it against 2.2.24 and 2.2.27, no problems with either. Using Heimdal 0.6.3 at the moment, but that shouldn't make any difference.

 When I set up an account with Samba and Heimdal credentials and
 perfrom a password change exop, both the Samba and Heimdal passwords
 are changes. I can auth against the account via kinit and Samba with
 the new password. The problem is that authenticating against the
 {K5KEY} attribute doesn't work. The callback in smbk5pwd is called,
 but it returns false no matter what.

 Also, the pass change exop leaves a hashed password in the
 userPassword field (replacing {K5KEY} anyway). While this is good,
 since I can't auth against LDAP without it for now, it is not ideal.
 I want to store as few versions of a user's password as possible.

These two paragraphs don't make sense. The userPassword will get whatever hash is specified by the "password-hash" directive in slapd.conf. The only way the k5key_chk function can get called is if the hash is actually {K5KEY}. So if you're seeing a different value in the userPassword attribute, then your slapd.conf is wrong. And if it really is different, then the k5key_chk function will never get invoked. If k5key_chk is actually executing, then that means the userPassword value *is* {K5KEY}.

 The only thing that I've noticed of any possible significance in gdb
 is that the string passed to decode_Key has my Kerberos realm
 appended to the end in lower case. Also, it makes it all the way
 through k5key_chk's last do-while loop. It returns LUTIL_PASSWD_ERROR

If it makes it all the way to the end and returns ERROR then that means the password you specified didn't match the one that was stored.

decode_Key has nothing to do with the encryption mechanism, it is merely unwrapping the encoding that was used to store the keys in the LDAP attribute. (Heimdal stores keys in BER format.) If you're seeing a human-readable realm name here, then something is probably invalid in the stored keys; usually a key is a sequence of binary data, mostly gibberish. (Of course it depends on what encryption types you've configured in krb5.conf.)

 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support