Latest posts by Michael Pietroforte (see all)
- Result of the 4sysops 2016 topic poll - Tue, Apr 5 2016
- New free eBooks for SysAdmins and DevOps – VMware NSX, Windows 10, SQL Server 2016 - Mon, Mar 14 2016
- Introducing the 4sysops IT pro network - Tue, Mar 1 2016
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.
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.
Publisher 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.
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 (188.8.131.52). 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).
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.
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.