Rule collections
The AppLocker Microsoft Management Console (MMC) snap-in is organized into four areas called rule collections. The four rule collections are executable files, scripts, Windows Installer files, and DLL files. These collections give the administrator an easy way to differentiate the rules for different types of applications. The following table lists the file formats included in each rule collection.
 | Note |
The DLL rule collection is not enabled by default. To learn how to enable the DLL rule collection, see Enforce AppLocker Rules. |
| Rule collection | Associated file formats |
|---|---|
Executable |
.exe .com |
Scripts |
.ps1 .bat .cmd .vbs .js |
Windows Installer |
.msi .msp |
DLL |
.dll .ocx |
 | Important |
If you use DLL rules, a DLL allow rule has to be created for each DLL that is used by all of the allowed applications. |
 | Caution |
When DLL rules are used, AppLocker must check each DLL that an application loads. Therefore, users may experience a reduction in performance if DLL rules are used. |
Rule conditions
Rule conditions are criteria that the AppLocker rule is based on. Primary conditions are required to create an AppLocker rule. The three primary rule conditions are publisher, path, and file hash.
Publisher
This condition identifies an application based on its digital signature and extended attributes. The digital signature contains information about the company that created the application (the publisher). The extended attributes, which are obtained from the binary resource, contain the name of the product that the application is part of and the version number of the application. The publisher may be a software development company, such as Microsoft, or the information technology department of your organization.
| Note |
Use a publisher condition when possible. Publisher conditions can be created to allow applications to continue to function even if the location of the application changes or if the application is updated. |
When you select a reference file for a publisher condition, the wizard creates a rule that specifies the publisher, product, file name, and version number. You can make the rule more generic by moving the slider down or by using a wildcard character (*) in the product, file name, or version number fields.
| Note |
To enter custom values while creating a rule in the Create Rules Wizard, you must select the Use custom values check box. When this check box is selected, you cannot use the slider to make the rule more or less specific. |
The file version controls whether a user can run a specific version, earlier versions, or later versions. You can choose a version number and then configure the following options:
- Exactly. The rule applies only to this version of the application.
- And above. The rule applies to this version and all later versions.
- And below. The rule applies to this version and all earlier versions.
The following table describes how a publisher condition is applied.
| Option | The publisher condition allows or denies… | |
|---|---|---|
All signed files | All files that are signed by a publisher. | |
Publisher only | All files that are signed by the named publisher. | |
Publisher and product name | All files for the specified product that are signed by the named publisher. | |
Publisher and product name, and file name | Any version of the named file for the named product that are signed by the publisher. | |
Publisher, product name, file name, and file version | Exactly | The specified version of the named file for the named product that are signed by the publisher. |
Publisher, product name, file name, and file version | And above | The specified version of the named file and any new releases for the product that are signed by the publisher. |
Publisher, product name, file name, and file version | And below | The specified version of the named file and any older versions for the product that are signed by the publisher. |
Custom | You can edit the Publisher, Product name, File name and Version fields to create a custom rule. | |
Path
This condition identifies an application by its location in the file system of the computer or on the network.
AppLocker uses path variables for directories in Windows.
| Note |
While two of these path variables use the same format as Windows environment variables, they are not environment variables. AppLocker can only interpret AppLocker path variables. |
The following table details these path variables.
| Windows directory or drive | AppLocker path variable | Windows environment variable |
|---|---|---|
Windows | %WINDIR% | %SystemRoot% |
System32 | %SYSTEM32% | %SystemDirectory% |
Windows installation directory | %OSDRIVE% | %SystemDrive% |
Program Files | %PROGRAMFILES% | %ProgramFiles% and %ProgramFiles(x86)% |
Removable media (for example, CD or DVD) | %REMOVABLE% | |
Removable storage device (for example, USB flash drive) | %HOT% |
| Important |
Because a path condition can be configured to include a large number of folders and files, path conditions should be carefully planned. For example, if an allow rule with a path condition includes a folder location that non-administrators are allowed to write data into, a user can then copy unapproved files into that location and run the files. For this reason, it is a best practice to not create path conditions for standard user writable locations, such as a user profile. |
File hash
When the file hash condition is chosen, the system computes a cryptographic hash of the identified file.
AppLocker default rules
AppLocker allows you to generate default rules for each of the rule types.
Executable default rule types:
- Allow members of the local Administrators group to run all applications.
- Allow members of the Everyone group to run applications that are located in the Windows folder.
- Allow members of the Everyone group to run applications that are located in the Program Files folder.
Windows Installer default rule types:
- Allow members of the local Administrators group to run all Windows Installer files.
- Allow members of the Everyone group to run digitally signed Windows Installer files.
- Allow members of the Everyone group to run all Windows Installer files located in the Windows\Installer folder.
Script default rule types:
- Allow members of the local Administrators group to run all scripts.
- Allow members of the Everyone group to run scripts located in the Program Files folder.
- Allow members of the Everyone group to run scripts located in the Windows folder.
DLL default rule types:
- Allow members of the local Administrators group to run all DLLs.
- Allow members of the Everyone group to run DLLs located in the Program Files folder.
- Allow members of the Everyone group to run DLLs located in the Windows folder.
For more information, see Create Default AppLocker Rules.
AppLocker rule behavior
If no AppLocker rules for a specific rule collection exist, all files with that file format are allowed to run. However, when an AppLocker rule for a specific rule collection is created, only the files explicitly allowed in a rule are permitted to run. For example, if you create an executable rule that allows .exe files in %SystemDrive%\FilePath to run, only executable files located in that path are allowed to run.
A rule can be configured to use either an allow or deny action:
- Allow. You can specify which files are allowed to run in your environment and for which users or groups of users. You can also configure exceptions to identify files that are excluded from the rule.
- Deny. You can specify which files are not allowed to run in your environment and for which users or groups of users. You can also configure exceptions to identify files that are excluded from the rule.
| Important |
You can use a combination of allow actions and deny actions. However, we recommend using allow actions with exceptions because deny actions override allow actions in all cases. Deny actions can also be circumvented. |
Rule exceptions
You can apply AppLocker rules to individual users or a group of users. If you apply a rule to a group of users, all users in that group are affected by that rule. If you need to allow a subset of a user group to use an application, you can create a special rule for that subset. For example, the rule "Allow Everyone to run Windows except Registry Editor" allows everyone in the organization to run Windows but does not allow anyone to run Registry Editor. The effect of this rule would prevent users such as help desk personnel from running a program that is necessary for their support tasks. To resolve this problem, create a second rule that applies to the Helpdesk user group: "Allow Helpdesk to run Registry Editor." If you create a deny rule that does not allow any users to run Registry Editor, the deny rule will override the second rule that allows the Helpdesk user group to run Registry Editor.
AppLocker wizards
You can create custom rules in two ways:
- The Create Rules Wizard enables you to create one rule at a time. For more information, see Create an AppLocker Rule.
- The Automatically Generate Rules Wizard allows you to select a folder, select a user or group to apply the rule to, and then create many rules at one time for that folder. This wizard automatically generates allow rules only. For more information, see Automatically Generate AppLocker Rules.
Additional considerations
- By default, AppLocker rules do not allow users to open or run any files that are not specifically allowed. Administrators should maintain an up-to-date list of allowed applications.
- There are two types of AppLocker conditions that do not persist following an update:
- File hash condition. File hash conditions can be used with any application because a cryptographic hash value of the application is generated at the time the rule is created. However, the hash value is specific to that exact version of the application. If there are several versions of the application in use within the organization, you need to create file hash conditions for each version in use and for any new versions that are released.
- A publisher condition with a specific product version set. If you create a publisher condition that uses the Exactly file condition option, the rule cannot persist if a new version of the application is installed. A new publisher condition must be created, or the rule version must be edited to be made less specific.
- File hash condition. File hash conditions can be used with any application because a cryptographic hash value of the application is generated at the time the rule is created. However, the hash value is specific to that exact version of the application. If there are several versions of the application in use within the organization, you need to create file hash conditions for each version in use and for any new versions that are released.
- If an application is not digitally signed, you cannot use a publisher condition.
- AppLocker rules cannot be used to manage computers running a Windows operating system earlier than Windows 7. Software Restriction Policies must be used instead.
- If AppLocker rules are defined in a Group Policy object (GPO), only those rules are applied. To ensure interoperability between Software Restriction Policies rules and AppLocker rules, define Software Restriction Policies rules and AppLocker rules in different GPOs.
- When an AppLocker rule is set to Audit only, the rule is not enforced. When a user runs an application that is included in the rule, the application is opened and runs normally, and information about that application is added to the AppLocker event log.
- A custom configured URL can be included in the message that is displayed when an application is blocked.
- Expect an increase in the number of help desk calls initially because of blocked applications. As users begin to understand that they cannot run applications that are not allowed, the help desk calls may decrease.
Additional references