Question regarding domain-local groups filtering

[Samuel Cabrero]

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.

Would you willing to accept a patch adding a new parameter to disable
the filtering of DLGs?

Regards,

[1] https://pagure.io/SSSD/sssd/issue/2161
[2] https://pagure.io/SSSD/sssd/issue/2178

[Sumit Bose]

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

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
> [e-mail]
> [e-mail]
> _______________________________________________
> sssd-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail].o...

[Sumit Bose]

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/bb26e67e6e351c46acbc32402254cc7334....
>
> 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
> > [e-mail]
> > [e-mail]
> > _______________________________________________
> > sssd-devel mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 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/[e-mail].o...
>
> sssd-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail].o...

[Samuel Cabrero]

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.

You are right but this is not the case I found. I don't know the
details of the AD deployment, but the server running SSSD wants to use
domain local groups from trusted domain in its sudo rules, maybe
because the administrators from those remote domain do not have
permissions to add their users to a group in the domain where SSSD is
joined.
> 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.

I have seen your patch was applied to 1.16, and this is the version I
would like to target.
> 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.

This may be somehow going against MS design, but it is proved there are
use cases where is useful, like the RH ticket, and we also have tickets
asking to implement this at SUSE. Adding a new option to disable the
filtering seems a good compromise.

You mentioned it may be necessary to disable global catalog lookups as
well. I am going to have a look to it, but do you have something in
mind which I should check in particular?
> 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/bb26e67e6e351c46acbc32402254cc7334....
> >
> > 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

[Samuel Cabrero]

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/bb26e67e6e351c46acbc32402254cc7334....
> >
> > 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
> > > [e-mail]
> > > [e-mail]
> > > _______________________________________________
> > > sssd-devel mailing list -- [e-mail]
> > > To unsubscribe send an email to 
> > > [e-mail]
> > > 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/[e-mail].o...
> >
> > sssd-devel mailing list -- [e-mail]
> > To unsubscribe send an email to 
> > [e-mail]
> > 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/[e-mail].o...
>
> sssd-devel mailing list -- [e-mail]
> To unsubscribe send an email to 
> [e-mail]
> 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/[e-mail].o...

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

[Samuel Cabrero]

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/bb26e67e6e351c46acbc32402254cc7334....
> > >
> > > 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
> > > > [e-mail]
> > > > [e-mail]
> > > > _______________________________________________
> > > > sssd-devel mailing list -- [e-mail]
> > > > To unsubscribe send an email to 
> > > > [e-mail]
> > > > 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/[e-mail].o...
> > >
> > > sssd-devel mailing list -- [e-mail]
> > > To unsubscribe send an email to 
> > > [e-mail]
> > > 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/[e-mail].o...
> >
> > sssd-devel mailing list -- [e-mail]
> > To unsubscribe send an email to 
> > [e-mail]
> > 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/[e-mail].o...
>
> 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?

Do you think the patch will be finally merged?

Sam

[Sumit Bose]

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/bb26e67e6e351c46acbc32402254cc7334....
> > > >
> > > > 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
> > > > > [e-mail]
> > > > > [e-mail]
> > > > > _______________________________________________
> > > > > sssd-devel mailing list -- [e-mail]
> > > > > To unsubscribe send an email to 
> > > > > [e-mail]
> > > > > 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/[e-mail].o...
> > > >
> > > > sssd-devel mailing list -- [e-mail]
> > > > To unsubscribe send an email to 
> > > > [e-mail]
> > > > 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/[e-mail].o...
> > >
> > > sssd-devel mailing list -- [e-mail]
> > > To unsubscribe send an email to 
> > > [e-mail]
> > > 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/[e-mail].o...
> >
> > 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
> Do you think the patch will be finally merged?
>
> Sam

[Samuel Cabrero]

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/bb26e67e6e351c46acbc32402254cc7334....
> > > > >
> > > > > 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
> > > > > > [e-mail]
> > > > > > [e-mail]
> > > > > > _______________________________________________
> > > > > > sssd-devel mailing list -- 
> > > > > > [e-mail]
> > > > > > To unsubscribe send an email to 
> > > > > > [e-mail]
> > > > > > 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/[e-mail].o...
> > > > >
> > > > > sssd-devel mailing list -- [e-mail]
> > > > > To unsubscribe send an email to 
> > > > > [e-mail]
> > > > > 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/[e-mail].o...
> > > >
> > > > sssd-devel mailing list -- [e-mail]
> > > > To unsubscribe send an email to 
> > > > [e-mail]
> > > > 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/[e-mail].o...
> > >
> > > 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.

[Sumit Bose]

On Fri, Mar 06, 2020 at 08:34:51PM +0100, Samuel Cabrero wrote:
> 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/bb26e67e6e351c46acbc32402254cc7334....
> > > > > >
> > > > > > 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
> > > > > > > [e-mail]
> > > > > > > [e-mail]
> > > > > > > _______________________________________________
> > > > > > > sssd-devel mailing list -- 
> > > > > > > [e-mail]
> > > > > > > To unsubscribe send an email to 
> > > > > > > [e-mail]
> > > > > > > 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/[e-mail].o...
> > > > > > _______________________________________________
> > > > > > sssd-devel mailing list -- [e-mail]
> > > > > > To unsubscribe send an email to 
> > > > > > [e-mail]
> > > > > > 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/[e-mail].o...
> > > > >
> > > > > sssd-devel mailing list -- [e-mail]
> > > > > To unsubscribe send an email to 
> > > > > [e-mail]
> > > > > 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/[e-mail].o...
> > > >
> > > > 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.
> ad_allow_remote_domain_local_groups = true ?

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