[Date Prev][Date Next] [Chronological] [Thread] [Top]

Kerberos (Was: Munging an OpenLDAP slapd server)

At 02:56 PM 1/25/2006, Jon Roberts wrote:
>Quanah Gibson-Mount wrote:
>>--On Wednesday, January 25, 2006 3:35 PM -0500 "J.Lance Wilkinson, 814-865-1818" <JLW@psulias.psu.edu> wrote:
>>>We have no LDAP databases which include passwords.  For another software
>>>package which only supported LDAP Authentication, we implemented a
>>>version  of slapd which had bind.c mangled to spawn off a kerberos kinit
>>>check for  the uid=xxx with the selected password.  That software package
>>>only required what is listed in step (0) and then only steps (4) thru (6)
>>>above.
>>>
>>>Hoping to use the same technology for this new software package that
>>>presumes all the above steps.  I can easily determine if the uid=xxx is
>>>valid for the application, and can construct a character string
>>>representing a suitable DN easily, too.  The catch is I have no idea
>>>which slapd module I'd need to munge, where I'd need to do it, and what
>>>I'd need to do to build the appropriate structures for slapd to pass back
>>>as a succesful (or failed) search.  Guidance?
>> 
>>I think you could just use saslauthd to forward the password stuff to the KDC, to get whether or not they can bind?
>
>I have read about both approaches on this list before, but I've never seen a comparison of the advantages or disadvantages. From what I recall, Howard Chu refers to saslauthd as worthless even when configuring SASL. What is the essential difference between having slapd, saslauthd, and/or the client itself performing kerberos authentication?

In the case of SASL/GSSAPI, the client and server participate in
mutual Kerberos authentication exchange requiring each to obtain
appropriate tickets from the KDC.  See a site about Kerberos for details.

One can configure saslauthd to verify a user's password,
provided by the client to the server via SASL/PLAIN,
LDAP simple bind, etc., against Kerberos credential information
maintained by the KDC.  This is NOT Kerberos authentication.
This is password authentication.

Use of the latter violates the Kerberos security model as
it, amongst other things, exposes the user's password to the
server (and, if you don't adequately protect the LDAP bind
request, the world).

Note that this discussion is not really OpenLDAP-specific,
say applies to any application protocol server configured
to verify user passwords in this manner instead of using
a Kerberos-based authentication mechanism of that
protocol (SASL/GSSAPI in the case of LDAPv3).  It should
be moved elsewhere.

Kurt