How to Use Group Policy

Group policy provides the capability to control a wide variety of desktop configurations. In addition, through group policy, selective and dynamic application deployment is possible. This section provides an overview of what can be done with group policy.

Now that you have been introduced to the components that make up group policy and understand how to create a GPO, the next level of planning and capability is to discuss how to use group policies.

A straight forward way to look at implementing group policies is to look at the various desktop types that you are interested in supporting. This is a simple first step. Based on your organization and the size of your staff, you need to decide on the number of supportable desktop configurations and how best to design the OU structure to support it.

The trade-off that you are evaluating is the benefit of the multiple desktop types and their impact on the complexity of the administrative environment. If you have single OUs and no child OUs to work with, and if each department in your organization would like to have a unique desktop standard, you can imagine a GPO nightmare in a large organization. The impact on performance, administration, and troubleshooting becomes too costly to justify the unique desktop standards. As the Active Directory designer and administrator, you might need to make compromises and to combine requirements into a single GPO. As an example, the Finance department users might have similar application requirements to the sales staff. Both need access to quantitative tools and database access tools. One approach would be to combine the requirements of these users into a single GPO.

Another approach would be to have unique OUs for each one of the unique desktop standards. This would result in an OU structure that was wide and flat. A flat OU structure provides for a decentralized administration, and the GPO processing time is better than deep OU structure with many GPOs to process.

Another approach is to create a layering of GPOs. How does this work? Group policies can be applied to SDOUs, as was mentioned before. The interesting part is that GPOs are applied to users and computers based on where they are located in the OU structure. The GPOs are applied from the top down, and they are cumulative. If we take Figure 9.5 as a sample environment, Site A has two users and two computer GPOs, Domain Windows 2000 has two users and computer GPOs, and OU1 has a single user and computer GPO. If a user, George, logs in, all the GPOs are applied to his computer and his user ID. Depending on if George's account is located in Domain Windows 2000, OU1, or Site A, he receives a different set of GPOs applied to his working environment.

Let's take a few scenarios to demonstrate how the GPOs are applied. If George's account is in Domain W2K, George and the workstation he is logging in to receive GPOcmp1 through GPOcmp4 when the computer starts up. User GPOs (GPOuser1 through GPOuser4) are applied when the user logs in. In addition, the administrator should note that the order of application is GPOcmp1, GPOcmp2, GPOcmp3, GPOcmp4, GPOuser1, GPOuser2, GPOuser3, and GPOuser4. This describes the simplest application of group policies. This example demonstrates how Active Directory hierarchy affects the application of GPOs.

With Active Directory, the administrator can block a policy from a specific OU or domain. In the example, the administrator could specify that the GPOuser3 be blocked from OU1. If a user in container OU1 logs into the directory, GPOuser3 is not inherited. A GPO that specifies Enforce is applied to all the objects in that container and to those below it. The Enforce takes precedence over a Block.

The next level of control for GPOs is the use of security groups. The administrator of each GPO has the ability to prevent the GPO from being applied to a specific group of users. By default the Apply Group Policy access control entity (ACE) is turned on. In other words, by default, GPOs apply to users and groups within the hierarchy. This can be explicitly turned off by disabling the Apply Group Policy ACE (see Figure 9.3).

Application of GPOs

The application of GPOs and user settings to your computer is important to understand when configuring a series of GPOs for managing your desktop. By understanding how GPOs are applied to your system when you start up and log in to your domain, you are better prepared to create a solid design that works as planned. In the case that your design is not operating the way you expected, the order in which the GPOs are applied and the interleafed events help debug and resolve unexplained occurrences.

If a Windows 2000 system starts up, the system applies the computer settings from the group policies. The Startup scripts are the executed. If the user logs into the computer, the user settings from the group polices are applied, and then the logon scripts are run.

