Delegating Group Policy

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

One of the features of Active Directory is its ability to delegate control of portions of the directory service. This section explains how Group Policy fits in with the delegation of sites, domains, and organizational units.

With GPMC, the following tasks can be delegated:

• Create GPOs in a domain.

• Set permissions on a GPO.

• Set policy-related permissions on site, domain or organizational unit.

  • Link GPOs to a given site, domain or organizational unit.

  • Perform Group Policy Modeling analyses on a given domain or organizational unit (but not on a site).

  • Read Group Policy Results data for objects in a given domain or organizational unit (but not on a site).

• Create WMI filters in a domain.

• Set permissions on a WMI filter.

GPMC simplifies delegation by managing the various ACEs required for a task as a single bundle of permissions for the task. If you want to see the ACL in detail, you can click the Advanced button on the Delegation tab.

The underlying mechanism for achieving delegation is the application of the appropriate DACLs to GPOs and other objects in Active Directory. This mechanism is identical to using security groups to filter the application of GPOs to various users, as described earlier in this paper.

You can also specify Group Policy to control the behavior of MMC and MMC snap-ins. For example, you can use Group Policy to manage the rights to create, configure, and use MMC consoles, and to control access to individual snap-ins.

Using Security Groups to Delegate Group Policy

The following table lists the default security-permission settings for a GPO:

• Remove Authenticated Users from the list on the security tab of the GPO, and add a new security group with the Apply Group Policy and Read attributes set to Allow. This new group should contain all the users that this Group Policy is intended to affect.

• Set the Apply Group Policy attribute to Deny for the Domain and Enterprise Admins, and possibly the Creator Owner groups. This will prevent the GPO from being applied to members of those groups. Remember that an ACE set to Deny always takes precedence over Allow. Therefore, if a given user is a member of another group that is set to explicitly Allow the Apply Group Policy attribute for this GPO, it will still be denied.

Managing Group Policy Links for a Site, Domain, or Organizational Unit

The Group Policy tab in the Properties page for a site, domain, or organizational unit allows the administrator to specify which GPOs are linked to this site, domain, or organizational unit. This property page stores the user's choices in two Active Directory properties called gPLink and gPOptions. The gPLink property contains the prioritized list of GPOs and the gPOptions property contains the Block Policy Inheritance setting.

To manage GPO links to a site, domain, or organizational unit, you must have read and write access to the gPLink and gPOptions properties. By default, Domain Admins have this permission for domains and organizational unit, and only Enterprise Admins and Domain Admins of the forest root domain can manage links to sites.

Active Directory supports security settings on a per-property basis. This means that a non-administrator can be given read and write access to specific properties. In this case, if non-administrators have read and write access to the gPLink and gPOptions properties, they can manage the list of GPOs linked to that site, domain, or organizational unit.

Creating GPOs

By default, only Domain Admins, Enterprise Admins, and Group Policy Creator Owners can create new GPOs. Creating GPOs is a user 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 user or group to membership of 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 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, 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, then create a new domain local group in the domain ("GPCO - External"), grant that group GPO creation rights in the domain, and then add external domain users to that group.

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. Users have the ability to create GPOs in the domain, but do not have permissions on GPOs created by other users. For example, 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 site, domain or organizational unit.

Note that when an administrator creates a GPO, the Domain Admins group becomes the Creator Owner of the GPO. The ability to link GPOs to a site, domain or organizational unit is a permission that is specific to that site, domain or organizational unit. When delegating to non-administrators, you should also consider delegating the ability to manage the links for a specific organizational unit. The reason is that by default, non-administrators cannot manage links.

In GPMC, this permission can be managed using the Delegation tab on the site, domain or organizational unit when you click the Link GPOs option in the permission drop-down list box. At the individual permission level in Active Directory, this allows Read and Write access to the gPLink and gPOptions attributes on the site, domain, or organizational unit. By default, only Domain Admins and Enterprise Admins have this permission.

Editing Group Policy Objects

To edit a GPO, the user must have both read and write access to the GPO. (However, read-only support for opening a GPO is provided in GPMC). To edit a GPO, the user must be one of the following:

• An administrator.

• A Creator Owner.

• A user with delegated access to the GPO. That is, an administrator, or the Creator Owner, must have provided to this user both read and write access to the GPO.

By default, Domain Admins, Enterprise Admins, the operating system, and the GPO Creator Owner can edit GPOs because they have full control of GPOs without the Apply Group Policy attribute.

Delegating an individual GPO

There are five permission options on GPOs in GPMC user interface. Each corresponds to a set of individual NT permissions. The correspondence is summarized in the following table.

Permissions on a GPO are managed from the Delegation tab of that GPO.

Specifying Group Policy to Control the Behavior of MMC extensions

Windows Server 2003 Group Policy includes several policy settings designed to control the behavior of MMC snap-ins. For example, you can use Group Policy to manage the rights to use MMC snap-ins.

Restricting Access to a List of Permitted Snap-ins

Administrators can specify which MMC snap-ins may be run by the affected user and which may not. This may be specified to be inclusive, which only allows a set of snap-ins to run, or it may be set as exclusive, which does not allow a set of snap-ins to run.

To create a list of permitted snap-ins for users, enable the Restrict users to the explicitly permitted list of snap-ins policy. When this policy is enabled, only permitted snap-ins can be run. If this policy is disabled or not configured, all snap-ins are permitted, except those you explicitly prohibit.

This policy is available in the Group Policy console under the User Configuration\Administrative Templates\Windows Components\Microsoft Management Console node.

Controlling Access to a Snap-in

To restrict or explicitly permit access to a particular snap-in, navigate to User Configuration\Administrative Templates\Windows Components\Microsoft Management Console\Restricted\Permitted snap-ins\Group Policy in the console tree. In the details pane, double-click the snap-in that you want to permit or restrict, and then select an option. For more information about these policy settings, select a policy setting, and view the description in the Web view or click the explain tab in the Properties dialog box for the policy setting.

Administrators can enable the Restrict the user from entering author mode policy in order to prevent users from using MMC in author mode. This policy is available in the Group Policy console under the User Configuration\Administrative Templates\Windows Components\Microsoft Management Console node.

Creating Custom Group Policy Object Editor Consoles

You can create custom Group Policy MMC consoles (.msc files), which include only a subset of the Group Policy Object Editor extensions. You can combine this with the use of the policy settings above to provide a customized tool. For example, you could create a custom Group Policy console that includes only the Security Settings extension. This allows you to define Group Policy settings in a modular fashion.

To set access permissions, use the Security tab on the Properties page of the selected GPO. These permissions allow or deny specified groups access to the GPO.