AGPM 3.0 doesnt preserve all the Deny ACEs

We had a great customer question today on AGPM 3.0 that would probably interest quite a few of you using AGPM.

 

"...A customer imports some GPOs [into AGPM] in order to change control them. Some of the GPOs have Deny permission for particular users’ that have administrative rights or similar. After changing the GPOs with AGPM methods (check out, check in) he uses “Deploy” to roll out the changes. At this point the Deny ACEs get deleted. Why are the Deny ACE's being stripped?..."

 

Its important to understand that AGPM is intended to be the central change control application for GP. We dont actually want ACE's being preserved from whats there - we actually want AGPM to be in control.

Anyway I checked this out myself and found that AGPM 3.0 only will preserve the Deny ACE for "Apply". This means that if you have custom security filtering on a specific group or user that you want specifically excluded from having policy applied to it we will ensure that it doesnt get applied by preserving this permission. We dont however preserve all individual the Deny permissions.

 

Why are you doing this?

 

This is by design in AGPM 3.0. Heres the interesting things you may not have considered:

1. There are two parts to the GP ACL. Theres the Security Filtering and the Administrative Delegation (AGPM calls this Production Delegation). One is an application of policy the other is the administration of policy though they actually appear in the same list
2. Remember the Deny ACE overrides everything
3. We need both Read and Apply to get policy to apply. If we don’t have either one we effectively stop policy applying for that object
4. Read is also required in order to administer policy – it’s the only common permission to both the application and administration of policy

So AGPM 3.0 we now have the ability for it to control the administrative (production) delegation that gets applied to the policy object and we override (and rewrite) the security descriptors for the GPO. This can ensure that every GPO is stamped with an ACL that mandates the control of that GPO belongs to AGPM - so you provide access to those that need it within AGPM, not within GPMC.

 

The other part of this is the Security Filtering and its important we preserve any explicit controls an admin has made to prevent a user having a policy apply to them - including a Deny...which leads to the next question...

 

So why is the Read being stripped then? Isnt it Read and Apply that both should be being preserved for the Deny?

Remember, we need Read and Apply. If we dont have either one of these then the policy wont apply to us. There is a downside though if we did this. Think for example if we set a Deny ACE on Domain Admins for a specific policy for Read and Apply (Security Filtering) and preserved the ACE of Deny for Read. That would combine with our production delegation from AGPM and suddenly the Domain Admin wouldn’t be able to Read that policy in order to be able to administer it.

By only preserving the Deny ACE for Apply, we effectively preserve the desired outcome for Security Filtering (that is: We stop that policy processing) but we also preserve the correct desired outcome for administration.

 

Hope this helps to clarify!

 

Michael Kleef

Program Manager - AGPM

Comments

• Anonymous
  January 01, 2003
  Today I wrote on the Group Policy team blog about AGPM 3.0 and how its not preserving all the Deny ACE's

• Anonymous
  January 01, 2003
  In Windows 7, search is so well integrated throughout the operating system (even in more apps than Vista), why can't it be implemented for Gpedit.msc/Local Group Policy?

• Anonymous
  May 27, 2015
  The comment has been removed