Chapter 6: Software Restriction Policy for Windows XP Clients

Updated: April 13, 2006


Software restriction policy provides administrators with a way to identify software and control its ability to run on local computers. This tool can help protect computers that run Microsoft® Windows® XP Professional against known conflicts and safeguard them against malicious software such as viruses and Trojan horse programs. Software restriction policy integrates fully with the Active Directory® directory service and Group Policy. You can also use it on stand-alone computers.

This chapter has a different structure than the previous chapters in this guide because of the way software restriction policy works. The previous chapters provided recommendations about how to configure Group Policy setting options. Software restriction policy requires an administrator to define the applications that are allowed to run on the client computers in your environment and to then determine the restrictions that the policy will apply to the clients.

When you implement software restriction policy, the first decision you must make is whether the default security level will be Unrestricted or Disallowed. If the default security level is Unrestricted, then all software will be allowed to run and you will need to configure additional rules to block specific applications. The more secure approach is to configure the default security level to Disallowed, which means no software will be allowed to run, and then configure additional rules to allow specific applications. You can apply software restriction policy to multiple computers through domain–based Group Policies or to individual computers through local Group Policy.

Important: It is important that you thoroughly test all of the policy settings that are discussed in this guide before you deploy them to production systems, especially software restriction policy settings. Mistakes in the design or implementation of this feature can cause considerable user frustration.

Software restriction policy provides a number of ways to identify software, as well as a policy–based infrastructure to enforce rules on how the identified software may run. Computer users must comply with the guidelines that are established in the software restriction policy by the administrator in their environment.

You can use software restriction policy to accomplish the following:

  • Control what software may run on the client computers in your environment.
  • Restrict user access to specific files on multi-user computers.
  • Decide who may add trusted publishers to client computers.
  • Define whether the policies affect all users or a subset of users on the client computers.
  • Prevent executable files from running on your local computers based on policies that are set at a computer, OU, site, or domain level.

Software Restriction Policy Architecture

Software restriction policy provides the following powerful features:

  • Policy enforcement that is either domain–based or local computer–based. Administrators create the policy and then define which applications are trusted and which are not. The policy is enforced at run time and users do not receive prompts that allow them to choose whether to run executable files.
  • Policy that applies to more than just binary executable files. The definition of what constitutes software is ambiguous. Software restriction policy provides control over Microsoft Visual Basic® Scripting Edition (VBScript), JScript®, and other scripting languages. It also integrates with the Windows Installer feature to provide control over which packages can be installed on client computers. This feature includes an application programming interface (API) that you can use to coordinate the policy runtime with other runtimes.
  • Policy that is scalable. Because it is implemented through Group Policy, software restriction policy can be effectively implemented and managed across domains that consist of tens of thousands of computers.
  • Policy that is flexible. Administrators have the flexibility to prohibit unauthorized scripts, to regulate Microsoft ActiveX® controls, and to tightly lock down client computers.
  • Policy that enables strong cryptography to identify software. Software restriction policy can identify software using hashes or digital signatures.

Software restriction policy implementation includes three phases:

  1. The administrator or a delegated authority creates the policy with the Microsoft Management Console (MMC) Group Policy snap-in for the Active Directory container site, domain, or OU. Microsoft recommends that you create a separate Group Policy object (GPO) for software restriction policy.Note: To create a new software restriction policy for a local stand-alone computer, you must be a member of the Administrators group on the local computer. To configure these policy settings, click Windows Settings, Security Settings, and then Software Restriction Policy.
  2. The computer-level policy is downloaded and takes effect after you start the computer. User policies take effect when the user logs on to the system or domain. To update the policy, execute the gpupdate.exe /force command.
  3. When a user starts an executable file such as an application or script, the policy determines whether it can run according to its precedence rules.

Unrestricted or Disallowed Settings

A software restriction policy consists of two parts:

  • A default rule that specifies which programs may run.
  • An inventory of exceptions to the default rule.

You can set the default rule that is used to identify software to either Unrestricted or Disallowed—which allow you to either run or not run all software, respectively.

