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