Who gets what? Deploying Group Policies

The following excerpt, courtesy of APress, is from Chapter 4 of the book "Active Directory Field Guide" written by Laura E. Hunter. Click for the complete book excerpt series or purchase the book.

Who gets what? Deploying Group Policies

Once you've customized your Group Policy Objects, you need to incorporate them into Active Directory so that your users can receive the appropriate settings. You accomplish this by linking Group Policy Objects to various containers within Active Directory: sites, domains, and Organizational Units. Once you've linked a GPO to a container, every object within that container will receive the GPO settings by default. In this section we'll look at how to link GPOs throughout your AD infrastructure, and how GPOs interact with one another if you have multiple objects linked to different points in your AD tree. We'll close with a look at some more advanced deployment topics such as controlling GPO inheritance and using security groups to fine-tune GPO deployment.

Using Organizational Units

The most common scenario for Group Policy deployment is to place the users and computers that require similar settings into a separate Organizational Unit, and then link a GPO to the OU to create a consistent configuration for all the members of that OU. You can link a GPO at the same time that you create it, or create an unlinked GPO and manually create a link once you've tested and finalized all of its settings.

To create and link a GPO to an OU, open the Group Policy Management Console. Right-click the OU and select Create and Link a GPO Here.

To link an existing GPO to an OU, open the GPMC. Right-click the OU and select Link an Existing GPO.

NOTE: You can link a single GPO to multiple sites, domains, or OUs within Active Directory. However, it's a best practice not to link a GPO from one domain to a container in another, since this can create performance issues.

Configuring Policy Inheritance

In a complex network, you may find yourself with numerous GPOs deployed at various points throughout the infrastructure. It's important to understand how these different policies will interact with each other and ultimately affect your users. Much like NTFS permissions in the Windows file structure, Group Policy settings adhere to specific rules of inheritance. When a user logs onto your network, policy objects will be applied in the following order:

1. First, the Local Group Policy Object will be applied.
2. Second are any GPOs applied to the site the user and computer belongs to.
3. This is followed by any GPOs applied to the user's domain.
4. Finally, any GPOs linked to Organizational Units will be applied. If you have a nested OU structure, the GPO linked to the topmost OU will be applied first, and then the GPOs of any child OUs.

GPO inheritance is a cumulative process: this means that settings applied by later GPOs will be added to any earlier settings, rather than overwriting any previous settings. So if the domain GPO sets a minimum password length of eight characters, and then an OU GPO is applied that mandates a uniform screen-saver setting, the user will receive both settings.

