SASL/GSSAPI bind in LDAP plugin?

[Will Fiveash]

On Tue, Feb 14, 2006 at 03:09:01PM +1100, Luke Howard wrote:
> 
> >I was looking at the LDAP KDB plugin and was wondering if it was
> >possible to support a SASL/GSSAPI LDAP bind when the kdc or kadmind
> >needed access the KDB via LDAP.  It appears to be a chicken and egg
> >issue since the KDC needs access to the LDAP/DS service princ. key which
> >it normally has via the KDB.  And given the LDAP plugin would be calling
> >libsasl/libgss/mech_krb5 as a client (running under the kdc process),
> 
> I think it's chicken-and-egg, unless you store the LDAP server key
> separately and use it to fake a ticket.

I was thinking the LDAP server key could be in a keytab accessible by
the KDC.  Certainly there would need to be whatever keys are required in
a keytab to allow the KDC to bind to the DS.

> >the code path would be generating a request to the kdc and blocking for
> >a reply from the kdc which wouldn't come unless the kdc was
> >multi-threaded.  Or is there another way?  It seems advantageous to
> 
> If you need to make a KDC request from within the same process as the
> KDC you really need to do it in-line, otherwise what happens if the
> last thread is making the request?

Or there is a dedicated krb msg reader thread in the KDC?  

Anyway, from what I know of the code path I think inline processing on
the current MIT KDC may not be possible because the KDC calls the LDAP
plugin which is calling libsasl/libgss/mech_krb5 as a client which would
have the mech_krb5 code issuing a AS_REQ and so forth to acquire a LDAP
service ticket.  All this is way below the KDC.

> >leverage the existing Kerberos infrastructure for this sort of
> >authenticated bind.
> 
> My preference is for the KDC to run on the same host as the LDAP server
> and use ldapi:// (LDAP over IPC). This is the approach we used in XAD.

That certainly avoids the issues I'm raising here.

-- 
Will Fiveash
Sun Microsystems Inc.
Austin, TX, USA (TZ=CST6CDT)