Hi Sumit, [redacted@NODE-1-2 ~]$ ipa permission-show 'System: Read User Membership'
Permission name: System: Read User Membership Granted rights: read, compare, search Excluded attributes: memberof Default attributes: memberof Bind rule type: all Subtree: cn=users,cn=accounts,dc=redacted,dc=com Type: user Permission flags: SYSTEM, V2, MANAGED Alfred On Thu, Jun 18, 2020 at 10:16 AM Sumit Bose <[email protected]> wrote: > 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/[email protected] > > ]# 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/[email protected] > > 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> > > >> 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 [ > > >> [email protected]]. > > >> > > > > >> > > > > >> > > 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 -- [email protected] > > >> > To unsubscribe send an email to > > >> [email protected] > > >> > 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/[email protected] > > >> > > >> > >
_______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]
