KDC Configuration Questions

[Ken Raeburn]

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