More than 2 failed master_kdc servers cause errors

[pgb205]

Greg,
Sorry my mistake
I meant the following krb5.conf
kdc=server1kdc=server2kdc=server3master_kdc=server1master_kdc=server2master_kdc=server3
the above DOES NOT WORK when server1 and server2 are down.But If I comment master_kdc=server2 I'm able to kinit. Like so:
kdc=server1kdc=server2kdc=server3master_kdc=server1#master_kdc=server2master_kdc=server3
It seems like kerberos is ok with encountering one failed master_kdc but not two or more.
This is what KRB_TRACE shows with 'bad' configuration. Server3 is never even tried.
kinit tries server1 and server2 but never even attempts server3KRB5_TRACE=/dev/stdout kinit user(a)test.domain [12536] 1501112935.251721: Getting initial credentials for user(a)test.domain [12536] 1501112935.251917: Sending request (181 bytes) to test.domain[12536] 1501112935.251956: Resolving hostname server1[12536] 1501112935.252875: Sending initial UDP request to dgram server1_ip:88[12536] 1501112936.253962: Resolving hostname server2[12536] 1501112936.255680: Retrying AS request with master KDC[12536] 1501112936.255699: Getting initial credentials for user(a)test.domain[12536] 1501112936.255763: Sending request (181 bytes) to test.domain (master)[12536] 1501112936.255779: Resolving hostname server1[12536] 1501112936.256379: Sending initial UDP request to dgram server1_ip:88[12536] 1501112937.257451: Resolving hostname server2kinit: Invalid argument while getting initial credentials

      From: Greg Hudson <ghudson at mit.edu>
 To: pgb205 <pgb205 at yahoo.com>; "kerberos at mit.edu" <kerberos at mit.edu> 
 Sent: Monday, August 7, 2017 4:52 PM
 Subject: Re: More than 2 failed master_kdc servers cause errors
   
On 08/07/2017 04:31 PM, pgb205 wrote:
> krb5.conf looks like
> kdc=server1
> kdc=server2
> kdc=server2
> master_kdc=server1
> master_kdc=server2
> master_kdc=server3
> server1 and server2 are down. server3 is up and running
> Attempting to auth with kinit user_id and above configuration will fail.

(Did you mean to list "kdc=server2" twice?)

master_kdc is only intended to operate as a fallback for when a client
contacts a KDC which contains out-of-date keys due to propagation delay.
 If the client tries to contact all of the KDCs listed in values of
"kdc" and can't contact any of them, it does not fall back to trying
KDCs listed in master_kdc.

Also, the master_kdc fallback only applies to initial authentication,
not to TGS requests, although that should probably change.

> However commenting master_kdc=server1 and master_kdc=server2 lines will allow authentication
> kdc=server1
> kdc=server2
> kdc=server2
> #master_kdc=server1
> #master_kdc=server2
> master_kdc=server3

I would not expect that to work when server1 and server2 are
inaccessible, and it doesn't work when I try it in a simple test
environment.