SRP (Software Restriction Policies)

From Bauman National Library
This page was last modified on 25 June 2016, at 21:43.

Software restriction policies, SRP are trust policies, which are regulations set by an administrator to restrict scripts and other code that is not fully trusted from running.


Software restriction policies provide administrators with a Group Policy-driven mechanism to identify software and control its ability to run on the local computer. These policies can be used to protect computers running Microsoft Windows XP Professional against known conflicts and safeguard the computers against security threats such as malicious viruses and Trojan horse programs. You can also use software restriction policies to create a highly restricted configuration for computers, in which you allow only specifically identified applications to run. Software restriction policies are integrated with Microsoft Active Directory and Group Policy. You can also create software restriction policies on stand-alone computers.

Group Policy-Based Software Restrictions

Administrators can use software restriction policies to define which applications are allowed or not allowed to run on a target computer. The configuration is deployed in Group Policy objects. To help organizations address the problem of unknown code, administrators can use software restriction policies to perform the following tasks:

  • Fight computer viruses
  • Regulate which ActiveX[1] controls can run
  • Run only digitally signed scripts
  • Enforce that only approved software is run on system computers
  • Create a highly restricted configuration for a computer (for example, stipulate that only specific programs are allowed to run)

Scenarios for Using Software Restriction Policies

Administrators can use software restriction policies for the following tasks:

  • Define what is trusted code
  • Design a flexible Group Policy for regulating scripts, executable files, and ActiveX controls

Software restriction policies are enforced by the operating system and by applications (such as scripting applications) that comply with software restriction policies.

Specifically, administrators can use software restriction policies for the following purposes:

  • Specify which software (executable files) can run on clients
  • Prevent users from running specific programs on shared computers
  • Specify who can add trusted publishers to clients
  • Set the scope of the software restriction policies (specify whether policies affect all users or a subset of users on clients)
  • Prevent executable files from running on the local computer, organizational unit (OU), site, or domain. This would be appropriate in cases when you are not using software restriction policies to address potential issues with malicious users.

Advantages of Software Restriction Policies

Using software restriction policies provides the following advantages:

  • Administrators can enforce software restriction policies in domains or on the local computer.

The software restriction policies can be implemented in a large enterprise with various types of computers and applications, and can also be applied in a stand-alone environment for computers that are not members of a domain. Software restriction policies leverage Active Directory and Group Policy for manageability. The software restriction policies are stored in a GPO. Administrators create the software restriction policy, and then define which applications are trusted and which are not. The software restriction policy is enforced at run time and users do not receive prompts allowing them to choose whether to run executable files.

  • Software restriction policies apply to multiple types of files.

Software restriction policies provide control over Microsoft Visual Basic Scripting Edition (VBScript), JScript, and other scripting languages. Software restriction policies also integrate with the Windows Installer feature to provide control over the types of software packages (.msi files) that can be installed on clients. This feature includes an application programming interface (API), which you can use to coordinate the software restriction policy run time with other run times.

  • Software restriction policies provide flexibility.

Administrators can prohibit unauthorized scripts from running, regulate Microsoft ActiveX controls, or lockdown client computers.

  • Software restriction policies use strong cryptography to identify software.

Software restriction policies can identify software by using a hash or a certificate.

Software requirements

The Software Restriction Policies extension to the Local Group Policy Editor can be accessed through the MMC. The following features are required to create and maintain software restriction policies on the local computer:

  • Local Group Policy Editor
  • Windows Installer
  • Authenticode and WinVerifyTrust

If your design calls for domain deployment of these policies, in addition to the above list, the following features are required:

  • Active Directory Domain Services
  • Group Policy

Software restriction policies components and architecture

Software restriction policies provide a mechanism for the operating system and applications compliant with software restriction policies to restrict the runtime execution of software programs.

At a high level, software restriction policies consist of the following components:

  • Software restriction policies API. The Application Programming Interfaces (APIs) are used to create and configure the rules that constitute the software restriction policy. There also are software restriction policies APIs for querying, processing, and enforcing software restriction policies.
  • A software restriction policies management tool. This consists of the Software Restriction Policies extension of the Local Group Policy Object Editor snap-in, which administrators use to create and edit the software restriction policies.
  • A set of operating system APIs and applications that call the software restriction policies APIs to provide enforcement of the software restriction policies at runtime.
  • Active Directory and Group Policy. Software restriction policies depend on the Group Policy infrastructure to propagate the software restriction policies from the Active Directory to the appropriate clients, and for scoping and filtering the application of these policies to the appropriate target computers.
  • Authenticode and WinVerify Trust APIs which are used to process signed executable files.
  • Event Viewer. The functions used by software restriction policies log events to the Event Viewer logs.
  • Resultant Set of Policies (RSoP), which can aid in the diagnosing of the effective policy that will be applied to a client.

Best practices

Do not modify the default domain policy.

  • If you do not edit the default domain policy, you always have the option of reapplying the default domain policy if something goes wrong with your customized domain policy.

Create a separate Group Policy Object for software restriction policies.

  • If you create a separate Group Policy Object (GPO) for software restriction policies, you can disable software restriction policies in an emergency without disabling the rest of your domain policy.

If you experience problems with applied policy settings, restart Windows in Safe Mode.

  • Software restriction policies do not apply when Windows is started in Safe Mode. If you accidentally lock down a workstation with software restriction policies, restart the computer in Safe Mode, log on as a local administrator, modify the policy, run gpupdate, restart the computer, and then log on normally.

Use caution when defining a default setting of Disallowed.

  • When you define a default setting of Disallowed, all software is disallowed except for software that has been explicitly allowed. Any file that you want to open has to have a software restriction policies rule that allows it to open.
  • To protect administrators from locking themselves out of the system, when the default security level is set to Disallowed, four registry path rules are automatically created. You can delete or modify these registry path rules; however, this is not recommended.

For best security, use access control lists in conjunction with software restriction policies.

  • Users might try to circumvent software restriction policies by renaming or moving disallowed files or by overwriting unrestricted files. As a result, it is recommended that you use access control lists (ACLs) to deny users the access necessary to perform these tasks.

Test new policy settings thoroughly in test environments before applying the policy settings to your domain.

  • New policy settings might act differently than originally expected. Testing diminishes the chance of encountering a problem when you deploy policy settings across your network.
  • You can set up a test domain, separate from your organization's domain, in which to test new policy settings. You can also test the policy settings by creating a test GPO and linking it to a test organizational unit. When you have thoroughly tested the policy settings with test users, you can link the test GPO to your domain.
  • Do not set programs or files to Disallowed without testing to see what the effect may be. Restrictions on certain files can seriously affect the operation of your computer or network.
  • Information that is entered incorrectly or typing mistakes can result in a policy setting that does not perform as expected. Testing new policy settings before applying them can prevent unexpected behavior.

Filter user policy settings based on membership in security groups.

  • You can specify users or groups for which you do not want a policy setting to apply by clearing the Apply Group Policy and Read check boxes, which are located on the Security tab of the properties dialog box for the GPO.
  • When the Read permission is denied, the policy setting is not downloaded by the computer. As a result, less bandwidth is consumed by downloading unnecessary policy settings, which enables the network to function more quickly. To deny the Read permission, select Deny for the Read check box, which is located on the Security tab of the properties dialog box for the GPO.

Do not link to a GPO in another domain or site.

  • Linking to a GPO in another domain or site can result in poor performance.



Cite error: Invalid <references> tag; parameter "group" is allowed only.

Use <references />, or <references group="..." />
  1. "ActiveX".