|This chapter excerpt from Microsoft Windows Vista Management and Administration, by Andrew Abbate, James Walker, Scott Chimner and Rand Morimoto, is printed with permission from Pearson Education, Copyright 2007.
Step 2 of 2:
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Further Understanding GPOs
Previously, when discussing the basics of Group Policy with Windows Vista, we touched on many of the rules and requirements around GPOs and their use in a domain environment. This chapter builds on the information presented there to give administrators a greater understanding of their uses and limitations.
Understanding the Order in Which Group Policies Are Applied
As mentioned previously, GPOs are applied in a specific order. Computers and users whose accounts are lower in the Directory tree can inherit Policies applied at different levels within the Active Directory tree. Group Policy is applied in the following order throughout the AD tree:
If a setting in a GPO is set to Not Configured in a policy higher up, the existing setting remains. However, if conflicts exist in configuration, the last GPO to be applied prevails. For example, if a conflict exists in a Site GPO and in an OU GPO, the settings configured in the OU GPO will "win."
Local Security Policy is applied first.
Site GPOs are applied next.
Domain GPOs are applied next.
Organizational Unit (OU) GPOs are applied next.
Nested OU GPOs and on down are applied next, until the OU at which the computer or user is a member is reached.
If multiple GPOs are applied to a specific AD object, such as a site or OU, they are applied in reverse of the order they are listed. The last GPO is applied first, and therefore if conflicts exist, settings in higher GPOs override those in lower ones. For example, if a Contacts OU has the following three Group Policies applied to it and they appear in this order the policies will be applied from the bottom up:
The Contacts Temporary Policy will be applied first. The Contacts Software Policy will apply next, and finally the Contacts Default Group Policy will be applied. Any settings in the Contacts Default Group Policy will override the settings configured in the two policies below, and the settings in the Contacts Software Policy will override any settings in the Contacts Temporary Policy.
Contacts Default Group Policy
Contacts Software Policy
Contacts Temporary Policy
Modifying Group Policy Inheritance
The Block Inheritance, Enforcement, and Link Enabled features allow control over the default inheritance rules.
GPOs can be configured to use the Enforcement feature. This setting does not allow the parent organizational unit to be overridden by the settings of the child OU if conflicts exist. Additionally, it nullifies the effects of Block Policy Inheritance if that functionality is applied on sub-GPOs.
OUs can be set to Block Policy Inheritance. This feature prevents the AD object that has the GPO applied to it from inheriting GPOs from its parent organizational unit, site, or domain (unless the parent GPO had Enforcement enabled as described previously).
To block Policy Inheritance on an OU, perform the following steps:
- Launch the Group Policy Management console (GPMC) (Start, Run, gpmc.msc).
- Expand the Forest container.
- Expand the Domains container.
- Browse to the OU to which you plan to Block Inheritance.
- Right-click the OU and choose Block Inheritance.
The OU will now display a blue circle with a white exclamation mark to indicate that Policy Inheritance is blocked from this point down in the hierarchy (see Figure 23.1). This is to say, GPOs set above this point will not affect objects below the point of blocking. This behavior can be overwritten by setting a GPO to Enforced.
Finally, the option exists that allows for the disabling of a GPO, also known as the GPO's Link Enabled status. By right-clicking the Group Policy in the Group Policy Management console and unchecking Link Enabled, you can disable the policy and render it unused until the time it is reenabled.
Configuring Group Policy Loopback
Loopback allows Group Policy to be applied to the user logging in based on the location of the computer object, not the location of the user object in AD. Loopback applies a Group Policy based on the computer the user is using, not the user logging in to the computer. An example of a good use of the loopback option concerns Terminal Services. If you need to apply specific permissions to everyone who logs in to a particular Terminal Server, regardless of the user Group Policies, loopback in replace mode will accomplish this objective by ignoring all user GPOs. Loopback also provides a merge mode that merges the GPOs that apply to the user and computer but gives precedence to the computer GPOs, overriding any conflicting user GPOs.
The GPO setting for Group Policy Loopback processing is located under
Computer Configuration / Administrative Templates / System / Group Policy / User Group Policy loopback processing mode.
Leveraging Local Policy
Local Policies can be used to enforce many of the same settings that GPOs can enforce. The advantage of the Local Policy is that it is enforced regardless of whether the computer can contact a domain controller. This means that settings can be placed into the initially deployed image and will be in effect from the moment the computer is powered on.
One very useful way to use Local Policy is to essentially reverse the paradigm of GPOs when dealing with security-related settings. For example, suppose that you want to configure Vista workstations so that their users can't run the Registry Editor. In this example, we assume that we'd like the local help desk staff to be able to run the Registry editor. The two ways to do this are the following:
Although at first glance the two options might seem equivalent, they are in fact somewhat different in their scopes. Imagine that Vista systems are being deployed to remote users. The system is built and shipped out to the end user. The user receives the computer and powers it on for the first time. If the user is on the network at this first boot, the GPO will be received and applied properly. If the system is not on the network, the domain GPOs cannot take effect. In Option 1, the remote user would be able to run the Registry Editor and make modifications to the system. In Option 2, the user would not be able to modify the system. In cases where the computer needs to be protected or modified prior to its first logon to the domain, Local Policy is a better option.
Option 1 -- Block the capability to run Registry Editor via GPO. Link the GPO to the container holding typical users. Place help desk personnel in another container in Active Directory. Do not link the Registry Editor blocking GPO to those users. Option 2 -- Block the capability to run Registry Editor in Local Policy on the deployed Vista image. Create a GPO that enables running the Registry Editor. Link it to a container that holds help desk personnel.
Local Policy can be accessed by performing the following steps:
- Click Start.
- Click All Programs.
- Click Administrative Tools.
- Click Local Security Policy (see Figure 23.3).
GROUP POLICY BASICS FOR WINDOWS VISTA
Tip 1: A basic primer on Microsoft Group Policy
Tip 2: How to configure GPOs
Tip 3: What's new with Vista Group Policy?
Tip 4: How to manage GPOs
Tip 5: Troubleshooting GPOs for Vista
Tip 6: Group Policy best practices
ADVANCED GROUP POLICY FOR WINDOWS VISTA
Tip 1: Which GPOs are available
Tip 2: Further understanding GPOs in Vista
Tip 3: Examples of useful GPOs in Vista
Tip 4: Moving policies between domains
Tip 5: Recommended practices with Vista Group Policy