Delegating Group Policy (Administering Group Policy with Group Policy Management Console)

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Group Policy is an essential component of management in Windows 2000 and Windows Server 2003 environments. A portion of Group Policy’s power lies in the ability to delegate certain Group Policy tasks to other administrators. For example, the creation, linking, and editing of GPOs are independent permissions that can be delegated separately.

Group Policy delegation covers these areas:

• The ability to create GPOs in a domain.

• Permissions on an individual GPO (for example, read access, edit access).

• Permissions on an individual SOM. There are three permissions related to policy:

  • The ability to link GPOs to a SOM.

  • The ability to perform Group Policy Modeling analyses for objects in that SOM.

  • The ability to collect Group Policy Results data for objects in that SOM.

• The ability to create WMI filters in a domain.

• Permissions on an individual WMI filter (for example, edit access)

One of the key goals for GPMC was to simplify the management of Group Policy related permissions. GPMC does this by abstracting the low-level permissions on the object and managing them as a single unit, based on the task that an administrator wants to perform. Using GPMC, delegation tasks for a given object can be performed by navigating to the Delegation tab for that object.

Using this new model in GPMC, an administrator may never need the traditional ACL Editor. However, for administrators that prefer the flexibility of that ACL editor, it is still available through GPMC by clicking the Advanced button on the Delegation tab.

Delegating Creation of GPOs

Creation of GPOs is a right of the Group Policy Creator Owners (GPCO) group by default but can be delegated to any group or user. There are two methods to grant a group or user this right:

• Add the group or user to the Group Policy Creator Owners group. This was the only method available prior to GPMC.

• Explicitly grant the group or user permission to create GPOs. This method is newly available with GPMC.

You can manage this permission using the delegation tab on the Group Policy Objects container for a given domain in GPMC. This tab shows the groups that have permission to create GPOs in the domain, including the GPCO group. From this tab, you can modify the membership of existing groups with this permission, or add new groups.

The ability to grant users or groups permissions to create GPOs without using GPCO was added to facilitate the delegation of GPO creation to users outside the domain. Because the Group Policy Creator Owners group is a domain global group, it cannot contain members from outside the domain. Thus, prior to GPMC, this task could not be delegated to members outside the domain.

It is recommended that for users and groups within the domain that you continue to use the GPCO group to grant them GPO creation rights. If you require that users outside the domain have the ability to create GPOs, consider using the following steps.

• Create a new domain local group in the domain (“GPCO – External” for example)

• Grant that group GPO creation rights in the domain

• Create a global group in the external domain (“GPCO in Domain X” for example)

• Add external domain groups or users to that group

• Add the global group (“GPCO in Domain X”) to the local group (“GPCO – External”)

Adding a user to the membership of GPCO, or granting the user GPO creation permissions directly using the new method available in GPMC, is identical in terms of permissions. Granting a user the ability to create GPOs in the domain does not give the user the ability to edit or delete existing GPOs or the ability to link the GPO to a SOM. Users have full control of GPOs that they created.

Figure 10

Figure 10 shows the results pane for the delegation tab of the Group Policy objects container in the Contoso.com domain. Domain Admins can add new delegations or remove existing delegations through the Add and Remove buttons on the delegation tab. The Properties button will display the object properties for the selected user or group.

Delegating an individual GPO

GPMC has simplified the ability to delegate rights on an individual GPO. Prior to GPMC, administrators needed to rely on the ACL editor and required an intimate knowledge of the low-level permissions on the GPO. GPMC abstracts this so the administrator can manage the permissions on the GPO at the task level.

There are five categories of Allowed Permissions on a GPO.

• Read

• Edit settings

• Edit, delete, modify security

• Read (from Security Filtering)

• Custom

These permissions are managed using the delegation tab of a GPO, as shown in Figure 11.

Figure 11

The options listed above represent predefined combinations of ACLs. The corresponding underlying permissions for each are shown in Table 1 below:

Table 1

