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: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
