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 familiarize yourself at a minimum with the following 
two articles:

https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/

https://jhrozek.wordpress.com/2015/03/11/anatomy-of-sssd-user-lookup/

Also, this is very good document to familiarize yourself with, it has a lot of 
very detailed and use information.

https://fedorahosted.org/sssd/wiki/InternalsDocs

My personal opinion based on experience is that if you are going to be 
leveraging sssd in a trusted AD setup, you should be prepared to take on 
performance tuning considerations and become intimately familiar with the 
internals of sssd, specifically how a lookup works, and how to tune sssd as 
well as 389ds.  You should know the difference between the mapped memory cache, 
the sysdb, how to use ldbsearch to inspect the cache, etc.  The learning curve 
is a little steep but once you get over it it’s not that bad. 

Dan

> On Feb 1, 2017, at 2:53 AM, Troels Hansen <t...@casalogic.dk> wrote:
> 
> 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 ldap_enumaration_search_timeout which defaults to 60.
> 
> rm -fr /var/lib/sss/{mc,db}/* && systemctl restart sssd && time id shja
> 
> However, I'm unable to crank it up on the server as it seems to be adjusted 
> Down to 60 Again?
> 
> Wed Feb  1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_get_options] (0x0400): 
> Option ldap_enumeration_search_timeout has value 120
> (Wed Feb  1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_copy_options_ex] 
> (0x0400): Option ldap_enumeration_search_timeout has value 60
> (Wed Feb  1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_copy_options_ex] 
> (0x0400): Option ldap_enumeration_search_timeout has value 60
> 
> LDAP seems speedy enough, not timeouts while querying it manually while a 
> client is doing a user lookup.
> 
> ----- On Jan 30, 2017, at 6:06 PM, Sullivan, Daniel [CRI] 
> dsulliv...@bsd.uchicago.edu wrote:
> 
>> 
>> If the timeout is occurring on the server, I would start by increasing one or
>> both of these values:
>> 
>> ldap_opt_timeout
>> ldap_search_timeout
>> 
>> If that doesn’t work I’d take look to see if the 389 server is under high 
>> load
>> when you are performing this operation.  The easiest way I have found to do
>> this is to just execute an LDAP query directly against the IPA server when 
>> you
>> are performing an id lookup, for example:
>> 
>> ldapsearch -D "cn=Directory Manager" -w <pw> -s base -b "cn=config"
>> "(objectclass=*)”
>> 
>> If the LDAP server is not responsive you probably need to increase the 
>> number of
>> worker threads for 389ds.  Also, you might want to disable referrals, check 
>> out
>> the man pages for this;
>> 
>> ldap_referrals = false
>> 
>> Also, FWIW, if you crank up debug logging on the sssd client, you should be 
>> able
>> to see the amount of seconds of timeout assigned to the operation, and 
>> witness
>> the fact that the operation is actually timing out by inspecting the logs
>> themselves.  The logs can get a little verbose but the data is there.
>> 


-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to