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:
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 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."
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:
Contacts Default Group Policy
Contacts Software Policy
Contacts Temporary Policy
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.
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.
Figure 23.1

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.
Figure 23.2

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:
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.
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.
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).
Figure 23.3


GROUP POLICY BASICS FOR WINDOWS VISTA

Home: Introduction
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
Home: Introduction
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