On 21/07/11 10:59 +0300, Nick Milas wrote:
On 21/7/2011 8:50 πμ, Michael Ströder wrote:
Dan White wrote:
See:
contrib/slapd-modules/smbk5pwd/
Note that this overlay only works when using heimdal software for the KDC which uses a different LDAP schema.
Since the orginal poster mentioned attributes krbPrincipalName and krbPrincipalKey he seems to use MIT Kerberos.
Thank you all for your feedback.
Yes, it's the MIT Kerberos. And, after looking into smbk5pwd, it does the opposite (of what I want): it automatically gets value for userPassword based on the Principal key (krb5Key) attribute (using the krb5-kdc.schema).
I am looking if it is possible to automatically populate/produce krbPrincipalKey attribute values (kerberos.schema) based on current userPassword attribute values (person objectClass in core.schema), without knowing the stored password (encoded mainly as MD5).
It's unclear from your original post if your are using SASL binds - you said you are doing "PLAIN auth over TLS/SSL".
If you are using SASL binds, or can force SASL binds, then you could use the autotransition feature of Cyrus SASL to transition from a hashed password store to a cleartext password store.
An approach would be to configure /usr/lib/sasl2/slapd.conf with:
pwcheck_method: saslauthd mech_list: plain login gssapi external auto_transition: yes auxprop_plugin: slapd
You could run saslauthd with the ldap backend (with a non-sasl configuration), or run it with the pam backend, and configure an nss plugin to, in turn, retrieve the hashed passwords from ldap.
That would get you a step closer, at which point you could generate your kerberos keys from the clear text passwords you've just stored in userPassword.
A simpler approach, and one that works with non-SASL binds, would be to configure pass-through authentication and perform saslauthd/kerberos5 authentication. As users change their passwords (against your kerberos server, via some unspecified process), you could replace their userPassword entries with {SASL}user@realm (as described in the Admin guide) and do away with hashed password entries altogether.