On Wed, Jul 26, 2017 at 03:56:52AM +0000, pgb205 via FreeIPA-users wrote:
As far as I know krb5.conf does not have limitations on the number of
KDCs that can be
listedhttps://web.mit.edu/kerberos/krb5-1....krb5_conf.html
I have 3 servers that I would like to be read. I have no problem with at least two being
listed there.kdc=server1kdc=server2
when I shutdown server1 authentication happens without trouble against server2.But when I
list 3 servers therekdc=server1kdc=server2kdc=server3
and shutdown server1 and server2 authentication fails.
My theories about this are:1. there is a variable that specifies max number of kdcs.
Seems unlikely2. Bug. Also unlikely3. There is a variable that specifies total number of
seconds to wait before giving up.I tried playing with max_timeout and max_retries but that
didn't help
I'm drawing blank as to why only first two kdc lines are honored and would appreciate
any advise.
Afaik there is no such limit. I just setup a test realm with for
non-existing KDCs:
TEST.REALM = {
kdc = 192.168.122.22
kdc = 192.168.122.23
kdc = 192.168.122.24
kdc = 192.168.122.25
}
and as you can see
# KRB5_TRACE=/dev/stdout kinit abc(a)TEST.REALM
[26006] 1501051789.950820: Getting initial credentials for abc(a)TEST.REALM
[26006] 1501051790.24213: Sending request (186 bytes) to TEST.REALM
[26006] 1501051790.24777: Resolving hostname 192.168.122.22
[26006] 1501051790.25215: Sending initial UDP request to dgram 192.168.122.22:88
[26006] 1501051791.26558: Resolving hostname 192.168.122.23
[26006] 1501051791.26948: Sending initial UDP request to dgram 192.168.122.23:88
[26006] 1501051792.28337: Resolving hostname 192.168.122.24
[26006] 1501051792.28956: Sending initial UDP request to dgram 192.168.122.24:88
[26006] 1501051793.30398: Resolving hostname 192.168.122.25
[26006] 1501051793.30832: Sending initial UDP request to dgram 192.168.122.25:88
[26006] 1501051794.32619: Initiating TCP connection to stream 192.168.122.22:88
[26006] 1501051795.34289: Initiating TCP connection to stream 192.168.122.23:88
[26006] 1501051796.36099: Initiating TCP connection to stream 192.168.122.24:88
[26006] 1501051797.37649: Initiating TCP connection to stream 192.168.122.25:88
[26006] 1501051797.138839: Terminating TCP connection to stream 192.168.122.22:88
[26006] 1501051798.98884: Terminating TCP connection to stream 192.168.122.23:88
[26006] 1501051799.122834: Terminating TCP connection to stream 192.168.122.24:88
[26006] 1501051800.40306: Sending retry UDP request to dgram 192.168.122.22:88
[26006] 1501051800.146735: Terminating TCP connection to stream 192.168.122.25:88
[26006] 1501051801.41116: Sending retry UDP request to dgram 192.168.122.23:88
[26006] 1501051802.42920: Sending retry UDP request to dgram 192.168.122.24:88
[26006] 1501051803.44617: Sending retry UDP request to dgram 192.168.122.25:88
[26006] 1501051808.50520: Sending retry UDP request to dgram 192.168.122.22:88
[26006] 1501051809.52449: Sending retry UDP request to dgram 192.168.122.23:88
[26006] 1501051810.54129: Sending retry UDP request to dgram 192.168.122.24:88
[26006] 1501051811.55774: Sending retry UDP request to dgram 192.168.122.25:88
kinit: Cannot contact any KDC for realm 'TEST.REALM' while getting initial
credentials
all addresses are tried. With what error does the authentication fail? Are
there any details in the logs of kdc3 which might help?
PS: I would also be interested in more information on relationship between sssd.conf and
krb5.conf
It seems like I can configure sssd.conf with ipa_server=_srv_, <explicit fqdn>
Then why is krb5.conf is necessary at all?
Setting in sssd.conf are typically valid on for SSSD while krb5.conf is used by
all Kerberos clients. But SSSD will create some config snippets which are
included by krb5.conf in /var/lib/sss/pubconf/krb5.include.d/. Those are mainly
about the discovered realms and their relationships discovered by SSSD.
Additionally there is the krb5 locator plugin where SSSD puts the IP address to
the KDC currently used. This was added to make sure a single client keeps
talking to a single KDC to avoid some types of issues. E.g. if you change you
password and immediately try to authenticate again the new password might only
be know on one kdc and not replicated to the others.
There is a known drawback of this approach. If this kdc becomes unavailable to
locator plugin is only updated if SSSD tries to run an operation against this
kdc and fails. Before SSSD updates the plugin all other clients like e.g. kinit
will try to use the kdc returned by the locator plugin because the plugin has a
higher priority than e.g. the settings in krb5.conf which cannot be changed. We
already have a ticket for SSSD to let the locator plugin return more than one
address to fix this.
HTH
bye,
Sumit
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org