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 use

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

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

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

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

In addition to the Group Policy Template, a GPO is composed of a Group Policy

Container (GPC) The GPC, in contrast to the Group Policy Template, represents the part

of the GPO that resides in Active Directory itself Thus, the GPC is a set of Active

Directory Objects that are generated when you first create a GPO To view the GPC structure within Active Directory, proceed as follows:

1 Start the Active Directory Users and Computers MMC snap-in, and select the

Advanced Features command from the View menu

2 Expand the console tree, drill down to your Active Directory domain, and it locate the folder named System within The System folder contains a subfolder named Policies, within which you will find GUID-based folders corresponding to Group Policy Objects existing within your domain (Fig 11.8)

Figure 11.8: Viewing Group Policy Containers using the Active Directory Users and Computers MMC snap-in

Windows Server 2003 Improvements to Group Policies

As might be expected, computer-specific nodes and their settings are applied to computer objects only when the computer processes the GPO — usually at system startup and periodically thereafter (These can be configured via Group Policy.) However, user

objects process user-specific settings only at time of user logon These settings also can

be updated manually in intervals configured via Group Policy Hence, a user could log on

to a particular computer processing different GPOs — if the computer account is in one

OU and the user is in another

Note You also can trigger computer and user policy manually In Windows 2000, this could be done by using the secedit.exe command with the /refreshpolicy option However, note that secedit.exe does not trigger any software installation policy you may have defined In Windows XP and Windows Server 2003, use the gpupdate command to refresh Group Policy This command replaces the Windows 2000

secedit /refreshpolicy command If you choose not to use the gpupdate command, Group Policy will still refresh; it will just take longer