If you set the default rule to Unrestricted, an administrator can define exceptions or a set of programs that are not allowed to run. Use the Unrestricted default setting in an environment with loosely managed client computers. For example, you can restrict users' ability to install a program that will conflict with existing programs by creating a rule to block it.

A more secure approach is to set the default rule to Disallowed and then allow only a specific set of programs to run. The Disallowed default setting requires an administrator to define all the rules for each application and ensure that users have the correct security policy settings on their computers to access the applications that they are allowed to run. The Disallowed default setting is the more secure approach for organizations that want to protect Windows XP client computers.

Four Rules to Identify Software

Rules in a software restriction policy identify one or more applications and specify whether they are allowed to run. The enforcement engine in Windows XP queries the policy’s rules before applications are allowed to run. To create a rule, you need to identify applications and then categorize them as exceptions to the Disallowed default setting. Each rule can include comments to describe its purpose.

A software restriction policy uses the following four rules to identify software:

  • Hash Rule. Uses a cryptographic fingerprint of the executable file.
  • Certificate Rule. Uses a digitally signed certificate from a software publisher for the .exe file.
  • Path Rule. Uses the local, Universal Naming Convention (UNC), or registry path of the .exe file location.
  • Zone Rule. Uses the Internet Zone where the executable file originated (if it was downloaded using Microsoft Internet Explorer).

The Hash Rule

A hash is a digital fingerprint that uniquely identifies a software program or executable file even if the program or executable file is moved or renamed. Administrators can use a hash to track a particular version of an executable file or program that they may not want users to run.

With a hash rule, software programs remain uniquely identifiable because the hash rule match is based on a cryptographic calculation that involves the contents of the file. The only file types that are affected by hash rules are those that are listed in the Designated File Types section of the details pane for Software Restriction Policies.

Hash rules work effectively in a static environment. If software in your environment is upgraded, the hash needs to be recalculated for each updated executable file. Hash rules work very well in environments that experience infrequent software changes or upgrades.

A hash rule consists of the following three pieces of data, separated by colons:

  • The MD5 or SHA-1 hash value
  • The file length
  • The hash algorithm ID number

Digitally signed files use the hash value that is contained in the signature, which may be MD5 or SHA-1. Executable files that are not digitally signed use an MD5 hash value.

Hash rules are formatted as follows:

[MD5 or SHA1 hash value]:[file length]:[hash algorithm id]

The following hash rule example is for a 126-byte file with contents that match the MD5 hash value (7bc04acc0d6480af862d22d724c3b049) and the hash algorithm (denoted by the hash algorithm identifier 32771):


Each file that the administrator wants to restrict or allow needs to contain a hash rule. When software is updated, the administrator must create a new hash rule for each application because the hash values for the original executable files will not match those of the new files.

Complete the steps in the following procedure to create a hash rule for an executable file.

To create a hash rule for an existing executable file

  1. On the Group Policy Object Editor tool bar, click Windows Settings, Security Settings, Software Restriction Policy, and then right-click Additional Rules.
  2. Click New Hash Rule on the shortcut menu.


    Figure 6.1 The New Hash Rule dialog box

    Figure 6.1 The New Hash Rule dialog box

    See full-sized image


  3. Click Browse to select the file for which you want to create a hash rule. In this example, the executable file is Excel.exe. The new file hash value displays in the File Hash: box, and the application version displays in the File Information: box.
  4. Select the default security level setting that you want for this rule. The options are:
    • Disallowed
    • Unrestricted

The Certificate Rule

A certificate rule specifies that a software publisher's certificate (used for code-signing) must exist before a program is allowed to run. For example, an administrator can require signed certificates for all scripts and ActiveX controls. Allowable sources that comply with the certificate rule include:

  • A commercial certificate authority (CA), such as VeriSign.
  • A Microsoft Windows 2000/Windows Server™ 2003 public key infrastructure (PKI).
  • A self-signed certificate.

