KDC Configuration Questions
Anh Nguyen
anguyen at redhat.com
Mon Mar 2 22:18:40 EST 2009
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-
More information about the Kerberos
mailing list