OpenLDAP to Kerberos, Take 2

[Russ Allbery]

Wes Modes <wmodes at ucsc.edu> writes:

> In general, I am trying to authenticate a login and password received
> via an OpenLDAP client (in this case SMB via the smbldap-tools) with the
> logins and passwords held in a Kerberos server elsewhere.  Is this a
> legitimate use of these services?

Well, it breaks the Kerberos security model, but sometimes you can't help
that.

> I thought it was possible that I could have an ldap-bind request
> referred via SASL/GSSAPI to do a Kerberos authentication.
>
> But on this Kerberos list, here's the response I got.
>
>     A KDC does not speak GSSAPI nor SASL.  A KDC issues tickets.  You
>     use SASL-GSSAPI-KRB5 when you want to establish an authenticated
>     connection to an application service for which a service principal
>     exists within the KDC database.  The KDC is not an application
>     service.
>
>     As Jeff pointed out, [you can't do that] with GSSAPI. What you might
>     be looking for is slapd code to take a username and password and do
>     in effect a kinit and a verify tgt, or have a sasl plugin do it for
>     your. I don't know of one.

This is from the KDC perspective and is correct as far as it goes.

> But on an OpenLDAP list I got:
>
>     There is an ugly hack: having a userPassword field with
>     "{SASL}<Kerberos principal>" in LDAP you can employ saslauthd's
>     Kerberos backend. We use it as a crutch for a web application which
>     can only authenticate against an LDAP directory

And what that does is exactly what's described above: it causes slapd to
take the username and password and do a kinit and ticket verification.
(What it actually does is hand the username and password off to saslauthd,
which then does that, but for your purposes it amounts to the same thing.)

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>