Option	Underlying Permissions
Read	Allow Read Access on the GPO
Edit settings	Allow Read, Write, Create Child Objects, Delete Child Objects
Edit, delete, and modify security	Allow Read, Write, Create Child Objects, Delete Child Objects, Delete, Modify Permissions, and Modify Owner. This essentially grants full control on the GPO, except that the “Apply Group Policy” right is not set.
Read (from Security Filtering)	This setting cannot be set directly, but appears if the user has Read and Apply Group Policy rights to the GPO (on the Scope tab of the GPO).
Custom	Any other combinations of rights, such as the use of deny permissions, will show up as Custom in the display. Custom rights cannot be set using the Add button, but they can be removed using the Remove button. They can be set only if using the ACL editor directly (which can be started with the Advanced button).

You can grant users permissions on a GPO using the Add button. This opens the object picker so you can find the desired user or group to set the permission level. You can then set the permission level by selecting either “Read”, “Edit”, or “Edit, Delete, Modify Security” permissions.

Note that the Apply Group Policy permission, which is used for Security Filtering, cannot be set using the Delegation tab. Setting Apply Group Policy is used for scoping the GPO, so is managed on the Scope tab. Note that when you grant a user Security Filtering on the Scope tab, you are actually setting both the Read and Apply Group Policy rights.

Delegating Policy-Related Permissions on SOMs

GPMC enables you to easily set the following three permissions on SOMs that are related to Group Policy:

• The ability to link GPOs to a SOM.

• The ability to perform Group Policy Modeling analysis for objects in that SOM.

• The ability to collect Group Policy Results data for objects in that SOM.

These permissions are viewed and managed using the Delegation tab on a given SOM, and selecting the desired option from the permissions dropdown. You can add new delegations or remove existing delegations through the Add and Remove buttons on this tab. The Properties button will display the object properties for the selected user or group. The Advanced button will display the Security properties dialog box (the ACL Editor) for the SOM, from which you can view the actual permissions for the individual attributes of the SOM.

When you grant permissions using the Add button, you will be prompted to specify whether the permission should apply only to the current container, or whether it should be inherited to child containers. Using the Add button only grants “Allow” permissions. It is strongly recommended that you avoid using “Deny”. However, if you must set a “Deny” permission, you can do so by pressing Advanced button.

Note

The “Applies to” column is not present on sites as they can not have child containers. Group Policy Modeling or Group Policy Results permissions cannot be delegated on sites so these options are not available in the permissions dropdown on site nodes.

Delegating Linking of GPOs

The settings in a GPO are applied to users and computers by linking the GPO to a SOM (site, domain, or OU) that contains the user or computer objects, either as a direct child or indirectly through inheritance. The ability to link GPOs to a SOM is a permission that is specific to that SOM. At the lowest level, the permission equates to having read and write access to the gPLink and gPOptions attributes on the SOM. However, with GPMC, there should be no need to manage these attributes individually. GPMC abstracts this permission as a single permission called “Link GPOs.” This permission also grants the ability to manage link order, block inheritance, and set the enforced attribute on GPO-links to this SOM.

This permission can be managed using the delegation tab on the SOM in GPMC when you select the Link GPOs option in the permission dropdown.

Figure 12 shows the Link GPOs permissions on the SOM delegation tab for the Child.Contoso.com domain.

Figure 12

Delegating Group Policy Modeling

Group Policy Modeling allows the user to simulate the resultant set of policy for objects in a domain or OU. This feature is described in more detail later in the white paper. This section discusses delegation aspects only for Group Policy Modeling.

This feature is only available to Domain Administrators by default but can be delegated to other users or groups. At its lowest level, this delegation equates to granting the user or group the “Generate Resultant Set of Policy (Planning)” permission on an OU or domain. This permission is available in any forest that has the Windows Server 2003 schema. Without GPMC, this attribute was available only on the advanced page of the ACL editor for a given domain or OU. GPMC simplifies the management of this permission by exposing this permission directly on the Delegation tab for any domain or OU. The administrator selects the “Perform Group Policy Modeling Analyses” setting from the Permissions drop-down box. This will display the Name, Applies To, Setting, and Inherited properties for the delegations. Figure 13 shows the Perform Group Policy Modeling Analyses permissions on Delegation tab for the Contoso.com domain.

