On Mon, Jul 18, 2016 at 11:56:24AM +0000, Sullivan, Daniel [AAA] wrote:
> Hi, Jakub,
> In line with your performance tuning document referenced prior in this
> thread, I’ve actually already implemented the three configuration changes
> you specified (prior to identifying this issue).  Right now I am focusing on
> the use case documented below, because as of right now I am unable to get
> that user populated into a client cache with sssd 1.14, at all.  In other
> cases for individual users (prior to implementing tmpfs for example), it
> seemed like an initial lookup on a client failed, then subsequent lookups
> would succeed, presumably as a result of the DC eventually looking up and
> caching the user.  This user (the one I can’t seem to lookup on a client)
> is a member of a large number of groups, and also some of these groups
> have longer names with spaces and special characters in them (i.e. $ and
> . @)   I haven’t gone through and checked if one of these groups has a
> large number of users, primarily because I am able to lookup users that
> are members of groups with a large number of members (over 1000) already.
> This is an actual group that this user is a member of, for example:
> 788658174(members of this group will have full mailbox access and send as 
> rights to 
> urbj...@health.bsd.uchicago.edu<mailto:urbj...@health.bsd.uchicago.edu> 
> mailbox)
> Right now my theory is that the @ in this group name is causing the lookup to 
> fail, as it is used as a character to specify the actual domain of a trusted 
> group, although that has yet to be verified.

Yes, I would say this is the issue, because sssd tries to split the
input string into name,domain components according to the re_expression
value which tries to match anything before the first @ as a groupname
and the rest as the username.

Are also users that are not part of this group misbehaving?

