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

[Benjamin Kaduk]

On Thu, 1 Sep 2016, Spike_White at dell.com wrote:

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

Well, I thought the default behavior was to do a SRV lookup for the KDC
list, which should round-robin through the DNS entries with the resolver's
behavior, but if you disable dns_lookup_kdc, that's correct.  (And maybe
I'm wrong about the default behavior.)

-Ben