Slipping in/out KDCs....what is KRB5 client behaviour?

[Spike_White@dell.com]

All,

I have a question about KDC client behavior that does not seem to be documented well.  (I think I know the behavior but want to confirm.)

Long boring back-story why I need to know this behavior, won't bore you with the full details.  Suffice to say, these particular apps are not site-aware, so these KRB5 clients cannot do the basic DNS SRV lookups to find their KDCs.  (Else they may be round-robined to a KDC geographically far far away.)

Instead, they do this:

                [realms]
                 AMER.EXAMPLE.COM = {
                                kdc = <load-balanced pool of geographically-close KDCs>
                                kdc = <literal host 2>
                                kdc = <literal host 3>
                ...
                }

We've stood up new KDCs and are in the process of retiring old KDCs.

My understanding is that Kerberos clients always consults the KDC in the first kdc entry.  So unless this above pool above returns a KDC, this client will never consult <literal host 2> and <literal host 3>.

Thus as long as the load-balanced kdc pools are populated w/ only the new KDCs, the above syntax will not produce errors.   (It's aesthetically poor, but the alternative is touching thousands of prod servers - to improve aesthetics.)

BTW, this load-balancing technology only round-robins among responsive geographically-close KDCs (well, daemons listening on port 88 anyway).

Is my KRB5 client understanding correct?   I.e., they go sequentially in order in consulting KDCs, according to their entries in the krb5.conf file?

Spike