Welcome to a series of seven short posts that will lay out all aspects of the GPO aka Group Policy Object – Microsoft’s framework for automated configuration of the Windows operating system.
Read the full article here or skip to the previous or next article using the link at the bottom of this post.
GPO Security Filtering and Delegation
Group Policy Objects are securable objects just like files and folders, Active Directory objects, registry keys, etc. The security settings of a GPO affects how it’s applied to users and computers.
To receive the settings from a GPO a computer or user must have Read and Apply rights on the GPO. If they don’t have both Read and Apply rights the GPO will not be applied.
This might not be something you notice initially as Authenticated Users are assigned Read and Apply by default. As both domain users and domain computers belong to this group the GPO is applied indiscriminately to all of them.
But sometimes you may want to restrict the GPO appliance to a single user or computer, e.g. during testing of a new GPO.
This is achieved either by removing the Apply permission from Authenticated Users or removing Authenticated Users entirely from the GPO’s ACL:
… And then assigning Read and Apply manually to the user or computer you use for testing:
This method is referred to as security filtering. It’s mainly used for testing and when you have a sub-optimal correspondence between your OU design and GPO appliance needs. Check the next section for more information regarding this.
Another reason to change your GPO ACL is delegation. This does not relate to GPO appliance but is a matter of GPO management.
In larger organizations it often make sense to delegate the administration of GPO’s to local teams. This can be done by assigning Write permissions to the GPO:
This will allow you to provision blank GPO’s and then delegate the configuration of the GPO to local teams. If needed you can also assign the right to modify the GPO ACL to allow them to set up security filtering for testing purposes.