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

Re: Kerberos with LDAP backend: password sync



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.

--
Dan White