More than 2 failed master_kdc servers cause errors
Greg Hudson
ghudson at mit.edu
Mon Aug 7 16:52:46 EDT 2017
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.
More information about the Kerberos
mailing list