A certificate rule is a strong software identification method because it uses signed hashes in the signature of the signed file to match files, regardless of name or location. Unfortunately, few software vendors use code-signing technology, and even those that do typically sign a small percentage of the executable files that they distribute. For these reasons, certificate rules are generally used for a few specific application types such as ActiveX controls or internally developed applications. For example, this guide recommends that organizations digitally sign scripts that are used to manage computers and users so that all unsigned scripts can be blocked. A hash rule can be used to identify exceptions to a certificate rule.

Enabling Certificate Rules

Certificate rules are not enabled by default. Complete the steps in the following procedure to enable certificate rules.

To enable certificate rules

  1. Open the GPO in the Group Policy Object Editor.
  2. In the console tree, click Security Options.
  3. In the details pane, double-click System settings: Use Certificate Rules on Windows Executables for Software Restriction Policies.
  4. Click Enabled to make the certificate rules available.

For detailed instructions about how to digitally sign files, see the “Step-by-Step Guide to Digitally Signing Files with Test Certificates” section of the "Using Software Restriction Policies to Protect Against Unauthorized Software" at

Many commercial Web sites have their software code-signed by a commercial certification authority (CA). These certificates are usually valid from one to several years. When you use certificate rules, be aware that the certificates carry expiration dates. You may be able contact the software publisher to find out more information about the expiration period for a published certificate. When you receive a certificate from a commercial CA, you can export it to a file to create a certificate rule. Complete the steps in the following procedure to export a certificate.

To export a certificate

  1. Select the trusted publisher that will issue the certificate. In this example, the certificate publisher is Microsoft MSN®.


    Figure 6.2 The Security Warning dialog box that shows the trusted publisher

    Figure 6.2 The Security Warning dialog box that shows the trusted publisher

    See full-sized image


  2. Click the Details tab and then Copy to File... to copy this certificate to a file and use it to create a certificate rule.


    Figure 6.3 The Details tab of the Certificate dialog box

    Figure 6.3 The Details tab of the Certificate dialog box

    See full-sized image


  3. The Certificate Export Wizard welcome page will display. Click Next to continue.


    Figure 6.4 The Certificate Export Wizard welcome page

    Figure 6.4 The Certificate Export Wizard welcome page

    See full-sized image


  4. On the Export File Format page, select DER encoded binary X.509 (.CER) and click Next to create the certificate file with a (.cer) extension.


    Figure 6.5 The Certificate Export Wizard

    Figure 6.5 The Certificate Export Wizard

    See full-sized image


  5. On the File to Export page, designate a descriptive certificate rule file name. The certificate will be saved to whatever location you select with whatever file name you choose.


    Figure 6.6 The Certificate Export Wizard

    Figure 6.6 The Certificate Export Wizard

    See full-sized image


  6. The Completing the Certificate Export Wizard page will display the certificate file’s specified settings. Review the settings and click Finish to export the file.


    Figure 6.7 The Certificate Export Wizard Completion page that shows the specified settings

    Figure 6.7 The Certificate Export Wizard Completion page that shows the specified settings

    See full-sized image


The Path Rule

A path rule specifies either a folder or a fully qualified path to a program. When a path rule specifies a folder, it matches any program that is contained in that folder and any programs that are contained in subfolders of that folder. Path rules support both local and UNC paths.

The administrator must define all directories from which a specific application will be launched in the path rule. For example, if a desktop shortcut is used to launch an application, the path rule must specify both the executable file and the shortcut paths to run the application. If a user attempts to run an application with only a partial path rule, the Software Restricted warning will display.

Many applications use the %ProgramFiles% variable to install files on the hard drive of Windows XP–based computers. Unfortunately, some applications are hard-coded to copy files to the C:\Program Files subdirectory, and will do so even if this variable is set to another directory on a different drive. Remember this limitation when you create and test path rules.

Using Environment Variables in Path Rules

You can define a path rule to use environment variables. Because path rules are evaluated in the client environment, environment variables allow an administrator to adapt a rule to a particular user’s environment.

The following two examples show instances of how to apply environment variables to a path rule.

  • “%UserProfile%” matches C:\Documents and Settings\<User> and all subfolders under this directory.
  • “%ProgramFiles%\<Application> matches C:\Program Files\<Application> and all subfolders under this directory.