There is also a tool for evaluating security settings without logging in and out of the system. You can use secedit. The syntax is: secedit /refresh policy {machine policy | user policy} [/enforce]. The machine policy is for the local machine. The user policy is for the user currently running secedit. The enforce option refreshes the security settings, even if there have been no changes to the security policy.

To cement the understanding of the application of GPOs on a user or computer, please examine the following scenarios. There are two security groups, Finance and Sales. The Finance and Sales groups have users at the domain level and at the OU level. The domain and GPOs are as depicted in Figure 9.4. Table 9.1 describes the additional features that have been applied to the specific GPOs and security groups.

Table 9.1. GPO and Security Group Features

GPO	Enforce	Block	Apply Group Policy	Policy
GPOcmp1				Enable disk quotas
GPOcmp2				Enable disk quota of 100MB; warning at 75MB
GPOuser1	Yes			Enable hide IE 5.0 icon on desktop
GPOuser2		Finance		Enable hide MyDocuments icon on desktop
GPOcmp3				Enable disk quota of 75MB; warning at 50MB
GPOcmp4			Deny Finance	Enable disk quota of 75MB; warning at 25MB
GPOuser3			Deny Finance	Disable hide IE 5.0 icon on desktop
GPOuser4				Screensaver enabled using specific screensaver
GPOcmp5		Sales		Enable disk quota of 50MB; warning at 25MB
GPOuser5			Deny Sales	Remove all desktop icons

Using Table 9.1 and Figure 9.4, we will demonstrate the impact of the GPOs on users logging into Active Directory. For this example, we'll consider a user that is located at the domain level and is a member of the Finance group.

Keep in mind that this is an example, and in the real world, the GPO would contain multiple configuration options, and the impact of an Enforce, Deny, or restriction based on user or group can be significant.

Applying or not applying a GPO affects a variety of options. If you start layering GPOs on top of each other and if each GPO has multiple features enabled with a variety of different configuration settings, predicting the outcome can be difficult.

Delegation Group Policy Administration

Group policy administration can be distributed based on groups. As an example, enterprise administrators have the ability to read, write, create all child objects, and delete child objects for a specific GPO. You are able to create a group of administrators and give them rights for administering a GPO. The list of permissions is long and granular. Administrators can identify individuals for specific tasks and give them the permissions to perform them on specific GPOs.

A scenario in which you might use delegation of the group policy administration is one with a set of GPOs that are used by a specific set of users. As an example, the Finance group might need to have a GPO, or a series of GPOs, modified while a new application is in beta. Rather than have a centralized administrator work with this while the standards for use are being developed, it is appropriate to give it to an individual that working on the specific application installation.

Group policy administration can be delegated to individuals and groups through security groups. There are six different parameters to set as part of the group policy. These options can be set to an individual level. They are as follows:

• Full Control

• Read

• Write

• Create all child objects

• Delete all child objects

• Apply group policy

Full Control permits the user, or group, the ability to change any of the settings for the GPO. The owner of the object should have this capability. The Read and Write are available for applying changes. The Apply option needs to be coupled with Read for the Apply option to be "Applied." The Create and Delete all child objects provide the permissions for deleting or creating child objects for the objects selected. The Apply Group Policy is to identify that a policy is applied to those users identified in the Security Group window.

These permissions are applied to some of the standard security group when GPOs are created. The Domain and Enterprise Admins group has the ability to read, write, create child objects, and delete child objects when the object is created. Authenticated Users have the GPO applied by default. They have the read and apply group policy permissions.

If you need to create a new GPO, you need to have access to the MMC snap-in Active Directory Users and Computers. From there, you need administrative access to the OU and the object. Most everyone has access to the OU. By default, all those in the domain have the read and apply permissions. These permit them to read the GPO, but you are not permitted to make any changes without specific access to the system.

If you create a GPO but you want someone else to maintain it, you are able to give him or her the tools and set their permissions on the object to read, write, create, and delete child object permissions. If you want to test the result of your changes, you should build a lab. This prevents any unwanted GPO application.