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 ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
