Executive Summary: You can use Group Policy to manage the security configurations on your Windows desktops. Group Policy’s security configuration capabilities fall into three general categories: core system security, application and device restrictions, and Microsoft Internet Explorer security. You can use the new Group Policy Preferences feature to manage most of Group Policy’s security configurations on your users’ systems.

Managing Windows desktop security can be complex, with a myriad of tools and approaches available. However, Windows OSs include a built-in tool that has all the capabilities most organizations need to create secure, locked down desktops across any size environment— Group Policy.

Group Policy is often thought of by many IT administrators as a tool for performing desktop management tasks such as deploying software, redirecting folders, or locking a user out of regedit.exe. However, Group Policy is also the primary Windows tool for managing security configurations. In fact, Group Policy includes quite a few security capabilities that you might not be aware of. In this article, I explore some of Group Policy’s security features, explain how they work, and give you some tips for getting the most from them.

Core System Security
I break Group Policy’s security configuration capabilities into the following general categories: core system security, application and device restrictions, and Microsoft Internet Explorer (IE) security. The policy settings in the core system security category can typically be found in Group Policy Editor under Computer Configuration Windows Settings\Security Settings, as shown in Web Figure 1 from a Windows Vista system. Here are some of the features found in the core system security area of Group Policy.

Account Policies
You might be familiar with this section of Group Policy because it’s where password and account lockout policies are set. For example, you can set a minimum password length or require passwords to contain complex characters in this area of Group Policy. If you define these policies in a Group Policy Object (GPO) linked to the domain (e.g., within the Default Domain policy), the password policy is processed by all the domain controllers (DCs) in your domain and the GPO controls password policy for your domain user accounts. When the password policy is defined in a GPO linked to the domain, it will also be processed by all workstations and member servers in the domain and will set account policy for any local accounts defined on those systems.

As you might know, you can have only one domain password policy defined through Group Policy. However, Windows Server 2008 supports a new set of password policy objects, defined in Active Directory (AD), that give you more granular control of password policy within a single domain.

Local Policies
The three security policy areas under Local Policies let you control a variety of security settings on your Windows systems. For example, these policies let you use Audit Policy to configure which events are collected by the Windows Security event logs on your servers, use User Rights Assignment to configure who can access a particular set of servers or workstations via Remote Desktop, or use Security Options to configure whether the Administrator account is enabled on a given set of systems and renamed something other than Administrator.

Audit Policy is fairly straightforward in that it lets you control which types of events will be collected by the Windows Security event log. You can specify success and/or failure events here for auditing types ranging from AD access to system object (e.g., file and registry key) access. Depending on where a GPO defining auditing events is linked, you can enable auditing on DCs or member servers and workstations. For example, if I link a GPO containing an audit policy that enables directory service access auditing to the Domain Controllers organizational unit, it will be processed by all the DCs in my domain and thus all access to AD will be logged on the DC that serviced the access request.

User Rights Assignment is another powerful security tool within Group Policy. This tool lets you control who can do what on a given system. Examples of user rights include the Logon Locally right, which lets you control who can log on interactively at the console of a server or workstation, and the Load and Unload Device Drivers right, which grants a group or user the ability to install device drivers such as printer and display drivers. By creating a GPO that’s linked at the domain level and populating the Deny Log on Locally right with the Authenticated Users group, you would effectively prevent all the users in your AD domain from logging on to their workstations. Obviously, the point of this example isn’t to show how to break things, but to show how powerful User Rights Assignment can be and how careful you need to be when using it. As with other policy settings, you want to make sure that the GPO in which you’re setting user rights applies only to the computers you intend it to and that the rights you’re granting or revoking are granted or removed from the correct user groups.

Another thing to keep in mind about User Rights Assignment is that the list of rights that you see in Group Policy Editor changes depending on which version of Windows you’re editing Group Policy from (i.e., the version of Windows that you’re running Group Policy Editor on). Newer versions of Windows, such as Server 2008 and Vista, contain more user rights than older versions such as Windows XP. So, if you define a user right in a GPO running on Vista, and that GPO is applied to an XP system that doesn’t know anything about that user right, the XP system will process the policy but then ignore it.

You can quickly compare the differences in security settings between versions of Windows by downloading the Group Policy Settings Reference spreadsheets that Microsoft maintains for each version of Windows at download.microsoft.com. Search on the term “Group Policy Settings Reference” to see the spreadsheets for each release. The spreadsheets contain a list of all the default Administrative Templates for that version, as well as security settings.

You can use User Rights Assignment, as well as some of the other security areas in Windows, to configure roles that define who can do what within your environment. The built-in groups, such as Server Operators and Backup Operators, are just groups that have been granted a set of user rights and permissions for other resources on a system. You can certainly create a Desktop Administrators group and grant that group rights to perform whatever tasks are needed on your Windows systems, without having to include members of that group in the Administrators group on every system.

The final area in the Local Policies section of Group Policy Editor is Security Options, which is located under Local Policies Security Options. I call these settings the “vulnerability controls” because they define security settings that control configuration behaviors related to a system’s security posture. For example, within this section, you can configure Server Message Block (SMB) signing requirements on clients or servers. SMB signing is a form of secure communication that makes it difficult for attackers that have access to the network between systems to hijack that traffic. Within this section, you can also control the behavior of Vista’s User Account Control (UAC) feature, as shown in Figure 1.

