1. 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 given situation.
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 1 shows multiple GPOs linked to a single OU.
The link precedence is shown in Figure 2. You can change the order of precedence by selecting a GPO link and moving it up or down.
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.
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. Multiple-forest 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.
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 of each 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.
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
Filtering GPOs
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 3
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.
