SASL/GSSAPI bind in LDAP plugin?
William.Fiveash at sun.com
Mon Feb 13 23:26:46 EST 2006
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.
Sun Microsystems Inc.
Austin, TX, USA (TZ=CST6CDT)
More information about the krbdev