Re: smbk5pwd: ldap_pvt_thread_pool_getkey fails, etc...

[Kris Maglione <bsdaemon@comcast.net>]

Howard Chu wrote:

> 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?

Yes. Even if it was possibly using another database, when I change the 
password with ldappassword, I can kinit with that password.

I don't have a decent debugger to single-step through the function with. 
I added debugging code, though. It fails the memcmp call. I printed 
ekey.key.keyvalue.date and key.keyvalue.data, and they are different.

> > 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.

I've thought about that. As it is, I'm using a module that ties into 
heimdal's password check function to modify Samba attributes. I've 
considered hacking hdb-ldap to just call the password modify exop and 
dispense with both problems at once.

> 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.