Hi Sumit,
That's correct, it is a copy/paste.
Alfred
On Thu, Jun 18, 2020 at 10:51 AM Sumit Bose <sb...@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 <sb...@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....@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....@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 <alvic...@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 <sb...@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 <
> alvic...@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 [
> > > > >> ipat...@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@lists.fedorahosted.org
> > > > >> > To unsubscribe send an email to
> > > > >> freeipa-users-le...@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.fedorahosted.org
> > > > >>
> > > > >>
> > >
> > >
>
>
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
