[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