[Freeipa-users] Re: Secondary groups intermittently missing from id/groups lookups

On Thu, Jun 18, 2020 at 09:43:09AM -0500, Alfred Victor wrote: > We have had another look and still cannot find any logical reason the group > memberships aren't reaching id/groups/sssd. The ldapsearch provided and ipa > user-show work fine but nothing else. It is also a somewhat random issue, > and will randomly return x number of secondary groups by id/groups commands > (but rarely if ever all), which is not something I would expect from > something deterministic like an ACL. Can anyone please advise if they have > any further ideas on this issue as it could really save us some time and > uncertainty :) Below please see ldapsearch run authenticated as the host, > which does not return memberOf, however if ldapsearch against 'member' > attribute from groups it works but this does not explain why we see > different results every x tries with id/groups/sssd cache cleared > destructively. Is this expected? Hi, the ldapsearch should have returned the memberOf attributes so there is something wrong with the ACI in the IPA directory server which prevents hosts to read this attribute. What does ipa permission-show 'System: Read User Membership' return? If SSSD cannot get some information it will used cached data. For id or groups this means since the memberships of the user cannot be read directly since the memberOf attribute cannot be read, the returned group memberships are based on the groups which are already looked up and the user is a member of. Since it is not deterministic which group is already looked up at the time id or groups is called the response which change over time. HTH bye, Sumit > > ]# kinit -k host/NODE-1-2.redacted.com(a)redacted.COM > ]# ldapsearch -Y GSSAPI -b 'cn=accounts,dc=redacted,dc=com' > '(&(uid=ipatest)(objectclass=posixAccount)(&(uidNumber=*)(!(uidNumber=0))))' > uid memberof -L > SASL/GSSAPI authentication started > SASL username: host/NODE-1-2.redacted.com(a)redacted.com > SASL SSF: 56 > SASL data security layer installed. > version: 1# > # LDAPv3 > # base <cn=accounts,dc=redacted,dc=com> with scope subtree > # filter: (&(uid=ipatest)(objectclass=posixAccount)(&(uidNumber=*)(!(uidNumber=0)))) > # requesting: uid memberof > ## ipatest, users, accounts, redacted.com > dn: uid=ipatest,cn=users,cn=accounts,dc=redacted,dc=com > uid: ipatest# search result# numResponses: 2 > # numEntries: 1 > > > > Alfred > > On Wed, Jun 17, 2020 at 9:54 AM Alfred Victor <alvic266(a)gmail.com&gt; wrote: > > > Hi Sumit, > > > > I have run those commands and both show the same amount of memberOf > > attributes. At first, with a nested group there were 143 so for a test with > > fewer groups, I removed the nested group but the result is the same. With > > 20 groups, and sssd cache destructively cleared and sssd restarted, the > > groups reach the ipa command and the ldapsearch fine but not id/groups > > commands. > > > > Alfred > > > > On Wed, Jun 17, 2020 at 1:39 AM Sumit Bose <sbose(a)redhat.com&gt; wrote: > > > >> On Tue, Jun 16, 2020 at 05:12:09PM -0500, Alfred Victor via FreeIPA-users > >> wrote: > >> > I should note the problem exists on latest CentOS7 with fully up to date > >> > rpms on both client/server. > >> > > >> > Alfred > >> > > >> > On Tue, Jun 16, 2020 at 3:02 PM Alfred Victor <alvic266(a)gmail.com&gt; > >> wrote: > >> > > >> > > Hi all, > >> > > > >> > > We have built a FreeIPA system and used ipa migrate-ds to migrate and > >> are > >> > > testing the environment however we have a stubbornly persistent issue > >> with > >> > > gid array from posix commands or when dealing with filesystem > >> ownerships. > >> > > When I create a user in IPA, then add some groups, the issue is > >> immediately > >> > > present. In this case these first two below are missing a group > >> ("testers"): > >> > > > >> > > [alvic@HOD28 ~]$ id ipatest > >> > > > >> > > uid=464200021(ipatest) gid=464200021(ipatest) > >> > > groups=464200021(ipatest),464200000(admins) > >> > > > >> > > And another: > >> > > > >> > > [alvic@NODE-1-1 ~]$ id ipatest > >> > > > >> > > uid=464200021(ipatest) gid=464200021(ipatest) > >> > > groups=464200021(ipatest),464200000(admins) > >> > > > >> > > > >> > > More commonly, this is the case where only primary gid is returned, > >> and > >> > > both groups are missing: > >> > > > >> > > > >> > > [alvic@NODE-1-2 ~]$ id ipatest > >> > > > >> > > uid=464200021(ipatest) gid=464200021(ipatest) > >> groups=464200021(ipatest) > >> > > > >> > > > >> > > > >> > > The client systems were each provisioned like so, and we have also > >> tested > >> > > and found this issue on a totally up to date new CentOS 7 system: > >> > > > >> > > > >> > > ipa-client-install -U -q -p [redacted] --domain=redacted.com > >> --server= > >> > > ipa.redacted.com --fixed-primary --force-join > >> > > > >> > > > >> > > > >> > > We have also attempted a full update of the IPA server via yum update > >> and > >> > > restarted it but the issue is incredibly common. We have also enabled > >> sssd > >> > > debuglevel 7 and I noted the following line: > >> > > > >> > > > >> > > > >> > > (Tue Jun 16 10:01:09 2020) [sssd[be[redacted.com]]] [sdap_save_user] > >> > > (0x0400): Original memberOf is not available for [ > >> ipatest(a)redacted.com]. > >> > > > >> > > > >> > > Worth noting that groups display fine for a user, without fail, only > >> if > >> > > using "ipa user-show" > >> > >> Hi, > >> > >> there might be a permission issue when reading the memberOf attribute. > >> > >> Can you first check if memberOf attributes are shown if you call: > >> > >> ipa user-show --all --raw ipatest > >> > >> The next step is the check ldapsearch > >> > >> kdestroy -A > >> kinit -k > >> ldapsearch -Y GSSAPI -b > >> 'uid=ipatest,cn=users,cn=accounts,dc=your,dc=ipa,dc=domain' > >> > >> You can copy the DN ('uid=ipatest,cn=...) from the first line of the > >> 'ipa user-show' output. Please check if ldapsearch returns the same > >> memberOf attributes as 'ipa user-show' > >> > >> bye, > >> Sumit > >> > >> > > > >> > > > >> > > > >> > > Alfred > >> > > > >> > >> > _______________________________________________ > >> > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org > >> > To unsubscribe send an email to > >> freeipa-users-leave(a)lists.fedorahosted.org > >> > Fedora Code of Conduct: > >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > >> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > >> > List Archives: > >> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho... > >> > >>