>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 [email protected] 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] > [email protected] 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
