Tài liệu Group Policy Objects phần 1 pptx

Group Policy Objects
Starting with Windows NT 4.0, Microsoft introduced System Policy, a mechanism for
using the registry to "lock down" specific portions of user desktops to prevent users from
tweaking the configuration. System Policy was a significant step forward in centralized
administration. However, it didn't completely address most enterprise issues related to
reducing the Total Cost of Ownership (TCO), such as:

Software distribution

Configuration management

Security management
Because of this, Microsoft continued its research and developed Group Policy Objects
(GPOs), which, starting with Windows 2000, have replaced System Policy.

Note Group Policy is implemented only on Windows 2000 and later. Windows NT 4.0
doesn't support the storage or processing GPOs. However, Windows 2000 and its
successors can process the old-style Windows NT 4.0 System Policies (such as
Ntconfig.pol) when a user logs on to a Windows NT 4.0 domain from a computer
running Windows 2000, Windows XP, or Windows Server 2003.
A local GPO exists on every workstation or server running Windows 2000, Windows XP,
or Windows Server 2003. By default, a local GPO is stored in the folder
%SystemRoot%\System32\GroupPolicy. The local GPO is a standalone object; you must
manage it on each computer running Windows 2000 or later using the MMC Group
Policy snap-in. Except for its prominence on individual computers, Group Policy shows
its power in the AD infrastructure. For example, some of the GPO capabilities available
in an AD-based domain environment (centralized software deployment, folder
redirection, etc.) are not available on local GPOs. For GPOs to fulfill their real promise, it
is necessary to deploy Active Directory and start migrating all workstations and servers
to Windows 2000 or later.
One of the key features in Microsoft's Change and Configuration Management (CCM)

strategy is the ability to use AD as a kind of application repository. For example, in AD
infrastructure you can "advertise" applications such as Word, Excel, or Visio as AD
objects. These can be distributed to and installed by end users, depending upon where the
objects related to the users or their computers reside in the directory. The name of the
feature you use for this advertisement function is Software Installation.
Specifically, Software Installation is defined within a Group Policy Object (GPO). GPOs
are AD objects that can be applied to a local machine, site, domain, or organizational unit
(OU). Similarly to Group Policy in Windows 2000, Group Policies in Windows Server
2003 can be applied to "containers": entire sites, domains, or OUs. A GPO is linked to a
container and applied only to the computers or users whose accounts exist within it. It is
rarely efficient or practical to implement site policies, so most policies will be
implemented at the domain or OU level. In addition to domain policies, a local Group
Policy is configured and can be adjusted on individual workstations or servers.

Note The acronym LSDOU (Local, Site, Domain, OU) is used to describe the cumulative
order in which GPOs are applied to users and machines. Each policy is applied
during boot or logon. The local policy is applied first, then the domain policy, then
the OU policy. Even within these containers, GPO application is cumulative. For
example, if we have three OUs — OU1, OU2, and OU3 — the policies linked to
OU1 are applied to the users and computers listed in OU2. Policies in OU1 and
OU2 are applied to OU3. If a setting is not configured in a previous GPO, the new
GPO's setting will be applied. If the new GPO and the old GPO have a conflicting
setting, the conflict is resolved by applying the new GPO's setting. But if this
setting is not configured, the previous one will remain.
It is important to understand the affect GPOs have on the system registry and how they
interrelate and interact with it. GPOs are multifunction AD objects, which comprise
multiple "nodes" (Fig. 11.4
). Each node within a GPO provides a different kind of control
over computers (Computer Configuration node) or users (User Configuration node).

Figure 11.4: GPOs are multifunction AD objects composed of multiple "nodes", each
providing a different control over computers or users.
Table 11.1
summarizes the most common per-computer and per-user nodes available in
GPOs.