Note: Environment variables are not protected by access control lists (ACLs). There are two types of environment variables, User and System. Users who are able to start a command prompt can redefine the Users environment variable to a different path. Only users in the Administrators group can change the System environment variable.

Although the two preceding examples are very useful, you may want to consider other available environment variables. For a complete list, see the “Command shell overview” at

Using Wildcards in Path Rules

A path rule can incorporate the "?" and "*" wildcards. The following examples show wildcards that are applied to different path rules:

  • \\DC – ??\login$ matches \\DC – 01\login$, \\DC – 02\login$, and so on.
  • *\Windows matches C:\Windows, D:\Windows, E:\Windows, and all subfolders under each directory.
  • C:\win* matches C:\winnt, C:\windows, C:\windir, and all subfolders under each directory.
  • *.vbs matches any application that has this extension in Windows XP Professional.
  • C:\Application Files\*.* matches all application files in the specific subdirectory.

Registry Path Rules

Many applications store paths to their installation folders or application directories in the Microsoft Windows registry. Some applications can be installed anywhere on the file system. To locate them, you can create a path rule to look up their registry keys.

These locations may not be easily identified using specific folder paths, such as C:\Program Files\Microsoft Platform SDK, or environment variables, such as %ProgramFiles%\Microsoft Platform SDK. However, if the program stores its application directories in the registry, you can create a path rule that will use the value that is stored in the registry, such as:

%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PlatformSDK\Directories\Install Dir%

This type of path rule, called a registry path rule, is formatted as follows:

%<Registry Hive>\<Registry Key Name>\<Value Name>%

Note: Any registry path rule suffix should not contain a \ character immediately after the last % sign in the rule. The registry hive name must be written completely; abbreviations will not work.

When the default rule is set to Disallowed, four registry path rules are set up so that the operating system has access to system files. These registry path rules are created as a safeguard—so that you do not lock yourself and all other users out of the system—and are set to Unrestricted. These rules should only be modified or deleted by advanced users. The registry path rule settings are:

  • %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%
  • %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%\*.exe
  • %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%\System32\*.exe
  • %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir%

Path Rule Precedence

When there are multiple path rules that match, the most specific rule takes precedence over the others. The following set of paths is ordered from highest precedence (most specific match) to lowest precedence (most general match):

  • Drive:\Folder1\Folder2\FileName.Extension
  • Drive:\Folder1\Folder2\*.Extension
  • *.Extension
  • Drive:\Folder1\Folder2\
  • Drive:\Folder1\

Zone Rule

You can use a zone rule to identify software that is downloaded from any of the following zones that are defined in Internet Explorer:

  • Internet
  • Intranet
  • Restricted Sites
  • Trusted Sites
  • My Computer

The current version of the Internet zone rule applies only to Windows Installer (*.msi) packages. Also, this rule does not apply to software that is downloaded through Internet Explorer. All other file types that are affected by zone rules are listed in the Designated File Types table later in this chapter. One list of designated file types is shared by all zone rules.

Rule Recommendations

Use the information in the following table to determine which type of rule is best suited for an application’s users and environment.

Table 6.1 Determining the Best Rule for a Given Application

Task Recommended rule

Allow or disallow a specific program version.

Hash ruleBrowse to the file to create a hash rule.

Identify a program always installed in the same place.

Path rule with environment variables%ProgramFiles%\Internet Explorer\iexplore.exe

Identify a program that can be installed anywhere on client computers.

Registry path rule%HKEY_LOCAL_MACHINE\SOFTWARE\ ComputerAssociates\InoculateIT\6.0\Path\HOME%

Identify a set of scripts on a central server.

Path rule\\SERVER_NAME\Share

Identify a set of scripts on a set of servers. For example, DC01, DC02, and DC03.

Path rule with wildcard\\DC??\Share

Disallow all .vbs files, except those in a login script directory.

Path rule with wildcard

*.VBS set to Disallowed

