Applying GPOs to a
Computer and User in an AD Environment
GPOs are applied to a
computer and user in an AD environment as follows.
The computer is turned on. All
the Local settings are read from the files on the local hard drive that
make up the Registry and the Local Computer Policy (LCP) and are placed
in RAM. Again, think of this RAM copy of the Registry as the live,
awake brain for this session on the computer. This is the “L” part of
the computer boot-up process.
Because the computer is a
member of Active Directory, it contacts a domain controller for its
domain and authenticates its computer account with AD. It then compares
its IP address to IP subnets configured in AD sites to identify which
site the computer is currently in. The computer then downloads and reads
all GPOs for the site that it is currently in and applies only the
computer half of those GPOs to the RAM copy of the Registry on the
computer. (At this point in the bootup process, it cannot apply the user
portion because there is no way to know what user will eventually be
logging on.) If any Site level settings conflict with any Local
settings, the Site level settings override the Local settings. This is
the “S” part of the computer bootup process.
The computer then
downloads and reads all GPOs for the domain that it is a member of and
applies only the computer half of those GPOs to the RAM copy of the
Registry on the computer. By default, if any Domain level settings
conflict with any Local or Site level settings, the Domain level
settings override the Local and Site level settings. This is the “D”
part of the computer bootup process.
The computer then downloads
and reads all GPOs for the top-level OU that its computer object resides
in and applies only the computer half of those GPOs to the RAM copy of
the Registry on the computer. By default, if any OU level settings
conflict with any Local, Site, or Domain level settings, the OU level
settings override the Local, Site, and Domain level settings. This is
the “OU” part of the computer bootup process.
The computer repeats this
process for each level OU that it may reside within. If the computer
object for the computer resides in the top-level OU, these are the only
OU GPOs to be processed. If the computer object for the computer resides
in the third-level OU, the top-level OU GPOs are processed, then the
second-level OU GPOs are processed, and finally the third-level OU GPOs
are processed. By default, the last GPO that gets applied overrides all
conflicts with previously applied GPOs.
Again, these GPO policies get
applied to the computer over the top of the Local Computer Policy
settings to provide enterprise (AD) administrative dominance over the
local configuration settings.
When all appropriate OU GPOs
are processed, the Windows GINA dialog box is presented, and finally you
are allowed to attempt to log on.
You are prompted to press and
hold the Ctrl+Alt
keys and then press the Del key to initialize the logon process, as shown
in Figure 3. You then provide your identity information, your
username and password, and click Enter.
When your identity
information is accepted as valid by a domain controller, you are
authenticated, and the L-S-D-OU-OU process begins all over again. Only
this time it uses your user profile (L) and the user half of the S, D,
and OU GPOs, as follows.
The user profile settings are
read from the files on the local hard drive and are placed in RAM. This
is the “L” part of the user logon process.
The computer again compares its
IP address to IP subnets configured in AD sites to identify which site
the computer is currently in. The computer then downloads and reads all
GPOs for the site that it is currently in and applies only the user half
of those GPOs to the RAM copy of the Registry on the computer. If any
Site level settings conflict with any Local settings, the Site level
settings override the Local settings. This is the “S” part of the user
logon process.
The user object can be located
in a different OU and even a different domain than the computer object,
but because you are logging on to the computer, you must be in the same
physical location as the computer and are subject to the computer’s
Site level GPOs.
The computer then contacts a
domain controller for the domain that you are a member of and downloads
and reads all GPOs for your domain. The computer applies only the user
half of those GPOs to the RAM copy of the Registry on the computer. By
default, if any Domain level settings conflict with any Local or Site
level settings, the Domain level settings override the Local and Site
level settings. This is the “D” part of the user logon process.
The computer then
downloads and reads all GPOs for the top-level OU that the user account
object resides in and applies only the user half of those GPOs to the
RAM copy of the Registry on the computer. By default, if any OU level
settings conflict with any Local, Site, or Domain level settings, the OU
level settings override the Local, Site, and Domain level settings.
This is the “OU” part of the user logon process.
The computer repeats this
process for each level OU that the user account object may reside
within. If the user account object resides in the top-level OU, these
are the only OU GPOs to be processed. If the user account object for the
computer resides in the third-level OU, then the top-level OU GPOs are
processed, followed by the second-level OU GPOs, and finally the
third-level OU GPOs are processed. By default, the last GPO that gets
applied overrides all conflicts with previously applied GPOs.
Once again, these policies
get applied to the RAM copy of the Registry on the computer over the top
of the User Profile settings to provide enterprise (AD) administrative
dominance over the local configuration settings.
Now you (finally) get your desktop and can begin
working.
And If That Isn’t
Enough: Enforced, Block Inheritance, and Slow Link Detection
With all the different
GPOs that can be applied to a computer and user, some settings in the
different GPOs are bound to conflict. Suppose at the site level, a GPO
sets the desktop wallpaper for all computers in the site to the company
logo wallpaper. And then some domain administrator sets a GPO at the
domain level so that the desktop wallpaper for all domain computers is a
picture of the domain’s softball team. By default, if any settings in
the numerous GPOs conflict, the last GPO that gets applied wins the
conflict.
This sounds like the lowliest
administrator in charge of two or three computers and a few users in an
OU can overrule the highest level enterprise administrator in charge of
hundreds or thousands of computers and users. If left to the defaults,
this is true. However, there is a setting called Enforced on each
GPO. If this setting is enabled (it is not enabled by default), it locks every setting
that is configured in the GPO, and no GPO that follows can override
these locked settings. So with the Enforced setting enabled on GPOs, the
first Enforced GPO that gets applied wins all conflicts. This is a
top-down mechanism.
Another configurable setting
regarding GPO processing is a bottom-up mechanism. If an administrator
at a domain or some OU level does not want any previously applied,
non-Enforced GPOs to affect his computers and users, he can enable a
setting called Block
Inheritance on the domain or the OU. This
setting turns off processing of all GPOs from higher-level containers
that are not Enforced. Remember, though, that a GPO with the Enforced
setting enabled blows right past the Block Inheritance setting and is
still processed by all computers and users in all child containers, even
if the Block Inheritance setting is enabled.
One more parameter that
changes the way GPOs are processed has to do with the bandwidth
connecting the client computer to the domain controllers. Because some
GPOs trigger a large amount of network traffic—a software deployment and
folder redirection GPOs, for example—an evaluation of the bandwidth of
the link to AD is performed before processing any GPOs. This is referred
to as Slow Link Detection. If the link speed is below 500Kbps, the default data rate
for a slow link, software GPOs do not deploy software, and folder
redirection GPOs do not relocate folders. If a computer cannot identify
the bandwidth of the link to AD, it assumes that it is using a slow link
and may not process all appropriate GPOs, like the software deployment
GPOs.
Alert
In earlier versions of Windows, like Windows
XP, the client computer utilized the Internet Control Message Protocol
(ICMP) Echo Request, the same function used in the PING application, to
perform the slow link detection process. This became problematic when we
all began blocking ICMP Echo Requests on our firewalls, due to the
numerous Denial of Service attacks that used it. Client computers began
to fail to identify slow links, and therefore they would fail to process
all appropriate GPOs because the firewalls on the domain controllers
blocked their slow link detection mechanism, the ICMP Echo Request
packets.
Windows
Vista has solved this problem by using a different service to identify
slow links. Windows Vista uses a service called Network Location Awareness, instead of ICMP, to perform Slow Link
Detection so that all appropriate GPOs are processed by Windows Vista
computers.
To
ensure Windows XP computers process all appropriate GPOs, you might
need to allow ICMP Echo Request packets through your firewalls.
GPO Refresh, Loopback
GPO Processing, and Turning Off the “L”
A few settings within the GPO
also can affect the way this GPO processing happens. The first one is
called the GPO Refresh. GPOs are applied to the computer during its bootup and
then to the user during logon. They also get reapplied on a regular
interval to ensure that new GPOs take effect quickly.
By default, GPOs refresh on
member servers, member client computers, and domain users every 90
minutes, plus a random offset of 0 to 30 minutes (90 to 120 minutes).
GPOs refresh on domain controllers every 5 minutes and have no random
offset. These default refresh intervals can be adjusted within the GPO
to affect all future refresh intervals. You can make this adjustment
under User Configuration > Administrative Templates > System >
Group Policy for the user refresh, and under Computer Configuration >
Administrative Templates > System > Group Policy for domain
member servers, domain member client computers, and domain controllers,
as shown in Figure 4.
Alert
Remember
that you can manually refresh GPOs by running the gpupdate.exe
/force command on the target computer. The
/force
switch reapplies all applicable GPO settings.
Another
tool within a GPO that affects the way GPOs get processed is called Loopback, and it has two modes: Merge and
Replace.
Alert
You
typically use Loopback when the computer is located in a public area,
and you want to minimize or eliminate any User GPO settings that might
be applied to the computer session.
With Loopback Merge mode
enabled, after the GPO processing described earlier (L-S-D-OU-OU-OU for
the computer and then L-S-D-OU-OU-OU again for the user) completes,
Loopback Merge mode kicks in and reapplies the computer settings, just
in case any user settings conflict with any computer settings. Remember,
the last GPO that applies wins conflicts, by default. User GPOs apply
after computer GPOs by default. Loopback reapplies the computer settings
to win any conflicts with user settings.
With Loopback Replace mode
enabled, after the GPO processing described earlier completes, Loopback
Replace mode kicks in and reapplies the computer settings, just in case
any user settings conflict with any computer settings. Then Loopback
Replace mode throws away every user GPO setting that has been applied,
and it processes the user half of all GPOs (S-D-OU-OU-OU) that apply to
the computer’s position in AD, not the user’s position in AD. The
Loopback processing GPO is shown in Figure 5.
Another GPO setting that affects GPO processing
is used to turn off Local Group Policy objects processing. You can
access this setting under Computer Configuration\Administrative
Templates\System\Group Policy in the Group Policy Management Console
running on a Windows Vista computer, as shown in Figure 6.
Alert
Enabling the Turn Off Local Group Policy Objects
Processing GPO setting disables policy processing for the L part of
L-S-D-OU and processes only S-D-OU.
Note
New GPOs There are approximately 800 new GPO settings
exclusively for Windows Vista. You can access these new settings only by
running GPMC and the Group Policy Object Editor (GPOE) on a Windows
Vista computer. You cannot access these new Vista GPO settings from GPOE
running on a Windows Server 2003 computer.
To be able to use and save the
GPMC MMC on a Windows Vista computer, you must use a computer that is a
member of an AD domain, and you must be logged in with a domain user
account with sufficient privilege to create and edit GPOs.
You can access the Group
Policy Management Console (GPMC), as shown in Figure 7,
on a Windows Vista computer by building a new MMC.
Building the Group
Policy Management Console (GPMC) MMC
To build the Group Policy
Management Console (GPMC) MMC, follow these steps:
1. | Click Start > Run,
type MMC, and click OK. (You can use Start > Start Search > MMC > and
click Enter.)
|
2. | From the
menu, select File > Add / Remove Snap-in.
|
3. | Select Group Policy
Management snap-in and click Add.
|
4. | Click OK.
|
5. | From the menu, select File
> Save As.
|
6. | Type the name GPMC.msc
and save the MMC either on the desktop or in Administrative Tools.
|
To create a new GPO in the GPMC
tool, follow these steps:
1. | Expand
Forest, Domains, and your domain name.
|
2. | Right-click the folder Group
Policy Objects and select New.
|
3. | Give your new GPO a descriptive name so that you know
what is configured in the GPO.
|
To edit the new GPO,
right-click the new GPO in the Group
Policy Objects folder and select Edit. This opens the GPO in the Group Policy
Object Editor (GPOE).
To link a GPO to a site,
domain, or OU in the GPMC tool, follow these steps:
1. | Expand
the appropriate folder to be able to view the target container.
|
2. | Click the desired GPO and drag it to the target
container and release. This creates a link between the GPO and the
container.
|
Alert
The
exam focuses on processing order, blocking inheritance (enforced),
delegation, loopback processing modes, and so on.
Caution
Use
Care When Dealing with GPOs Two GPOs
are provided by default in every new domain. They are the Default Domain
Policy and the Default Domain Controllers Policy. These policies are
generally LEFT ALONE, with no new settings added. These policies have
many carefully conceived, preconfigured settings to control and secure
your domain and domain controllers (DCs).
You might make an
occasional adjustment to a preconfigured setting or two inside these
policies, but these changes should be carefully considered, planned,
formally approved by senior IT administration, and carefully
implemented. If you want to add GPO settings to the domain or to the
DCs, create new GPOs with your desired settings and link them in the
proper locations.
