>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
IPA -> AD
IPA -> Second AD
Second AD -> IPA
IPA -> Second AD
IPA -> AD
AD -> IPA
IPA -> AD
IPA -> client
client -> IPA
IPA -> Client

Something similar continues for every group the user has.

Soo, I guess the question that I haven't been able to find documented anywhere. 
Isn't the SSSD group cache on the IPA servers supposed to be used then a sssd 
client requests a user?



----- On Feb 1, 2017, at 9: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

-- 
Med venlig hilsen 

Troels Hansen 

Systemkonsulent 

Casalogic A/S 


T (+45) 70 20 10 63 

M (+45) 22 43 71 57 

Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og 
meget mere.

-- 
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