\\LOGIN_SRV\Share\*.VBS set to Unrestricted

Disallow a file installed by a virus that is always called Flcss.exe.

Path rule

Flcss.exe set to Disallowed

Identify a set of scripts that can be run anywhere.

Certificate rule

Use a certificate to digitally sign the scripts.

Allow software to be installed from trusted Internet zone sites.

Zone rule

Set Trusted Sites to Unrestricted.

Software Restriction Policy Precedence Rules

Rules are evaluated in a specific order. The rules that more specifically match a program take precedence over rules that more generally match the same program. If two identical rules with differing security levels are established for the same software, the rule with the highest security level takes precedence. For example, if two hash rules—one with the security level Disallowed and one with the security level Unrestricted—are applied to the same software program, the rule with the security level Disallowed takes precedence, and the program will not run. The following list defines the precedence order for the rules, from the most specific to the least specific:

  1. Hash rule
  2. Certificate rule
  3. Path rule
  4. Zone rule
  5. Default rule

Software Restriction Policy Options

This section discusses the various enforcement options that influence the way a software restriction policy functions. These options alter the way Microsoft Authenticode® trust settings are enforced for digitally signed files. There are two enforcement options: Dynamic-link library (DLL) checking and Skip Administrators.

DLL Checking

Most programs consist of an executable file and many supporting DLLs. By default, software restriction policy rules are not enforced on DLLs. This default setting is recommended for most customers for the following three reasons:

  • If the main executable file is disallowed the program is prevented from running, so there is no need to disallow the constituent DLLs.
  • DLL checking degrades system performance because it has to check all libraries that are linked to the application. For example, if a user runs 10 programs during a logon session, the software restriction policy evaluates each program. With DLL checking turned on, the software restriction policy evaluates each DLL load within each program. If each program uses 20 DLLs, this configuration would result in 10 executable program checks plus 200 DLL checks—which would require the software restriction policy to perform 210 evaluations. A program such as Internet Explorer consists of an executable file (iexplore.exe) and many supporting DLLs.
  • If the default security level is set to Disallowed, the system is forced to not only identify the main executable file before it is allowed to run but also all of the .exe file's constituent DLLs, which places added burden on the system.

Because viruses primarily target executable files, some specifically target DLLs. Therefore, DLL checking is the recommended option when you want the highest possible assurance for the programs running in your environment.

To ensure that a program does not contain a virus, you can use a set of hash rules that identify the executable file and all of its constituent DLLs.

To turn off the DLL Checking option

  • When you edit a software restriction policy, in the Enforcement Properties dialog box select All software files except libraries (such as DLLs) as shown in the following figure:


    Figure 6.8 The Enforcement Properties dialog box that shows file and user enforcement options

    Figure 6.8 The Enforcement Properties dialog box that shows file and user enforcement options

    See full-sized image


Skip Administrators

You may want to disallow programs from running for most users but allow administrators to run all of them. For example, an administrator may have a shared computer that multiple users connect to through Terminal Server. The administrator may want users to run only specific applications on the computer, but members in the local Administrators group to be able to run anything. Use the Skip Administrators enforcement option to achieve this functionality.

If the software restriction policy is created in a GPO that is linked to an object in Active Directory, Microsoft recommends that you deny the Apply Group Policy permission on the GPO to the Administrators group and not use the Skip Administrators option. This method consumes less network bandwidth because GPO settings that do not apply to administrators are not downloaded.

Note: Software restriction policy defined in local security policy objects cannot filter user groups, and would therefore require use of the Skip Administrators option.

To turn on the Skip Administrators option

  • In the Enforcement Properties dialog box (shown in Figure 6.8), select All users except local administrators.

Defining Executables

The Designated File Types Properties dialog box in the following figure lists the file types that are governed by software restriction policy. These file types are considered executable files. For example, a screen saver file (.scr), is considered an executable file because it loads as a program when you double-click it in Windows Explorer.

