Combining GPO Policies
To modify the
security configuration for a group of servers performing a particular
role, without altering your baseline configuration, you can create a
separate GPO for a server role and, after these computers receive the
GPO containing the baseline configuration, you can apply the
role-specific GPO to them. The settings in the role-specific GPO
override those in the baseline. You can use the role-specific GPO to do
any of the following:
Modify settings you configured in the baseline
Configure settings that are not defined in the baseline
Leave the baseline settings for specific parameters unchanged
Because a GPO
assigned to an Active Directory container affects all the objects in
that container, you must create separate organizational units for the
servers running the Windows operating system on your network that are
performing different roles. You can deploy your server GPOs in two ways:
by creating role-specific organizational units anywhere in the Active
Directory tree and assigning multiple GPOs to each organizational unit,
or by creating a hierarchy of organizational units and letting group
policy inheritance do some of the work for you.
Applying Multiple GPOs
When you create a
GPO, you must associate it with a specific Active Directory domain,
site, or organizational unit object. However, once you have created the
GPO, you can link it to as many other objects as you want. Therefore, if
servers running Windows Server 2003 on your network are performing
different roles, you can create separate organizational units for them
at the same level, as shown in Figure 1.
In
the figure, you see the Domain Controllers organizational unit that the
Windows Server 2003 creates by default when you create the domain, as
well as new organizational units for member servers (named Members),
infrastructure servers (named InfSvrs), file and print servers (named
FilePrint), and application servers (named Web). To create a separate
security configuration for each server role, you would use a procedure
like the following:
1. | Create a new GPO for the Members container and use it to create your baseline security configuration.
|
2. | Create a new GPO in each of the role-specific containers and use it to create a role-specific security configuration.
|
3. | Link
the Members GPO to each of the role-specific containers and move it to
the bottom of the Group Policy Object Links list in the Group Policy tab
in the Domain Controllers Properties dialog box.
|
Important
When
you link a GPO to multiple container objects, you are only creating
links between the object pairs; you are not creating copies of the GPO.
Therefore, when you modify the policy settings for the GPO from one of
the linked containers, the changes you make affect all the containers to
which you have linked the GPO. |
The order in which the
GPOs appear in the Group Policy Object Links list is critical. GPOs that
are higher in the list have higher priority, so that a setting in the
first policy listed will overwrite a setting in the second. If you list
the GPOs in the wrong order, a different set of policy values than you
had planned might be in effect.
Tip
Although
Active Directory objects inherit group policy settings from their
parent objects by default, it is possible to block the inheritance.
Display the Properties dialog box for an object, click the Group Policy
tab, and then select the Block Policy Inheritance check box to prevent
that object from inheriting group policy settings from its parent
objects. |
Creating a Container Hierarchy
Instead of manually
linking your GPOs to the various organizational unit objects in your
Active Directory tree, you can also create a hierarchy of organizational
unit objects, as shown in Figure 2. In this figure, you see the Members organizational unit, with the role-specific organizational units beneath it.
As with most tree
hierarchies in Windows operating systems, the properties of a parent
object are passed down to the child objects beneath it. Therefore, when
you create a GPO and link it to the Members container, not only the
computer objects in Members receive the policy settings from the GPO;
all the computers in the role-specific organizational units receive
these settings.
Note
The
one exception to the rule of group policy inheritance is that
subdomains do not inherit group policy settings from their parent
domains. |
Tip
If
you plan to create a hierarchy of organizational units that includes
domain controllers in one of the role-specific containers, you will not
be able to move the Domain Controllers organizational unit object that
Windows Server 2003 creates automatically at domain creation to another
location in the tree. However, you can create a new organizational unit
object in the hierarchy and move the computer objects there from the
Domain Controllers container. |
To
create security configurations for the servers in the role-specific
organizational units, you create a new GPO for each container. When you
do this, the policy settings in the GPOs linked to the role-specific
containers take precedence over the settings for the same policies in
the parent container’s GPO. The rules governing the combination of
inherited and direct policy settings are as follows:
If the parent
container’s GPO contains a policy setting, and the same policy is
undefined in the child container’s GPO, the objects in the child
container use the setting from the parent GPO.
If
the child container’s GPO contains a policy setting, and the same
policy is undefined in the parent container’s GPO, the objects in the
child container use the setting from the child GPO.
If
the parent container’s GPO contains a policy setting, and the same
policy has a different setting in the child container’s GPO, the objects
in the child container use the setting from the child GPO.
When
you apply multiple GPOs to a container, whether with multiple links or
with a hierarchical GPO arrangement, it is important to understand the
difference between an undefined policy and an explicit policy setting.
An undefined policy is not necessarily the same as a Disabled setting.
When you leave a policy undefined in the GPO, the computers to which
that GPO applies use the operating system’s default setting, which might
be Enabled, Disabled, or something else, depending on the policy. If
you define a policy with an Enabled value in the parent container’s GPO,
you must explicitly define the same policy in the child container’s GPO
to assign it a different value, even if that value is the same as the
Windows Server 2003 default setting. |
