Re: SASL, Kerberos V and LDAP

["Booker C. Bense" <bbense@networking.stanford.edu>]

On Tue, 24 Apr 2001, Armin Herbert wrote:

> "Mark H. Wood" wrote:
>
> > I think the confusion comes from a change in the directory's role:  from a
> > *provider* of authentication (before adding Kerberos) to a *consumer* of
> > authentication services (after adding Kerberos).  You'd switch from
> > pam_ldap to pam_krb5 for login authentication, and any fetching of user
> > data from the directory would use the ticket cache established by pam_krb5
> > to authenticate to the directory service.  You could run ldapsearch in the
> > login script and dig useful information out of its output, or write
> > something more specific to your needs.
> >
> > Kerberos would be the *only* service that knows the user's password, so
> > the user would use 'kpasswd' to change it, and kpasswd knows all about
> > ticket handling.  The directory wouldn't be involved at all.
>
> I read about this way from <turbo@bayour.com> in his LDAPv3 paper, and I
> don't think this is what I want (but I'm quite unsure, I'm not through all
> Kerberos papers yet ..)

- If this isn't what you want, then you don't want kerberos. The model
above is fundemental to the kerberos security model. Using kerberos in
any other way seriously weakens it's security.

>
> I thought when requesting a service ticket from Kerberos, the server could
> ask ldap if the user's allowed to be on the host the request came from, at
> which times he may be there etc pp. And I thought Kerberos could ask LDAP
> all this through the SASL authentication/authorization "mapping".
>

- Kerberos does one thing pretty well. It answers the question

	"who are you?"

- If you try and use it to answer the question,

	"What can you do?"

then you're almost always making a design mistake.

> So a user could authenticate itself to LDAP by providing a service ticket
> and then changing his userPassword, which would be used by Kerberos (which
> should have some sort of "trust relationship" to LDAP) to authenticate the
> user to LDAP.

- This is kind of how microsoft's combination ldap/kerberos server
works. I don't know of any other implementation that would support
this. I guess you could write a custom back end that would sync up
the passwords between the ldap and kerberos servers, but I think
that's a bad idea.

>
> Login etc would still be done with pam_ldap.
>

- To me the entire point of using kerberos is to get the password
out of the ldap server. If that's not your goal then, you should
seriously reconsider whether you need kerberos or not.

- Booker C. Bense