Software restriction policy rules only apply to the file types listed in the Designated File Types Properties dialog box. If your environment uses a file type that you want to apply rules to, add it to the list. For example, for Perl script files you may choose to add .pl and other file types associated with the Perl engine to the Designated file types: list under the General tab of the Designated File Types Properties dialog box.


Figure 6.9 The Designated File Types Properties dialog box

Figure 6.9 The Designated File Types Properties dialog box

See full-sized image


For the GPO design that is defined in this guide, the file types .mdb and .lnk are removed and .ocx is added. The following table lists the designated file types.

Table 6.2 Designated File Types

File extension Description   File extension Description


Microsoft Access Project extension



Microsoft Common Console document


Microsoft Access Project



Windows Installer Package


Visual Basic Class Module



Windows Installer Patch


Batch file



Visual Test Source file


Compiled HTML Help file



ActiveX Control


Windows NT command script



Photo CD Image


MS-DOS application



Shortcut to MS-DOS program


Control Panel extension



Registry entry


Security certificate



Screen Saver





Windows Script Component


Windows Help file



Shell Scrap Object


HTML application



Internet Shortcut (Uniform Resource Locator)


Setup Information file



Visual Basic file


Internet Communication setting



VBScript Encoded Script file


Internet Communication setting



VBScript Script file


JScript file



Windows Script Component


JScript Encoded Script file



Windows Script file


Microsoft Access MDE Database



Windows Scripting Host Setting file

Trusted Publishers

You can use the Trusted Publishers Properties dialog box to configure which users can select trusted publishers. You can also determine which, if any, certificate revocation checks are performed before you trust a publisher. With certificate rules enabled, software restriction policy will check a certificate revocation list (CRL) to ensure that the software's certificate and signature are valid. However, this process may decrease performance when signed programs are started.

The options on the General tab of the Trusted Publishers Properties dialog box shown in the following figure allow you to configure settings that are related to ActiveX controls and other signed content.


Figure 6.10 The Trusted Publisher Properties dialog box

Figure 6.10 The Trusted Publisher Properties dialog box

See full-sized image


The following table shows trusted publisher options that are related to ActiveX controls and other signed content.

Table 6.3 Trusted Publisher Tasks and Settings

Setting name Task

Enterprise administrators

Use to allow only enterprise administrators to make decisions about signed active content.

Local computer administrators

Use to allow local computer administrators to make all decisions about signed active content.

End users

Use to allow users to make decisions about signed active content.


Use to ensure that the certificate the software publisher uses has not been revoked.


Use to ensure that the certificate the organization uses to time stamp the active content has not been revoked.

Software Restriction Policy Design and Deployment

This section describes how to administer software restriction policy with Group Policy snap-ins, things to consider when you edit a policy for the first time, and how to apply a software restriction policy to a group of users. A variety of issues that relate to software restriction policy deployment are also discussed.

Integration with Group Policy

You can administer software restriction policy with Group Policy snap-ins to a set of client computers as well as to all the users that log on to the computers. The policy is applied to the Desktop OU and the Laptop OU that are defined in this guide.


The administrator should create a separate GPO for the software restriction policy. This method provides a way to disable the Group Policy without disrupting other policies that are applied to the object if unexpected problems should arise.


A local policy should be configured for the stand-alone client computers in your environment as described in Chapter 5, "Securing Stand-Alone Windows XP Clients" of this guide.

Designing a Policy

This section describes the steps to follow when you design and deploy a software restriction policy. Policy design requires you to make several decisions, all of which are described in the following table.

Table 6.4 Important Policy Design Considerations

Decision Factors to consider

Laptops or workstations

Investigate the needs of the mobile users in your environment to determine if the laptops require a different policy than that for desktops. Laptops tend to need more flexibility than desktops.

Server shares, logon scripts, and home drives

You will need to define a path rule for any applications that start from a server share or home directory. You can add logon script files to the path rule. If a script calls any other script, also add the executable locations to the path rule.

GPO or local security policy

In this guide a GPO is used for the design. However, you should consider the effects that local policy will have on your design.

User or computer policy

This design applies all settings at the computer level.

Default security level

