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

Re: smbk5pwd: ldap_pvt_thread_pool_getkey fails, etc...

Kris Maglione wrote:

I'm having another problem now, though. The change password operation now works perfectly. The {K5KEY} mechenism doesn't, however. The k5key_chk function gets called, but I can't authenticate a user. The password works fine for kinit. The account has write access to all kerberos and samba attributes. If it's important, I collect kerberos4, 5, and afs keys.

Are you sure that the KDC that kinit is talking to is using the same data? I.e., your KDC is a Heimdal KDC using an LDAP database? What do you see from single-stepping through the k5key_chk function, where does the check fail?

By the way, is there a way (I'm willing to write the code) to deny write access to all kerberos/samba attributes and still have an overlay change them? I want the module to be able to change the "must change" time, etc, but not the user. I also don't want them to be able to manually alter their own hashes.

You can change the schema definition of the krb5key attribute to have NO-USER-MODIFICATION, and then only internal operations (e.g. the smbk5pwd module) will be able to change the attribute. That means all externally generated LDAP requests to modify the attribute will fail, including requests generated by the kadmin program. Probably a bad idea.

As another alternative, you could write another overlay that intercepts external Modify requests and rejects attempts to modify the attributes you're worried about. It seems this is a requirement that's coming up more generally, we probably need a cleaner way o handle it.

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