Select Page

The other day I got a question about one of our free GPMC PowerShell cmdlets–namely, the Add-SDMgpoSecurity that lets you modify GPO security. One of the permissions that you can grant using the cmdlet is the GPO creation permission–which controls who can create GPOs in the domain. This particular questioner was wondering why they were getting an error when trying to set GPO creation permissions on a particular OU. The question made me think that a blog entry on Group Policy delegation was in order. So, for this particular issue I just described, the answer is relatively straightforward. You can only delegate creation of GPOs at the domain level. That is why, in GPMC, you will notice that when you click on the Delegation tab for a particular OU, you don’t have the option to delegate GPO creation.

In fact, the only place you will see that delegation, is when you click on the "Group Policy Objects" node within a particular domain, and view the Delegation tab. So, the right to create GPOs in a domain is domain-wide. Now of course, if you delegate to someone the right to create a GPO, it does not necessarily give them the ability to make it "live". That ability requires a different kind of delegation–the delegation of linking. Remember that a GPO can be linked to an AD site, domain or OU. Each of these AD containers has a set of permissions associated with it. One of those permissions is the ability to write to the gpLink attribute on the container, and it is that permission that controls who can link a GPO to that particular site, domain or OU. You can, of course, delegate that permission without having to dig into the bowels of the AD ACL Editor, by using the GPMC–simply by clicking the Delegation tab while focused on a container object and then choosing "Link GPOs" as the permission you want to manage.

The final type of delegation I will mention is the ability to edit GPOs. Regardless of who creates a GPO, there is the separate ability to be able to edit that GPO once its created. When a GPO is created, it gets a set of permissions that are controlled by the defaultSecurityDescriptor attribute on the AD schema groupPolicyContainer object class. That default security descriptor controls which groups have which permissions on newly created GPOs. You can, of course, modify that attribute in your AD environment so that you can control which groups get what rights on all newly GPOs (see KB article for more information), but you may also want to modify the ability to edit GPOs after they are created. For that GPMC again provides the answer. You simply need to highlight a particular GPO, choose the Delegation tab and from there you can set permissions for who can edit a GPO or who can edit, delete and modify the security on a GPO. Its also important to note that these permissions are stored on the GPO object itself, not the link or container object. So, while you can link a GPO to any number of AD containers, keep in mind that the permissions on that GPO in terms of who can read and write it remain constant, regardless of where its linked.

Finally, I will mention a slight variation on the GPO delegation I just described. The ability for a computer or user to process a GPO is just a different kind of delegation on that GPO. Namely, by granting a user or computer (or a group to which they belong) the Read and "Apply Group Policy" rights on a GPO, that user or computer is allowed to process that GPO, assuming its properly linked to them within the AD hierarchy. Strangely, this particular delegation is listed in two places within GPMC. If you’re highlight a GPO, you will see it under the Scope tab, in the "Security Filtering" listview, and you will also see that same delegation listed on the Delegation tab for that GPO, except that it will say "Read(from Security Filtering)", next to the security principal name to indicate that the permission being granted is really the ability to process the GPO. Confused yet? Laughing

Of course, all of these delegation operations are supported in our free PowerShell GPMC cmdlets as well!



Group Policy, PowerShell, GPMC