When you design a Group Policy strategy, you can develop some common-sense rules to follow—
except they contradict each other. You know what you would like to do, but existing security,
permissions, and Active Directory structures make it difficult. And, no, the company will not
stop trading for a few weeks while you sort it all out.
This lesson looks at how you plan Group Policy and define a Group Policy hierarchy. It looks
at how you control device installation, authentication and authorization, and the new finegrained
password policy that Windows Server 2008 introduces. Mainly, however, it looks at
the art of the possible. This is the structure you have—where do you go from here?
After this lesson, you will be able to:
■ Plan a Group Policy hierarchy and implement scope filtering.
■ Control device installation through Group Policy.
■ Distinguish between multifactor authentication and multifactor authorization.
■ Plan a password policy, including the use of fine-grained passwords.
■ Plan an authentication policy that uses security certificates and smart cards.
Estimated lesson time: 40 minutes
When I first walked into a senior administrator’s post, I confess I was a bit lost.
I knew there was a lot to do and a very short time in which to do it. As in many organizations,
the Active Directory and Group Policy structures in the enterprise had been
allowed simply to grow with no proper planning. Nobody knew exactly which settings
were in force and how to change them.
Fortunately, I knew my job wasn’t to Remote Desktop to the nearest DC and start reconfiguring.
I needed to get my team together and start planning. I needed to gather what little
documentation there was, find out where we were, and decide where we were going.
My team was less than enamored by the thought of meetings, planning, and discussions.
They were desperately fighting emergencies. Ten users, nine of them managers and the
other the CEO’s secretary, had forgotten their passwords and been locked out of their
computers. Other users couldn’t locate their files on the file server. One more knowledgeable
user had discovered she could access files that she shouldn’t have been able to.
Lesson 2: Designing Enterprise-Level Group Policy Strategy 201
I’d been there. I’d done all that. The only way that my people wouldn’t spend 40 hours
a week resolving emergencies was to plan and reorganize the structures. I made my
views heard. Loudly.
You probably feel the same when you look at an examination such as 70-647. Where is
the comfortable “do this, do that, it will work, and here’s the theory behind it”? Instead,
you get “you know the theory; you’ve done this procedure a hundred times. Now plan
things properly so you won’t need to do it a hundred times more.”
It’s not a comfort zone. Get used to it.
Planning a Group Policy Hierarchy
Group Policy is applied through OUs that are linked to GPOs. A domain is itself an OU, and
the default domain policies are defined in the Default Domain Policy GPO. Thus, Group Policy
hierarchy and structure is closely linked with Active Directory OU structure. You will seldom
have the luxury of planning and creating an Active Directory structure, a Group Policy structure,
and a Group Policy hierarchy from scratch. You will be faced with current structures and
a list of requirements, some of them contradictory.
The effective Group Policy is made up of multiple Group Policy elements that are applied to
user objects and to computer objects. You must manage your GPOs so that you keep them well
organized and make it as simple as possible to determine which policy elements apply in a
GPOs that apply at domain and site level can be combined with GPOs that apply to OUs, OU
hierarchies, and local computer settings. Several GPOs can link to a single OU, and you need
to determine the order in which they are applied. If Group Policy settings in multiple GPOs
conflict, the GPO that is applied last defines the settings. This applies unless a GPO earlier in
the order has been configured to be enforced. When a GPO is configured to be enforced, its
settings override those applied later. You can apply site policy, domain policy, and OU policy.
Figure 4-15 shows multiple GPOs linked to a single OU.
202 Chapter 4 Designing Active Directory Administration and Group Policy Strategy
Figure 4-15 Linking multiple GPOs to an OU
The link precedence is shown in Figure 4-16. You can change the order of precedence by selecting
a GPO link and moving it up or down.
Figure 4-16 GPO precedence
Rules for Planning a GPO Structure
The first rule is to keep things as simple as possible. The ability to block Group Policy inheritance
and to enable the Enforced property to prevent inheritance blocking can be useful if used
sparingly but can make structures complex and difficult to interpret if overused. The same can
be said for Loopback Policy.
You should not have too many non-default settings configured in a single GPO. Design GPOs for
a single purpose, for example, a device installation configuration GPO, and name them accordingly.
Similarly, give your OUs sensible names. Sales Department OU is descriptive. OU1 is not.
Lesson 2: Designing Enterprise-Level Group Policy Strategy 203
Never link GPOs to OUs across sites and over slow WAN links. If you have two containers in
different sites that require the same settings, use two GPOs. In Windows Server 2008, you can
use Group Policy Management Console to copy a GPO. The new GPO you create is not linked
to any domain or OU; you need to link it to a domain or OU. You can copy a GPO to another
site or to another domain in the same forest or export a GPO to a domain in another forest,
provided a forest trust is configured.
Always disable unused Group Policy elements. In larger organizations, you might need GPOs
at every level of AD DS, but smaller organizations can often design their Group Policy structure
so that links take place at a single level within AD DS, and inheritance does the rest. If a
GPO contains only user settings and is linked to an OU that contains only users, you can disable
the computer settings for that GPO. This simplifies the structure, uses fewer resources,
and speeds up user logons.
As an experienced administrator, you will be familiar with the Block Inheritance and Enforced
features that you can configure to control Group Policy inheritance. As a planner, you should
know when to use these features—they can sometimes be very useful—but mainly when not to
use them. Block Inheritance and Enforced are known as exceptions. They add complexity and
make your structure difficult to understand. They need careful documentation. Plan to use
them as seldom as possible.
Planning Active Directory Structure
AD DS stores and organizes objects (users, computers, devices, and so on) in a secure hierarchical
containment structure that is known as the logical structure. Although the logical structure
of AD DS is a hierarchical organization of all users, computers, and other physical
resources, the forest and domain form the basis of the logical structure. As previously stated in
this lesson, you seldom get to plan and design Active Directory structure from scratch, but you
need to consider the principles of good Active Directory design when planning Group Policy
structure and strategy.
Forests are the security boundaries of the logical structure. You can plan and design them to
provide data and service autonomy and isolation in an organization in ways that can both
reflect site and group identities and remove dependencies on the physical topology. Multipleforest
enterprises tend to occur during an acquisition or merger, and you might need to plan
whether to retain multiple forests or create a new, single-forest structure.
Domains provide data and service autonomy (but not isolation) and optimize replication
within a given region. This separation of logical and physical structures improves manageability
and reduces administrative costs because the logical structure is not affected by changes in
the physical structure. The logical structure also makes it possible to control access to data.
This means that you can use the logical structure to compartmentalize data so that you can
control access to it by controlling access to the various compartments.
204 Chapter 4 Designing Active Directory Administration and Group Policy Strategy
Information stored in AD DS can come from diverse sources. As a result, it employs a standardized
storage mechanism to maintain data integrity. In AD DS, objects are used to store information
in the directory, and all objects are defined in the schema. The object definitions
contain information—such as data type and syntax—that the directory uses to ensure that the
stored data is valid. No data can be stored in the directory unless the objects used to store the
data are first defined in the schema. The default schema contains all the object definitions that
AD DS needs to function. You can also add object definitions to the schema.
AD DS appears to the administrator and planner as a logical structure that consists of elements
such as OUs, domains, and forests. However, the directory itself is implemented through a
physical structure that consists of a database stored on all DCs in a forest. The Active Directory
data store handles all access to the database and consists of both services and physical files.
These services and physical files make the directory available, and they manage the processes
of reading and writing the data inside the database that exists on the hard disk ofeach DC.
Planning Active Directory Domains and Forests
Domains partition the directory into smaller sections within a single forest. This partitioning
results in more control over how data is replicated so that an efficient replication topology can
be established, and network bandwidth is not wasted by replicating data where it is not
required. OUs make it possible to group resources in a domain for management purposes
such as applying Group Policy or delegating control to administrators.
In the days before AD DS, the domain was the security and administrative boundary, and
Windows NT 4.0 and Windows NT 3.5 networks typically held a number of domains for this
reason. In AD DS, much of what was done in Windows NT domains can now be accomplished
by using OUs, and even quite large Active Directory networks can be single domain. The reasons
for multiple domains were replication efficiency (still a consideration) and password policies.
In a domain at the Windows 2000 Server Native or Windows 2003 domain functional
levels, it is not possible to implement different password policies for different users without
creating more than one domain. If you raise the domain functional level to Windows Server
2008, however, you can use fine-grained password policies (described later in this lesson),
invalidating another reason for multiple domains.
The Active Directory Schema
The Active Directory schema contains definitions for all the objects used to store information
in the directory. There is one schema per forest. However, a copy of the schema exists on every
DC in the forest. This way, every DC can quickly access any object definition it might need, and
every DC uses the same definition when it creates a given object. The data store relies on the
schema to provide object definitions and uses those definitions to enforce data integrity. The
result is that all objects are created uniformly. It does not matter which DC creates or modifies
an object because all DCs use the same object definition.
Lesson 2: Designing Enterprise-Level Group Policy Strategy 205
The Active Directory Data Store
The Active Directory data store is made up of several components that together provide directory
services to directory clients. These components include the following:
■ The directory database in which the data is actually stored
■ The Lightweight Directory Access Protocol (LDAP) interface
■ The Replication (REPL) and DC management interface
■ The Messaging API (MAPI) interface
■ The Security Accounts Manager (SAM) interface
■ The Directory System Agent (DSA) service component
■ The Database Layer service component
■ The Extensible Storage Engine (ESE) service component
When planning your Group Policy structure, bear in mind that you can further refine the
application of the policy settings in a GPO by specifying that they should be applied only to
specified security groups. These security groups need to be in the container or containers (for
example, OU or domain) to which the GPO is linked. They can contain user or computer
accounts. If a security group contains user accounts, remove Authenticated Users from the
policy scope before you add the security group to the scope.
Figure 4-17 shows the scope of the Device Installation GPO limited to computers in the USA
Computers security group. Take note of this facility because it could play a part in your Group
Policy design but, like the Enforced option, it is an exception and should be used sparingly.
Figure 4-17 GPO filtering
206 Chapter 4 Designing Active Directory Administration and Group Policy Strategy
Controlling Device Installation
When you are formulating a plan to control the installation of devices (typically, USB devices)
in your enterprise, you can use Group Policy to specify whether devices can be installed and,
if so, which criteria should be applied. Depending upon company policy, your plan could have
one of the following outcomes:
■ Prevent users (except for administrators) from installing any device.
■ Allow users to install only devices that are on an approved list. If a device is not on the
list, the user cannot install it.
■ Prevent users from installing devices that are on a prohibited list. If a device is not on the
list, the user can install it.
■ Deny read or write access to users for devices that are removable or that use removable
media such as CD and DVD burners, external hard drives, and portable devices such as
media players, smart phones, or Pocket PC devices.
You need to be familiar with the device installation process and the identification strings that
match a device with the device driver packages available on a computer. Obtaining device
identities (IDs) and global unique identifiers (GUIDs) is discussed later in this section.
By restricting the devices that users can install, you can reduce the risk of data theft. Users will
find it more difficult to make unauthorized copies of company data if they cannot install unapproved
devices that support removable media on their computers. You can plan to use Group
Policy to deny write access to users for devices that are removable or that use removable media.
Restricting device installation can also reduce support costs. You can ensure that users install
only those devices that your help desk is trained and equipped to support. This reduces both
support costs and user confusion.
In an enterprise environment in which you manage a large number of client computers, you
can apply Group Policy settings to manage device installation on computers that are members
of a domain or of an OU in a domain. You can choose from one of the following strategies:
■ Prevent installation of all devices You plan to prevent standard users from installing any
device but to allow administrators to install or update devices. In this scenario, you configure
two computer Group Policy settings. The first prevents all users from installing
devices, and the second exempts administrators from the restrictions.
■ Allow users to install authorized devices only You plan to allow users to install only the
devices included on a list of authorized devices. In this scenario, you initially prevent
standard users from installing any device. You then create a list of authorized devices
and configure Group Policy so that standard users can install only specified devices.
■ Prevent installation of prohibited devices only You plan to allow standard users to
install most devices but prevent them from installing devices included on a list of prohibited
devices. In this scenario, you do not use Group Policy to prohibit installation of
Lesson 2: Designing Enterprise-Level Group Policy Strategy 207
all devices; instead, you create a list of prohibited devices and configure Group Policy so
that standard users can install any device except those on the list.
■ Control the use of removable media storage devices You plan to prevent standard users
from writing data to removable storage devices or to devices with removable media such
as USB memory drives or a CD or DVD burner. In this scenario, you configure a computer
Group Policy to allow read access but deny write access to USB memory devices
and to any CD or DVD burner device on users’ computers. You can then configure a setting
that prevents this policy from affecting users who are members of the Administrators
NOTE System installation
These plans and policies do not restrict the use of devices by the system, for example, the Windows
ReadyBoost feature on Windows Vista clients.
Group Policy Settings That Control Device Installation
Windows Vista and Windows Server 2008 introduce new policy settings that enable you to
control device installation. You can configure these policy settings individually on a single
computer, but in the enterprise environment, you are more likely to apply them to a large number
of computers through Group Policy in an Active Directory domain. These are computer policies
and affect any user logged on to a computer, except for the Allow Administrators To Override
Device Installation Policies setting, which exempts members of the built-in local Administrators
group from any of the device installation restrictions. The following policy settings allow you or
members of your administrative team to implement your device installation plan:
■ Prevent Installation Of Devices Not Described By Other Policy Settings If this policy setting
is enabled, users cannot install or update the drivers for devices unless they are
described by either the Allow Installation Of Devices That Match Any Of These Device IDs
policy setting or the Allow Installation Of Devices Using Drivers That Match These Device
Setup Classes policy setting. If your plan involves disabling or not configuring this policy
setting, users can install and update the driver for any device that is not described by the
Prevent Installation Of Devices That Match Any Of These Device IDs policy setting, the
Prevent Installation Of Devices Using Drivers That Match These Device Setup Classes policy
setting, or the Prevent Installation Of Removable Devices policy setting.
■ Allow Administrators To Override Device Installation Restriction Policies If this policy
setting is enabled, it allows members of the local Administrators group to install and
update the drivers for any device, regardless of other policy settings. Administrators can
use the Add Hardware Wizard or the Update Driver Wizard to install and update the
drivers for any device. If your plan disables or does not configure this policy setting,
administrators are subject to all policy settings that restrict device installation.
208 Chapter 4 Designing Active Directory Administration and Group Policy Strategy
■ Prevent Installation Of Devices That Match Any Of These Device IDs This policy setting
enables you to specify a list of Plug and Play hardware IDs and compatible IDs for
devices that users cannot install. Enabling this policy setting prevents users from installing
or updating the driver for a device if any of its hardware IDs or compatible IDs is
included in the list. If your plan disables or does not configure this policy setting, users
can install devices and update their drivers as permitted by other policy settings for
device installation. This policy setting takes precedence over any other policy settings
that allow users to install a device and prevents users from installing a device even if its
ID matches another policy setting that would allow installation.
■ Prevent Installation Of Devices Using Drivers That Match These Device Setup Classes
This policy setting enables you to specify a list of Plug and Play device setup class GUIDs
that define devices users cannot install. If you enable this policy setting, users cannot
install or update drivers for a device that belongs to any of the listed device setup classes.
If your plan disables or does not configure this policy setting, users can install and
update drivers for devices as permitted by other policy settings for device installation.
This policy setting takes precedence over any other policy settings that allow users to
install a device and prevents users from installing a device with a GUID on the list even
if its ID matches another policy setting that would allow installation.
■ Allow Installation Of Devices That Match Any Of These Device IDs If you enable this policy
setting, you can specify a list of Plug and Play hardware IDs and compatible IDs that
describe devices users can install. Plan to use this setting only when the Prevent Installation
Of Devices Not Described By Other Policy Settings policy setting is enabled and
does not take precedence over any policy setting that would prevent users from installing
a device. If you enable this policy setting, users can install and update any device
with a hardware ID or compatible ID that matches an ID in this list if that installation has
not been specifically prevented by the Prevent Installation Of Devices That Match These
Device IDs policy setting, the Prevent Installation Of Devices Using Drivers That Match
These Device Setup Classes policy setting, or the Prevent Installation Of Removable
Devices policy setting. If another policy setting prevents users from installing a device,
users cannot install it even if the device is also described by a value in this policy setting.
If your plan involves disabling or not configuring this policy setting and no other policy
describes the device, the Prevent Installation Of Devices Not Described By Other Policy
Settings policy setting determines whether users can install the device.
■ Allow Installation Of Devices Using Drivers That Match These Device Setup Classes If
you enable this policy setting, you can specify a list of device setup class GUIDs that
describe devices users can install. Plan to use this setting only when the Prevent Installation
Of Devices Not Described By Other Policy Settings policy setting is enabled and
does not take precedence over any policy setting that would prevent users from installing
a device. If you enable this setting, users can install and update any device with a
device setup class that matches one of the device setup class GUIDs in this list unless
Lesson 2: Designing Enterprise-Level Group Policy Strategy 209
that installation has not been specifically prevented by the Prevent Installation Of
Devices That Match Any Of These Device IDs policy setting, the Prevent Installation Of
Devices Using Drivers For These Device Setup Classes policy setting, or the Prevent
Installation Of Removable Devices policy setting. If another policy setting prevents users
from installing a device, users cannot install it even if the device is also described by a
value in this policy setting. If your plan involves disabling or not configuring this policy
setting and no other policy setting describes the device, the Prevent Installation Of
Devices Not Described By Other Policy Settings policy setting determines whether users
can install the device.
NOTE Planning device installation
The way the device installation computer policies interact with each other is fairly intuitive and not
as complex as it seems when described on paper. If you are formulating plans in this area, practice
using these policies until you are familiar with what they do and how they interact. This is a suggested
practice later in this chapter and is one of the few instances when an enterprise administrator
should carry out configuration rather than delegate it.
Figure 4-18 shows the Device Installation Restriction policies in Group Policy Management
Editor. Figure 4-19 shows one of the simplest and most used sets of policy settings that prevents
standard users from installing devices but permits administrators to do so.
Figure 4-18 Device Installation Restriction policies
210 Chapter 4 Designing Active Directory Administration and Group Policy Strategy
Figure 4-19 Standard users cannot install devices, but administrators can
Obtaining Hardware IDs, Compatible IDs, and GUIDs
You can allow or prevent the installation of specific devices by enabling the appropriate Group
Policy setting and adding a list of hardware IDs, compatible IDs, or both. You can also specify
device setup class GUIDs that describe devices users can install.
Hardware IDs Hardware IDs provide the most exact match between a device and a driver
package. The first string in the list of hardware IDs is referred to as the device ID because it
matches the exact make, model, and version of the device. The other hardware IDs in the list
match the details of the device less exactly. For example, a hardware ID might identify the
make and model of the device but not the specific version. This scheme allows Windows to
use a driver for a different version of the device if the driver for the correct revision is not available.
Figure 4-20 shows the list of hardware IDs for a USB flash memory device. You can access
this from the device’s Properties dialog box in Device Manager.
Lesson 2: Designing Enterprise-Level Group Policy Strategy 211
Figure 4-20 Hardware IDs
Compatible IDs Windows Server 2008 uses compatible IDs to select a device driver if the
operating system cannot find a match with the device ID or any of the other hardware IDs.
Compatible IDs are listed in the order of decreasing suitability. These strings are optional and,
when provided, they are generic, such as Disk. When a match is made using a compatible ID,
you can typically use only the most basic functions of the device. Figure 4-21 shows the list of
hardware IDs for a USB flash memory device.
212 Chapter 4 Designing Active Directory Administration and Group Policy Strategy
Figure 4-21 Compatible IDs
GUIDs A GUID defines a device setup class, which the device manufacturer assigns to a
device in the device driver package. The device setup class groups devices that are installed
and configured in the same way. For example, all CD drives belong to the CDROM device
setup class and use the same co-installer. When Windows Server 2008 starts, it builds a tree
structure in memory with the GUIDs for all the detected devices.
In addition to the GUID for the device setup class of the device itself, Windows Server 2008
might need to insert the GUID for the device setup class of the bus to which the device is
attached (for example, USB). When you use device setup classes to control users’ installation
of device drivers, you must specify the GUIDs for all the device’s device setup classes, or you
might not achieve the results you want. In addition, GUIDs are held in the HKLM\CurrentControlSet\
Control\Class\ClassGUID registry key and are not as easily obtained as hardware IDs.
For these reasons, hardware IDs rather than GUIDs are typically used to specify the devices
than can or cannot be installed. Figure 4-22 shows a hardware ID list specified for the Allow
Installation Of Devices That Match Any Of These Device IDs setting.
Lesson 2: Designing Enterprise-Level Group Policy Strategy 213
Figure 4-22 Specifying hardware IDs
Exam Tip The most likely scenario to appear in the 70-647 examination is one in which users
cannot install devices but administrators can. The settings for this scenario are shown in Figure 4-19.
The next most likely scenario is that users can install only allowed devices although administrators
can install any device. This requires the settings shown in Figure 4-19 plus enabling the Allow
Installation Of Devices That Match Any Of These Device IDs setting and adding hardware IDs as
shown in Figure 4-22.