> From: "Aviolat Romain"
> To: sssd-users(a)lists.fedorahosted.org
> Sent: Thursday, February 26, 2015 5:51:36 PM
> Subject: [SSSD-users] FreeIPA/SSSD LDAP cross-forest trust slow
> We have setup FreeIPA (VERSION: 4.1.2, API_VERSION: 2.109) in our
> realm (IPA.DOMAIN1.COM
), with trust to an AD forest (DOMAIN2.NET
> which itself has trust to AD.DOMAIN2.NET
, where the corporate users
> are). Everything works fine when using Kerberos, we can obtain tickets
> from AD.DOMAIN2.NET
and authenticate to services in IPA.DOMAIN1.COM
> We can also do "getent passwd user(a)ad.domain2.net" on a host enrolled in
FreeIPA and quickly get a result.
> But we have some legacy applications that perform authentication with
> simple LDAP binds, so we have the compat tree enabled, and while
> trying to authenticate users in the AD.DOMAIN2.NET
realm this way
> eventually succeeds, it takes an awfully long time (30 seconds or so,
> sometimes more), with a lot going on between the AD and FreeIPA. We've
> attached the log file of SSSD (version 1.12.4, we've upgraded based on
> advice from IRC #sssd, but the problem didn't go away) from the
> FreeIPA server while running "ldapwhoami -D
> uid=user(a)ad.domain2.net,cn=users,cn=compat,dc=ipa,dc=domain1,dc=com -W" from a
client machine. The debug level was set to 0x07f0.
The slow execution and big traffic between FreeIPA and AD can be caused by downloading a
huge count of groups.
Is the user user(a)ad.domain2.net member of many groups? How many?
The user is a direct member of 26 groups and an indirect member of 110 groups.
I could also see in log file that AD infrastructure is quite big.
Got 8 primary and 20 backup servers
Could you confirm that sssd was connected to the nearest and the fastest AD server?
Yes the infrastructure is quite big, and yes we're connected to the nearest and the
fastest AD servers.
You can use netstat for detection of opened connections from SSSD
netstat -tpn | grep sssd_be
Of course, here's the output asked during a "slow" query:
# netstat -tpn | grep sssd_be
tcp 0 0 10.XXX.XXX.XXX:33364 10.XXX.XXX.10:389 ESTABLISHED
tcp 0 0 10.XXX.XXX.XXX:32883 10.XXX.XXX.11:389 ESTABLISHED
tcp 0 0 10.XXX.XXX.XXX:56351 10.XXX.XXX.12:3268 ESTABLISHED
> On (rare) occasions, authentication is very fast while running the
> exact same command on the client machine. We've also attached the SSSD
> log file when that happens, for comparison. The log files have been
> sanitized and the slow log output was bit simplified, we removed 25
> repeated events where sssd was trying to resolve unknown SIDs, it
> would have taken too much time to sanitize so we left 5 caching events
> only (we made a remark on the log file where we removed those lines.)
I can see in sssd_fast_query.log that request to AD was performed in offline mode
[be_pam_handler_callback] (0x0100): Backend returned: (1, 9, <NULL>) [Provider is
Offline (Authentication service cannot retrieve authentication info)]
[be_pam_handler_callback] (0x0100): Sending result [ad.domain2.net
[be_pam_handler_callback] (0x0100): Sent result >[ad.domain2.net]
[child_sig_handler] (0x0100): child  finished successfully.
The data has already been cached and therefore authentication did not fail and was very
I could not see a reason in sssd log file why ad.domain2.net
I couldn't see a reason too... I'm 100% sure that the infra (AD servers and
network) is always UP. Tell me if I can dig a bit further into some log files.
Thanks again for your help.
sssd-users mailing list