So what happens if these additive settings conflict with each other? Say the domain GPO in your domain has a linked policy that blocks access to Registry editing tools, but you have created a Development OU that houses programming staff who require access to the Windows Registry. You create a GPO and link it to the Development OU, and explicitly grant access to Registry editing tools. Will this work? It will, because Group Policy Objects that are applied later have precedence over those that are applied earlier. (Think of it as having an argument where the person who gets in the last word is the one who wins.) So in this case, the Registry editing tools setting that was applied by the Development GPO "wins" over the setting applied in the domain GPO. So users in your Development OU will have access to the Registry editor, but other users in the domain (provided they don't have other GPOs applied elsewhere) will not be able to access them.

CAUTION: These inheritance rules do not apply to those settings that can only be set at the domain level: account policies, account lockout policies, and Kerberos policies. Even if you set different values for these items at an OU level, your domain users will still be held to the settings configured for the domain.

Customizing Policy Inheritance

What we've just described is the default behavior of Group Policy inheritance. But like anything else within Active Directory, you can customize these rules to finely control the way that Group Policies are deployed throughout your network. You can do this using security filtering with Active Directory security groups and Windows Management Instrumentation WMI filters, and by changing the default inheritance behavior for certain Organizational Units within your AD structure.

Blocking GPO Inheritance

If you have an OU that requires a very specific configuration, you may decide that you only want a single GPO to apply to it, so as to avoid interactions with other policy objects. You can accomplish this by right-clicking the OU within the Group Policy Management Console and selecting Block Inheritance. As the name suggests, this will prevent any GPO settings elsewhere in Active Directory from being applied within this particular OU; it will only receive settings from GPOs linked directly to the OU itself.

But in this case, even the exceptions can have exceptions: you can rightclick a particular GPO link (not the GPO object itself) within the GPMC and select the Enforced option. This will ensure that the settings applied by this particular link cannot be blocked by any containers further down the GPO processing line.

NOTE: In Windows 2000, you'll enable the No Override option on the Properties sheet of the GPO itself.

As you can imagine, overuse of these two options can wreak havoc on your network and make troubleshooting quite a challenge. What happens if you have a GPO attached to a parent OU that has the Enforced option enabled, and then a child OU with a different GPO that has the Enforced setting enabled? If there is a setting conflict, which "enforced" GPO will win? In this case, the rules of inheritance will be reversed, and the first GPO applied with the Enforced setting enabled will take precedence. Tough to follow? I certainly think so: try to keep things simple and avoid convoluted scenarios like this one wherever possible.

Applying Security Filtering

Just like files and folders stored on NTFS volumes, you can create Access Control Lists for Group Policy Objects to control which Windows users and groups have access to them. In order for a GPO to be applied to a user or computer object, that object needs to have the Read and Apply Group Policy NTFS permissions to the GPO object. If both of these permissions are not present, the user or computer will not apply the settings within that particular GPO; in effect, it won't exist as far as that user/computer is concerned. When you create a new GPO in Windows Server 2003, for example, the following permissions are created by default:

Authenticated Users: Read, Apply Group Policy

Enterprise Domain Controllers: Read

Domain Admins/Enterprise Admins/SYSTEM: Read, Write, Create All Child Objects, Delete All Child Objects

You can modify these permissions to ensure that specific GPOs will be applied to certain users or groups within a site, a domain, or an OU, and likewise prevent them from being applied to others. Notice that Domain Admins and Enterprise Admins do not receive the Apply Group Policy permission by default. This is to ensure that administrators do not become "locked out" of operating system functions when they need to perform troubleshooting or make modifications.

A scenario that is particularly conducive to using security filtering is software installation, since you may have one application that needs to be installed for specific users located across several Organizational Units, but not for your entire domain or even the entire population of an OU. Rather than creating multiple GPOs for each OU that requires the software, or managing multiple links to a single GPO, you can deploy the software within the domain GPO, and then use security filtering to specify which users and groups should receive the software. Depending on your specific needs, you can adopt one of two strategies:

Remove the Read/Apply Group Policy entry for the Authenticated Users group. Then manually add the specific users and groups who should receive the GPO settings, and grant each one Read and Apply Group Policy permissions.

Leave the default permissions for Authenticated Users in place, and then explicitly deny the Read/Apply Group Policy permissions to groups who should not receive the GPO. Setting explicit Deny permissions to a specific group will override the default Authenticated Users permission, and those specific groups will not receive the GPO settings.

Either of these procedures will be effective, you simply need to decide which is more appropriate for your organization. As a general rule, adopt the strategy that will result in the most straightforward permission assignment for the GPO, since this will simplify any changes you need to make later, as well as any troubleshooting you need to do.

Using WMI Filtering

For Windows XP and Windows Server 2003 machines, you can also control which machines receive particular GPO settings through the use of a WMI filter. WMI allows you to query a computer about its specific hardware and software settings, such as which service pack is installed, how much free space is available on the C: drive, and whether a specific service is installed or running. You can then create filters, which consist of one or more queries based on this type of data, to control whether or not the GPO gets applied. If the result of the WMI filter (such as "Is Service Pack 2 installed?" or "Does the machine have 350MB free drive space?") is true, then the GPO is applied to that destination computer. If not, then the GPO is ignored.

CAUTION: On a machine running Windows 2000, any WMI filters will be ignored and the GPO will always applied.

To create a WMI filter, follow these steps:

1. Open the GPMC console tree, right-click the WMI Filters node, and click New.
2. Enter a name and description for the WMI filter, and then click Add.
3. In the WMI Query dialog box, enter the text of the query that you want to run, such as

Select * from Win32_OperatingSystem where
Caption = " Microsoft Windows XP Professional"

4. Click OK after you've entered your query. If you want to filter on more than one query, you can click Add to enter additional query information. When you're finished, click Save.
5. Select the GPO that you want to link this WMI filter to, and select the name of the filter in the WMI Filtering drop-down box near the bottom of the right-hand pane of the GPMC console.

Just as you can link a single GPO to multiple sites, domains, and OUs, so you can link a single WMI filter to multiple Group Policy Objects. However, you can only link a single WMI filter to a GPO at any one time. This is because processing a WMI filter, especially a complicated one involving multiple queries, can be resource-intensive for the target computer and can increase a user's logon time.

Click for the next excerpt in this series: Controlling the desktop