On Fri, 2020-01-24 at 17:30 +0100, Samuel Cabrero wrote:
> On Wed, 2020-01-22 at 09:39 +0100, Sumit Bose wrote:
> > On Fri, Jan 17, 2020 at 05:32:19PM +0100, Sumit Bose wrote:
> > > On Wed, Jan 15, 2020 at 07:59:13PM +0100, Samuel Cabrero wrote:
> > > > Hi,
> > > >
> > > > I found the filtering of domain-local groups was implemented
> > > > after a
> > > > change to query the group memberships from the LDAP server of
> > > > the
> > > > domain the user belongs to instead of the global catalog, which
> > > > had the
> > > > side effect of retrieving the DLGs of trusted domains [1].
> > > >
> > > > This DLGs are cached but treated as non-POSIX gruops (no gid
> > > > number
> > > > assigned and not returned), after the commit implementing the
> > > > filter
> > > > [2].
> > > >
> > > > I have found an use case where not filtering domain-local
> > > > groups
> > > > would
> > > > be useful. If you want to use group memberships in sudo rules
> > > > to
> > > > allow
> > > > temporary sudo access, the replication latency of global groups
> > > > is very
> > > > high and can take up to 15 minutes, but using domain local
> > > > groups
> > > > replication is done in less than one minute.
> >
> > Hi,
> >
> > for your use case you do not need the patch I mentioned below. The
> > filtering from
https://pagure.io/SSSD/sssd/issue/2178 only applies
> > to
> > 'domain local' groups from remote (non local) domains, the 'domain
> > local' group from the local domain are still available.
> >
> > If you add a user from the remote domain to a 'domain local' group
> > of
> > the local domain your use case should work as well.
> >
> > Older versions had issues adding remote users to local 'domain
> > local'
> > groups as can be seen in
https://pagure.io/SSSD/sssd/issue/3206,
> > but
> > it
> > should work properly with current versions.
> >
> > Btw, another reason for filtering remote 'domain local' groups is
> > that
> > the PAC in Kerberos ticket for services from the local domain (e.g.
> > for
> > the local host) do not contain the remote 'domain local' groups as
> > well.
> > Of course the PAC for a service from the remote domain will contain
> > the
> > 'domain local' groups of the remote domain but from the remote
> > domain
> > and no 'domain local' groups from any other domain.
> >
> > bye,
> > Sumit
> >
> > > > Would you willing to accept a patch adding a new parameter to
> > > > disable
> > > > the filtering of DLGs?
> > >
> > > Hi,
> > >
> > > in general yes, especially since I have such a patch already from
> > > some
> > > time in my tree
> > >
https://github.com/sumit-bose/sssd/commit/bb26e67e6e351c46acbc32402254cc7....
> > >
> > > We were asked to implement such option in
> > >
https://bugzilla.redhat.com/show_bug.cgi?id=1756240. I didn't
> > > create a
> > > pull-request yet because it might be necesary to disable global
> > > catalog
> > > lookups at the same time (at least if the patch is applied to
> > > older
> > > versions of SSSD which uses the GC more often).
> > >
> > > bye,
> > > Sumit
> > >
> > > > Regards,
> > > >
> > > > [1]
https://pagure.io/SSSD/sssd/issue/2161
> > > > [2]
https://pagure.io/SSSD/sssd/issue/2178
> > > >
> > > > --
> > > > Samuel Cabrero / SUSE Labs Samba Team
> > > > GPG: D7D6 E259 F91C F0B3 2E61 1239 3655 6EC9 7051 0856
> > > > scabrero(a)suse.com
> > > > scabrero(a)suse.de
> > > > _______________________________________________
> > > > sssd-devel mailing list -- sssd-devel(a)lists.fedorahosted.org
> > > > To unsubscribe send an email to
> > > > sssd-devel-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/sssd-devel@lists.fedorahoste...
> > > _______________________________________________
> > > sssd-devel mailing list -- sssd-devel(a)lists.fedorahosted.org
> > > To unsubscribe send an email to
> > > sssd-devel-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/sssd-devel@lists.fedorahoste...
> > _______________________________________________
> > sssd-devel mailing list -- sssd-devel(a)lists.fedorahosted.org
> > To unsubscribe send an email to
> > sssd-devel-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/sssd-devel@lists.fedorahoste...
>
> Hi Sumit,
>
> I tested the patch in master and sssd-1-16 branches and I didn't
> found
> problems with it.
>
> To make the tests I deployed an AD forest ("aforest.ad") with a child
> domain ("achild.aforest.ad") and joined sssd to the child domain. I
> populated both domains with the attached scripts to create the
> attached
> groups layout, then I ran the attached tests and all of them passed.
>
> Please let me know if you want me to perform more tests.
>
> Sam
>
Hi Sumit,
Did you have the chance to have a look to my test results?
Hi,
the tests are looking pretty complete. I'm still not sure about the
Global Catalog, especially with the sssd-1-16 branch. Do you have a
Global Catalog server in each domain? Can you try to run the test once
only using the Global Catalog server from aforest.ad and another run
using the GC from achild.aforest.ad (both tests starting with an empty
cache of course)?
In my experience (and I think this is documented my MSFT as well) the
'member' attribute of domain local groups in the Global Catalog is not
reliable. It might be available and complete on a GC of the domain the
domain local group belongs to but the 'member' attribute is not
replicated to GCs in other domains. So I would expect that when using
the GC of achild.aforest.ad the member of the domain local groups from
aforest.ad cannot be resolved.
bye,
Sumit