Re: smbk5pwd: ldap_pvt_thread_pool_getkey fails, etc...

[Howard Chu <hyc@symas.com>]

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