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.
Michal
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 ? 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.
On (31/08/16 13:24), 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 ? 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.
I do not think either that patch is correct.
Downstream test failed for me. I am not sure whetther following part would be helpful but here is a simplified bash version. Unfortunatelly, I do not know what is allowed by "SSSD Site Policy" and "SSSD Domain Policy"
# Link a GPO object # Args: order gpo_name target # Example: gpo_link "SSSD Domain GPO" "DC=example,DC=com" function gpo_link()
# Unlink a GPO object # Args: gpo_name target # Example: gpo_unlink "SSSD Domain GPO" "DC=example,DC=com" ... N function gpo_unlink()
# The order in which the gpos are link does matter, so its relinked. gpo_unlink "SSSD Site Policy" "Default-First-Site-Name" gpo_link "SSSD Domain Policy" "$AD_SERVER1_BASEDN" gpo_link "SSSD Site Policy" "Default-First-Site-Name"
CCing Stephen who helped with GPO in past and reviewed gpo test-cases
LS
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.
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
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.
On 09/01/2016 10:31 AM, Jakub Hrozek wrote:
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.
Simplified it looks like this, addomain.test has 2 GPOs:
------------------------------------------------------------- precedence: Name: Location: ------------------------------------------------------------- 1 Default Domain Policy addomain.test 2 my-special-gpo addomain.test
Both are enabled and enforced. Both contain lists of SIDs that are allowed to login remotely (group SIDs). Let's say Default Domain Policy contains SID of group1 and my-special-gpo contains SID of group2.
Now userA is logging into machine, both GPOs are downloaded by SSSD and applicable for the userA.
Should the userA be allowed to login if he is member of grpoup1 or group2?
Michal
On Thu, 01 Sep 2016, Michal Židek wrote:
On 09/01/2016 10:31 AM, Jakub Hrozek wrote:
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.
Simplified it looks like this, addomain.test has 2 GPOs:
precedence: Name: Location:
1 Default Domain Policy addomain.test 2 my-special-gpo addomain.test
Both are enabled and enforced. Both contain lists of SIDs that are allowed to login remotely (group SIDs). Let's say Default Domain Policy contains SID of group1 and my-special-gpo contains SID of group2.
Now userA is logging into machine, both GPOs are downloaded by SSSD and applicable for the userA.
Should the userA be allowed to login if he is member of grpoup1 or group2?
Enforced GPOs are sorted by the precedence in the descending order of priority within the same SOM. However, a precedence calculated based on link order in the reverse way: a GPO that has a smaller link order associated with an SOM has higher GPO precedence than a GPO that has a higher link order associated with the same SOM.
Non-enforced ones are sorted by the scope.
See MS-GPOL 2.2.2 (last note), 3.2.1.4, and 3.2.5.2
sssd-devel@lists.fedorahosted.org