2. Working with central policies
In addition to local Group Policy Objects,
networks that run Active Directory have centralized GPOs. Compared to
local GPOs, centralized GPOs are management GPOs because you can modify
them in a central location and have them affect any group of objects. By
default, every AD network includes two default policies:
A specific default domain policy is applied to
every domain in a network. The same applies for the default DC policy,
except that instead of being applied at the domain level, this policy is
applied specifically to domain controllers. Although these two GPOs
have little impact on PCs, they do provide central control elements that
affect all users.
The Default Domain Policy is often called the
Account Policy because it provides central control of account settings
in the network. If your servers are running Windows Server 2003, then
you will have only a single account policy. If your servers are running
Windows Server 2008, then you can have multiple account policies, all
contained within the same GPO. Most organizations use a single account
policy and apply it to all users. In some rare cases, organizations use
multiple account policies to provide more secure login restrictions for
key groups of users, for example, the Administrators group. This lets
them use a more open policy for normal users and a more restrictive one
for administrative staff. Your base account policy should include the
settings listed in Table 9.1
for both the Account Policies and Local Policies sections. Passwords
are an important aspect of any security policy and should be enforced in
every organization.
Working with PC-related Group Policy Objects
PC-related GPOs do not exist by default; they
must be created and customized. As mentioned earlier, a GPO can manage
thousands of settings on computers; in fact, in Vista, GPOs include
2,450 settings by default. These settings are divided into different
categories as shown in Table 2.
Table 2. Group Policy Object Contents
| Managed Object | Description |
|---|
| Computer and User Settings | Vista
includes options that can control both computer (HKEY_LOCAL_MACHINE or
HKLM) or user (HKEY_CURRENT_USER or HKCU) registry settings. |
| Scripts | Vista
machines can run startup, shutdown, logon, or logoff scripts. Scripts
are assigned through GPOs. Startup and shutdown scripts apply to PCs
while logon and logoff scripts apply to users. |
| Folder Redirection | Vista
machines can automatically protect user data through the use of folder
redirection — the automatic move of local folders to remote servers. In
addition, redirected data is available to users from any PC in the
network. Finally, redirected data is automatically cached locally
through offline folder settings so that users can work on the data even
if the network connection is lost. In the event of a connection failure,
data is re-synchronized as soon as the connection returns. |
| Software Delivery | Software
installations that are packaged in Windows Installer format can
automatically be assigned to either PCs or users through Group Policy
Objects. |
| Security Features | All of Vista's security features can be controlled centrally through GPOs. |
GPOs are divided into two major sections. The
first includes computer settings and is designed to apply to a PC no
matter who logs on or what their user rights are. The second is focused
on user settings and is designed to apply to specific users no matter
which computer they log on to. Both sections include many of the same
settings, but because of their very nature, both also include settings
that are not available in the other.
A good practice is to create GPOs for either
users or computers and configure them as single-purpose GPOs; that is,
as GPOs that are designed to affect only one single type of object. This
makes it easier to control and otherwise manage GPOs. Another good
practice is to create as few GPOs as possible. The more GPOs you create,
the more confusing your system management practices will become.
Group Policy application concepts
Group Policy settings are applied in a specific
order. Computer settings are applied first because these settings are
applied when the computer starts up. User settings are applied second as
users log onto the system. Computers have their own machine account
that must be authenticated in the Active Directory domain when they boot
up. During this authentication process the Group Policy is applied.
When multiple GPOs are applied to the same
object, for example, if multiple GPOs are applied to a PC, they are
applied in order of precedence, as shown in Figure 5.
The local GPO or LSP is applied at computer startup.
If available, GPOs that are assigned to a site are applied next.
Domain GPOs are applied after site GPOs.
Organizational unit GPOs are applied last.
If
the object (either computer or user) is located within a child OU and
the child OU contains an additional GPO, this GPO is applied last.
This process is often called the L-S-D-OU
process for the Local-Site-Domain-OU application order. If conflicts
arise between policies, the settings in the last policy override all of
the others. For example, if you deny access to an item in the Start menu
in the domain policy, but it is allowed in an OU policy, the resultant
policy will allow access to the menu.
For this reason, understanding some basic Active
Directory concepts before you can proceed with GPO assignment and
management is important. AD structures are designed to control how
objects are managed in a network. These structures include several basic
components:
Active Directory Forest: The base structure of a directory that contains all of the objects in the network.
AD Domain:
A container and an account policy boundary. A domain can contain
several different object types: printers, user accounts, machine
accounts, groups, shared folders, and much more. A forest can contain
several domains. Organizations usually create a single production domain
which is designed to contain all of their computer and user accounts.
Each domain's objects are managed by domain controllers.
Site:
A local network that contains domain controllers but that is separated
from the rest of the network by a wide area network (WAN) connection.
Organizational Unit (OU):
A container that is located within a domain. OUs are designed to help
regroup objects for better management. Domains can contain millions of
objects; therefore, using OUs to properly categorize these objects is
important. OUs have four purposes:
To categorize objects; that is, to regroups objects of one particular type, for example computers
To manage objects by applying GPOs to them
To
delegate object management, for example, taking all of the computers in
an OU and assigning their management to a specific group of PC
technicians
To hide objects by placing them in an OU and controlling its access rights
As mentioned before, there is at least one GPO
that is assigned to each domain: the Default Domain Policy. Site GPOs
are fairly rare because they apply to groups of objects within a
specific remote office and not to others. Instead of using sites, many
organizations will choose to apply a GPO for remote office management to
a container that will include every remote office. This is why most
organizations apply GPOs to Organizational Units because these can span
multiple sites.
As you can see, the structure of your AD domain has such an impact on your PC management strategy.
NOTE
In Windows Server 2008, Active Directory is
called Active Directory Domain Services (ADDS) because WS08 includes
several different technologies which are all labeled with the Active
Directory name. Along with Active Directory Domain Services, these
include Active Directory Certificate Services, Active Directory
Lightweight Directory Services, Active Directory Rights Management
Services, and Active Directory Federation Services. However, because the
previous two versions of Windows Server, 2000 and 2003, referred to
Active Directory as Active Directory alone, most people still refer to
ADDS as Active Directory.
Controlling GPO inheritance
In addition to the application order, you can
control how GPOs will be inherited from one location to another.
Remember that by default, GPOs are assigned through the LSDOU rule.
However, if you assign a GPO at the domain level and you want to make
sure that its settings are not overridden by GPOs that are assigned
after it (GPOs that are assigned to an OU, for example), you can force
the application of your settings. You do this by forcing GPO
inheritance.
When GPOs are inherited through the LSDOU
inheritance order, they automatically override each other if they
contain conflicting settings. If settings are applied in a domain GPO,
but are removed in an OU GPO, then the OU GPO contains the setting that
will be applied. If a setting is applied in a parent OU and then removed
in a child OU, then the setting in the child OU will be applied. But,
in certain situations, you want to make sure that global policies are
not overridden by more focused policies. To do this, you can assign the
Enforced attribute to the GPO. Using the Enforced attribute ensures that
the GPO will not be overridden by any other.
Conversely, you might want to ensure that
certain more focused GPOs are not overridden by global GPOs. You can
also do this by assigning a Block Inheritance attribute, but this time,
not to the GPO itself, but rather to the Organizational Unit itself.
As you can see, you could assign the Enforced
attribute to a GPO while someone else assigns the Block Inheritance
attribute to his or her OU. Enforcing and Blocking at the same time
could lead to quite a bit of confusion in the overall settings that
would be applied, but fear not: Enforced always wins. Despite the fact
that Enforced always wins, you should use the Enforced and Block
Inheritance attributes sparingly and make sure your overall GPO strategy
is coherent and does not require either setting.
Controlling GPO updates
By default, Group Policy Objects are updated on a
regular schedule on all systems, PCs and servers. Domain controllers
are updated every 5 minutes because they provide an essential service.
PCs and member servers are updated at 90-minute intervals. If the
contents of a policy have not changed since the last time it was
applied, it is not applied again.
Each Group Policy Object includes a file named
GPT.INI. This file contains the version number for the GPO. Each time a
change is applied to the GPO, this version number is incremented. When
the GPO refresh is applied, the system reads the GPT.INI to see if the
version number has changed. If it hasn't changed, then there are no
updates to the system. If it has, then the system reads the policy and
applies any changes.
You can modify the default behavior, once again, through GPO settings.
You can also force the reapplication of GPOs to any system. Do this by using a command line tool:
gpupdate /force
Using this command on any system updates both
computer and user GPOs and reapplies all settings even if the version
number has not changed.
Structuring GPO application for PCs
Group policy is a very powerful management tool that can be applied to four different object categories:
Domain controllers
PCs
Member servers
User accounts
In terms of Vista, you should be concerned about
the application of GPO settings to PCs and user accounts. Domain
controllers and member servers are under the purview of other
administrators in the network. These won't change until your servers are
upgraded to Windows Server 2008. At that point, they will benefit from
the many features Microsoft has enhanced in Vista. Until then, the only
items that can profit from Vista's new GPO settings will be PCs running
Vista and the users who have access to them.
NOTE
Group Policy is an excellent vehicle for
system administration, but it is possible to overdo it. Begin your Vista
GPO strategy by inventorying the GPOs you have in place and then look
them over to see if there is room for rationalization. Because Vista
brings so many new settings, you don't want to find yourself in a
situation where you are proliferating GPOs.
PCs should be further segregated into different
categories. Because GPOs are inherited and are mostly applied to
organizational units, you should create a hierarchical OU structure that
will refine settings as your categories are developed. For example, you
should create a main GPO that will affect all PCs whether they are
workstations or mobile computers. Then, you should create sub-GPOs that
would refine settings based on whether a system is a desktop or a mobile
PC. For example, desktops will rarely rely on wireless networks whereas
mobile systems will often do so. Desktops will rely on wired
communications and may not require communication encryption whereas
mobile systems will.For this strategy to work, you need to create a corresponding OU structure as seen in Figure 6.
This structure includes a main OU that will include two sub-OUs. The
main OU is named PCs and includes a targeted GPO that contains settings
for all PCs. Sub-OUs include desktops and mobile systems. Each sub-OU
contains a corresponding GPO to further refine settings. Note that the
Desktops GPO is optional since you may not need to further refine
settings beyond those applied to all PCs. It is still important to
create this OU though in order to categorize desktop systems and
separate them from mobile systems.
A third sub-OU can be used when you have Kiosk
PCs or PCs that are exposed to the public and require advanced security
settings. These PCs will rely on GPO Loopback settings. Loopback
settings always ensure that computer settings are applied no matter who
logs on. This is performed in one of two ways. Merged settings will
append computer settings once user settings are applied. Replaced
settings will completely replace user settings with computer settings.
Policy loopback is controlled in the Computer Configuration under
Administrative Templates => System => Group Policy.
NOTE
By default, computer accounts created in
Active Directory are stored in the Computers container. Similarly, user
accounts are stored in the Users container. Both of these containers are
special containers that do not behave as OUs and therefore cannot be
the target of Group Policy Objects. Because of this, you must create new
OUs that will contain PC and user accounts. To make sure that you do
not confuse these new OUs with the default containers, call them PCs and
People. Then, after these OUs are created, move the PC and user
accounts to the appropriate levels in the OU structure to begin their
management through GPOs.
In some cases, organizations decide to group PCs
on a regional basis because doing this lets them delegate PC
administration to regional technicians. In this case, you still need to
create the PCs, Desktop and PCs, and Mobile OU structures to
differentiate between desktops and mobile systems.
Structuring GPO application for users
Designing policy application for users is a bit
more complicated because user GPOs can become quite granular if you're
not careful. We recommended that you keep user GPOs to a minimum. In
fact, you can often have one single user-oriented GPO and have it apply
to all users through the People top-level OU.
You can refine the structure of the People OU by
including sub-OUs, but unless you have the need to provide separate
management settings for different types of users, there should be no
need for other user-oriented GPOs as shown Figure 7.
Follow the keep it simple, stupid (KISS) rule
and keep it as simple as possible. Doing this makes it much easier to
manage GPO content and will make GPO troubleshooting much more
straightforward when required.
