Security filtering permissions control which
computers and users can process a GPO; there are
also security permissions that control who can
edit that GPO. You can see those security permissions
by highlighting a GPO in GPMC and
selecting the Delegation tab, as in Figure 2.
The Delegation tab is a bit confusing
because it shows the security filtering permissions
from the previous Security Filtering
dialog box, as well as the permissions
to edit or modify the
GPO. In fact, you can grant
both kinds of access here:
granting permission to process
a GPO here (as well as
from Security Filtering) and
also controlling who can edit
a GPO. Furthermore, the
Advanced button that you see
at the bottom of the screen is
the only place in GPMC where
you can set Deny access to the
GPO. Remember that security
permissions can either
allow or deny access—and
both types of Access Control
Entries (ACEs) are valid for GPO permissions. However, by default, the
GPMC interface lets you set only allow permissions.
So, for example, if you need to deny Read
Group Policy and Apply Group Policy permissions
to a group of users or computers that you
want to exclude from processing a GPO, you’d
need to do that by clicking the Advanced button,
which brings up the familiar Access Control
List editor that you use to set permissions
on files or in AD.
The final type of filtering that you have
access to in Vista, Windows Server 2003, and
Windows XP is the Windows Management
Instrumentation (WMI) filter. WMI is a set
of instrumentation in Windows that you can
leverage to filter GPO processing. For example,
let’s say you want a GPO to apply only to XP
systems. Using GPMC, you can create a WMI
filter by right-clicking the WMI Filters node in
the tree pane and selecting New. A WMI filter
must take the form of a WMI query. (For more
information about WMI filters, see technet2.microsoft.com/WindowsServer/en/library/dfba1dc6-6848-4ed8-96da-f4241c1acfbd1033.mspx; for more information about WMI queries,
see “Sesame Script: WMI Query Language,”
www.microsoft.com/technet/scriptcenter/resources/begin/ss1206.mspx.)
You can link just one WMI filter to a given
GPO. If the query that’s specified in the filter
evaluates to True when the GPO is read, the
GPO is applied. The evaluation of a WMI query
takes place on the client computer that’s processing
the GPO. It interrogates its own local
WMI repository to see if the query evaluates
to true or false. If the query evaluates to False,
the GPO is denied to the user or computer.
Whether the WMI filter applies to a user or
a computer depends upon the query. For
example, if the query asks whether the computer
is running XP, that’s a computer-specific
question, and if the computer is running XP,
the GPO will apply whether the user is logged
on or not. However, if the query asks whether
“Joe Smith” is the currently logged on user on
the computer, the GPO will apply only when
Joe Smith is actually logged on.
Policies vs. Preferences
Perhaps the most popular area of Group Policy
is Administrative Templates, or registry policy.
This policy area lets you control many aspects
of your Windows systems. The best part of
registry policy is that it no longer “tattoos” or
gets stuck in, the registry when the policy no
longer applies, as it
did in NT 4.0 system
policy. What the end
of tattooing means
is this: Let’s say you
enable (or disable) a
registry policy item
in a GPO and apply
it to a user or computer,
then remove
that GPO or security
filter it away from
the user or computer.
During the
next foreground or
background processing
cycle, that
policy setting will
automatically be
removed, rather than being stuck in the registry
until you explicitly delete.
Behind the scenes, this removal process
works this way because Microsoft has specifically
set aside four special registry keys where
all policies are written, and they are removed
when they no longer apply. There are two keys
for computer registry policy:
HKEY_LOCAL_MACHINE\Software\Policies
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies
and two for user registry policy:
HKEY_CURRENT_USER\Software\Policies
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies
As long as registry policy settings write to one
of these four keys, they will not tattoo the registry
when the GPO is removed. Of course, to
write policies to these four keys, the underlying
applications or components in Windows had
to be written to look in these keys for policy
settings. However, you can still create custom
ADM (or ADMX in Vista) template files that can
write to any keys in the registry (under HKEY_
LOCAL_MACHINE or HKEY_CURRENT_
USER). Policies that do this are called preferences
and will indeed tattoo the registry, even
if the GPO containing them is removed. So,
if you need to undo a preference that was
enabled, you would need to disable it in the
Group Policy Editor (GPE) interface or manually
delete the registry value.
Now this tattooing stuff is most commonly
associated with registry policy, but other policy
areas exhibit this behavior as well. For example,
security policy effectively tattoos a system
when it’s applied. That is, if you set user rights
assignments on a given system, for example,
(using the policy found in Computer Configuration\Windows Settings\Security Settings Local Policies\User rights assignment), and
then you remove the GPO that applied those
settings from where the computer was processing
it, then those user rights assignments
remain until you explicitly change them. This is
important to understand because each policy
area behaves a little differently with respect
to their tattooing of your systems. In some
cases, such as Folder Redirection or Software
Installation policy, you have to tell the policy
specifically what to do when the GPO no longer
applies, as Figure 3 shows. Understanding the tattooing nature of each policy area will help
you know how to manage the application and
removal policy better.
