The new Group Policy Preferences
feature, which is included in Server 2008
but can be installed on XP and later, also
includes the ability to control groups within
the Computer (and User) Configuration Preferences\Control Panel Settings\Local
Users and Groups policy area. You can use
this feature to perform tasks such as rename
groups and selectively add or remove specific
users and groups from group memberships.
Group Policy Preferences provides a
much more flexible version of the Restricted
Groups policy, and I recommend using it as
an alternative if you’re a Restricted Groups
fan but don’t like its limitations.
I just want to say a final word about
using Restricted Groups and Group Policy
Preferences. You might be tempted to try
and use these policies to control AD group
membership. However, these types of policies
aren’t designed to be used in AD’s multimaster environment, and
you can get into some ugly scenarios
in which Group Policy
applies group membership
changes at different times from
different DCs. This can be a
problem because group memberships
are replicated from the
DC that originates the change.
Because Group Policy is processed
equally by every DC in a
domain, each DC would process
identical changes to AD group
membership as specified by the
Restricted Groups policy, and
you would essentially be “pingponging”
identical replication
changes of group memberships
across all DCs, depending on
when each DC processes the
policy.
System Services Policy
The System Services policy lets
you control which Windows services are
started on a given computer. It also lets you
control the permissions on a service. For
example, you can use this policy area to
grant only your server administrators the
ability to stop and start the Print Spooler service
on all Windows servers acting as print
servers. You can use the System Services
policy to grant a select group the ability to
perform their job without requiring them to
be administrators on the systems that they
need to access.
Group Policy Preferences, located under
Computer Configuration\Preferences\Services,
also provides a policy for controlling
system services. This feature also provides
you with additional control over service configuration,
including the ability to change
the service account and the service account
password on a set of systems. The latter
capability is powerful because previously
when you had a service running on a bunch
of machines in the context of a user account,
you had to visit each machine to change the
service account password when you wanted
to change the user account’s password. As a
consequence, many organizations avoided
changing the service account password,
which is a big security risk because many
service accounts are more privileged than
user accounts. With Group Policy Preferences,
you also have a mechanism for pushing that change to all of your computers so
that you can change your service account
password regularly.
Registry and File System Policies
These policies provide you with the ability
to centrally mandate file system and registry
key permissions, respectively. For example,
say you want to lock down a certain file or
folder that exists on all your desktop systems,
such as a workstation’s HOSTS file, so that
malware that gets onto the system can’t
easily modify that file. In that scenario, the
File System policy lets you centrally define
permissions and permissions inheritance that
should exist on that file on all computers that
process the policy. But generally speaking, the
file system and registry security policies aren’t
used very often as a way of centrally managing
file system and registry security and can be
problematic if misused. These policies aren’t
designed to work well when repermissioning
large trees of files and folders or registry
keys. They simply don’t perform that well
during Group Policy processing and have
been known to slow systems to a crawl when
a policy is being processed. The problem is
exacerbated because security policy automatically
refreshes every 16 hours by default,
even if no policy changes occur.
If you need to do some file system or registry
permission tightening, I recommend using an out-of-band method that doesn’t
rely on Group Policy, such as scripts, Windows
security templates, or third-party
security tools. That being said, it is possible
to use these policies if you’re permissioning
only a small number of files, folders, or
registry keys, and it can be an ideal way to
ensure that these key resources are secured
and stay secure, given the recurring processing
behavior of Group Policy.
Application Restrictions
In an ideal scenario, you would like to
define every process that users can run and
exclude all unapproved processes. That way,
if users install something on their systems
inadvertently, you can ensure that it won’t
be executed. This is the general premise
behind Software Restriction Policies
(SRP), which are located under Computer
and User Configuration\Windows Settings Security Settings\Software Restriction Policies.
Essentially, you can control, through a
variety of rule mechanisms, which code is
allowed to run.
SRP can be configured to run in three
different modes. The default mode lets all
code execute and the administrator restrict
those applications or scripts that he or she
explicitly wants to deny. This process is
called blacklisting, and although it’s easy
to administer, it’s not very secure because you
don’t know what you don’t
know and it’s impossible to
specify every piece of code that
users might run.
The second mode is called
whitelisting and is the most
secure way to use SRP, but it
requires more management on
the part of the administrator.
In this mode, you can set the
default execution level to Disallowed,
meaning that no code
will execute on the system other
than core Windows code and
any other applications or scripts
that you specify. You can set the
default mode under the Security
Levels folder within Software
Restriction Policies, as shown in Figure 2.
When you enable this mode, you must
create rules that specify which code is
allowed to execute. To do so, you need to
know which processes your users will run
and keep up with their demands for new
applications. Although this can make the
process of managing whitelists onerous, it
does provide for a very secure environment
if your users run only a handful of applications.
For example, when you whitelist the
applications that are allowed to run, users
who inadvertently download malicious
code can’t run that code because it isn’t on
the list of approved applications. You define
allowed and disallowed applications using
the SRP rules that I describe later.
The final mode, called Basic user, was
first exposed in Vista but is also supported in
XP. In scenarios in which your users run as
administrators, when you set the default level
to Basic user, al processes that an administrative
user runs are stripped of their administrative
tokens, which essentially forces the
process to run as a non-administrative user.
This approach can be useful if you want to
ensure that your administrators aren’t running
certain processes using their administrative
accounts.
The basic approach for using SRP is
to first set the default Security Levels to
Unrestricted, Disallowed, or Basic user.
You can then create rules by clicking the
Additional Rules folder within Software
Restriction Policy, as shown in Web Figure
2. These additional rules provide for exceptions
to either enable or disable certain
processes’ ability to execute. SRP comes with four rule types: hash, path, certificate,
and network-zone rules.
• Hash rules—Hash rules are used to
uniquely identify an executable piece of
code. When you use a hash rule, you pick
a particular version of an executable or
script and say that only that particular
version is Unrestricted or Disallowed.
If the user renames the executable, the
hash is still valid and the user is blocked,
if it’s set to Disallowed. However, any
time the application changes versions,
you’ll need to create a new hash rule to
reflect that change. If applications have
different versions for different Windows
releases, each version needs its own hash
rule. This type of rule is cumbersome
to maintain for lots of applications, but
bulletproof for ensuring that a particular
application can or can’t run. The hash
rule is computed by Group Policy Editor
at the time that you add the executable to
the policy.
• Path rules—Path rules are more flexible
than hash rules. They let you specify
a path in the file system that contains
executable code and allow or disallow
all code found in that path (and its child
folders as well). You can use wildcards
and environmental variables to define
path rules, making the rules even more
flexible. The downside to path rules is
that they’re only as good as the permissions
on your local file system. If your
users can simply copy code they want to
run into a different folder to get around
a path rule, your path rules won’t help
much. For example, temporary file locations are typically writeable by users, so
you should create a path rule that prevents
any code execution from the various
temporary file locations in Windows.
For this reason, a combination of path
rules, hash rules, and tight file system
permissions might prove to be the best
solution.
• Certificate and network zone rules—
These rules are the least frequently used.
Certificate rules let you specify code that
can run based on who signed the code
with public key certificates. The downside
to these rules is that they require you to
ensure that all code that’s run is signed,
which isn’t always feasible. Network
zone rules let you control how files are
installed based on where they came from
but are almost useless because they apply
only to Windows Installer (.msi) files.
Also, if a user downloads a setup.exe file,
this rule is ignored.
Continue to page 3
Register
