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

[S***@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



_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Benjamin Kaduk]

Post by S***@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.)
[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
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[S***@dell.com]

Ben,

Thank you for confirming this Kerberos5 client behavior. Yes, we set:

dns_lookup_kdc = false
dns_lookup_realm = false

For these non-site-aware apps (typically java apps).

Spike

------------------------------

Date: Thu, 1 Sep 2016 20:50:16 -0400 (EDT)
From: Benjamin Kaduk
Subject: Re: Slipping in/out KDCs....what is KRB5 client behaviour?
To: ***@dell.com
Cc: ***@mit.edu
Message-ID:
Content-Type: TEXT/PLAIN; charset=US-ASCII

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.)
[realms]
AMER.EXAMPLE.COM = {
kdc =
kdc =
kdc =
...
}
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 and .
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


_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev