----- Original Message -----
From: "Aviolat Romain" <Romain.Aviolat(a)nagra.com>
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 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(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?
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