Seeking KDC Priority/Weight Clarification/Recommendation

[Mark T. Valites]

We are using a SUN One Directory Server (LDAP) Authentication plugin as 
the backend authentication mechanism for users binding to our LDAP 
servers. It uses the underlying Sun provided SUNWkrbux libraries to act as 
a proxy to our kerberos servers.

We also use cosign as the login mechanism for users authenticating to our 
shibboleth service. It uses the underlying Red Hat provided krb5-libs to 
communicate with our kerberos servers.

Redunancy/HA for the LDAP and shibboleth/cosign services is acheived by 
loading balancing behind a set of Cisco content service switches.

Our kerberos environment consists of one MIT krb-1.5.x master KDC and 
three MIT krb-1.5.x slave KDCs. Redundancy is acheived with a 
_kerberos._udp.ourrealm.edu SRV record that includes all four KDCs, each 
with the same the same weight and priority, as well as a round robin DNS 
entry for kerberos.ourdomain.com, which includes the same four KDCs (the 
realm and domain names match):

$ dig _kerberos._udp.ourrealm.edu SRV
_kerberos._udp.ourrealm.edu. 600 IN  SRV     0 0 88 kerb1.ourdomain.edu.
_kerberos._udp.ourrealm.edu. 600 IN  SRV     0 0 88 kerb2.ourdomain.edu.
_kerberos._udp.ourrealm.edu. 600 IN  SRV     0 0 88 kerb3.ourdomain.edu.
_kerberos._udp.ourrealm.edu. 600 IN  SRV     0 0 88 kerb4.ourdomain.edu.

$ dig kerberos.ourdomain.edu
kerberos.ourdomain.edu. 60   IN      A       <IP 1>
kerberos.ourdomain.edu. 60   IN      A       <IP 2>
kerberos.ourdomain.edu. 60   IN      A       <IP 3>
kerberos.ourdomain.edu. 60   IN      A       <IP 4>

The krb5.conf files on the ldap & shibboleth/cosign servers are currently 
configued with the following:

[libdefaults]
         default_realm = ourrealm.ourdomain.edu

[realms]
         dce.buffalo.edu = {
                 kdc = kerberos.ourdomain.edu
                 admin_server = kadminserver.ourdomain.edu
 	}

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.

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 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.

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?

Andy other thoughts/suggestions on achieving a HA/redundnat kerb seting 
are welcome.

-Mark

-- 
Mark T. Valites
Senior Systems Administrator
Enterprise Infrastructure Services
University at Buffalo