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> 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> 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>
> > 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>
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>
> > > >> 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...
> > > >>
> > > >>
> >
> >