SASL/GSSAPI bind in LDAP plugin?

[Henry B. Hotz]

Thinking about using Kerberos for a KDC to access a DS backend gives  
me a headache.  Having a multi-threaded DS probably helps, but it  
makes the headache worse.

On Feb 16, 2006, at 2:47 PM, Will Fiveash wrote:

> On Thu, Feb 16, 2006 at 12:48:36PM -0800, Henry B. Hotz wrote:
>>
>>
>> I don't think this answers the question.  If you're using Kerberized
>> replication utilities then you need to configure slave machines to
>> authenticate against an external kdc to bootstrap.  This has nothing
>> to do with LDAP back-ends.
>
> I originally started this thread trying to understand a scenario like
> the one pictured below (figure thanks to JavE):
>
>    +-------+     +-------+       +-------+
>    |  KDC  |     |  KDC  |       |  KDC  |
>    +--|----+     +--+----+       +-.-'---+
>        `-.          |           .-'
>           `-.       |        .-'
>              `.     |     .-'
>                `-.  |  .-'
>                   `-.-'
>                +---------+
>                | DS/KDC  |
>                | (KDB)   |
>                +---------+

For this to be reasonable I think you would want approximately as  
many DS's as KDC's.  I guess the original proposal was that the DS/ 
KDC would be used to support a cold startup, but no user interaction  
(otherwise what are the pure KDC's for?).  Given good geographic  
distribution of servers and external authentication I suppose warm- 
starts would be easy.

OR:  are we considering an architecture where the Kerberos master has  
its database in LDAP, but the Kerberos slaves get theirs via kprop?

> I was wondering if how the KDCs not on the DS could do a SASL/GSSAPI
> LDAP bind to the DS which uses Kerberos for auth.  I was not trying to
> suggest this was the only way for a KDC to access a KDB stored in a
> directory.
>
>> As for who's running who:  well if the data is all in LDAP, then I
>> think that decision has already been made.  The kdc is just a
>> specialized front-end for the directory.
>>
>> In that architecture I would probably prefer to put the DS(s) and the
>> KDC(s) on the same machine(s) precisely to simplify (and better
>> secure) their interaction.
>
> Sure but some may want a more flexible configuration.
>
> -- 
> Will Fiveash
> Sun Microsystems Inc.
> Austin, TX, USA (TZ=CST6CDT)
------------------------------------------------------------------------ 
----
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu