KDC Configuration Questions

[Anh Nguyen]

Ken Raeburn wrote:
> On Feb 6, 2009, at 11:31, Anh Nguyen wrote:
>> Hi,
>> Sorry for the following newbies questions, but thanks in advance for
>> your comments and suggestions:
>> 1. Could we set up multiple KDC per single realm?
>
> Absolutely; at most sites I think it's the normal way of doing 
> things.  You just set up additional DNS SRV records for the realm, or 
> (in the MIT client implementation) multiple "kdc = <host>" lines in 
> the config file.  I think MIT's administration manual (or possibly 
> installation manual, I haven't checked in a while) should describe both.
>
> With multiple SRV records, unless you set different priorities, the 
> clients should try the KDCs in random order, thus spreading the load.  
> With config file entries, for historical reasons, the client will try 
> them in order, so the second only gets tried if a response doesn't 
> come back from the first quickly enough, etc.
>
>> 2. Is it possible to set up multiple independent sets of KDC/realm's
>> working against a single database managed by directory server?
>
> If you use the LDAP database back end, yes, just point all the KDCs in 
> a realm to the same LDAP server(s) and data.  I'm pretty sure you 
> could also do multiple realms in one LDAP directory, but I don't know 
> what subtle issues might lie there; I'm more familiar with our more 
> traditional Berkeley DB back end.
>
> Technically, with the Berkeley DB back end, you could probably set up 
> multiple KDCs too, but all KDCs need access to the same DB files, and 
> for security reasons they probably shouldn't be exported over the net, 
> so you'd be talking about running multiple KDCs on one machine, which 
> is not as useful if you're looking to improve availability in cases of 
> machine failure.
>
>> 3. Is there a plan to multi-thread KDC?
>
> Well, that's an interesting question....  It's been discussed, since 
> waiting for LDAP query results could make your KDC slow down.  We've 
> even had some code donated, but changing a sensitive security service 
> like the KDC in such a drastic way makes a lot of people nervous for 
> good reasons (ignoring the actual code we got -- going from a big 
> single-threaded program with a bunch of global storage to a 
> multi-threaded program with work queues between different parts is a 
> significant restructuring and likely to have subtle problems), so 
> we've held off on it for now, until we can take a better look at the 
> issue and possible approaches.
>
> In the meantime, actually, that might be a good use case for running 
> multiple KDC processes on one host.  You could spread out the load 
> somewhat, among, say, three processes on host A on different port 
> numbers, and three processes on host B on different port numbers.  
> You'd be relying on this load-sharing to reduce the problems from LDAP 
> latency, so you'd really want to go with the SRV records rather than 
> config file entries.
>
> I've got a couple other ideas about less drastic code changes we might 
> be able to make to allow for some parallel processing, by forking the 
> KDC process, but there are some interactions with the way we're 
> handling network interfaces that need a little thought.  If you're 
> interested in working on some code, let me know. :-)
>
> Ken
Hi Ken,
I'd like to apologize for this very late reply.
Your mail was mistakenly filtered to a folder, which I just coincidently 
checked.
Thank you very much for your explanation of the potentials.
Regarding the last one for improving concurrency I will certainly relay 
the message to other teams, and will keep you posted.
Thanks again.
Anh-