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 <[email protected]>
To: pgb205 <[email protected]>; "[email protected]" <[email protected]>
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.
________________________________________________
Kerberos mailing list [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
