Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.
Blocking Domain Users from Executing Certain Programs
Restrict users from executing certain programs by using Software Restriction Policies to classify content as trusted or untrusted.
Jan De Clercq
March 11, 2008
6 Min Read
Q: I'm looking for a way to block my domain users from executing certain programs from their Windows Vista and Windows XP desktops. Should I investigate third-party software for this or does Microsoft include features in the OS that can handle this? If there is such feature in Windows. are there any differences between the way this is implemented in Windows XP and Windows Vista, and Windows Server 2003 and Windows Server 2008?
A: Beginning with Windows 2003 and XP, Microsoft includes a feature called Software Restriction Policies (SRPs) in the Windows OS, which provides the functionality you are looking for. SRPs allow code to be classified as either trusted or untrusted. Trusted code can be executed and untrusted code cannot. SRPs are a very powerful mechanism: No code stored on your Windows system can hide from SRPs--no matter where the code comes from and no matter who or what (a user, a machine, or a service) executes it. SRPs can apply to any piece of code including scripts, batch files, and executables. By default, SRPs exclude DLL files – but you can change this default behavior as I'll explain.
You can use SRPs, for example, to prohibit an administrator from starting a Telnet session from a server, to restrict user access to Minesweeper, or to only allow the execution of ActiveX controls that were properly signed using your organization’s code-signing certificate. In large environments, such as that of a terminal services-based Application Service Provider (ASP), you can use SRPs to control the applications that are made available to different users.
From a management, distribution, and enforcement point-of-view, SRPs are tightly integrated with Windows Group Policy Object (GPO) technology. To enforce SRPs, administrators need to configure the corresponding GPO settings. Because enforcement of the SRP settings requires the appropriate GPO client-side extension, you cannot enforce them on earlier Windows servers and clients.
To define an SRP, you first need to set one of two default security levels: Unrestricted (meaning an account can run any piece of code if it has the appropriate access rights) or Disallowed (meaning an account cannot run any code no matter what its access rights are). If you are an administrator who knows little about the software your users run, I recommend that you choose the Disallowed security level.
Security levels are defined in the “Security Levels” GPO container, which is located in the Computer ConfigurationWindows SettingsSecurity SettingsSoftware Restriction Policies container of the GPO Microsoft Management Console (MMC) snap-in (As illustrated in Figure 1). If you want to define SRPs for a particular GPO for the first time, the Security Levels container will not show up. Instead, Windows displays a warning message “No Software Restriction Policies Defined”. To make the container visible, right-click the Software Restriction Policies container and select “Create New Policies”. The default security level shows a black checkbox on its icon. In the example in Figure 1, the default security level is set to “Disallowed”.
After you set the default security level, you can create additional rules to refine and set exceptions to the default security level. An SRP rule basically identifies a piece of software. If the default security level is set to Unrestricted, all additional rules will identify code that cannot be executed (is disallowed). If the default security level is set to Disallowed, additional rules identify code that is allowed to execute. Using an SRP rule you can identify a piece of software using one of the following methods:
A hash rule identifies code based on its hash thumbprint.
A certificate rule identifies code based on the software-signing certificate that was used to sign the code.
A path rule uses the file system path to the folder where the code is stored for code identification.
A zone rule identifies code using the Internet zone of the Web site from which the code was downloaded.
You create SRP rules by right-clicking the “Additional Rules” container (see Figure 1) and selecting “New Certificate Rule…” or any of the other three rules. Figure 2 shows how a hash rule for the Solitaire executable (Sol.exe) is defined. When the program’s executable has been selected, the SRP engine will automatically calculate the file hash and fill in its file properties.
In addition to the definition of a default security level and exceptions to this default level using rules, SRPs also let you specify the file types that are subjected to your SRP, and to set special enforcement and trusted publisher rules. These can be set from the “Enforcement”, “Designated File Types” and “Trusted Publishers” GPO entries that are also located in the “Software Restriction Policies” container.
The Designated File Types SRP property lets you add or remove file type extensions for which SRPs should be applied. If you open up the Designated File Types dialog box, you will notice that – by default – it is filled with a long list of file types SRPs apply to, ranging from batch files (*.bat) to registry files (*.reg).
The additional Enforcement settings allow you to exclude DLLs and local administrators from the SRPs. Excluding DLLs from the SRP rules may be an interesting option if the default rule is set to “disallowed”. If in this setup, you want to give users access to a particular program, you must also define plenty of SRP exception rules (for each of the program’s DLLs).
The Trusted Publishers settings le you define who can add certificates to the Trusted Publishers certificate container in the Certificates MMC snap-in and how a code-signing certificate is verified. The Trusted Publishers certificate container is a special certificate store container that holds the certificates of all trusted code-signing entities. Accounts that are allowed to add certificates to this container indirectly decide upon which code is considered trustworthy on a user’s Windows machine.
In Vista and Windows 2008, Microsoft includes the following SRP changes:
The addition of another default security level called “Basic User” (As illustrated in Figure 3). It means that when no SRP exception rule match is found, the application will be run as a normal user--this is in the security context of a non-administrator-level account. This new level offers an intermediate secure approach for setting SRP restrictions: It's more restrictive than the unrestricted level and less restrictive than the disallowed level.
Support for hash rules that leverage the SHA256 hashing algorithm. On previous versions, SRP uses MD5 hashes. On Vista and Windows 2008, the SRP engine will generate both an SHA256 and MD5 hash (for down-level compatibility).
Support for the enabling or disabling of SRP certificate rules through the Enforcement Property dialog box. Evaluation of SRP certificate rules negatively affects machine performance--administrators may want to disable certificate rule-based SRP evaluation on their less powerful Windows clients.
For more details about using SRPs in Vista and Windows 2008, read the Microsoft article “Using Software Restriction Policies to Protect Against Unauthorized Software,” which is available at http://technet.microsoft.com/en-us/windowsvista/aa940985.aspx.
FIGURE 1: SRP GPO settings in Windows XP and Windows Server
FIGURE 2: Defining an SRP hash rule
FIGURE 3: SRP GPO settings in Windows Vista and Windows Server 2008
About the Author
You May Also Like
.jpg?width=700&auto=webp&quality=80&disable=upscale)
