Delegating Control of Group Policy
Group Policy is one of the administrative tasks that can be delegated in Windows 2000. The following three Group Policy tasks can be independently delegated:
Managing Group Policy links for a site, domain, or organizational unit.
Creating Group Policy objects.
Editing Group Policy objects.
Non-local Group Policy, like all Active Directory–based administrative tools, requires a Windows 2000 domain controller. Group Policy, like most other Windows 2000 administrative tools, is hosted in MMC consoles. The rights to create, configure, and use MMC consoles, therefore, have policy implications. You can control these rights through Group Policy under
< Group Policy object name >/User Configuration/Administrative Templates/Windows Components/Microsoft Management Console/
and its subfolders.
Table 22.2 lists the security permission settings for a Group Policy object.
Table 22.2 Security Permission Settings For A Group Policy Object.
Groups or Users
Read with Apply Group Policy ACE
Domain Administrators Enterprise Administrators Creator Owner Local System
Full Control without Apply Group Policy ACE
By default, if you are an administrator, you are also an authenticated user, which means that you have the Apply Group Policy attribute set. For more information, see "Editing Group Policy Objects" later in this chapter.
To administer Group Policy, you need to log on to a local or remote domain controller, which requires special permission. If you are a domain administrator or you are the built- in administrator on a domain controller, you have this permission.
Non-administrators can log on to a domain controller only if they have Log On Locally permission. This is part of the Default Domain Controllers Group Policy object, linked to the Domain Controllers organizational unit in Active Directory Users and Computers. The setting is found under Computer Configuration/Windows Settings/Security Settings/Local Policies/User Rights Assignment/Log on locally.
It is recommended that you create a security group containing those users who should be able to log on locally to the domain controller, and add them to the list of groups shown on the Log On Locally form. Remember that computer policy for the domain controller must refresh before the new permissions take effect.
Managing Group Policy Links for a Site, Domain, or Organizational Unit
The Group Policy tab in the site, domain, or organizational unit's Properties page allows you to specify which Group Policy objects 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 Group Policy object links and the gPOptions property contains the Block Policy Inheritance policy setting for domains or organizational units. The Block Policy Inheritance policy setting is not available for sites.
Figure 22.5 illustrates the creation of a new Group Policy object from within Active Directory Users and Computers. It has the default name New Group Policy Object , which you can change to something more descriptive. It will be stored in the noam.reskit.com domain, and it will automatically be linked to the Manufacturing organizational unit.
Figure 22.5 Manufacturing Properties of New Group Policy Object
Active Directory supports security settings on individual properties. Thus, a non-administrator can be given Read and Write access to specific properties. If non-administrators have Read and Write access to the gPLink and gPOptions properties, they can manage the list of Group Policy objects linked to that site, domain, or organizational unit. To give a user Read and Write access to these properties, use the Delegation of Control Wizard and select the Manage Group Policy links predefined task.
Creating Group Policy Objects
By default, only Domain Administrators, Enterprise Administrators, Group Policy Creator Owners, and the operating system can create new Group Policy objects. If the domain administrator wants a non-administrator or group to be able to create Group Policy objects, that user or group can be added to the Group Policy Creator Owners security group. When a non-administrator who is a member of the Group Policy Creator Owners group creates a Group Policy object, that user becomes the Creator Owner of the Group Policy object. Then the user can edit the Group Policy object. Being a member of the Group Policy Creator Owners group gives the non-administrator full control of only those Group Policy objects that the user creates or those explicitly delegated to that user. It does not give the user full control of any other Group Policy objects, and does not allow the user to link Group Policy objects to sites, domains, or organizational units.
Editing Group Policy Objects
By default, Group Policy objects give Domain Administrators, Enterprise Administrators, the operating system, and the Group Policy object Creator Owner full control without the Apply Group Policy attribute. They can edit the Group Policy object. But even if members of those groups have accounts in Active Directory sites domains, or organizational units linked to the Group Policy object, the policy settings contained in that Group Policy object do not apply to them unless both of the following two conditions pertain:
They have Apply Group Policy set to Allow as members of another security group.
They don't have Apply Group Policy set to Deny as members of any security group.
By default, Authenticated Users have Read access to the Group Policy object with the Apply Group Policy attribute set.
By default, if you are an administrator, you are also an authenticated user, which means that you have the Apply Group Policy attribute set. If this is not what you intend, you have two choices:
Remove authenticated users from the list, and add a security group with the Apply Group Policy attribute set to Allow . This new group should contain all the users who this Group Policy is intended to affect.
Set the Apply Group Policy attribute to Deny for the Domain and Enterprise Administrators, and possibly the Creator Owner groups. This will prevent the Group Policy object from being applied to members of those groups. Remember that an ACE set to Deny always takes precedence over Allow . If a given user is a member of another group that is set to explicitly Allow the Apply Group Policy attribute for this Group Policy object, it will still be denied.
When a non-administrator creates a Group Policy object, he or she becomes the Creator Owner of the Group Policy object. When an administrator creates a Group Policy object, the Domain Administrators group becomes the Creator Owner of the Group Policy object.
To edit a Group Policy object, the user must have both Read and Write access to the Group Policy object. A Group Policy object cannot be opened in read-only mode. In other words, if you can open the Group Policy snap-in, you can edit the Group Policy object that appears in the namespace. Moreover, the changes occur during the edit. There is no "Save" or "Activate" step. As a precaution, you might want to unlink a Group Policy object from any site, domain, or organizational unit during the edit. Or you can leave it linked, but disable both the User and Computer nodes.
To edit a Group Policy object, the user must be one of the following:
A Creator Owner.
A user with delegated access to the Group Policy object. That is, an administrator or the Creator Owner must have delegated access to this user by using the Security tab in the Group Policy object Properties page, and adding them to the Group Policy Creator Owners list.
Examples of Group Policy Delegation
Below are three examples of Group Policy delegation.
In this example, control of an organizational unit is delegated to a non-administrative user so that a user can link existing Group Policy objects to the organizational unit but not create new Group Policy objects.
Throughout this example, a security group can take the place of the individual user.
In Active Directory Users and Computers snap-in, right-click the Organizational Unit that you want to delegate, and select Delegate Control .
In the Delegation of Control Wizard , click Next to go past the introduction page. You will be prompted for the names of the users and groups to which you want to delegate control.
Select a previously defined user, and click Next .
In the list of Predefined Tasks , select Manage Group Policy links , and then click Next .
Click Finish to complete the changes.
The user who you selected can add and delete Group Policy object links for the organizational unit whose control you delegated, to any Group Policy objects to which they have Read access.
If the Group Policy object is stored in another domain, the user's domain must be trusted by the storage domain.
In this example, a user is given permission to create new Group Policy objects.
This permission is often useful in combination with the right to create links, as described in the previous example. To allow for creation of new Group Policy objects, you need to add the user to the Group Policy Creator Owners administrators group.
In Active Directory Users and Computers , navigate to the Users container in the root of the domain.
Double-click Group Policy Creator Owners .
In the Properties page, select the Members tab.
Click Add , and then add the user selected above to the security group.
The user can create new Group Policy objects, and the specific user who created each object becomes the Creator Owner of that Group Policy object.
You create Group Policy objects from within Active Directory Users and Computers by right-clicking the domain or organizational unit, clicking Properties , then the Group Policy tab, and then New. These objects are, by default, linked to the domain or organizational unit that has focus when they are created. Thus, a user with delegated rights, or you as an administrator, or any user who carries out the task of creating a Group Policy object in this way must have permission not only to create the Group Policy object, but also permission to link it to the domain or organizational unit. Otherwise the New button on the Properties sheet for the domain or organizational unit is shaded.
In this example, control of a Group Policy object is delegated to a non-administrator user or group of users.
Open a Group Policy object in the Group Policy snap-in.
Right-click the root node, select Properties , and click Security .
Click Add to add the group of users or user, and then click Full control .
Clear the Apply Group Policy option or leave it checked depending on your purpose.
This example shows how to delegate control of the Group Policy object. For this, you do not need the Apply Group Policy permission. If you clear the Apply Group Policy check box, the Full Control check box is also cleared, but the user still has Read/Write access to the Group Policy object.
Click OK to save the changes.
The user or group of users can edit the Group Policy object.
Creating MMC Consoles to Delegate Group Policy
You can delegate Group Policy administrative rights by creating and saving Group Policy MMC consoles, and then specifying which users and groups have access permissions to the Group Policy object, site, domain, or organizational unit. You define permissions for a Group Policy object by using the Security tab on the Properties page of the Group Policy object. These permissions grant or deny access to a Group Policy object to specified groups.
This type of delegation is augmented by the Group Policy settings available for MMC. Several settings are available in the Administrative Templates node, under Windows Components, Microsoft Management Console. These settings enable you to establish which MMC snap-ins the affected user can or cannot run. You can specify this as inclusive, which only allows a set of snap-ins to run, or as exclusive, which does not allow a set of snap-ins to run. See the Explain tab text of the individual policy setting for more information.
You can create custom consoles (.msc files) for Group Policy as for any other snap-in.
You can create and save custom Group Policy consoles that include only a subset of the Group Policy snap-in extensions. For example, you can 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.
You can also create custom consoles that contain instances of Group Policy focused on different Group Policy objects or that contain snap-ins unrelated to Group Policy.
The computer on which the console runs must hold any DLLs used by the snap-ins. If the computer is a domain controller, the DLLs are probably present already. If not, their presence on the Windows 2000 member server or Windows 2000 Professional–based computer can be ensured by assigning or publishing the Windows 2000 Administration Tools. The package is called Adminpak.msi, and you can find it on the Windows 2000 Server companion CD.
There are several ways to start the Group Policy snap-in depending on your purpose. See Windows 2000 Help for more information. It is recommended that you delegate Group Policy using Custom Consoles. To do this, you should start Group Policy as a stand-alone snap-in:
To start Group Policy as a stand-alone snap-in
Click Start , click Run , type MMC , and then click Enter .
In the MMC window, on the Console menu, click Add/RemoveSnap-in .
On the Standalone tab, click Add .
In the Add Snap-in dialog box, click Group Policy , and then click Add.
In the Select Group Policy object dialog box, click Browse to find the Group Policy object you want to manage.
Click Extensions , and then select the extension snap-ins you want to use.
Click Finish .
Click OK . The Group Policy snap-in opens with focus on the Group Policy object you specified.
After you specify the policy settings you want to use, click Save As on the Console menu to save your settings in an .msc file.
To set access permissions, use the Security tab on the Properties page of the selected Group Policy object. These permissions allow or deny access to the Group Policy object by specified groups.
There are dozens of Group Policy settings that allow or deny access to various snap-ins and snap-in extensions. Check the following folders for settings that might be relevant for your organization:
User Configuration/Administrative Templates/Microsoft Management Console
User Configuration/Administrative Templates/Microsoft Management Console/Restricted/Permitted snap-ins
User Configuration/Administrative Templates/Microsoft Management Console/Restricted/Permitted snap-ins/Extension Snap-ins
User Configuration/Administrative Templates/Microsoft Management Console/Restricted/Permitted snap-ins/Group Policy