Re: Kerberos with LDAP backend: password sync

[Dan White <dwhite@olp.net>]

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