[SSSD-users] FreeIPA/SSSD LDAP cross-forest trust slow queries

Lukas Slebodnik lslebodn at redhat.com
Fri Feb 27 22:01:56 UTC 2015



----- Original Message -----
> From: "Aviolat Romain" <Romain.Aviolat at nagra.com>
> To: sssd-users at lists.fedorahosted.org
> Sent: Thursday, February 26, 2015 5:51:36 PM
> Subject: [SSSD-users] FreeIPA/SSSD LDAP cross-forest trust slow queries
> 
> Hi,
> 
> 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 at 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 at 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 at ad.domain2.net member of many groups? How many?

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?

You can use netstat for detection of opened connections from SSSD
netstat -tpn | grep sssd_be


> 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 [9][ad.domain2.net] 
[be_pam_handler_callback] (0x0100): Sent result [9][ad.domain2.net] 
[child_sig_handler] (0x0100): child [10313] finished successfully.

The data has already been cached and therefore authentication did not fail and was very fast.
I could not see a reason in sssd log file why ad.domain2.net  was offline.

LS


More information about the sssd-users mailing list