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.