Table 11.1: Available Functionality Nodes in Group Policy Objects
Computer or user: Node
name
Description
Computer: Software Settings:
Software Installation
Computer-based deployment of applications
Computer: Windows Settings:
Security Settings
Computer-based configuration of security (includes
items such as account policy, audit policy, and event log
configurations)
Computer: Windows Settings:
Scripts-Starup & Shutdown
Specification of computer startup and shut down scripts
Computer: Administrative
Templates
Windows NT 1.0-style System Policy: which enforces
changes to the KHLM registry key
User: Software Setting:
Software Installation
User-based deployment of applications
User: Internet Explorer
Maintenance

Used to set Internet Explorer preferences and "branding"
settings per user
User: Windows Settings:
Security Settings
Configuratin of user-specific IP Security and public-key
usage policies
User: Windows Settings:
Scripts-Logon and Logoff
Specification of user-specific logon and logoff scripts
User: Remote Installation
Services
Configuration options for people using Remote Install
Service to install Windows 2000/XP or Windows Server
2003
User: Administrative
Templates
Windows NT 4.0-style System Policy, which enforces
changes to the HKCU registry key

Concerning our discussion of AD and Group Policy interrelationship with the registry,
the most interesting nodes to us are Software Installation and Administrative
Templates.

Note GPOs are applied to user objects and computer objects only. They are not applied to
security groups. However, the effect of a GPO can be filtered by security groups.
That is, you can have a GPO assigned to a particular OU (all of its users and
computers) but restrict how that GPO is applied based on the particular security
group to which those users or computers belong.
One more thing to note about GPOs is their physical makeup. As outlined in Chapter 10
,

GPOs are composed of two physical "pieces": the Group Policy Template (GPT) and the
Group Policy Container (GPC). The first piece, the GPT, is composed of a set of files and
folders that are replicated to all domain controllers in an AD domain. By default, GPOs
are replicated as part of the SYSVOL share, which is created automatically on all
Windows 2000 and Windows Server 2003 domain controllers. Files contained in the
SYSVOL share are automatically replicated on the same schedule as the Active Directory
replication. The NT File Replication Service (NTFRS) is responsible for replicating
SYSVOL. The SYSVOL share resides in %SystemRoot%\sysvol\sysvol for a given
domain controller. The source files for SYSVOL, however, are kept in the
%SystemRoot%\sysvol\domain folder. If you expand this folder, you see a Policies
subfolder. In this Policies subfolder, you see several folders with names that look like
GUIDs (Globally Unique Identifiers) which they are — for the corresponding GPOs in
the directory. To view a GPO's GUID using the Group Policy MMC snap-in, right-click
the required GPO name and select the Properties command from the context menu. The
GUID is listed as the "Unique name" for that GPO on the General tab or the GPO
properties window (Fig. 11.5
).

Figure 11.5: The GUID is listed as the "Unique name" for a specific GPO on the General
tab or the GPO properties window.
There are a couple of ways to bring up the Group Policy tool, but perhaps the easiest is to
load the Active Directory Users and Computers MMC snap-in. Right-click on a Domain
or OU name and select Properties from the context menu. You'll see a Group Policy tab
(Fig. 11.6
), which lists all available GPOs at that level and lets you edit them. You can
also load the Group Policy tool by typing gpedit.msc from a command line. However,
when you launch the tool this way, it is automatically focused on the local GPO for that
computer, rather than a domain, OU, or site-based GPO.

Figure 11.6: The Group Policy tab of the GPO properties window

The example illustrating a directory structure for one of the GPOs in the SYSVOL folder
(Fig. 11.7
) shows that a typical GPO contains a lot of nested directories. Files in each of
these nested directories are replicated to each domain controller within a given domain.
For the purposes of this chapter, we'll explore only those pieces of GPO that directly
relate to registry, namely, the following subdirectories and their contents:

\Adm

\Machine\Applications\*.*

\User\Applications\*.*

Figure 11.7: The example directory structure for one of the GPOs stored in the SYSVOL
folder