Group rights to manage Group Policy?

by Wes Sayeed   Last Updated October 09, 2019 23:00 PM - source

Consider the following scenario:

The Client Engineering department is responsible for the administration of all systems that users interactively log into, including most corporate desktop and laptop computers, as well as RDS servers and some application servers. They have local Admin rights to all these systems, and have the full authority to make operational decisions about how they are configured, what software is installed on them, and who is allowed to access what.

To this end, the Client Engineering team needs to be able to control Group Policy for systems within their purview. Therefore, the Client Engineering security group has been delegated access to the Group Policy Objects container in GPMC as well as the ability to link and unlink GPOs to/from the OUs that they manage.

The problem:
Bob (a member of the Client Engineering team) creates a GPO to test some application settings for a project he's working on and links it to an OU to test functionality. Because Bob created the GPO, he can edit, delete, link, unlink, and delegate the GPO as needed. But Bob does not have permissions to manage GPOs created by other teams, nor does he have the permissions to link his new GPO to containers outside the delegated OU tree. So far, so good; this is exactly what we want.

Unfortunately, when Bob created the new GPO, Windows added his user account to the GPO's ACL rather than the Client Engineering group as specified in the GPMC's Group Policy Objects delegation tab. Other members of the team can link/unlink it to other OUs (because that delegation is done from ADUC, not from GPMC), but Bob is the only person who can edit, delete, or change permissions on that GPO. No other member of the Client Engineering team can manage this policy unless Bob remembers to explicitly grant permissions to the Client Engineering group, nor can Bob manage policies created by other members of his team unless they've done the same. This is bad -- not at all what we want.

How can we set permissions up correctly in AD so that members of the Client Engineering security group can create, edit, delete, and delegate Group Policy Objects that they create?



Related Questions