> Are also users that are not part of this group misbehaving? Not that I am aware of. I’ll get you a real answer though. Are there any known workarounds to the @ problem used to transform group names (i.e. a more robust ‘override_space’ option)? I looked a the doc briefly but can’t find anything.
I was thinking maybe could use re_expression to tokenize group names by taking the last token parsed by @ for the domain portion, although this seems kind of hacky, also not sure if it would work. Dan > On Jul 18, 2016, at 8:23 AM, Jakub Hrozek <jhro...@redhat.com> wrote: > > 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 users@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 users@bs dad.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 >> ******************************************************************************** ******************************************************************************** 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
