Seeking KDC Priority/Weight Clarification/Recommendation

[Ken Raeburn]

On Dec 15, 2008, at 15:04, Mark T. Valites wrote:
> We recently saw a hardware failure on one our (non-master) KDCs that
> brought the box completely off line. Even though they are redunant/ 
> highly
> available on their own, the downstream ldap & shibboleth/cosign  
> servers
> all immeadiately saw issues because of this, exposing the weak link  
> in the
> chain.

What sort of issues?

> The O'Reilly Kerberos (The Definitive Guide) book states that  
> setting the
> weight to 0 in the SRV record causes clients to choose from equal  
> priority
> KDCs randomly, but doesn't explicitely say anything about when one of
> those is not available.

The MIT code will pick one KDC address to try contacting, and if it  
doesn't answer within a second, it will try the next one.  (Both the  
config-file and DNS approaches as you described them would result in a  
list of four addresses.  The library code should randomize the order  
of all SRV records returned with weights all zero.  However, if the  
config file version is used, the addresses will be tried in the order  
returned by the getaddrinfo() function, and the hostnames listed in  
the file, if more than one, are assumed to be in priority order so  
they're not randomized.)

So if you're getting random or rotating ordering of address records  
returned, then with one server (address) of four unreachable, one  
quarter of the time you should see a delay of a second.  If  
getaddrinfo() or your DNS cache is being clever and trying to give you  
an order optimized for proximity or some such, you may see delays more  
often or less often, but the delay should still be no more than a  
second.  If it is, you could try monitoring the network traffic with  
tcpdump and see what it's doing in terms of trying to reach the  
various KDCs.

A significantly longer delay should only come up if no KDC is  
responding.

(A minor point: You might want to put a dot at the end of the KDC  
names in your config file, to prevent the use of domain search paths,  
just in case.)

> The book also indicates that setting priorities on the KDCs will  
> cause the
> client to try the next highest one if the first is not available,  
> but to
> me this implies that there would always be one KDC hit hardest.

That's correct.

> Can the krb5.conf file/SRV record be configued to make the clients
> fallback to one of the other KDCs if the first one tried is not  
> available,
> without always favoring the one(s) with the lowest priority numbered  
> one?

As noted above, that should be the behavior...

Ken