Hi all
Just wanted to follow up on this as I created a case with RedHat, and here is
their findings, for all of you to share:
>From RedHat support:
--
As per the current discussion with our engineering team.
---
The client requests info about a user. This goes to the
Cache is verified valid by looking at the cache files /var/lib/sss/db/ ldb
files.
Also, if I lookup the user on the IPA server I get a fast response.
Looking up the user on a client which have a valid cache return the user within
a few ms or secs.
Invalidating the cache on the client with
Are you actually logging in or or just doing a lookup on a user? I remember
reading somewhere that groups are always re-evaluated at the point of login,
regardless of what is in the cache. I am not sure if this is accurate or the
implications of whether or not it is on the client, server or
No, ignore_group_members option is already set.
Tried setting and removing it on the client but didn't make a huge different.
Is a client have an completely empty cache, newly joined, empty
/var/lig/sssd/db and mc cache or something, the IPA server ALWAYS asks the AD
for group info, despite
Have you looked at the ignore_group_members option? Maybe this is the problem
you are seeing?
https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/
==snip==
ignore_group_members
Normally the most data-intensive operation is downloading the groups
Hi
I'm aware of the anatomy of how the lookup is done, but I would suppose a valid
cache on the IPA server would result in the cache from the IPA server being
used?
I have been debugging this issue some more, and can confirm is the client have
its sssd cache invalidated by "sss_cache -E" and
Have you checked to see if the user is expired in the cache, or if it is
impacted by entry_cache_nowait_percentage (ref sssd.conf). The default entry
timeout is only 90 minutes and entry_cache_nowait_percentage default is 50.
ldbsearch -H /var/lib/sss/db/timestamps_xxx.xxx.uchicago.edu.ldb >
The ldap_enumeration_search_timeout is for enumeration, this is for looking up
all users, try using the ldap_opt_timeout and or ldap_opt_timeout for a single
user lookup. If a lookup is timing out you will definitely see it in your
domain logs, it’s hard to miss.
I would take the time to
>From looking af at TCP dump, I can see that if a client requests a AD user
>from IPA, IPA does a full user lookup in AD, even though the IPA server have
>the user in local cache?
It looks like a single group generates a LOT of traffic to AD like:
client -> IPA
IPA -> client
IPA -> AD
AD -> IPA
Hmm, suspect its happening on the server.. thous I haven't been able to
pinpoint a log entry that confirms my suspecting.
I have pinpointed the timeout to happen after 58 seconds after completely
removing the SSSD cache and restaring SSSD, which leads me to think my issue is
related to
I have had to deal with the symptoms you describe, never with 730 groups
though. Based on my experience doing a lookup for a user in an AD trusted
domain is a resource intensive process on the server. I’d first start by
taking a look at your logs to see if the lookup is failing on the server
Hi there
I'm trying to debug on a strange IPA timeout issue.
Its SSSD 1.14, IPA 4.4, RHEL 7.3.
2 IPA servers in AD trust.
Besides being a bit slow on groups membership lookups on users with a moderate
number of Groups, there are some users with a HUGE amount of nested groups.
A server
12 matches
Mail list logo
