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