Perhaps the most interesting thing about the Security Options section is that the list of security options that are presented in this section, while dependent on the version of Windows you’re running Group Policy Editor from, can be manually changed. The list is configured from an underlying file, called sceregvl.inf, that’s contained within the %windir%\inf folder on the machine you’re configuring. Within this file, each of the policies that you see in Security Options is defined, and you can edit the file for additional settings that you want to control via Group Policy. More information about customizing this file can be found at support.microsoft.com/kb/214752.

Restricted Groups Policy
The purpose of the Restricted Groups policy is to provide a mechanism for controlling local group membership on member servers and workstations. For example, you can use the Restricted Groups policy to ensure that only Help desk administrators are members of the Remote Desktop Users group on all your workstations. Restricted Groups has two modes of operation—Members and Member Of. The Members mode is the most restrictive mode. It says that for a given local group on a set of workstations, only the listed users and groups are members, and all other groups or users are removed (with the exception of the local Administrator account, which is never affected by the Restricted Groups policy). By contrast, the Members Of mode lets you add users and groups to other groups non-exclusively. In other words, you can create a policy that says Always make the Desktop Administrators group a member of local Administrators on any computers that process the policy. In that case, Desktop Administrators is added to the local Administrators group, but no other group members are affected.

Continue to page 2

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

Device Restrictions
Controlling what users do with your valuable business data is equally as important as controlling which code they execute. Protecting your data involves not only good data security where the data is stored, but also being able to control whether your users can physically take the data off their machines. In this era of $20 multigigabyte USB thumb drives, an awful lot of corporate data can just “walk away” without your knowing it. Enter Group Policy–based device restrictions. These device restrictions were made available in Server 2008 and Vista systems under Computer (or User Configuration)\Administrative Templates\System\Removable Storage Access. You can deny read or write access (or both) for any class of removable storage, including USB thumb drives, writeable CDs and DVDs, and removable hard drives, as Web Figure 3 shows.

Previously, if you were in a pre-Vista desktop environment, you were out of luck unless you bought third-party device restriction products. However, with the introduction of Group Policy Preferences, device restrictions are now extended to Windows Server 2003 and XP. You can enable or disable the use of specific device classes by their unique ID under Computer (User) Configuration\Preferences\Control Panel Settings\Devices. Although this feature doesn’t provide the same level of granularity as the Vista device restrictions policy we discussed earlier to control the ability to read but not write to a given device type, you can at least create a set of policies that restrict, for example, all removable storage devices, as shown in Web Figure 4.

IE Security
Of all the areas I’ve discussed, perhaps the most challenging to configure via Group Policy is IE. The reason for this is that there are at least three different ways you can configure IE using Group Policy. The first way to configure IE is by using the IE Maintenance policy (under User Configuration\Windows Settings\IE Maintenance Policy). The second way is by using the Administrative Template policy (under Computer—or User— Configuration\Administrative Templates\Windows Components\Internet Explorer). The third way you can configure IE is by using Group Policy Preferences’ features (under User Configuration\Preferences\Control Panel Settings\Internet Settings).

Each of these three areas has its strengths and weaknesses when configuring IE. For example, if you want to configure settings such as IE’s proxy or home page, you can use the IE Maintenance policy or Group Policy Preferences to do so. Of the two, I recommend using Group Policy Preferences if you can because the IE Maintenance policy has a long of history of not being very reliable in terms of delivering policy settings to clients. Of course, in most cases, Group Policy Preferences are just that—preferences. They don’t prevent users from making changes to, for example, proxy settings, as the IE Maintenance policy does. For that reason, if you use Group Policy Preferences to control something like proxy settings, you’ll need to use the Administrative Template policy to disable the page within IE that lets the user access those settings. The goal behind IE security policy is to ensure that users who are browsing websites aren’t allowed to access or download malicious content. By using features such as IE proxy enforcement, you guarantee that users get to the Internet through your point of control—the proxy server. By locking down elements of IE within Administrative Template policy, you ensure that the user can’t change IE’s configuration to get around your restrictions.

If the security configuration task you need to perform is setting IE zone security (which lets you centrally control which websites should be considered safe) or assigning website addresses to popup blocker lists or security zones, you can use all three methods to control these settings. Each method has a different behavior and supports a different set of options. For example, you can use the policies under Computer (or User) Configuration Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Security Page to configure security for each IE zone (e.g., Trusted, Intranet, Internet), as well as a site-tozone assignment list that lets you specify which websites should be added to each security zone for your users. If you use this method, users will be unable to add to or change these settings in IE—they will be totally locked out. However, if you use the IE Maintenance policy, you can configure zone security and site-to-zone assignment, but users will still be able to add websites to a given zone. Finally, if you use Group Policy Preferences, you’ll be able to configure zone security but won’t be able to assign websites to zones. However, Group Policy Preferences gives you full access to all the settings on the Advanced tab under IE’s Properties (shown in Figure 3), which the other two methods don’t.

Resources that Can Help You Get Started
Although there are often multiple methods for configuring the same set of items, there are few desktop security tasks that you can’t accomplish using Group Policy. For help getting started securing your desktops, I recommend checking out the security guides that Microsoft has made available for Vista and XP. You can download them from download.microsoft.com by searching on the term “Security Guide.” These guides include best practices for desktop security configuration, as well as security templates and spreadsheets of settings that define secure configurations. In addition, Microsoft provides the GPO Accelerator (www.microsoft.com/downloads/details.aspx?FamilyID=a46f1dbe-760c-4807-a82f-4f02ae3c97b0), which offers prebuilt GPOs that you can import into your environment and use to implement the best practices specified in the security guides. Although these prebuilt GPOs might not be exactly what you need in your environment, they can give you a starting point to work from as you implement and test secure configurations within your network.