Figure 13

Delegating Group Policy Results

Group Policy Results allows the user to read RSoP logging data for objects in the domain or OU. Group Policy Results is described in more detail later in the white paper. This section discusses delegation aspects only for Group Policy Results.

By default, only users with local administrator rights on the target computer can remotely access Group Policy results data; however this right can be delegated to other users or groups. Delegation is performed on either a domain or OU. Users with this permission can read Group Policy Results data for any object in that container, and in child containers if the permission is specified to be inherited.

At its lowest level, this delegation equates to granting the user or group the “Generate Resultant Set of Policy (Logging)” permission on an OU or domain. This permission is available in any forest with the Windows Server 2003 schema. Without GPMC, this attribute was available only on the advanced page of the ACL editor for a given container. GPMC simplifies the management of this permission by exposing this permission directly on the Delegation tab for the domain or OU. The administrator selects the “Read Group Policy Results Data” setting from the Permissions drop-down box. This will display the users and groups that have this permission for the domain or OU, if the setting applies to only this container or to the container and all child objects, if the setting is allowed, and if the permission is inherited from a parent container. Figure 14 shows the Read Group Policy Results data permissions on the Delegation tab for the Contoso.com domain.

Figure 14

Delegating Creation of WMI Filters

WMI filters are a new feature in Windows Server 2003. When a new WMI filter is created it is stored in the WMIPolicy container in the domain’s System container in Active Directory. It is the permissions applied on this container that govern the rights a user has to create, edit, and delete WMI Filters. This section is limited to delegation aspects of WMI filters. For more information about WMI filters, see the WMI Filters section in this white paper.

There are two levels of permission for creating WMI filters, which can only be delegated by Domain Admins:

• Creator Owner: Allows the user to create new WMI Filters in the domain, but does not grant them permissions on WMI filters created by other users. This permission is analogous to the GPO creation permission.

• Full Control: Allows the user to create WMI filters, and grants them full control on all WMI Filters in the domain, whether they created them or not. There is no corresponding permission level for GPOs because permissions in the sysvol are not inherited, so it’s not technically possible to guarantee full control to all GPOs

By default, Domain Admins and Enterprise Admins have Full Control and Group Policy Creator Owners have Creator Owner permissions.

To delegate either permission to a user or group, use the Add button on the delegation tab of the WMI Filters pane. Figure 15 shows the delegation tab for the WMI Filters container.

Figure 15

An administrator can Add, Remove, and view Properties for WMI Filter delegations from the Delegation tab. Selecting Add will prompt for a user or group before selecting the permission level (Creator Owner or Full Control) to assign to the user or group. Selecting Remove will prompt for confirmation that the delegation should be removed. Selecting Properties will display the user or group properties for that object.

Delegating an individual WMI Filter

GPMC has the ability to delegate rights on an individual WMI Filter. There are two levels of permissions that can be granted to a user or group on an individual WMI Filter.

• Edit – allows the user or group to edit the WMI Filter.

• Full Control – allows the user or group to edit, delete, and modify security on the WMI Filter.

These permissions are managed using the Delegation tab of an individual WMI Filter, as shown in Figure 16.

Figure 16

The Delegation tab shows the users and groups that have permissions on the WMI Filter, the permission level, and if the permission is inherited from a parent container. Buttons on this tab allow the user to Add or Remove users and groups to the delegation list for the WMI Filter.

Note that all users have Read access to all WMI filters. GPMC does not allow this permission to be removed. If the Read permission were removed, this could cause policy processing on the client to fail. Therefore, GPMC deliberately doesn’t offer the capability to remove this permission.