AppLocker is a new feature of Windows 7 that allows you to restrict program execution via Group Policy. It is comparable to—but better than—the Software Restriction Policies of former Windows versions, which are still supported in Windows 7 and Windows Server 2008 R2. Software Restriction Policies are not very popular among admins, because configuring them is time-consuming although it can easily be circumvented. AppLocker promises to address both downsides to Software Restriction Policies. In this article, I will give an overview of the capabilities, and in my next post, I will explain how to use AppLocker.

AppLockerAppLocker supports three types of rules: Path Rules, File Hash Rules, and Publisher Rules. Path Rules and Hash Rules are already available as part of the Software Restriction Policies.

Path Rules enable you to restrict the execution of programs to a certain directory path. For example, you can allow end users to launch applications only from the Windows Program Files folders. This is safe as long as end users are not allowed to install programs. The problem with this rule type is that users often also need to start applications from other locations—for example, from a file server. Depending on the complexity of your environment, it can be time-consuming to keep track of legitimate program folders.

Hash Rules use a cryptographic hash of the executable to identify a legitimate program. The major downside of this rule type is that you have to modify the rule whenever you update the program, because any kind of change to the executable will also change the hash.

AppLocker-Digital-SignaturePublisher Rules identify an application based on a digital signature of the application that was issued by the publisher. They are comparable to the Certificates Rules found in the Software Restriction Policies. However, Publisher Rules are more sophisticated. Most newer applications have a signature that can be used for Publisher Rules. In Vista and Windows 7, you can view this signature through the file properties of the executable. Certificates Rules usually work only with ActiveX controls that have an appropriate certificate, and these are very rare.

AppLocker-Create-Executable-Rules2 Furthermore, Publisher Rules have more options than Certificate Rules. They allow you to work with different scopes. You can restrict the execution of a program to the publisher (for example, Microsoft), to the product name (Internet Explorer), to the file name (iexplore.exe), or to the file version ( Note that the file version does not necessarily correspond with the program version. It is also possible to restrict the rule to a specific version only, to a specific version number and above, or to specific version number and below. Because AppLocker gets this information from the digital signature of the executable, end users can't circumvent Publisher Rules by just renaming a file.

All three rule types (Path, Hash, and Publisher) can be applied to executables (.exe), to scripts (.ps1, .bat, .cmd, .vbs, .js), to installer files (.msi, .msp), and to system libraries (.dll, .ocx). The latter option is not yet implemented in Windows 7 Beta1 (build 7000).

AppLocker-User-Group All rule types allow you to configure exceptions. An exception can be one of the three rule types, and it can be a different rule type from the rule it belongs to. For instance, you could configure a Path Rule that allows the execution of all apps in the Program Files folder except those of the publisher Microsoft. This would prevent users from launching Internet Explorer, Windows Media Player, etc. Or you could restrict the rule to a certain user or user group. It is also possible to configure ‘allow’ and ‘deny’ rules. According to my tests, it seems as if ‘deny’ rules may have a higher priority than ‘allow’ rules.

Subscribe to 4sysops newsletter!

Part 2 of my review of AppLocker will offer some practical tips based on my experiences. For now, I recommend that you wait to test AppLocker until you have read my next post. It will save you some time.

  1. Christoph 14 years ago

    Excellent roundup, kudos!
    Yes, software restrictions are a pain to establish, this however looks very promising und useful.

  2. Simon Bishop 14 years ago

    The deny rules overriding allow rules sounds like an extension of NTFS permissions, where No Access means No Access…

    I can feel a whole layer of pain coming on!

  3. Christoph, thanks.

    Simon. You are right it is comparable to the NTFS permission. Actually, it is common practice in security that deny rules override allow rules.

  4. Grayda 13 years ago

    Now, I wonder if this lets you block SWF files too. Software Restriction policies are fantastic and AppLocker seems to be much better, but it’s not as fantastic as I’d like. Still, I’ll wait and see what’s going on..

Leave a reply

Please enclose code in pre tags

Your email address will not be published.


© 4sysops 2006 - 2023


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account