[Freeipa-users] Slow logins with multi site replication

Neal Harrington | i-Neda Ltd nharrington at i-neda.com
Thu Aug 25 16:11:29 UTC 2016


> > Hi,

> >
> > I am experiencing slow logins and sudo authentication for servers joined to my FreeIPA domain. I have been following the other recent thread on slow logins and believe my issue is different.
> >
> > I have replication setup with 2 FreeIPA servers at each of 3 sites. The replication is working well and I am able to login correctly on client servers with correct sudo permissions etc. Logins seem to take a long time however. There seems to be some kind of DNS/connection timeout issues, see the example below where the client times out on the auth01 server, then retries and connects. I have also seen it switch to an alternate IPA server on timeout. Total delay in this example is about 10 seconds however it can take longer (approx 30 seconds). It is worth mentioning that client servers in each site cannot connect to IPA servers is a different site - however in the example below the auth01 IPA server is in the same site as the client server. I'm not sure if there is any way to make the IPA clients site aware so they prefer to log in to a local server?
> >
> >
> > On the IPA servers themselves there is no noticeable delay and once I have authenticated with sudo once, subsequent attempts in the same login are also near instant. I have not been able to find any reason for this delay in any logs (which probably just means I'm not looking in the right place).
> >
> >
> > DNS servers are running on each IPA server and responding well whenever I have tested.
> >
> >
> > IPA Servers: CentOS 7.2.1511 running IPA 4.2.0 (from standard CentOS repo)
> >
> > Client servers: Ubuntu 14.04 running IPA 3.3.4 (From standard Ubuntu repo)
> >
> >
> > Any comments or suggestions greatly appreciated.
> >
> >
> > Thanks,
> >
> > Neal.
> >
> >
> > Example sssd log for a "sudo -l" attempt.
> >
> > (Mon Aug 1 14:39:59 2016) [sssd[be[fqdn.com]]] [krb5_child_timeout]
> > (0x0040): Timeout for child [7430] reached. In case KDC is distant or
> > network is slow you may consider increasing value of krb5_auth_timeout.
> > (Mon Aug 1 14:39:59 2016) [sssd[be[fqdn.com]]] [krb5_auth_done] (0x0020):
> > child timed out!
>
> These debug messages seem to be telling you what the problem is. Have
> you tried how long does it take to kinit (preferably with
> KRB5_TRACE=/dev/stderr prepended) ?

Hi Jakub,

Thanks for your response and sorry for my delay in replying. kinit takes between 2 and 25 seconds to complete - the KRB5_TRACE option shows it trying a random auth server, timing out and trying another random server until it picks a local server which then completes almost immediately. This seems to confirm that the problem is simply the server tries to authenticate against a FreeIPA server that is unreachable and times out causing the randomly slow logins. Given 6 auth servers with only 2 on each site there is a ~ 10% chance of hitting 3 bad servers in a row before login succeeds - if each takes 20 seconds that would explain the random login times of a few sec - 1 minute.

If I enter the local kdc servers manually in the realm section of krb5.conf then ssh logins always happen in < 2sec - however I would prefer to avoid the manual step of configuring and updating this (planning to expand out to a few hundred servers over 4-5 sites). Manually setting these is likely to lead to mistakes and it just feels inelegant compared to DNS SRV records.

I have seen https://www.freeipa.org/page/V4/DNS_Location_Mechanism which looks good but is a proposal from 2013 with no indications that it has actually been developed. I was also very interested by https://www.freeipa.org/page/Howto/IPA_locations which would be perfect - except the "ipa location-add" commands do not seem to be recognised by my FreeIPA installs.

Am I missing a better way to handle the case of multiple locations with clients in Location A being unable to authenticate against FreeIPA servers at location B?

Any suggestions greatly appreciated.

Thanks,
Neal.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20160825/a8e3a541/attachment.htm>


More information about the Freeipa-users mailing list