On Fri, Feb 28, 2020 at 09:46:30AM +0100, Samuel Cabrero wrote:
> 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
Hi Sumit,
in fact, I have found that only DLGs from the domain the user belongs
to plus the ones from the "local" domain are returned. Considering this
setup:
AFOREST.AD
| |
| +--> group_local_aforest_4
| * user-aforest
| * user-achild
| * user-abrother
|
+-> ACHILD.AFOREST.AD <---> (sssd)
| |
| +--> group_local_achild_4
| * user-aforest
| * user-achild
| *
user-abrother
|
+-> ABROTHER.AFOREST.AD
|
+--> group_local_abrother_4
* user-aforest
* user-achild
* user-abrother
id AFOREST\\user-aforest returns:
- group-achild-local-4
- group-aforest-local-4
id ACHILD\\user-achild returns:
- group-achild-local-4
id ABROTHER\\user-abrother
- group-achild-local-4
- group-abrother-local-4
The patch disables the filtering when returning results from the cache,
but as the the backend retrieves the initgroups querying the
tokenGroups attribute in the LDAP server the user belongs to it will
never contain the DLGs from other domains, only the ones from the
user's domain. Later, if the user is from a remote domain, the list is
completed looking at the local domain. The result is that DLGs from
other domains apart from those two are not returned.
I get these results with the following settings (master branch):
* ad_enable_gc = true and ldap_use_tokengroups = true
* ad_enable_gc =
false and ldap_use_tokengroups = true
* ad_enable_gc = false and
ldap_use_tokengroups = false
Enabling the GC but disabling tokenGroups the results are:
* ad_enable_gc = true, ldap_use_tokengroups = false
id AFOREST\\user-aforest returns:
- group-achild-local-4
id ACHILD\\user-achild returns:
- group-achild-local-4
id ABROTHER\\user-abrother
- group-achild-local-4
Is this an expected behavior? IIUC to return all DLGs from remote
domains it will be necessary to iterate the subdomains and query the
tokenGroups from all of them... Maybe only if
ad_allow_remote_domain_local_groups = true ?
Sam.