On 08/31/2016 07:49 PM, Stephen Gallagher wrote:
On 08/31/2016 01:24 PM, Simo Sorce wrote:
On Wed, 2016-08-31 at 17:41 +0200, Michal Židek wrote:
Hi,
here is patch for ticket #3161.
See more in the ticket description.
I was thinking why we originally replaced
the lists and I think it comes from confusion
on how we handle the same keys in single
GPO ini file, however that is handled by
libini not by SSSD.
Sorry to come to this late, but do you have a documentation reference
that says that merging is the correct behavior ?
Merging is not (nor has it ever been) the correct behavior. The way that AD GPOs
work is with a strict hierarchy. I'd have to double-check the code to remember
which order it is, but I *think* it's:
Domain is overridden by site which is overridden by individual machine.
Basically, if I have a GPO on domain EXAMPLE.COM that include
SeInteractiveLogonRight=foo and another GPO on machine client.example.com that
has SeInteractiveLogonRight="bar, baz", then "bar, baz" completely replaces
"foo" for that machine. It does not merge in any way.
This is the reason that we switched to storing this information in the LDB
cache; we were able to do the processing the same way Windows does with the
registry, by having each iteration through the hierarchy replace the previous
one.
Again, no merging should happen here.
I forgot a lot about how multiple GPOs are supposed to be merged but I
seem to recall there may be a policy that actually controls how merging
is done.
CCing Günther who has worked around GPO processing a few years ago.
Simo.
Thank you everyone for the input.
So either we have a different bug or the configuration I am
working with is wrong.
Does anyone know, how is the precedence of GPOs (that are
defined on the same level, for example for domain.test)
determined? I guess the tree structure of LDB is not helping much
here. When I look in the Group policy management window at the
GPOs, it looks like the ones I created later have higher precedence
(are applied later). But I am not sure if this is a coincidence.
Michal
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
