On Thu, Sep 01, 2016 at 09:56:33AM +0200, Michal Židek wrote:
> 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, I think it would help if you describe in detail how the affected
GPO configuration looks like.
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org

Reply via email to