It is recommended to configure the default setting to Disallowed, and then configure the rest of the policy accordingly. The Unrestricted default setting is also available.

Additional rules

You will need to apply additional operating system path rules as needed when you use the Disallowed default policy. In the Disallowed configuration, the four rules are created automatically.

Policy options

If you use a local security policy and do not want the policy to apply to administrators on the client computers in your environment, select the policy enforcement option Skip Administrators.

If you want to check DLLs as well as executable files and scripts, select the policy enforcement option DLL Checking.

If you want to establish rules for file types that are not in the default list of designated file types, use the option to add them as needed to the Designated File Types Properties dialog box.

If you want to change who can make decisions about whether ActiveX controls and other signed content can be downloaded, select the check box for Publisher under the General tab of the Trusted Publishers Properties dialog box.

Applying the policy to a site, domain, or OU

The policy will reside under the OU in which the desktops and laptops are located.

Note: Although this guide recommends that software restriction policy be enforced at the computer level there are many cases in which enforcement at the user level will make sense. For example, an organization with shared computers such as Terminal Server application servers or call center workstations may want to allow certain users to run a suite of applications, but block all other users from access.

Best Practices

Microsoft recommends that you create a separate GPO for software restriction policy, so that if you need to disable the policy in an emergency it will not affect the rest of your domain or local policy.

Also, if you accidentally lock down a workstation with software restriction policy in the design phase of your OU, restart the computer in Safe mode, log on as a local administrator, and then modify the policy. Software restriction policy is not applied when you start Windows in Safe mode. After you start the computer in Safe mode, run Gpupdate.exe and then restart it.

For the best security, use ACLs in conjunction with software restriction policy and do not give users administrative privileges. Users may try to rename or move disallowed files or overwrite unrestricted files to circumvent software restriction policy. Use ACLs to deny users access to perform either of these actions. Users who are members of the local Administrators group will be able to bypass your software restriction policy implementation; therefore Microsoft recommends that you do not give users administrative privileges whenever feasible.

Login scripts are usually located under SYSVOL on the domain controller or a centralized server. The domain controller often changes with each login. If your default rule is set to Disallowed, be sure to create rules that identify the locations of your logon scripts. If the logon servers have similar names, consider the use of wildcards to locate them, or use the logon script name with unrestricted settings.

Note: Test new software restriction policy settings thoroughly in test environments before you apply them to your domain. New policy settings may act differently than originally expected. Thorough tests will diminish the chance that you will encounter a problem when you deploy the software restriction policy settings across your network.

Stepping Through the Process

Use the following information to guide you through the process of software restriction policy design and application of the design as a GPO to the laptops and desktops in your environment.

Step 1. Create a GPO for the OU

Locate the OU that was created for the desktops or laptops in your environment. If you are working on a stand-alone client computer, the policy settings are located in the Local Computer Policy. In this policy, click Properties, and then create a new GPO. Name the policy according to your organization's naming convention. Remember, this policy will only be used to enforce software restrictions.

Step 2. Set the Software Restriction Policy

Highlight the GPO and click Edit. Traverse the tree until you locate Windows Settings\Security Settings\Software Restriction Policy. The first time you edit the policy you will see the following message:

No Software Security Policies are defined.

This message warns you that you will define default values when you create a policy. These default values can override policy settings from other software restriction policies. Because no software restriction policy settings have been set yet, use the default settings to start. Right-click the Actions menu and select New Software Restriction Policies.

Step 3. Set Up the Path Rules

After you determine which applications and scripts the workstations will use, you can set up the path rules. Some programs launch other programs to perform tasks, and the software applications in your environment may depend on one or more programs that support other programs. Inventory and installation documentation about the currently installed software is very useful for tracking path rules. An example of a workstation design might include the following guidelines:

  • Applications = *\Program Files
  • Shared Group Applications= g:\Group Applications
  • Logon script = Logon.bat
  • Desktop Shortcuts = *.lnk
  • Approved VBS Scripts =*.vbs

Step 4. Set the Policy Options