> NSS - https://gist.github.com/dsulli99/01715234efab09772e8236a13e4f4ef5
> IPA - https://gist.github.com/dsulli99/f3cc92d7c32061fd4676a83a039c31b1
> Here is the full list of groups the user is a member of, from the output of 
> the id command on a DC:
> uid=339741696(hah...@bsdad.uchicago.edu<mailto:hah...@bsdad.uchicago.edu>) 
> gid=339741696(hah...@bsdad.uchicago.edu<mailto:hah...@bsdad.uchicago.edu>) 
> groups=339741696(hah...@bsdad.uchicago.edu<mailto:hah...@bsdad.uchicago.edu>),788655857(hsd$
>  kcbd 6260 conference room freebusy 
> r...@bsdad.uchicago.edu<mailto:r...@bsdad.uchicago.edu>),788668882(phs 
> phsapps remoteapp default 
> a...@bsdad.uchicago.edu<mailto:a...@bsdad.uchicago.edu>),788670425(phs 
> phsapps notepad2 
> us...@bsdad.uchicago.edu<mailto:us...@bsdad.uchicago.edu>),788670429(phs 
> phsapps cmd 
> us...@bsdad.uchicago.edu<mailto:us...@bsdad.uchicago.edu>),339797692(cri-hpc_allus...@bsdad.uchicago.edu<mailto:cri-hpc_allus...@bsdad.uchicago.edu>),788670440(phs
>  phsapps r v3.2.0 32-bit 
> us...@bsdad.uchicago.edu<mailto:us...@bsdad.uchicago.edu>),788672389(phs 
> phsapps remote desktop 
> us...@bsdad.uchicago.edu<mailto:us...@bsdad.uchicago.edu>),788655856(hsd$ 
> w230 conference room freebusy 
> r...@bsdad.uchicago.edu<mailto:r...@bsdad.uchicago.edu>),788670441(phs 
> phsapps r v3.2.0 64-bit 
> us...@bsdad.uchicago.edu<mailto:us...@bsdad.uchicago.edu>),788672413(phs 
> phsapps r v3.2.3 64-bit 
> us...@bsdad.uchicago.edu<mailto:us...@bsdad.uchicago.edu>),788670431(phs 
> phsapps file explorer 
> us...@bsdad.uchicago.edu<mailto:us...@bsdad.uchicago.edu>),788670428(phs 
> phsapps adobe reader xi 
> us...@bsdad.uchicago.edu<mailto:us...@bsdad.uchicago.edu>),788609545(adm-trackitus...@bsdad.uchicago.edu<mailto:adm-trackitus...@bsdad.uchicago.edu>),788615356(hsd$
>  workstation local 
> lo...@bsdad.uchicago.edu<mailto:lo...@bsdad.uchicago.edu>),339794097(cri-lmem_cri_us...@bsdad.uchicago.edu<mailto:cri-lmem_cri_us...@bsdad.uchicago.edu>),788670445(phs
>  phsapps taskmgr 
> us...@bsdad.uchicago.edu<mailto:us...@bsdad.uchicago.edu>),788624309(hsd$ 
> pr...@bsdad.uchicago.edu<mailto:pr...@bsdad.uchicago.edu>),788670436(phs 
> phsapps notepadplusplus 
> us...@bsdad.uchicago.edu<mailto:us...@bsdad.uchicago.edu>),788654299(cri-all_gro...@bsdad.uchicago.edu<mailto:cri-all_gro...@bsdad.uchicago.edu>),788670434(phs
>  phsapps notepad 
> us...@bsdad.uchicago.edu<mailto:us...@bsdad.uchicago.edu>),788670438(phs 
> phsapps plink 1.90 
> us...@bsdad.uchicago.edu<mailto:us...@bsdad.uchicago.edu>),788670427(phs 
> phsapps office access 2013 
> us...@bsdad.uchicago.edu<mailto:us...@bsdad.uchicago.edu>),788655855(hsd$ 
> w229 conference room freebusy 
> r...@bsdad.uchicago.edu<mailto:r...@bsdad.uchicago.edu>),788635799(adm-sde-clie...@bsdad.uchicago.edu<mailto:adm-sde-clie...@bsdad.uchicago.edu>),788670439(phs
>  phsapps office powerpoint 2013 
> u...@bsdad.uchicago.edu<mailto:u...@bsdad.uchicago.edu>),788610792(hsd$ all 
> health 
> stud...@bsdad.uchicago.edu<mailto:stud...@bsdad.uchicago.edu>),788655854(hsd$ 
> n102 conference room freebusy 
> r...@bsdad.uchicago.edu<mailto:r...@bsdad.uchicago.edu>),339793627(cri-galaxy_web_us...@bsdad.uchicago.edu<mailto:cri-galaxy_web_us...@bsdad.uchicago.edu>),788670444(phs
>  phsapps statamp 14 
> us...@bsdad.uchicago.edu<mailto:us...@bsdad.uchicago.edu>),339792922(cri-all_us...@bsdad.uchicago.edu<mailto:cri-all_us...@bsdad.uchicago.edu>),788670442(phs
>  phsapps rstudio 
> us...@bsdad.uchicago.edu<mailto:us...@bsdad.uchicago.edu>),788655852(hsd$ 
> freebusy read for all conference 
> ro...@bsdad.uchicago.edu<mailto:ro...@bsdad.uchicago.edu>),788600513(domain 
> us...@bsdad.uchicago.edu<mailto:us...@bsdad.uchicago.edu>),788670430(phs 
> phsapps office excel 2013 
> us...@bsdad.uchicago.edu<mailto:us...@bsdad.uchicago.edu>),788672414(phs 
> phsapps r v3.2.3 32-bit 
> us...@bsdad.uchicago.edu<mailto:us...@bsdad.uchicago.edu>),339800245(cri-ahsan_...@bsdad.uchicago.edu<mailto:cri-ahsan_...@bsdad.uchicago.edu>),788655034(fml$
>  n108 conference room freebusy 
> r...@bsdad.uchicago.edu<mailto:r...@bsdad.uchicago.edu>),788670446(phs 
> phsapps office word 2013 
> us...@bsdad.uchicago.edu<mailto:us...@bsdad.uchicago.edu>),788670437(phs 
> phsapps plink 1.07 
> us...@bsdad.uchicago.edu<mailto:us...@bsdad.uchicago.edu>),788670443(phs 
> phsapps sas 9.4 
> us...@bsdad.uchicago.edu<mailto:us...@bsdad.uchicago.edu>),788610930(hsd$ 
> proof 
> po...@bsdad.uchicago.edu<mailto:po...@bsdad.uchicago.edu>),788670432(phs 
> phsapps mmc 
> us...@bsdad.uchicago.edu<mailto:us...@bsdad.uchicago.edu>),788670433(phs 
> phsapps mobaxterm 
> us...@bsdad.uchicago.edu<mailto:us...@bsdad.uchicago.edu>),788658174(members 
> of this group will have full mailbox access and send as rights to 
> urbj...@health.bsd.uchicago.edu<mailto:urbj...@health.bsd.uchicago.edu> 
> mailbox)
> I am not particularly well versed in deciphering IPA/NSS logs for SSSD,
> but at first review nothing is blaring, aside from these line in the NSS
> log, which doesn’t provide much good information:
> Error: 3, 0, Account info lookup failed
> Will try to return what we have in cache
> My goal is to spend at least some time focusing on this today to try and 
> further identify root cause of being unable to lookup this user.  I will 
> report back if I find anything meaningful. In the meantime I would appreciate 
> any advisement that could be provided.
> Thank you for replying to me.
> Best,
> Dan Sullivan
> On Jul 18, 2016, at 3:19 AM, Jakub Hrozek 
> <jhro...@redhat.com<mailto:jhro...@redhat.com>> wrote:
> On Fri, Jul 15, 2016 at 04:35:54PM +0000, Sullivan, Daniel [AAA] wrote:
> Jakub,
> Thank you for replying to me.  Before I forget I will say that I am still on 
> sssd 1.13 on the domain controller; I didn’t upgrade it because I haven’t had 
> any problems logging into that system yet.  That being said:
> Thank you, but did this command return "No such user” ?
> Yes.  Whenever this occurs "No such user" is the result from the id command 
> executed on the client.
> If it did, was the user cached previously (iow, was there a successfull
> lookup before) ?
> No, this is the first time the user has ever been looked up.  As far as I 
> know the user has never been successfully entered into the cache.  Similarly, 
> the user has never logged in to the IPA server via an SSSD client.
> Ah, thank you, if the user has not been cached before, then it's
> expected that the lookup has nothing to fall back to if the client fails
> to look up information from the server.
> Here is an example of a failed lookup from a client:
> [root@cri-kcriwebgdp1 problem]# id hahsan
> id: hahsan: No such user
> The DC logs for this operation are
> NSS - https://gist.github.com/dsulli99/01715234efab09772e8236a13e4f4ef5
> IPA - https://gist.github.com/dsulli99/f3cc92d7c32061fd4676a83a039c31b1
> Thank you, I see that there is quite a lot of groups and the lookup
> takes a bit of time. I wonder if any of the groups the user is a member
> of are large?
> If yes (and since moving the cache to tmpfs had helped), I wonder if
> also using ignore_group_members would mitigate the issue further, like
> this:
> subdomain_inherit = ignore_group_members, ldap_purge_cache_timeout
> ignore_group_members = True
> ldap_purge_cache_timeout = 0
> These would go into the domain section on the server itself.
> ********************************************************************************
> This e-mail is intended only for the use of the individual or entity to which
> it is addressed and may contain information that is privileged and 
> confidential.
> If the reader of this e-mail message is not the intended recipient, you are 
> hereby notified that any dissemination, distribution or copying of this
> communication is prohibited. If you have received this e-mail in error, 
> please 
> notify the sender and destroy all copies of the transmittal. 
> Thank you
> University of Chicago Medicine and Biological Sciences 
> ********************************************************************************

Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to