On Fri, 2020-02-28 at 18:46 +0100, Sumit Bose wrote:
> 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
Hi,
yes, currently this is expected and you described it correctly.
Currently only the tokenGroups result from the LDAP server of the home
domain of the user and the domain local group of the domain the client
is joined to are evaluated. This is done to get the same group
memberships as listed in the PAC. So other domains in the forest are not
taking into account.
domains it will be necessary to iterate the subdomains and query the
tokenGroups from all of them... Maybe only if
I think tokenGroups won't work because the user is not a member to the
other domain. You have to do a LDAP search with 'member=DN_of_the_user'
as part of the filter and (now comes the bad part) with
'member=DN_of_each_group_the_user_is_a_member_of' thanks to group
nesting. And if groups are found in an other domain you have to follow
the group hierarchy of this group as well to make sure all domain local
groups in the other domain are covered.
I don't know if there is a Windows/AD/RPC/whatever-API call which can
return all groups but I doubt this since even the 'AD Users and
Computer' tool does only show the direct memberships of the user in its
home domain. Even if the user is a direct member of a domain local group
of a different domain this group is not shown by the tool.
yes, maybe even making this a non-boolean option so that it can be
selected in which other domains 'domain local groups' should be
searched because searching a whole forest might be quite expensive.
But I still think 'domain local groups' were created for a reason and
the reason is to restrict their scope and I also think that's the reason
why it it hard to resolve them for other domains.
bye,
Sumit