Re: SASL, Kerberos V and LDAP

["Mark H. Wood" <mwood@IUPUI.Edu>]

On Mon, 23 Apr 2001, Armin Herbert wrote:
[snip]
> "My" Linux users authenticate against OpenLDAP v2.0x. Anything works fine,
> but I want to add a security layer to be sure that users who want to
> change their passwords (to which they are by now granted access by a "self
> write" acl-entry in slapd.conf) are really the users they claim to be.
> 
> OpenLDAP uses SASL, and the more I read about it the more I wanted to use
> Kerberos V with it.
> But I don't really understand the principle, and I hope you can help me
> with this.
> 
> When a user logs into a client, the login involves 1) authentication
> against LDAP, which works fine, and 2) requesting a ticket-granting-ticket
> from the Kerberos server, which should do as well.

Probably this is backwards, if you want to use Kerberos to secure access
to your directory.  The login process would *first* get a TGT as part of
initial authentication, then perhaps get a service ticket for the host on
which the user is logging in.  When the user needs to query the directory,
the query agent should be written to notice that he has a TGT and request
a service ticket for the directory server and then present that ticket to
the directory using GSSAPI/SASL.  All of this might happen during login,
if you need to use the directory to set up the user session.

> But now when that user wants to change his password, he first has to
> request a service ticket from the Kerberos server, in order to gain access
> to his own password - because when he asks OpenLDAP for it without first
> having a service ticket, SASL will say "no you mustn't".
> 
> So I have to install a program which, on executing "passwd", requests a
> service ticket from Kerberos. I didn't find any, and pam_ldap doesn't seem
> to do so as well.
> 
> Did I oversee some program, did I completely misunderstand the use of
> Kerberos, or is there just no program available to do this? What would you
> suggest as an alternative?

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.

-- 
Mark H. Wood, Lead System Programmer   mwood@IUPUI.Edu
Make a good day.