We help IT Professionals succeed at work.

We've partnered with Certified Experts, Carl Webster and Richard Faulkner, to bring you a podcast all about Citrix Workspace, moving to the cloud, and analytics & intelligence. Episode 2 coming soon!Listen Now


How to block certain file extensions executing

Medium Priority
Last Modified: 2012-05-06
How do I prevent users on a domain from executing certain file types EG .AVI, .WMA, I have a Windows 2003 server and all clients running XP. Can this be done using Group Policy
Watch Question

Not exactly file extensions, but take a look at this:

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 organizations 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 Configuration\Windows Settings\Security Settings\Software 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 programs 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 programs 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 users 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.

Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts


Thanks for the help. This works well
Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.