Re: Kerberos and DIGEST-MD5

[Jose González Gómez <jgonzalez@opentechnet.com>]

Howard Chu wrote:

> Jose Gonzalez Gomez wrote:
>
> > > The cleanest way to make this work is to use Heimdal Kerberos and 
> > > set its KDC to store the Kerberos authentication data in LDAP. Then 
> > > use the smbk5pwd module in OpenLDAP's CVS to keep the userPassword 
> > > and krb5Key in sync. Synchronization is one-way - when you change 
> > > passwords using LDAP then both LDAP and Kerberos will be updated at 
> > > once, but if you change passwords using Kerberos only Kerberos will 
> > > change. Note that this approach only works with OpenLDAP 2.2 and 
> > > Heimdal Kerberos. Also there is no need to use saslauthd when using 
> > > this method; the LDAP userPassword simply holds the user's cleartext 
> > > password. Obviously there are other security considerations from 
> > > storing a cleartext password in LDAP.
   A question about something I didn't notice before... Is this 
synchronization really needed? You seem to imply that the password 
information stored in the KDC and in LDAP may differ and they need to be 
synchronized. But if Kerberos *uses* LDAP to store the password, doesn't 
the password gets changed once you change it in LDAP? What am I missing 
here?

   This point rises another question... if Heimdal is able to store its 
passwords in LDAP, does that mean that changing a password using kpasswd 
would change it in LDAP? That would solve this whole issue as long as 
you are able to store them in clear text and make the LDAP/Kerberos 
synchronization unneeded if you force to change passwords using Kerberos 
(possible with LDAP ACLs). Am I right?


> >    So you gain the ability to offer DIGEST-MD5 authentication without 
> > having duplicated password information, but then you lose the 
> > possibility of letting users change their passwords using the 
> > standard unix/linux/kerberos tools. The first obvious implication of 
> > this approach is that you will have a hard time trying to enforce any 
> > password policy in your network, as this usually involves an expired 
> > password that must be changed at logon time using pam, and enforcing 
> > the quality of the password using kerberos policies... am I missing 
> > anything here? Should I use a combination of cracklib/ldap modules 
> > for password and kerberos modules for auth/account/session in pam? 
> > Would such a setup work?
>
>
> Use pam_ldap instead of pam_krb, and you'll be able to change your 
> passwords using the standard Unix/Linux tools. Password policy 
> enforcement is also available in OpenLDAP CVS.

   But using pam_ldap makes you lose the ability to get the Kerberos 
ticket on login, doesn't it? Every user should issue a kinit command 
after log in, so all the transparent single sign on capabilities of 
Kerberos (that's why I was using it) get lost. Maybe you could stack the 
login modules so after successful login using pam_ldap, pam_krb5 
connects to the KDC and gets the ticket... would this be possible?

> >    Regarding the smbk5pwd... will this be included in a future 
> > release of OpenLDAP?
>
>
> Don't know; I wrote this following a request from Andrew Bartlett on 
> the Samba project but he went quiet and no one else provided any 
> feedback so it seems there hasn't been any demand/interest.
>
> > And a final question regarding Kerberos... until now I've been using 
> > mit-krb5, do you recommend heimdal over mit for any reason?
>
>
> Well, the most obvious reason is that the MIT KDC doesn't support 
> LDAP. There are other reasons that have been hashed out on this list 
> countless times, read the mailing list archive.

   Thanks a lot, best regards
   Jose