Secondary groups intermittently missing from id/groups lookups

[Alfred Victor]

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"



Alfred

[Alfred Victor]

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"
>
>
>
>  Alfred
>

[Sumit Bose]

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/[e-mail]...

[Alfred Victor]

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/[e-mail]...
>
>

[Alfred Victor]

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?

]# 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/[e-mail]...
> >
> >

[Sumit Bose]

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/[e-mail]...
>  >>
>  >>

[Alfred Victor]

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 <sbose(a)redhat.com&gt; 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/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/[e-mail]...
>  > >>
>  > >>
>
>

[Sumit Bose]

On Thu, Jun 18, 2020 at 10:25:43AM -0500, Alfred Victor wrote:
>  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 
Hi,

are you sure it is 'Excluded attributes:' and not 'Effective
attributes:'?

bye,
Sumit

>  
>    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 <sbose(a)redhat.com&gt; 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/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/[e-mail]...
>  > > >>
>  > > >>
>  >
>  >

[Alfred Victor]

Hi Sumit,

That's correct, it is a copy/paste.

Alfred

On Thu, Jun 18, 2020 at 10:51 AM Sumit Bose <sbose(a)redhat.com&gt; wrote:

>  On Thu, Jun 18, 2020 at 10:25:43AM -0500, Alfred Victor wrote:
>  > 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
>
>  Hi,
>
>  are you sure it is 'Excluded attributes:' and not 'Effective
>  attributes:'?
>
>  bye,
>  Sumit
>
>  >
>  >   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 <sbose(a)redhat.com&gt; 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/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/[e-mail]...
>  > > > >>
>  > > > >>
>  > >
>  > >
>
>

[Sumit Bose]

On Thu, Jun 18, 2020 at 11:04:04AM -0500, Alfred Victor wrote:
>  Hi Sumit,
>  
>  That's correct, it is a copy/paste. 
Hi,

can you try to call

    kinit admin
    ipa permission-mod --excludedattrs='' 'System: Read User Membership'

bye,
Sumit

>  
>  Alfred
>  
>  On Thu, Jun 18, 2020 at 10:51 AM Sumit Bose <sbose(a)redhat.com&gt; wrote:
>  
>  > On Thu, Jun 18, 2020 at 10:25:43AM -0500, Alfred Victor wrote:
>  > > 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
>  >
>  > Hi,
>  >
>  > are you sure it is 'Excluded attributes:' and not 'Effective
>  > attributes:'?
>  >
>  > bye,
>  > Sumit
>  >
>  > >
>  > >   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 <sbose(a)redhat.com&gt; 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/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/[e-mail]...
>  > > > > >>
>  > > > > >>
>  > > >
>  > > >
>  >
>  >