I recently had a client ask if there is a way to grant access to a vendor so they could only work with specific Group Policy Objects (GPOs) in Active Directory and not the entire Group Policy structure. The client had created a non-domain admin (regular domain user) account for the vendor with limited access and rights in their domain. The vendor needed the ability to change GPO settings for testing purposes, and the client did not want them to have Domain Admin (DA) rights. It is possible to give non-admin account access to edit GPOs. Here are a couple of ways how.
Option 1 – Restricted Access to GPO
The first option requires a DA to get the vendor started and possibly interact with them throughout the vendor’s testing process. We would first have the DA create the GPO itself under the proper OU in the Group Policy Management Console (GPMC), name it, then give Edit rights for the vendor’s AD account. This will allow the vendor to change any settings within the GPO itself, but they will not be able to do anything other than edit the GPO settings. They cannot Enable, Disable, or Enforce the GPO itself, nor can they link or remove the GPO from the OU in GPMC. If they need to disable, enable, or remove it, they will need a DA to do it for them.
This is the most restrictive option and gives them the least amount of freedom to do anything but edit the GPO settings (unless we also grant them Delete and Modify Security on the GPO, which allows them to can delete it). This option may require occasional interaction from a DA depending upon the vendor’s needs while they test various GPO configurations.
Option 2 – Giving Non-Admin Access to Create and Delete GPOs
With this option, the vendor account would have a bit more freedom to work with the GPO for testing purposes. They can create the GPO themselves, edit its settings, enable or disable it, enforce it, and ultimately delete the GPO if they need to, but only the GPO they have created and no other GPOs. It’s akin to the Creator/Owner permission on files and folders within NTFS. A DA does not have to interact with the vendor during the process other than the initial access setup.
To accomplish this, a DA would first add the vendor’s AD account to the Group Policy Creator Owners (GPCO) built-in AD group. Members of this group can create, edit, and delete their own GPOs. They cannot do anything with any GPOs they did not create. Even though they can create, edit, and delete their own GPOs, GPCO group members still cannot link or unlink GPOs from any OUs in the GPMC. Therefore, while they can create and edit their GPOs, they cannot apply them.
To be able to link and apply GPOs to a specific OU, the vendor’s account needs access to “Manage Group Policy links” for any OU they need to link GPOs. To accomplish this, the DA will need to right-click the OU in AD Users and Computers that needs access and then select “Delegate Control.” Once this delegation is created, then the vendor login will be able to create and work with their own GPOs (after being added to the GPCO group), plus be able to link and unlink GPOs in GPMC for any OU that has this delegation.
At this point, the vendor login can now add or remove any (even preexisting) GPOs from the OU we delegate access to, but they still cannot edit or do anything but link/unlink preexisting GPOs or work with any non-delegated OUs. This does give them a bit more flexibility and shouldn’t require any DA interaction for them to complete their testing.
Conclusion
Although there are many ways to accomplish this same scenario, I believe these two options are the quickest and easiest to configure and utilize. Even if we used option 2 and the vendor accidentally removed a preexisting GPO from an OU they had delegated access on, it would take only a few minutes for an admin to relink that GPO to the OU. The vendor still will not be able to edit, delete, or adjust permissions on any preexisting GPOs (any GPOs they did not create) with either of the above options. Option 1 may be the easiest, quickest, and safest way to get the job done, but if you want to be hands-off during the vendor’s testing, then option 2 would be the way to go and still be comfortable they can’t do any permanent damage to the AD and GPO structure.
Both options will still require that the vendor login be able to access a domain-joined desktop and have the Group Policy Management Console available to them.
Have any questions about how to grant non-admin accounts edit access to GPOs? Please reach out to one of our experts at any time!