The following options include the recommended policy settings for the design that is defined in this guide. These options alter the enforcement behavior scope or the Authenticode trust settings for digitally signed files.

  • Enforcement. If the computer is part of the domain, ensure that the Domain Admins group is automatically added to the Administrators group.
  • Apply to Users. Includes all users except local Administrators. Use of this option delays the launch of each application. To compensate for this delay, the design configures the policy to not check DLLs.
  • Apply to Files. Includes all software files except libraries (such as DLLs). Use of this option delays the launch of each application. To compensate for this delay, the design configures the policy to not check DLLs.
  • Designated file types. For the GPO design that is defined in this guide, .ocx files were added to the list and .mdb and .lnk file types were removed. You could add custom application file type extensions as needed to make them subject to the same rules.
  • Trusted Publishers. For the GPO design that is defined in this guide, the Administrators group was enabled and the option for Trusted Publisher Properties: Local Computer Administrators was selected.

Before you trust a publisher, select the Check: Publisher option when you design the GPO to ensure the policy will validate certificates.

Step 5. Apply the Default Settings

It is a best practice to configure the policy to the default Unrestricted setting. This method ensures that the policy is properly initialized before software restrictions are applied. After you review the policy settings, reset the default setting to Disallowed.

Step 6. Test the Policy

If the computer is part of a domain, move the computer into the OU container where the policy is applied. Restart the test computer and log on to it. The test plans should have instructions about how each of the applications should work when the policy is applied. Run the applications to ensure they have full functionality and that you can access all of their features. After you have validated the functionality of the applications, simulate an attack on the applications to ensure that the policy has no security vulnerabilities.

If the computer is a stand-alone client, log on to the test computer and follow your test plan. After you have validated the applications, launch the simulated attack again to ensure that the policy has no security vulnerabilities.

Deploying Software Restriction Policy

After the policy is thoroughly tested, apply it to the desktop or laptop OU in your environment. If it is for a stand-alone client computer, apply it to the Local Computer Settings on the client. Open the MMC Computers and Users snap-in and traverse the directory until you reach the OU container for the desktops or laptops. Then, create the new GPO with the Group Policy Object Editor. Edit the properties and apply the appropriate policy settings based on the information in the following tables to the Software Restriction Policy under Windows Settings\Security Settings.

Table 6.5 Security Levels

Default rule in UI Description Setting


Software will not run, regardless of the access rights of the user.

Use this default rule

Table 6.6 Additional Rules

Path rule Setting

%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\Current Version\SystemRoot%


%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\Current Version\SystemRoot%\*.exe


%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\Current Version\SystemRoot%\System32\*.exe


%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\Current Version\ProgramFilesDir%




G:\Group Applications


Logon.bat or Logon script


*\Program Files


Table 6.7 Enforcement on Files and Users

Enforcement options Recommendation

Apply software restriction policies to the following:

All software files except DLLs.

Apply software restriction policies to the following users:

All users except local administrators.

Table 6.8 Designated File Types

File types Recommendation

Designated file types properties

Remove .mdb and .lnk file types and add .ocx.

Table 6.9 Trusted Publishers

Trusted publishers Recommendation

Allow the following user groups to select trusted publishers:

Local Computer Administrators

Determine if the certificate is revoked.

Select the Publisher option.


Software restriction policy provides administrators with an effective way to identify and control software on computers that run Windows XP Professional. You can create policies to block malicious scripts, lock down computers in your environment in various ways, and prevent applications from running. In an enterprise organization, it is a best practice to manage software restriction policy with GPOs and to customize each policy to accommodate the needs of the different user groups and computers. Microsoft recommends that you not attempt to manage user groups in a stand-alone environment.

When correctly applied, software restriction policy will improve the integrity and manageability of computers in your organization and ultimately lower the ownership and maintenance costs of the operating systems on those computers.

More Information

The following links provide additional information about Windows XP Professional security-related topics.

This accelerator is part of a larger series of tools and guidance from Solution Accelerators.


Get the Windows XP Security Guide

Solution Accelerator Notifications

Sign up to stay informed


Send us your comments or suggestions