Beyond the standardized environment, security of the Windows computers is something that should not be compromised or put into jeopardy. When Group Policy is used to control this security, the control over the administrators and others that can manipulate Group Policy must also be maintained. By default this control over Group Policy is not very granular. There are a few settings which can be made within the Active Directory Users and Computers, but they don't provide the granular control that is necessary to protect such an important aspect of every computer in the enterprise. However, the Group Policy Management Console (GPMC) provided free from Microsoft enhances the capabilities of controlling "who" can perform "which" tasks with Group Policy. This article describes those tasks and the proper way to configure them within the GPMC.
Getting the GPMC
When Active Directory was first introduced, the only way to access and modify Group Policy in an efficient manner was to use the Active Directory Users and Computers snap-in. There was an option to use a Group Policy snap-in, but this interface did not provide a very good view of the Group Policy infrastructure as a whole so it was rarely, if ever, used.
If you still use the Active Directory Users and Computers to administer Group Policy, I strongly encourage you to go to Microsoft's Web site and download GPMC (www.microsoft.com/windowsserver2003/gpmc/). The only negative to using the GPMC is that you must install it and run it on a Windows XP or Windows Server 2003 computer. This does not prohibit it from controlling Group Policy in a Windows 2000 domain, it only means that administration must occur from one of the newer operating systems.
Group Policy Roles via GPMC
The GPMC provides an excellent environment to take control over the Group Policy administration within you Active Directory enterprise. Some of the roles are comparable to those that were offered without the GPMC, but with the GPMC, the configuration of those roles is easier and more granular. The following roles can be delegated over Group Policy to one or more administrators.
- Creating GPOs
- Linking GPOs
- Managing GPOs
- Editing GPOs
- Read GPOs
As you can see, these roles are very important and target the key areas of administration over Group Policy and Group Policy Objects (GPOs). In addition to this article describing what each role encompasses, it will also help you determine where each role can be configured within the interface, which is more than half of the battle.
The creation of GPOs is handled at the domain level. This means that you can either create GPOs for the entire domain, or you can't create them at all. This is one of the tasks that the "pre-GPMC" could handle. It was handled by adding users to the Group Policy Creator Owners group. Membership in this group still provides you with this luxury of creating GPOs, but the GPMC adds another layer of delegation, giving a clearer look as to who can create GPOs in the domain.
This delegation can be seen if you click on the domain name in the GPMC console, then select the Delegation tab on the right-hand pane. Here, you can see the list of users and groups that can create GPOs in the domain, as shown in Figure 1.
Figure 1: Users and groups that can create GPOs in the domain
To add more groups to this list, simply click the Add button.
The linking of GPOs is not a domain wide task, rather it is a task that is handled at the Active Directory container where the GPO should be linked. Therefore, this is a delegated role that is scattered throughout the Active Directory structure, at each container that can accept a GPO link. Since only sites, the domain node, and organizational units (OUs) can have GPOs linked to them, these are the containers where the delegation can be configured.
To see and enable link delegation, click on the desired node within the GPMC structure, then select the Delegation tab on the right-hand pane. Here, you will see the list of users and groups that can create a link to a GPO from this container within the Active Directory structure, as shown in Figure 2.
Figure 2: Users and groups that can create a link to a GPO from this container
Like the creation of GPOs delegation, additional groups can be added to the list here by clicking on the Add button. This granular control of who can link a GPO to specific levels within the Active Directory is very attractive to companies that have OU level administrators. This is a common administrative structure and one that fits very nicely into the delegation model that Microsoft provides within the GPMC. In most companies that I have dealt with, the OU administrators send in a request for a GPO to be created, which the delegation presents them with the chance to link it to their OU.
A special note here about these first two delegations. If an administrator has been given the delegation to create GPOs, it does not provide them with the ability to link it to any location within Active Directory. It only provides them with the ability to create GPOs in the Group Policy Objects node within the GPMC. Likewise, if an administrator has been given the ability to link GPOs, it does not provide them with the capability to create them. The only way that an administrator has the ability to create and link GPOs is to have them located in a group which supplies them with both of these delegated privileges.
Management of GPOs is not actually named "Management" in the GPMC. However, it is certainly a management role that is provided when a user is given the ability to "Edit settings, delete, modify security" of a GPO. This is a role that was not supported in any way before the GPMC and is one that is highly useful. This role is different than the first two we reviewed, in that this role is delegated at the GPO level. This means that each GPO within the domain can have a unique set of administrators that control it. Again, this matches up nicely with the OU administrator concept.
To see and enable this delegated privilege, simply select the desired GPO, then click on the Delegation tab on the right-hand pane. Right-clicking on the entry within the right-pane gives you the option to "Edit settings, delete, modify security" for the GPO. The list of configured users and groups indicates the level at which the object has been given privilege, as shown in Figure 3.
Figure 3: Users and groups which have permission to manage, edit, or read GPOs
This delegation gives the user the ability to do the following actions to the GPO:
- Edit policy settings
- Delete the GPO and all links to it
- Configure WMI filters for the GPO
- Enable or disable all or part of the GPO
- Configure Delegation for the GPO
- Configure GPO filtering on the GPO
Editing and Reading GPOs
These privileges were possible before the GPMC, but they were very difficult to configure and something that required deep level permission configuration. The benefit is that the GPMC brings these valuable delegation privileges to the surface. To configure these delegations, you only need to go to the same tab where the Management of GPOs was configured, as can be seen in Figure 3.
These privileges are subsets of the Management delegation, which restricts the administrator to only updating the policy settings or reading the settings using the settings report of the RSoP report. In a situation where you want to limit the administrator to just controlling the settings contained within the GPO, it is clear that this delegated role is ideal.
The GPMC is a tool that every administrator of Group Policy should be using. Without it, administration and delegation over Group Policy management is very difficult. The GPMC allows for granular delegation over key roles associated with Group Policy, including creating, linking, managing, editing, and reading GPOs. By using the GPMC to delegate these roles to administrators, a company is certain that the correct users have control over the appropriate tasks based on the overall Active Directory administrative structure. I will also add that GPMC provides excellent capabilities over backing up, restoring, and archiving GPOs.