Professional Documents
Culture Documents
AppLocker (Windows 10)
AppLocker (Windows 10)
AppLocker
Administer AppLocker
Administer AppLocker using MDM
Maintain AppLocker policies
Edit an AppLocker policy
Test and update an AppLocker policy
Deploy AppLocker policies by using the enforce rules setting
Use the AppLocker Windows PowerShell cmdlets
Use AppLocker and Software Restriction Policies in the same domain
Optimize AppLocker performance
Monitor app usage with AppLocker
Manage packaged apps with AppLocker
Working with AppLocker rules
Create a rule that uses a file hash condition
Create a rule that uses a path condition
Create a rule that uses a publisher condition
Create AppLocker default rules
Add exceptions for an AppLocker rule
Create a rule for packaged apps
Delete an AppLocker rule
Edit AppLocker rules
Enable the DLL rule collection
Enforce AppLocker rules
Run the Automatically Generate Rules wizard
Working with AppLocker policies
Configure the Application Identity service
Configure an AppLocker policy for audit only
Configure an AppLocker policy for enforce rules
Display a custom URL message when users try to run a blocked app
Export an AppLocker policy from a GPO
Export an AppLocker policy to an XML file
Import an AppLocker policy from another computer
Import an AppLocker policy into a GPO
Add rules for packaged apps to existing AppLocker rule-set
Merge AppLocker policies by using Set-ApplockerPolicy
Merge AppLocker policies manually
Refresh an AppLocker policy
Test an AppLocker policy by using Test-AppLockerPolicy
AppLocker design guide
Understand AppLocker policy design decisions
Determine your application control objectives
Create a list of apps deployed to each business group
Document your app list
Select the types of rules to create
Document your AppLocker rules
Determine the Group Policy structure and rule enforcement
Understand AppLocker enforcement settings
Understand AppLocker rules and enforcement setting inheritance in Group Policy
Document the Group Policy structure and AppLocker rule enforcement
Plan for AppLocker policy management
AppLocker deployment guide
Understand the AppLocker policy deployment process
Requirements for Deploying AppLocker Policies
Use Software Restriction Policies and AppLocker policies
Create Your AppLocker policies
Create Your AppLocker rules
Deploy the AppLocker policy into production
Use a reference device to create and maintain AppLocker policies
Determine which apps are digitally signed on a reference device
Configure the AppLocker reference device
AppLocker technical reference
What Is AppLocker?
What Is AppLocker?
Requirements to use AppLocker
AppLocker policy use scenarios
How AppLocker works
Understanding AppLocker rule behavior
Understanding AppLocker rule exceptions
Understanding AppLocker rule collections
Understanding AppLocker allow and deny actions on rules
Understanding AppLocker rule condition types
Understanding the publisher rule condition in AppLocker
Understanding the path rule condition in AppLocker
Understanding the file hash rule condition in AppLocker
Understanding AppLocker default rules
Executable rules in AppLocker
Windows Installer rules in AppLocker
Script rules in AppLocker
DLL rules in AppLocker
Packaged apps and packaged app installer rules in AppLocker
AppLocker architecture and components
AppLocker processes and interactions
AppLocker functions
Security considerations for AppLocker
Tools to Use with AppLocker
Using Event Viewer with AppLocker
AppLocker Settings
AppLocker
6/27/2018 • 7 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic provides a description of AppLocker and can help you decide if your organization can benefit from
deploying AppLocker application control policies. AppLocker helps you control which apps and files users can run.
These include executable files, scripts, Windows Installer files, dynamic-link libraries (DLLs), packaged apps, and
packaged app installers.
AppLocker can help you:
Define rules based on file attributes that persist across app updates, such as the publisher name (derived from
the digital signature), product name, file name, and file version. You can also create rules based on the file path
and hash.
Assign a rule to a security group or an individual user.
Create exceptions to rules. For example, you can create a rule that allows all users to run all Windows binaries,
except the Registry Editor (regedit.exe).
Use audit-only mode to deploy the policy and understand its impact before enforcing it.
Create rules on a staging server, test them, then export them to your production environment and import them
into a Group Policy Object.
Simplify creating and managing AppLocker rules by using Windows PowerShell.
AppLocker helps reduce administrative overhead and helps reduce the organization's cost of managing computing
resources by decreasing the number of Help Desk calls that result from users running unapproved apps.
AppLocker addresses the following app security scenarios:
Application inventory
AppLocker has the ability to enforce its policy in an audit-only mode where all app access activity is
registered in event logs. These events can be collected for further analysis. Windows PowerShell cmdlets
also help you analyze this data programmatically.
Protection against unwanted software
AppLocker has the ability to deny apps from running when you exclude them from the list of allowed apps.
When AppLocker rules are enforced in the production environment, any apps that are not included in the
allowed rules are blocked from running.
Licensing conformance
AppLocker can help you create rules that preclude unlicensed software from running and restrict licensed
software to authorized users.
Software standardization
AppLocker policies can be configured to allow only supported or approved apps to run on computers
within a business group. This permits a more uniform app deployment.
Manageability improvement
AppLocker includes a number of improvements in manageability as compared to its predecessor Software
Restriction Policies. Importing and exporting policies, automatic generation of rules from multiple files,
audit-only mode deployment, and Windows PowerShell cmdlets are a few of the improvements over
Software Restriction Policies.
System requirements
AppLocker policies can only be configured on and applied to computers that are running on the supported
versions and editions of the Windows operating system. Group Policy is required to distribute Group Policy
Objects that contain AppLocker policies. For more info, see Requirements to Use AppLocker.
AppLocker rules can be created on domain controllers.
Installing AppLocker
AppLocker is included with enterprise-level editions of Windows. You can author AppLocker rules for a single
computer or for a group of computers. For a single computer, you can author the rules by using the Local Security
Policy editor (secpol.msc). For a group of computers, you can author the rules within a Group Policy Object by
using the Group Policy Management Console (GPMC ).
Note: The GPMC is available in client computers running Windows only by installing the Remote Server
Administration Tools. On computer running Windows Server, you must install the Group Policy Management
feature.
Minimum privileges required Administrator on the local computer; Domain Admin, or any
set of rights that allow you to create, edit and distribute
Group Policy Objects.
In this section
TOPIC DESCRIPTION
AppLocker design guide This topic for the IT professional introduces the design and
planning steps required to deploy application control policies
by using AppLocker.
AppLocker deployment guide This topic for IT professionals introduces the concepts and
describes the steps required to deploy AppLocker policies.
AppLocker technical reference This overview topic for IT professionals provides links to the
topics in the technical reference.
Administer AppLocker
9/5/2018 • 3 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for IT professionals provides links to specific procedures to use when administering AppLocker
policies.
AppLocker helps administrators control how users can access and use files, such as executable files, packaged
apps, scripts, Windows Installer files, and DLLs. Using AppLocker, you can:
Define rules based on file attributes derived from the digital signature, including the publisher, product name,
file name, and file version. For example, you can create rules based on the publisher attribute that is persistent
through updates, or you can create rules for a specific version of a file.
Assign a rule to a security group or an individual user.
Create exceptions to rules. For example, you can create a rule that allows all Windows processes to run, except
Registry Editor (regedit.exe).
Use audit-only mode to deploy the policy and understand its impact before enforcing it.
Import and export rules. The import and export affects the entire policy. For example, if you export a policy, all
of the rules from all of the rule collections are exported, including the enforcement settings for the rule
collections. If you import a policy, the existing policy is overwritten.
Simplify creating and managing AppLocker rules by using AppLocker PowerShell cmdlets. > Note For more
info about enhanced capabilities of AppLocker to control Windows apps, see Packaged apps and packaged
app installer rules in AppLocker.
In this section
TOPIC DESCRIPTION
Administer AppLocker using Mobile Device Management This topic describes how to used MDM to manage AppLocker
(MDM) policies.
Maintain AppLocker policies This topic describes how to maintain rules within AppLocker
policies.
Edit an AppLocker policy This topic for IT professionals describes the steps required to
modify an AppLocker policy.
Test and update an AppLocker policy This topic discusses the steps required to test an AppLocker
policy prior to deployment.
Deploy AppLocker policies by using the enforce rules setting This topic for IT professionals describes the steps to deploy
AppLocker policies by using the enforcement setting method.
Use the AppLocker Windows PowerShell cmdlets This topic for IT professionals describes how each AppLocker
Windows PowerShell cmdlet can help you administer your
AppLocker application control policies.
TOPIC DESCRIPTION
Use AppLocker and Software Restriction Policies in the same This topic for IT professionals describes concepts and
domain procedures to help you manage your application control
strategy using Software Restriction Policies and AppLocker.
Optimize AppLocker performance This topic for IT professionals describes how to optimize
AppLocker policy enforcement.
Monitor app usage with AppLocker This topic for IT professionals describes how to monitor app
usage when AppLocker policies are applied.
Manage packaged apps with AppLocker This topic for IT professionals describes concepts and lists
procedures to help you manage Packaged apps with
AppLocker as part of your overall application control strategy.
Working with AppLocker rules This topic for IT professionals describes AppLocker rule types
and how to work with them for your application control
policies.
Working with AppLocker policies This topic for IT professionals provides links to procedural
topics about creating, maintaining, and testing AppLocker
policies.
Applies to
Windows 10
Windows Server
Maintain AppLocker policies
9/5/2018 • 4 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic describes how to maintain rules within AppLocker policies.
Common AppLocker maintenance scenarios include:
A new app is deployed, and you need to update an AppLocker policy.
A new version of an app is deployed, and you need to either update an AppLocker policy or create a new rule to
update the policy.
An app is no longer supported by your organization, so you need to prevent it from being used.
An app appears to be blocked but should be allowed.
An app appears to be allowed but should be blocked.
A single user or small subset of users needs to use a specific app that is blocked.
There are three methods you can use to maintain AppLocker policies:
Maintaining AppLocker policies by using Mobile Device Management (MDM )
Maintaining AppLocker policies by using Group Policy
Maintaining AppLocker policies on the local computer
Caution: You should not edit an AppLocker rule collection while it is being enforced in Group Policy. Because
AppLocker controls what files are allowed to run, making changes to a live policy can create unexpected
behavior.
Applies to
Windows 10
Windows Server
This topic for IT professionals describes the steps required to modify an AppLocker policy.
You can edit an AppLocker policy by adding, changing, or removing rules. However, you cannot create a new
version of the policy by importing additional rules. To modify an AppLocker policy that is in production, you
should use Group Policy management software that allows you to version Group Policy Objects (GPOs). If you
have created multiple AppLocker policies and need to merge them to create one AppLocker policy, you can either
manually merge the policies or use the Windows PowerShell cmdlets for AppLocker. You cannot automatically
merge policies by using the AppLocker snap-in. You must create one rule collection from two or more policies.
The AppLocker policy is saved in XML format, and the exported policy can be edited with any text or XML editor.
For info about merging policies, see Merge AppLocker policies manually or Merge AppLocker policies by using
Set-ApplockerPolicy.
There are three methods you can use to edit an AppLocker policy:
Editing an AppLocker policy by using Mobile Device Management (MDM )
Editing an AppLocker policy by using Group Policy
Editing an AppLocker policy by using the Local Security Policy snap-in
Caution: Importing a policy onto another PC will overwrite the existing policy on that PC.
Caution: You should never edit an AppLocker rule collection while it is being enforced in Group Policy.
Because AppLocker controls what files are allowed run, making changes to a live policy can create unexpected
behavior. For info about testing policies, see Test and update an AppLocker policy.
Note: If you are performing these steps by using Microsoft Advanced Group Policy Management (AGPM ),
check out the GPO before exporting the policy.
Caution: Importing a policy onto another PC will overwrite the existing policy on that PC.
Additional resources
For steps to perform other AppLocker policy tasks, see Administer AppLocker.
Test and update an AppLocker policy
9/5/2018 • 3 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic discusses the steps required to test an AppLocker policy prior to deployment.
You should test each set of rules to ensure that the rules perform as intended. If you use Group Policy to manage
AppLocker policies, complete the following steps for each Group Policy Object (GPO ) where you have created
AppLocker rules. Because AppLocker rules are inherited from linked GPOs, you should deploy all of the rules for
simultaneous testing in all of your test GPOs.
Additional resources
For steps to perform other AppLocker policy tasks, see Administer AppLocker.
Deploy AppLocker policies by using the enforce rules
setting
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for IT professionals describes the steps to deploy AppLocker policies by using the enforcement setting
method.
Caution: You should not edit an AppLocker rule collection while it is being enforced in Group Policy. Because
AppLocker controls what files are allowed to run, making changes to a live policy can create unexpected
behavior.
For the procedure to update the GPO, see Import an AppLocker policy into a GPO.
For the procedures to distribute policies for local PCs by using the Local Security Policy snap-in (secpol.msc), see
Export an AppLocker policy to an XML file and Import an AppLocker policy from another computer.
Additional resources
For steps to perform other AppLocker policy tasks, see Administer AppLocker.
Use the AppLocker Windows PowerShell cmdlets
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for IT professionals describes how each AppLocker Windows PowerShell cmdlet can help you
administer your AppLocker application control policies.
Additional resources
For steps to perform other AppLocker policy tasks, see Administer AppLocker.
Use AppLocker and Software Restriction Policies in
the same domain
9/5/2018 • 4 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for IT professionals describes concepts and procedures to help you manage your application control
strategy using Software Restriction Policies and AppLocker.
Scope SRP policies can be applied to all AppLocker policies apply only to
Windows operating systems Windows Server 2008 R2, Windows
beginning with Windows XP and 7, and later.
Windows Server 2003.
Policy creation SRP policies are maintained through AppLocker policies are maintained
Group Policy and only the through Group Policy and only the
administrator of the GPO can administrator of the GPO can
update the SRP policy. The update the policy. The
administrator on the local computer administrator on the local
can modify the SRP policies defined computer can modify the
in the local GPO. AppLocker policies defined in the
local GPO.
AppLocker permits customization
of error messages to direct users to
a Web page for help.
Policy maintenance SRP policies must be updated by AppLocker policies can be updated
using the Local Security Policy by using the Local Security Policy
snap-in (if the policies are created snap-in (if the policies are created
locally) or the Group Policy locally), or the GPMC, or the
Management Console (GPMC). Windows PowerShell AppLocker
cmdlets.
APPLICATION CONTROL FUNCTION SRP APPLOCKER
Policy application SRP policies are distributed through AppLocker policies are distributed
Group Policy. through Group Policy.
Enforcement mode SRP works in the “deny list mode” AppLocker by default works in the
where administrators can create “allow list mode” where only those
rules for files that they do not want files are allowed to run for which
to allow in this Enterprise whereas there is a matching allow rule.
the rest of the file are allowed to
run by default.
SRP can also be configured in the
“allow list mode” so that by default
all files are blocked and
administrators need to create allow
rules for files that they want to
allow.
File types that can be controlled SRP can control the following file AppLocker can control the
types: following file types:
Executables Executables
Dlls Dlls
Scripts Scripts
Windows Installers Windows Installers
SRP cannot control each file type Packaged apps and
separately. All SRP rules are in a installers
single rule collection.
AppLocker maintains a separate
rule collection for each of the five
file types.
Designated file types SRP supports an extensible list of AppLocker currently supports the
file types that are considered following file extensions:
executable. Administrators can add
extensions for files that should be Executables (.exe, .com)
considered executable. Dlls (.ocx, .dll)
Scripts (.vbs, .js, .ps1, .cmd,
.bat)
Windows Installers (.msi,
.mst, .msp)
Packaged app installers
(.appx)
Rule types SRP supports four types of rules: AppLocker supports three types of
rules:
Hash
File hash
Path
Path
Signature
Publisher
Internet zone
APPLICATION CONTROL FUNCTION SRP APPLOCKER
Editing the hash value In Windows XP, you could use SRP AppLocker computes the hash
to provide custom hash values. value itself. Internally, it uses the
SHA2 Authenticode hash for
Beginning with Windows 7 and Portable Executables (exe and dll)
Windows Server 2008 R2, you can and Windows Installers and a SHA2
only select the file to hash, not flat file hash for the rest.
provide the hash value.
Support for different security levels With SRP, you can specify the AppLocker does not support
permissions with which an app can security levels.
run. So, you can configure a rule
such that Notepad always runs with
restricted permissions and never
with administrative privileges.
SRP on Windows Vista and earlier
supported multiple security levels.
On Windows 7, that list was
restricted to just two levels:
Disallowed and Unrestricted (Basic
User translates to Disallowed).
Manage Packaged apps and Not supported .appx is a valid file type which
Packaged app installers. AppLocker can manage.
Targeting a rule to a user or a SRP rules apply to all users on a AppLocker rules can be targeted to
group of users particular computer. a specific user or a group of users.
Support for rule exceptions SRP does not support rule AppLocker rules can have
exceptions. exceptions which allow you to
create rules such as “Allow
everything from Windows except
for regedit.exe”.
Support for audit mode SRP does not support audit mode. AppLocker supports audit mode
The only way to test SRP policies is which allows you to test the effect
to set up a test environment and of their policy in the real production
run a few experiments. environment without impacting the
user experience. Once you are
satisfied with the results, you can
start enforcing the policy.
Support for exporting and SRP does not support policy AppLocker supports the importing
importing policies import/export. and exporting of policies. This
allows you to create AppLocker
policy on a sample device, test it
out and then export that policy and
import it back into the desired
GPO.
APPLICATION CONTROL FUNCTION SRP APPLOCKER
Rule enforcement Internally, SRP rules enforcement Internally, AppLocker rules for .exe
happens in the user-mode which is and .dll files are enforced in the
less secure. kernel-mode which is more secure
than enforcing them in the user-
mode.
Optimize AppLocker performance
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for IT professionals describes how to optimize AppLocker policy enforcement.
Applies to
Windows 10
Windows Server
This topic for IT professionals describes how to monitor app usage when AppLocker policies are applied.
Once you set rules and deploy the AppLocker policies, it is good practice to determine if the policy
implementation is what you expected.
Discover the effect of an AppLocker policy
You can evaluate how the AppLocker policy is currently implemented for documentation or audit purposes, or
before you modify the policy. Updating your AppLocker Policy Deployment Planning document will help you
track your findings. You can perform one or more of the following steps to understand what application controls
are currently enforced through AppLocker rules.
Analyze the AppLocker logs in Event Viewer
When AppLocker policy enforcement is set to Enforce rules, rules are enforced for the rule collection and
all events are audited. When AppLocker policy enforcement is set to Audit only, rules are not enforced
but are still evaluated to generate audit event data that is written to the AppLocker logs.
For the procedure to access the log, see View the AppLocker Log in Event Viewer.
Enable the Audit only AppLocker enforcement setting
By using the Audit only enforcement setting, you can ensure that the AppLocker rules are properly
configured for your organization. When AppLocker policy enforcement is set to Audit only, rules are
only evaluated but all events generated from that evaluation are written to the AppLocker log.
For the procedure to do this, see Configure an AppLocker policy for audit only.
Review AppLocker events with Get-AppLockerFileInformation
For both event subscriptions and local events, you can use the Get-AppLockerFileInformation
Windows PowerShell cmdlet to determine which files have been blocked or would have been blocked (if
you are using the audit-only enforcement mode) and how many times the event has occurred for each
file.
For the procedure to do this, see Review AppLocker Events with Get-AppLockerFileInformation.
Review AppLocker events with Test-AppLockerPolicy
You can use the Test-AppLockerPolicy Windows PowerShell cmdlet to determine whether any of the
rules in your rule collections will be blocked on your reference device or the device on which you maintain
policies.
For the procedure to do this, see Test an AppLocker policy by using Test-AppLockerPolicy.
Review AppLocker events with Get-AppLockerFileInformation
For both event subscriptions and local events, you can use the Get-AppLockerFileInformation Windows
PowerShell cmdlet to determine which files have been blocked or would have been blocked (if the Audit only
enforcement setting is applied) and how many times the event has occurred for each file.
Membership in the local Administrators group, or equivalent, is the minimum required to complete this
procedure.
Note: If the AppLocker logs are not on your local device, you will need permission to view the logs. If the
output is saved to a file, you will need permission to read that file.
3. Run the following command to review how many times a file has been allowed to run or prevented from
running:
Get-AppLockerFileInformation –EventLog –EventType Allowed –Statistics
Related topics
AppLocker
Manage packaged apps with AppLocker
9/5/2018 • 5 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for IT professionals describes concepts and lists procedures to help you manage Packaged apps with
AppLocker as part of your overall application control strategy.
Note: AppLocker supports only publisher rules for packaged apps. All packaged apps must be signed by the
software publisher because Windows does not support unsigned packaged apps.
Typically, an app consists of multiple components: the installer that is used to install the app, and one or more exes,
dlls, or scripts. With classic Windows apps, not all these components always share common attributes such as the
software’s publisher name, product name, and product version. Therefore, AppLocker controls each of these
components separately through different rule collections, such as exe, dll, script, and Windows Installer rules. In
contrast, all the components of a packaged app share the same publisher name, package name, and package
version attributes. Therefore, you can control an entire app with a single rule.
Comparing classic Windows apps and packaged apps
AppLocker policies for packaged apps can only be applied to apps installed on computers running at least
Windows Server 2012 or Windows 8, but classic Windows apps can be controlled on devices running at least
Windows Server 2008 R2 or Windows 7. The rules for classic Windows apps and packaged apps can be enforced
in tandem. The differences between packaged apps and classic Windows apps that you should consider include:
Installing the apps All packaged apps can be installed by a standard user, whereas a number of classic
Windows apps require administrative privileges to install. In an environment where most of the users are
standard users, you might not have numerous exe rules (because classic Windows apps require administrative
privileges to install), but you might want to have more explicit policies for packaged apps.
Changing the system state Classic Windows apps can be written to change the system state if they are run
with administrative privileges. Most packaged apps cannot change the system state because they run with
limited privileges. When you design your AppLocker policies, it is important to understand whether an app that
you are allowing can make system-wide changes.
Acquiring the apps Packaged apps can be acquired through the Store, or by loading using Windows
PowerShell cmdlets (which requires a special enterprise license). Classic Windows apps can be acquired
through traditional means.
AppLocker uses different rule collections to control packaged apps and classic Windows apps. You have the choice
to control one type, the other type, or both.
For info about controlling classic Windows apps, see Administer AppLocker.
For more info about packaged apps, see Packaged apps and packaged app installer rules in AppLocker.
Note: Not all packaged apps are listed in AppLocker’s application inventory wizard. Certain app packages are
framework packages that are leveraged by other apps. By themselves, these packages cannot do anything, but
blocking such packages can inadvertently cause failure for apps that you want to allow. Instead, you can create
Allow or Deny rules for the packaged apps that use these framework packages. The AppLocker user interface
deliberately filters out all the packages that are registered as framework packages. For info about how to create
an inventory list, see Create list of apps deployed to each business group.
For info about how to use the Get-AppxPackage Windows PowerShell cmdlet, see the AppLocker PowerShell
Command Reference.
For info about creating rules for Packaged apps, see Create a rule for packaged apps.
Consider the following info when you are designing and deploying apps:
Because AppLocker supports only publisher rules for packaged apps, collecting the installation path
information for packaged apps is not necessary.
You cannot create hash- or path-based rules for packaged apps because all packaged apps and packaged app
installers are signed by the software publisher of the package. Classic Windows apps were not always
consistently signed; therefore, AppLocker has to support hash- or path-based rules.
By default, if there are no rules in a particular rule collection, AppLocker allows every file that is included in
that rule collection. For example, if there are no Windows Installer rules, AppLocker allows all .msi, .msp,
and .mst files to run. An existing AppLocker policy that was targeted at computers running Windows Server
2008 R2 and Windows 7 would not have rules for Packaged apps. Therefore, when a computer running at
least Windows Server 2012 or Windows 8 joins a domain where an AppLocker policy is already configured,
users would be allowed to run any packaged app. This might be contrary to your design.
To prevent all packaged apps from running on a newly domain-joined computer, by default AppLocker
blocks all packaged apps on a computer running at least Windows Server 2012 or Windows 8 if the existing
domain policy has rules configured in the exe rule collection. You must take explicit action to allow packaged
apps in your enterprise. You can allow only a select set of packaged apps. Or if you want to allow all
packaged apps, you can create a default rule for the packaged apps collection.
Applies to
Windows 10
Windows Server
This topic for IT professionals describes AppLocker rule types and how to work with them for your application
control policies.
In this section
TOPIC DESCRIPTION
Create a rule that uses a file hash condition This topic for IT professionals shows how to create an
AppLocker rule with a file hash condition.
Create a rule that uses a path condition This topic for IT professionals shows how to create an
AppLocker rule with a path condition.
Create a rule that uses a publisher condition This topic for IT professionals shows how to create an
AppLocker rule with a publisher condition.
Create AppLocker default rules This topic for IT professionals describes the steps to create a
standard set of AppLocker rules that will allow Windows
system files to run.
Add exceptions for an AppLocker rule This topic for IT professionals describes the steps to specify
which apps can or cannot run as exceptions to an AppLocker
rule.
Create a rule for packaged apps This topic for IT professionals shows how to create an
AppLocker rule for packaged apps with a publisher condition.
Delete an AppLocker rule This topic for IT professionals describes the steps to delete an
AppLocker rule.
Edit AppLocker rules This topic for IT professionals describes the steps to edit a
publisher rule, path rule, and file hash rule in AppLocker.
Enable the DLL rule collection This topic for IT professionals describes the steps to enable
the DLL rule collection feature for AppLocker.
Enforce AppLocker rules This topic for IT professionals describes how to enforce
application control rules by using AppLocker.
Run the Automatically Generate Rules wizard This topic for IT professionals describes steps to run the
wizard to create AppLocker rules on a reference device.
The three AppLocker enforcement modes are described in the following table. The enforcement mode setting
defined here can be overwritten by the setting derived from a linked Group Policy Object (GPO ) with a higher
precedence.
Not configured This is the default setting which means that the rules defined
here will be enforced unless a linked GPO with a higher
precedence has a different value for this setting.
Audit only Rules are audited but not enforced. When a user runs an app
that is affected by an AppLocker rule, the app is allowed to
run and the info about the app is added to the AppLocker
event log. The Audit-only enforcement mode helps you
determine which apps will be affected by the policy before the
policy is enforced. When the AppLocker policy for a rule
collection is set to Audit only, rules for that rule collection are
not enforced
When AppLocker policies from various GPOs are merged, the rules from all the GPOs are merged and the
enforcement mode setting of the winning GPO is applied.
Rule collections
The AppLocker console is organized into rule collections, which are executable files, scripts, Windows Installer files,
packaged apps and packaged app installers, and DLL files. These collections give you an easy way to differentiate
the rules for different types of apps. The following table lists the file formats that are included in each rule
collection.
Scripts .ps1
.bat
.cmd
.vbs
.js
Important: If you use DLL rules, you need to create an allow rule for each DLL that is used by all of the
allowed apps.
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.
The DLL rule collection is not enabled by default. To learn how to enable the DLL rule collection, see DLL rule
collections.
EXE rules apply to portable executable (PE ) files. AppLocker checks whether a file is a valid PE file, rather than just
applying rules based on file extension, which attackers can easily change. Regardless of the file extension, the
AppLocker EXE rule collection will work on a file as long as it is a valid PE file.
Rule conditions
Rule conditions are criteria that help AppLocker identify the apps to which the rule applies. The three primary rule
conditions are publisher, path, and file hash.
Publisher: Identifies an app based on its digital signature
Path: Identifies an app by its location in the file system of the computer or on the network
File hash: Represents the system computed cryptographic hash of the identified file
Publisher
This condition identifies an app based on its digital signature and extended attributes when available. The digital
signature contains info about the company that created the app (the publisher). Executable files, dlls, Windows
installers, packaged apps and packaged app installers also have extended attributes, which are obtained from the
binary resource. In case of executable files, dlls and Windows installers, these attributes contain the name of the
product that the file is a part of, the original name of the file as supplied by the publisher, and the version number
of the file. In case of packaged apps and packaged app installers, these extended attributes contain the name and
the version of the app package.
Note: Rules created in the packaged apps and packaged app installers rule collection can only have publisher
conditions since Windows does not support unsigned packaged apps and packaged app installers.
Note: Use a publisher rule condition when possible because they can survive app updates as well as a change
in the location of files.
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 up or by using a
wildcard character (*) in the product, file name, or version number fields.
Note: To enter custom values for any of the fields of a publisher rule condition 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.
The File version and Package version control whether a user can run a specific version, earlier versions, or later
versions of the app. You can choose a version number and then configure the following options:
Exactly. The rule applies only to this version of the app
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.
All signed files All files that are signed by any 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.
OPTION THE PUBLISHER CONDITION ALLOWS OR DENIES…
Publisher and product name, and file name Any version of the named file or package 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 or package 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 or package and any
earlier versions for the product that are signed by the
publisher.
Custom You can edit the Publisher, Product name, File name,
Version Package name, and Package version fields to
create a custom rule.
Path
This rule condition identifies an application by its location in the file system of the computer or on the network.
AppLocker uses custom path variables for well-known paths, such as Program Files and Windows.
The following table details these path variables.
Important: Because a path rule 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 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 you choose the file hash rule condition, the system computes a cryptographic hash of the identified file. The
advantage of this rule condition is that because each file has a unique hash, a file hash rule condition applies to
only one file. The disadvantage is that each time the file is updated (such as a security update or upgrade) the file's
hash will change. As a result, you must manually update file hash rules.
Important: For a best practice, use allow actions with exceptions. You can use a combination of allow and
deny actions but understand that deny actions override allow actions in all cases, and can be circumvented.
Important: If you join a computer running at least Windows Server 2012 or Windows 8 to a domain that
already enforces AppLocker rules for executable files, users will not be able to run any packaged apps unless
you also create rules for packaged apps. If you want to allow any packaged apps in your environment while
continuing to control executable files, you should create the default rules for packaged apps and set the
enforcement mode to Audit-only for the packaged apps rule collection.
Rule exceptions
You can apply AppLocker rules to individual users or to 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 app, 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 the Windows operating system, but it 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 Help Desk user group:
"Allow Help Desk 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 Help Desk user group to run Registry Editor.
Important: Before you enforce DLL rules, make sure that there are allow rules for each DLL that is
used by any of the allowed apps.
AppLocker wizards
You can create rules by using two AppLocker wizards:
1. The Create Rules Wizard enables you to create one rule at a time.
2. The Automatically Generate Rules Wizard allows you to create multiple rules at one time. You can either select
a folder and let the wizard create rules for the relevant files within that folder or in case of packaged apps let the
wizard create rules for all packaged apps installed on the computer. You can also specify the user or group to
which to apply the rules. This wizard automatically generates allow rules only.
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 of an app:
A file hash condition File hash rule conditions can be used with any app because a cryptographic
hash value of the app is generated at the time the rule is created. However, the hash value is specific
to that exact version of the app. 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 rule
condition that uses the Exactly version option, the rule cannot persist if a new version of the app is
installed. A new publisher condition must be created, or the version must be edited in the rule to be
made less specific.
If an app is not digitally signed, you cannot use a publisher rule condition for that app.
AppLocker rules cannot be used to manage computers running a Windows operating system earlier than
Windows Server 2008 R2 or 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.
The packaged apps and packaged apps installer rule collection is available on devices running at least Windows
Server 2012 and Windows 8.
When the rules for the executable rule collection are enforced and the packaged apps and packaged app
installers rule collection does not contain any rules, no packaged apps and packaged app installers are allowed
to run. In order to allow any packaged apps and packaged app installers, you must create rules for the
packaged apps and packaged app installers rule collection.
When an AppLocker rule collection is set to Audit only, the rules are not enforced. When a user runs an
application that is included in the rule, the app is opened and runs normally, and information about that app is
added to the AppLocker event log.
A custom configured URL can be included in the message that is displayed when an app is blocked.
Expect an increase in the number of Help Desk calls initially because of blocked apps until users understand
that they cannot run apps that are not allowed.
Create a rule that uses a file hash condition
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for IT professionals shows how to create an AppLocker rule with a file hash condition.
File hash rules use a system-computed cryptographic hash of the identified file.
For info about the file hash condition, see Understanding the File Hash Rule Condition in AppLocker.
You can perform this task by using the Group Policy Management Console for an AppLocker policy in a Group
Policy Object (GPO ) or by using the Local Security Policy snap-in for an AppLocker policy on a local computer or
in a security template. For info how to use these MMC snap-ins to administer AppLocker, see Administer
AppLocker.
To create a new rule with a file hash condition
1. Open the AppLocker console, and then click the rule collection that you want to create the rule for.
2. On the Action menu, click Create New Rule.
3. On the Before You Begin page, click Next.
4. On the Permissions page, select the action (allow or deny) and the user or group that the rule should apply to,
and then click Next.
5. On the Conditions page, select the File hash rule condition, and then click Next.
6. Browse Files to locate the targeted application file.
Note: You can also click Browse Folders which calculates the hash for all the appropriate files relative
to the rule collection. To remove hashes individually, click the Remove button.
7. Click Next.
8. On the Name page, either accept the automatically generated rule name or type a new rule name, and then
click Create.
Create a rule that uses a path condition
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for IT professionals shows how to create an AppLocker rule with a path condition.
The path condition identifies an app by its location in the file system of the computer or on the network.
Important: When creating a rule that uses a deny action, path conditions are less secure for preventing
access to a file because a user could easily copy the file to a different location than what is specified in the rule.
Because path rules correspond to locations within the file system, you should ensure that there are no
subdirectories that are writable by non-administrators. For example, if you create a path rule for C:\ with the
allow action, any file within C:\ will be allowed to run, including users' profiles.
For info about the path condition, see Understanding the path rule condition in AppLocker.
You can perform this task by using the Group Policy Management Console for an AppLocker policy in a Group
Policy Object (GPO ) or by using the Local Security Policy snap-in for an AppLocker policy on a local computer or
in a security template. For information how to use these MMC snap-ins to administer AppLocker, see Administer
AppLocker.
To create a new rule with a path condition
1. Open the AppLocker console, and then click the rule collection that you want to create the rule for.
2. On the Action menu, click Create New Rule.
3. On the Before You Begin page, click Next.
4. On the Permissions page, select the action (allow or deny) and the user or group that the rule should apply to,
and then click Next.
5. On the Conditions page, select the Path rule condition, and then click Next.
6. Click Browse Files to locate the targeted folder for the app.
Note: When you browse to a file or folder location, the wizard automatically converts absolute file
paths to use AppLocker path variables. You may edit the path after browsing to specify an absolute
path, or you may type the path directly into the Path box. To learn more about AppLocker path
variables, see Understanding the path rule condition in AppLocker.
7. Click Next.
8. (Optional) On the Exceptions page, specify conditions by which to exclude files from being affected by the
rule. Click Next.
9. On the Name page, either accept the automatically generated rule name or type a new rule name, and then
click Create.
Create a rule that uses a publisher condition
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for IT professionals shows how to create an AppLocker rule with a publisher condition.
You can use publisher conditions only for files that are digitally signed; the publisher condition identifies an app
based on its digital signature and extended attributes. The digital signature contains information about the
company that created the app (the publisher). The extended attributes, which are obtained from the binary
resource, contain the name of the product that the file 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. Packaged app rules are by definition rules that use publisher conditions. For info about
creating a packaged app rule, see Create a rule for packaged apps.
For info about the publisher condition, see Understanding the publisher rule condition in AppLocker.
You can perform this task by using the Group Policy Management Console for an AppLocker policy in a Group
Policy Object (GPO ) or by using the Local Security Policy snap-in for an AppLocker policy on a local computer or
in a security template. For info how to use these MMC snap-ins to administer AppLocker, see Administer
AppLocker.
To create a new rule with a publisher condition
1. Open the AppLocker console, and then click the rule collection that you want to create the rule for.
2. On the Action menu, click Create New Rule.
3. On the Before You Begin page, click Next.
4. On the Permissions page, select the action (allow or deny) and the user or group that the rule should apply to,
and then click Next.
5. On the Conditions page, select the Publisher rule condition, and then click Next.
6. On the Publisher page, click Browse to select a signed file, and then use the slider to specify the scope of the
rule. To use custom values in any of the fields or to specify a specific file version, select the Use custom values
check box. For example, you can use the asterisk (*) wildcard character within a publisher rule to specify that
any value should be matched.
7. Click Next.
8. (Optional) On the Exceptions page, specify conditions by which to exclude files from being affected by the
rule. Click Next.
9. On the Name page, either accept the automatically generated rule name or type a new rule name, and then
click Create.
Create AppLocker default rules
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for IT professionals describes the steps to create a standard set of AppLocker rules that will allow
Windows system files to run.
AppLocker includes default rules for each rule collection. These rules are intended to help ensure that the files that
are required for Windows to operate properly are allowed to run.
Important: You can use the default rules as a template when creating your own rules to allow files within the
Windows folders to run. However, these rules are only meant to function as a starter policy when you are first
testing AppLocker rules. The default rules can be modified in the same way as other AppLocker rule types.
You can perform this task by using the Group Policy Management Console for an AppLocker policy in a Group
Policy Object (GPO ) or by using the Local Security Policy snap-in for an AppLocker policy on a local computer or
in a security template. For information how to use these MMC snap-ins to administer AppLocker, see Administer
AppLocker.
To create default rules
1. Open the AppLocker console.
2. Right-click the appropriate rule type for which you want to automatically generate default rules. You can
automatically generate rules for executable, Windows Installer, script rules and Packaged app rules.
3. Click Create Default Rules.
Related topics
Understanding AppLocker default rules
Add exceptions for an AppLocker rule
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for IT professionals describes the steps to specify which apps can or cannot run as exceptions to an
AppLocker rule.
Rule exceptions allow you to specify files or folders to exclude from the rule. For more information about
exceptions, see Understanding AppLocker rule exceptions.
You can perform this task by using the Group Policy Management Console for an AppLocker policy in a Group
Policy Object (GPO ) or by using the Local Security Policy snap-in for an AppLocker policy on a local computer or
in a security template. For info how to use these MMC snap-ins to administer AppLocker, see Administer
AppLocker.
To configure exceptions for a rule
1. Open the AppLocker console.
2. Expand the rule collection, right-click the rule that you want to configure exceptions for, and then click
Properties.
3. Click the Exceptions tab.
4. In the Add exception box, select the rule type that you want to create, and then click Add.
For a publisher exception, click Browse, select the file that contains the publisher to exclude, and then
click OK.
For a path exception, choose the file or folder path to exclude, and then click OK.
For a file hash exception, edit the file hash rule, and click Remove.
For a packaged apps exception, click Add to create the exceptions based on reference app and rule
scope.
Create a rule for packaged apps
9/5/2018 • 4 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for IT professionals shows how to create an AppLocker rule for packaged apps with a publisher
condition.
Packaged apps, also known as Universal Windows apps, are based on an app model that ensures that all the files
within an app package share the same identity. Therefore, it is possible to control the entire app using a single
AppLocker rule as opposed to the non-packaged apps where each file within the app could have a unique identity.
Windows does not support unsigned packaged apps which implies all packaged apps must be signed. AppLocker
supports only publisher rules for packaged apps. A publisher rule for a packaged app is based on the following
information:
Publisher of the package
Package name
Package version
All the files within a package as well as the package installer share these attributes. Therefore, an AppLocker rule
for a packaged app controls both the installation as well as the running of the app. Otherwise, the publisher rules
for packaged apps are no different than the rest of the rule collections; they support exceptions, can be increased
or decreased in scope, and can be assigned to users and groups.
For info about the publisher condition, see Understanding the publisher rule condition in AppLocker.
You can perform this task by using the Group Policy Management Console for an AppLocker policy in a Group
Policy Object (GPO ) or by using the Local Security Policy snap-in for an AppLocker policy on a local computer or
in a security template. For info how to use these MMC snap-ins to administer AppLocker, see Administer
AppLocker.
To create a packaged app rule
1. Open the AppLocker console.
2. On the Action menu, or by right-clicking on Packaged app Rules, click Create New Rule.
3. On the Before You Begin page, click Next.
4. On the Permissions page, select the action (allow or deny) and the user or group that the rule should apply to,
and then click Next.
5. On the Publisher page, you can select a specific reference for the packaged app rule and set the scope for
the rule. The following table describes the reference options.
Use an installed packaged If selected, AppLocker requires You want the Sales group only to
app as a reference you to choose an app that is use the app named
already installed on which to Microsoft.BingMaps for its
base your new rule. AppLocker outside sales calls. The
uses the publisher, package Microsoft.BingMaps app is
name and package version to already installed on the device
define the rule. where you are creating the rule,
so you choose this option, and
select the app from the list of
apps installed on the computer
and create the rule using this
app as a reference.
Use a packaged app installer If selected, AppLocker requires Your company has developed a
as a reference you to choose an app installer number of internal line-of-
on which to base your new rule. business packaged apps. The app
A packaged app installer has the installers are stored on a
.appx extension. AppLocker uses common file share. Employees
the publisher, package name and can install the required apps
package version of the installer from that file share. You want to
to define the rule. allow all your employees to
install the Payroll app from this
share. So you choose this option
from the wizard, browse to the
file share and choose the installer
for the Payroll app as a reference
to create your rule.
The following table describes setting the scope for the packaged app rule.
Applies to Any publisher This is the least restrictive scope You want the Sales group to use
condition for an Allow rule. It any packaged app from any
permits every packaged app to signed publisher. You set the
run or install. permissions to allow the Sales
group to be able to run any app.
Conversely, if this is a Deny rule,
then this option is the most
restrictive because it denies all
apps from installing or running.
Applies to a specific Publisher This scopes the rule to all apps You want to allow all your users
published by a particular to install apps published by the
publisher. publisher of Microsoft.BingMaps.
You could select
Microsoft.BingMaps as a
reference and choose this rule
scope.
SELECTION DESCRIPTION EXAMPLE
Applies to a Package name This scopes the rule to all You want to allow your Sales
packages that share the group to install any version of
publisher name and package the Microsoft.BingMaps app. You
name as the reference file. could select the
Microsoft.BingMaps app as a
reference and choose this rule
scope.
Applies to a Package version This scopes the rule to a You want to be very selective in
particular version of the package. what you allow. You do not want
to implicitly trust all future
updates of the
Microsoft.BingMaps app. You
can limit the scope of your rule
to the version of the app
currently installed on your
reference computer.
Applying custom values to the Selecting the Use custom You want to allow users to install
rule values check box allows you to all Microsoft.Bing* applications
adjust the scope fields for your which include
particular circumstance. Microsoft.BingMaps,
Microsoft.BingWeather,
Microsoft.BingMoney. You can
choose the Microsoft.BingMaps
as a reference, select the Use
custom values check box and
edit the package name field by
adding “Microsoft.Bing*” as the
Package name.
6. Click Next.
7. (Optional) On the Exceptions page, specify conditions by which to exclude files from being affected by the
rule. This allows you to add exceptions based on the same rule reference and rule scope as you set before. Click
Next.
8. On the Name page, either accept the automatically generated rule name or type a new rule name, and then
click Create.
Delete an AppLocker rule
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for IT professionals describes the steps to delete an AppLocker rule.
As older apps are retired and new apps are deployed in your organization, it will be necessary to modify the
application control policies. If an app becomes unsupported by the IT department or is no longer allowed due to
the organization's security policy, then deleting the rule or rules associated with that app will prevent the app from
running.
For info about testing an AppLocker policy to see what rules affect which files or applications, see Test an
AppLocker policy by Using Test-AppLockerPolicy.
You can perform this task by using the Group Policy Management Console for an AppLocker policy in a Group
Policy Object (GPO ) or by using the Local Security Policy snap-in for an AppLocker policy on a local computer or
in a security template. For info how to use these MMC snap-ins to administer AppLocker, see Administer
AppLocker.
These steps apply only for locally managed devices. If the device has AppLocker policies applied by using MDM
or a GPO, the local policy will not override those settings.
To delete a rule in an AppLocker policy
1. Open the AppLocker console.
2. Click the appropriate rule collection for which you want to delete the rule.
3. In the details pane, right-click the rule to delete, click Delete, and then click Yes.
Note: When using Group Policy, for the rule deletion to take effect on computers within the domain, the GPO
must be distributed or refreshed.
When this procedure is performed on the local device, the AppLocker policy takes effect immediately.
To clear AppLocker policies on a single system or remote systems Use the Set-AppLockerPolicy cmdlet with
the -XMLPolicy parameter, using an .XML file that contains the following contents:
<AppLockerPolicy Version="1">
<RuleCollection Type="Exe" EnforcementMode="NotConfigured" />
<RuleCollection Type="Msi" EnforcementMode="NotConfigured" />
<RuleCollection Type="Script" EnforcementMode="NotConfigured" />
<RuleCollection Type="Dll" EnforcementMode="NotConfigured" />
<RuleCollection Type="Appx" EnforcementMode="NotConfigured" />
</AppLockerPolicy>
We will create a file (for example, clear.xml), place it in the same directory where we are executing our cmdlet, and
add the preceding XML contents. Then run the following command:
This will remove all AppLocker Policies on a machine and could be potentially scripted to use on multiple
machines using remote execution tools with accounts with proper access.
Edit AppLocker rules
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for IT professionals describes the steps to edit a publisher rule, path rule, and file hash rule in
AppLocker.
For more info about these rule types, see Understanding AppLocker rule condition types.
You can perform this task by using the Group Policy Management Console for an AppLocker policy in a Group
Policy Object (GPO ) or by using the Local Security Policy snap-in for an AppLocker policy on a local computer or
in a security template. For info how to use these MMC snap-ins to administer AppLocker, see Administer
AppLocker.
To edit a publisher rule
1. Open the AppLocker console, and then click the appropriate rule collection.
2. In the Action pane, right-click the publisher rule, and then click Properties.
3. Click the appropriate tab to edit the rule properties.
Click the General tab to change the rule name, add a rule description, configure whether the rule is
used to allow or deny applications, and set the security group for which this rule should apply.
Click the Publisher tab to configure the certificate's common name, the product name, the file name, or
file version of the publisher.
Click the Exceptions tab to create or edit exceptions.
When you finish updating the rule, click OK.
To edit a file hash rule
1. Open the AppLocker console, and then click the appropriate rule collection.
2. Choose the appropriate rule collection.
3. In the Action pane, right-click the file hash rule, and then click Properties.
4. Click the appropriate tab to edit the rule properties.
Click the General tab to change the rule name, add a rule description, configure whether the rule is
used to allow or deny applications, and set the security group in which this rule should apply.
Click the File Hash tab to configure the files that should be used to enforce the rule. You can click
Browse Files to add a specific file or click Browse Folders to add all files in a specified folder. To
remove hashes individually, click Remove.
When you finish updating the rule, click OK.
To edit a path rule
1. Open the AppLocker console, and then click the appropriate rule collection.
2. Choose the appropriate rule collection.
3. In the Action pane, right-click the path rule, and then click Properties.
4. Click the appropriate tab to edit the rule properties.
Click the General tab to change the rule name, add a rule description, configure whether the rule is
used to allow or deny applications, and set the security group in which this rule should apply.
Click the Path tab to configure the path on the computer in which the rule should be enforced.
Click the Exceptions tab to create exceptions for specific files in a folder.
When you finish updating the rule, click OK.
Enable the DLL rule collection
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for IT professionals describes the steps to enable the DLL rule collection feature for AppLocker.
The DLL rule collection includes the .dll and .ocx file formats.
For info about these rules, see DLL rules in AppLocker.
You can perform this task by using the Group Policy Management Console for an AppLocker policy in a Group
Policy Object (GPO ) or by using the Local Security Policy snap-in for an AppLocker policy on a local computer or
in a security template. For info how to use these MMC snap-ins to administer AppLocker, see Administer
AppLocker.
To enable the DLL rule collection
1. From the AppLocker console, right-click AppLocker, and then click Properties.
2. Click the Advanced tab, select the Enable the DLL rule collection check box, and then click OK.
Important: Before you enforce DLL rules, make sure that there are allow rules for each DLL that is
used by any of the allowed apps.
Enforce AppLocker rules
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for IT professionals describes how to enforce application control rules by using AppLocker.
After AppLocker rules are created within the rule collection, you can configure the enforcement setting to Enforce
rules or Audit only on the rule collection.
When AppLocker policy enforcement is set to Enforce rules, rules are enforced for the rule collection and all
events are audited. When AppLocker policy enforcement is set to Audit only, rules are only evaluated but all
events generated from that evaluation are written to the AppLocker log.
There is no audit mode for the DLL rule collection. DLL rules affect specific apps. Therefore, test the impact of
these rules first before deploying them to production.
To enforce AppLocker rules by configuring an AppLocker policy to Enforce rules, see Configure an AppLocker
policy for enforce rules.
Caution: AppLocker rules will be enforced immediately on the local device or when the Group Policy object
(GPO ) is updated by performing this procedure. If you want to see the effect of applying an AppLocker policy
before setting the enforcement setting to Enforce rules, configure the policy to Audit only. For info about
how to do this, see Configure an AppLocker policy for audit onlyor Test an AppLocker policy by Using Test-
AppLockerPolicy.
Run the Automatically Generate Rules wizard
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for IT professionals describes steps to run the wizard to create AppLocker rules on a reference device.
AppLocker allows you to automatically generate rules for all files within a folder. It will scan the specified folder
and create the condition types that you choose for each file in that folder.
You can perform this task by using the Group Policy Management Console for an AppLocker policy in a Group
Policy Object (GPO ) or by using the Local Security Policy snap-in for an AppLocker policy on a local device or in a
security template. For info how to use these MMC snap-ins to administer AppLocker, see Administer AppLocker.
To automatically generate rules
1. Open the AppLocker console.
2. Right-click the appropriate rule type for which you want to automatically generate rules. You can automatically
generate rules for executable, Windows Installer, script and packaged app rules.
3. Click Automatically Generate Rules.
4. On the Folder and Permissions page, click Browse to choose the folder to be analyzed. By default, this is the
Program Files folder.
5. Click Select to choose the security group in which the default rules should be applied. By default, this is the
Everyone group.
6. The wizard provides a name in the Name to identify this set of rules box based on the name of the folder
that you have selected. Accept the provided name or type a different name, and then click Next.
7. On the Rule Preferences page, choose the conditions that you want the wizard to use while creating rules,
and then click Next. For more info about rule conditions, see Understanding AppLocker rule condition
types.
Note: The Reduce the number of rules created by grouping similar files check box is selected by
default. This helps you organize AppLocker rules and reduce the number of rules that you create by
performing the following operations for the rule condition that you select:
One publisher condition is created for all files that have the same publisher and product name.
One path condition is created for the folder that you select. For example, if you select C:\Program
Files\ProgramName\ and the files in that folder are not signed, the wizard creates a rule for
*%programfiles%\ProgramName\**.
One file hash condition is created that contains all of the file hashes. When rule grouping is disabled, the
wizard creates a file hash rule for each file.
8. Review the files that were analyzed and the rules that will be automatically created. To make changes, click
Previous to return to the page where you can change your selections. After reviewing the rules, click
Create.
Note: If you are running the wizard to create your first rules for a GPO, you will be prompted to create the
default rules, which allow critical system files to run, after completing the wizard. You may edit the default rules
at any time. If your organization has decided to edit the default rules or create custom rules to allow the
Windows system files to run, ensure that you delete the default rules after replacing them with your custom
rules.
Working with AppLocker policies
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for IT professionals provides links to procedural topics about creating, maintaining, and testing
AppLocker policies.
In this section
TOPIC DESCRIPTION
Configure the Application Identity service This topic for IT professionals shows how to configure the
Application Identity service to start automatically or manually.
Configure an AppLocker policy for audit only This topic for IT professionals describes how to set AppLocker
policies to **Audit only ** within your IT environment by using
AppLocker.
Configure an AppLocker policy for enforce rules This topic for IT professionals describes the steps to enable the
AppLocker policy enforcement setting.
Display a custom URL message when users try to run a This topic for IT professionals describes the steps for
blocked app displaying a customized message to users when an AppLocker
policy denies access to an app.
Export an AppLocker policy from a GPO This topic for IT professionals describes the steps to export an
AppLocker policy from a Group Policy Object (GPO) so that it
can be modified.
Export an AppLocker policy to an XML file This topic for IT professionals describes the steps to export an
AppLocker policy to an XML file for review or testing.
Import an AppLocker policy from another computer This topic for IT professionals describes how to import an
AppLocker policy.
Import an AppLocker policy into a GPO This topic for IT professionals describes the steps to import an
AppLocker policy into a Group Policy Object (GPO).
Add rules for packaged apps to existing AppLocker rule-set This topic for IT professionals describes how to update your
existing AppLocker policies for packaged apps using the
Remote Server Administration Toolkit (RSAT).
Merge AppLocker policies by using Set-ApplockerPolicy This topic for IT professionals describes the steps to merge
AppLocker policies by using Windows PowerShell.
Merge AppLocker policies manually This topic for IT professionals describes the steps to manually
merge AppLocker policies to update the Group Policy Object
(GPO).
TOPIC DESCRIPTION
Refresh an AppLocker policy This topic for IT professionals describes the steps to force an
update for an AppLocker policy.
Test an AppLocker policy by using Test-AppLockerPolicy This topic for IT professionals describes the steps to test an
AppLocker policy prior to importing it into a Group Policy
Object (GPO) or another computer.
Configure the Application Identity service
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for IT professionals shows how to configure the Application Identity service to start automatically or
manually.
The Application Identity service determines and verifies the identity of an app. Stopping this service will prevent
AppLocker policies from being enforced.
Important: When using Group Policy, you must configure it to start automatically in at least one Group Policy
Object (GPO ) that applies AppLocker rules. This is because AppLocker uses this service to verify the attributes
of a file.
Create a security template that configures appidsvc to be automatic start, and apply it using secedit.exe or
LGPO.exe.
Configure an AppLocker policy for audit only
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for IT professionals describes how to set AppLocker policies to Audit only within your IT environment
by using AppLocker.
After AppLocker rules are created within the rule collection, you can configure the enforcement setting to
Enforce rules or Audit only.
When AppLocker policy enforcement is set to Enforce rules, rules are enforced for the rule collection and all
events are audited. When AppLocker policy enforcement is set to Audit only, rules are only evaluated but all
events generated from that evaluation are written to the AppLocker log.
You can perform this task by using the Group Policy Management Console for an AppLocker policy in a Group
Policy Object (GPO ) or by using the Local Security Policy snap-in for an AppLocker policy on a local computer or
in a security template. For info how to use these MMC snap-ins to administer AppLocker, see Administer
AppLocker.
To audit rule collections
1. From the AppLocker console, right-click AppLocker, and then click Properties.
2. On the Enforcement tab, select the Configured check box for the rule collection that you want to enforce,
and then verify that Audit only is selected in the list for that rule collection.
3. Repeat the above step to configure the enforcement setting to Audit only for additional rule collections.
4. Click OK.
Configure an AppLocker policy for enforce rules
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for IT professionals describes the steps to enable the AppLocker policy enforcement setting.
Note: When AppLocker policy enforcement is set to Enforce rules, rules are enforced for the rule collection
and all events are audited.
For info about how AppLocker policies are applied within a GPO structure, see Understand AppLocker rules and
enforcement setting inheritance in Group Policy.
You can perform this task by using the Group Policy Management Console for an AppLocker policy in a Group
Policy Object (GPO ) or by using the Local Security Policy snap-in for an AppLocker policy on a local computer or
in a security template. For info how to use these MMC snap-ins to administer AppLocker, see Administer
AppLocker.
To enable the Enforce rules enforcement setting
1. From the AppLocker console, right-click AppLocker, and then click Properties.
2. On the Enforcement tab of the AppLocker Properties dialog box, select the Configured check box for the
rule collection that you are editing, and then verify that Enforce rules is selected.
3. Click OK.
For info about viewing the events generated from rules enforcement, see Monitor app usage with AppLocker.
Display a custom URL message when users try to run
a blocked app
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for IT professionals describes the steps for displaying a customized message to users when an
AppLocker policy denies access to an app.
Using Group Policy, AppLocker can be configured to display a message with a custom URL. You can use this URL
to redirect users to a support site that contains info about why the user received the error and which apps are
allowed. If you do not display a custom message when an apps is blocked, the default access denied message is
displayed.
To complete this procedure, you must have the Edit Setting permission to edit a GPO. By default, members of the
Domain Admins group, the Enterprise Admins group, and the Group Policy Creator Owners group have this
permission.
To display a custom URL message when users try to run a blocked app
1. On the Start screen, type gpmc.msc to open the Group Policy Management Console (GPMC ).
2. Navigate to the Group Policy Object (GPO ) that you want to edit.
3. Right-click the GPO, and then click Edit.
4. In the console tree under Policies\Administrative Templates\Windows Components, click File Explorer.
5. In the details pane, double-click Set a support web page link.
6. Click Enabled, and then type the URL of the custom Web page in the Support Web page URL box.
7. Click OK to apply the setting.
Export an AppLocker policy from a GPO
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for IT professionals describes the steps to export an AppLocker policy from a Group Policy Object
(GPO ) so that it can be modified.
Updating an AppLocker policy that is currently enforced in your production environment can have unintended
results. Therefore, export the policy from the GPO and update the rule or rules by using AppLocker on your
AppLocker reference device.
To complete this procedure, you must have the Edit Setting permission to edit a GPO. By default, members of
the Domain Admins group, the Enterprise Admins group, and the Group Policy Creator Owners group have
this permission.
Export the policy from the GPO
1. In the Group Policy Management Console (GPMC ), open the GPO that you want to edit.
2. In the console tree under Computer Configuration\Policies\Windows Settings\Security
Settings\Application Control Policies, click AppLocker.
3. Right-click AppLocker, and then click Export Policy.
4. In the Export Policy dialog box, type a name for the exported policy (for example, the name of the GPO ),
select a location to save the policy, and then click Save.
5. The AppLocker dialog box will notify you of how many rules were exported. Click OK.
Export an AppLocker policy to an XML file
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for IT professionals describes the steps to export an AppLocker policy to an XML file for review or
testing. Membership in the local Administrators group, or equivalent, is the minimum required to complete this
procedure.
To export an AppLocker policy to an XML file
1. From the AppLocker console, right-click AppLocker, and then click Export Policy.
2. Browse to the location where you want to save the XML file.
3. In the File name box, type a file name for the XML file, and then click Save.
Import an AppLocker policy from another computer
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for IT professionals describes how to import an AppLocker policy.
Before completing this procedure, you should have exported an AppLocker policy. For more information, see
Export an AppLocker policy to an XML file.
Membership in the local Administrators group, or equivalent, is the minimum required to complete this
procedure.
Caution: Importing a policy will overwrite the existing policy on that computer.
Applies to
Windows 10
Windows Server
This topic for IT professionals describes the steps to import an AppLocker policy into a Group Policy Object
(GPO ). AppLocker policies can be created as local security policies and modified like any other local security
policy, or they can be created as part of a GPO and managed by using Group Policy. You can create AppLocker
policies on any supported computer. For info about which Windows editions are supported, see Requirements to
Use AppLocker.
Important: Follow your organization's standard procedures for updating GPOs. For info about specific steps
to follow for AppLocker policies, see Maintain AppLocker policies.
To complete this procedure, you must have the Edit Setting permission to edit a GPO. By default, members of
the Domain Admins group, the Enterprise Admins group, and the Group Policy Creator Owners group
have this permission.
To import an AppLocker policy into a GPO
1. In the Group Policy Management Console (GPMC ), open the GPO that you want to edit.
2. In the console tree under Computer Configuration\Policies\Windows Settings\Security
Settings\Application Control Policies, click AppLocker.
3. Right-click AppLocker, and then click Import Policy.
4. In the Import Policy dialog box, locate the XML policy file, and click Open.
5. The AppLocker dialog box will notify you of how many rules were imported. Click OK.
Add rules for packaged apps to existing AppLocker
rule-set
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for IT professionals describes how to update your existing AppLocker policies for packaged apps using
the Remote Server Administration Toolkit (RSAT).
You can create packaged app rules for the computers running Windows Server 2012 or Windows 8 and later in
your domain by updating your existing AppLocker rule set. All you need is a computer running at least Windows
8. Download and install the Remote Server Administration Toolkit (RSAT) from the Microsoft Download Center.
RSAT comes with the Group Policy Management Console which allows you to edit the GPO or GPOs where your
existing AppLocker policy are authored. RSAT has the necessary files required to author packaged app rules.
Packaged app rules will be ignored on computers running Windows 7 and earlier but will be enforced on those
computers in your domain running at least Windows Server 2012 and Windows 8.
Merge AppLocker policies by using Set-
ApplockerPolicy
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for IT professionals describes the steps to merge AppLocker policies by using Windows PowerShell.
The Set-AppLockerPolicy cmdlet sets the specified Group Policy Object (GPO ) to contain the specified
AppLocker policy. If no Lightweight Directory Access Protocol (LDAP ) is specified, the local GPO is the default.
When the Merge parameter is used, rules in the specified AppLocker policy will be merged with the AppLocker
rules in the target GPO specified in the LDAP path. The merging of policies will remove rules with duplicate rule
IDs, and the enforcement setting specified by the AppLocker policy in the target GPO will be preserved. If the
Merge parameter is not specified, then the new policy will overwrite the existing policy.
For info about using Set-AppLockerPolicy, including syntax descriptions and parameters, see Set-
AppLockerPolicy.
For info about using Windows PowerShell for AppLocker, including how to import the AppLocker cmdlets into
Windows PowerShell, see Use the AppLocker Windows PowerShell cmdlets.
You can also manually merge AppLocker policies. For the procedure to do this, see Merge AppLocker policies
manually.
To merge a local AppLocker policy with another AppLocker policy by using LDAP paths
1. Open the PowerShell command window. For info about performing Windows PowerShell commands for
AppLocker, see Use the AppLocker Windows PowerShell cmdlets.
2. At the command prompt, type C:\PS>Get-AppLockerPolicy -Local | Set-AppLockerPolicy -LDAP "LDAP:
//<string>" -Merge where <string> specifies the LDAP path of the unique GPO.
Example
Gets the local AppLocker policy, and then merges the policy with the existing AppLocker policy in the GPO
specified in the LDAP path.
Applies to
Windows 10
Windows Server
This topic for IT professionals describes the steps to manually merge AppLocker policies to update the Group
Policy Object (GPO ).
If you have created multiple AppLocker policies and need to merge them to create one AppLocker policy, you can
either manually merge the policies or use the Windows PowerShell cmdlets for AppLocker. You cannot
automatically merge policies by using the AppLocker console. You must create one rule collection from two or
more policies. For info about merging policies by using the cmdlet, see Merge AppLocker policies by using Set-
ApplockerPolicy.
The AppLocker policy is saved in XML format, and the exported policy can be edited with any text or XML editor.
Rule collections are specified within the RuleCollection Type element. The XML schema includes five attributes
for the different rule collections, as shown in the following table:
Rule enforcement is specified with the EnforcementMode element. The three enforcement modes in the XML
correspond to the three enforcement modes in the AppLocker console, as shown in the following table:
Each of the three condition types use specific elements. For XML examples of the different rule types, see Merge
AppLocker policies manually.
Membership in the local Administrators group, or equivalent, is the minimum required to complete this
procedure.
To merge two or more AppLocker policies
1. Open an XML policy file in a text editor or XML editor, such as Notepad.
2. Select the rule collection where you want to copy rules from.
3. Select the rules that you want to add to another policy file, and then copy the text.
4. Open the policy where you want to add the copied rules.
5. Select and expand the rule collection where you want to add the rules.
6. At the bottom of the rule list for the collection, after the closing element, paste the rules that you copied from
the first policy file. Verify that the opening and closing elements are intact, and then save the policy.
7. Upload the policy to a reference computer to ensure that it is functioning properly within the GPO.
Refresh an AppLocker policy
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for IT professionals describes the steps to force an update for an AppLocker policy.
If you update the rule collection on a local computer by using the Local Security Policy snap-in, the policy will take
effect immediately. If Group Policy is used to distribute the AppLocker policy and you want to immediately
implement the policy, you must manually refresh the policy. The Group Policy refresh might take several minutes,
depending upon the number of policies within the Group Policy Object (GPO ) and the number of target
computers.
To use Group Policy to distribute the AppLocker policy change, you need to retrieve the deployed AppLocker
policy first. To prepare for the update and subsequent refresh, see Edit an AppLocker policy
Edit an AppLocker policy and Use the AppLocker Windows PowerShell cmdlets.
To complete this procedure, you must have Edit Setting permission to edit a GPO. By default, members of the
Domain Admins group, the Enterprise Admins group, and the Group Policy Creator Owners group have this
permission.
To manually refresh the AppLocker policy by using Group Policy
1. From a command prompt, type gpupdate /force, and then press ENTER.
2. When the command finishes, close the command prompt window, and then verify that the intended rule
behavior is correct. You can do this by checking the AppLocker event logs for events that include "policy
applied."
To change a policy on an individual computer, or to implement that policy on other computers, without using
Group Policy, you first need to update the rule within the rule collection. For information about updating existing
rules, see Edit AppLocker rules. For information about creating a new rule for an existing policy, see:
Create a rule that uses a publisher condition
Create a rule that uses a file hash condition
Create a rule that uses a path condition
Membership in the local Administrators group, or equivalent, is the minimum required to complete this
procedure.
To refresh the AppLocker policy on the local computer
Update the rule collection by using the Local Security Policy console with one of the following procedures:
Edit AppLocker rules
Delete an AppLocker rule
Add exceptions for an AppLocker rule
When finished, the policy is in effect.
To make the same change on another device, you can use any of the following methods:
From the device that you made the change on, export the AppLocker policy, and then import the policy onto
the other device. To do this, use the AppLocker Export Policy and Import Policy features to copy the rules
from the changed computer.
Caution: When importing rules from another computer, all the rules will be applied, not just the one
that was updated. Merging policies allows both existing and updated (or new ) rules to be applied.
Merge AppLocker policies. For procedures to do this, see Merge AppLocker policies manually and Merge
AppLocker policies by using Set-ApplockerPolicy.
Test an AppLocker policy by using Test-
AppLockerPolicy
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for IT professionals describes the steps to test an AppLocker policy prior to importing it into a Group
Policy Object (GPO ) or another computer.
The Test-AppLockerPolicy Windows PowerShell cmdlet can be used to determine whether any of the rules in
your rule collections will be blocked on your reference computer or the computer on which you maintain policies.
Perform the following steps on any computer where the AppLocker policies are applied.
Any user account can be used to complete this procedure.
To test an AppLocker policy by using Test-AppLockerPolicy
1. Export the effective AppLocker policy. To do this, you must use the Get-AppLockerPolicy Windows
PowerShell cmdlet.
a. Open a Windows PowerShell command prompt window as an administrator.
b. Use the Get-AppLockerPolicy cmdlet to export the effective AppLocker policy to an XML file:
Get-AppLockerPolicy –Effective –XML > <PathofFiletoExport.XML>
2. Use the Get-ChildItem cmdlet to specify the directory that you want to test, specify the Test-
AppLockerPolicy cmdlet with the XML file from the previous step to test the policy, and use the Export-
CSV cmdlet to export the results to a file to be analyzed:
Get-ChildItem <DirectoryPathtoReview> -Filter <FileExtensionFilter> -Recurse | Convert-Path | Test-
AppLockerPolicy –XMLPolicy <PathToExportedPolicyFile> -User <domain\username> -Filter
<TypeofRuletoFilterFor> | Export-CSV <PathToExportResultsTo.CSV>
In the example, the effective AppLocker policy is exported to the file C:\Effective.xml. The Get-ChildItem cmdlet
is used to recursively gather path names for the .exe files in C:\Program Files\Microsoft Office\. The XMLPolicy
parameter specifies that the C:\Effective.xml file is an XML AppLocker policy file. By specifying the User
parameter, you can test the rules for specific users, and the Export-CSV cmdlet allows the results to be exported
to a comma-separated file. In the example, -FilterDenied,DeniedByDefault displays only those files that will be
blocked for the user under the policy.
AppLocker design guide
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for the IT professional introduces the design and planning steps required to deploy application control
policies by using AppLocker.
This guide provides important designing and planning information for deploying application control policies by
using AppLocker. It is intended for security architects, security administrators, and system administrators.
Through a sequential and iterative process, you can create an AppLocker policy deployment plan for your
organization that will address your specific application control requirements by department, organizational unit,
or business group.
This guide does not cover the deployment of application control policies by using Software Restriction Policies
(SRP ). However, SRP is discussed as a deployment option in conjunction with AppLocker policies. For info about
these options, see Determine your application control objectives.
To understand if AppLocker is the correct application control solution for your organization, see Understand
AppLocker policy design decisions.
In this section
TOPIC DESCRIPTION
Understand AppLocker policy design decisions This topic for the IT professional lists the design questions,
possible answers, and ramifications of the decisions when you
plan a deployment of application control policies by using
AppLocker within a Windows operating system environment.
Determine your application control objectives This topic helps you with the decisions you need to make to
determine what applications to control and how to control
them by comparing Software Restriction Policies (SRP) and
AppLocker.
Create a list of apps deployed to each business group This topic describes the process of gathering app usage
requirements from each business group in order to
implement application control policies by using AppLocker.
Select the types of rules to create This topic lists resources you can use when selecting your
application control policy rules by using AppLocker.
Determine the Group Policy structure and rule enforcement This overview topic describes the process to follow when you
are planning to deploy AppLocker rules.
Plan for AppLocker policy management This topic for describes the decisions you need to make to
establish the processes for managing and maintaining
AppLocker policies.
After careful design and detailed planning, the next step is to deploy AppLocker policies. AppLocker Deployment
Guide covers the creation and testing of policies, deploying the enforcement setting, and managing and
maintaining the policies.
Understand AppLocker policy design decisions
9/5/2018 • 16 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for the IT professional lists the design questions, possible answers, and ramifications of the decisions
when you plan a deployment of application control policies by using AppLocker within a Windows operating
system environment.
When you begin the design and planning process, you should consider the ramifications of your design choices.
The resulting decisions will affect your policy deployment scheme and subsequent application control policy
maintenance.
You should consider using AppLocker as part of your organization's application control policies if all the following
are true:
You have deployed or plan to deploy the supported versions of Windows in your organization. For specific
operating system version requirements, see Requirements to Use AppLocker.
You need improved control over the access to your organization's applications and the data your users access.
The number of applications in your organization is known and manageable.
You have resources to test policies against the organization's requirements.
You have resources to involve Help Desk or to build a self-help process for end-user application access issues.
The group's requirements for productivity, manageability, and security can be controlled by restrictive policies.
The following questions are not in priority or sequential order. They should be considered when you deploy
application control policies (as appropriate for your targeted environment).
Which apps do you need to control in your organization?
You might need to control a limited number of apps because they access sensitive data, or you might have to
exclude all applications except those that are sanctioned for business purposes. There might be certain business
groups that require strict control, and others that promote independent application usage.
Control specific apps When you create AppLocker rules, a list of allowed apps are
created. All apps on that list will be allowed to run (except
those on the exception list). Apps that are not on the list will
be prevented from running. AppLocker policies can only be
applied to apps installed on computers running any of the
supported versions of Windows. For specific operating system
version requirements, see Requirements to use AppLocker.
POSSIBLE ANSWERS DESIGN CONSIDERATIONS
Control only Classic Windows applications, only Universal AppLocker policies control apps by creating an allowed list of
Windows apps, or both apps by file type. Because Universal Windows apps are
categorized under the Publisher condition, Classic Windows
applications and Universal Windows apps can be controlled
together. AppLocker policies for Universal Windows apps can
be applied only to apps that are installed on PCs that support
the Microsoft Store, but Classic Windows applications can be
controlled with AppLocker on all supported versions of
Windows. The rules you currently have configured for Classic
Windows applications can remain, and you can create new
ones for Universal Windows apps.
For a comparison of Classic Windows applications and
Universal Windows apps, see Comparing Classic Windows
applications and Universal Windows apps for AppLocker
policy design decisions in this topic.
Control apps by business group and user AppLocker policies can be applied through a Group Policy
Object (GPO) to computer objects within an organizational
unit (OU). Individual AppLocker rules can be applied to
individual users or to groups of users.
Understand app usage, but there is no need to control any AppLocker policies can be set to audit app usage to help you
apps yet track which apps are used in your organization. You can then
use the AppLocker event log to create AppLocker policies.
Important: The following list contains files or types of files that cannot be managed by AppLocker:
AppLocker does not protect against running 16-bit DOS binaries in a NT Virtual DOS Machine (NTVDM ).
This technology allows running legacy DOS and 16-bit Windows programs on computers that are using
Intel 80386 or higher when there is already another operating system running and controlling the
hardware. The result is that 16-bit binaries can still run on Windows Server 2008 R2 and Windows 7 when
AppLocker is configured to otherwise block binaries and libraries. If it is a requirement to prevent 16-bit
applications from running, you must configure the Deny rule in the Executable rule collection for
NTVDM.exe.
You cannot use AppLocker to prevent code from running outside the Win32 subsystem. In particular, this
applies to the (POSIX) subsystem in Windows NT. If it is a requirement to prevent applications from
running in the POSIX subsystem, you must disable the subsystem.
AppLocker can only control VBScript, JScript, .bat files, .cmd files and Windows PowerShell scripts. It does
not control all interpreted code that runs within a host process, for example Perl scripts and macros.
Interpreted code is a form of executable code that runs within a host process. For example, Windows batch
files (*.bat) run within the context of the Windows Command Host (cmd.exe). To use AppLocker to control
interpreted code, the host process must call AppLocker before it runs the interpreted code, and then
enforce the decision that is returned by AppLocker. Not all host processes call into AppLocker. Therefore,
AppLocker cannot control every kind of interpreted code, for example Microsoft Office macros.
Important: You should configure the appropriate security settings of these host processes if you must
allow them to run. For example, configure the security settings in Microsoft Office to ensure that only
signed and trusted macros are loaded.
AppLocker rules allow or prevent an app from launching. AppLocker does not control the behavior of apps
after they are launched. Applications could contain flags that are passed to functions that signal AppLocker
to circumvent the rules and allow another .exe or .dll file to be loaded. In practice, an app that is allowed by
AppLocker could use these flags to bypass AppLocker rules and launch child processes. You must follow a
process that best suits your needs to thoroughly vet each app before allowing them to run using
AppLocker rules.
For more info, see Security considerations for AppLocker.
Comparing Classic Windows applications and Universal Windows apps for AppLocker policy design decisions
AppLocker policies for Universal Windows apps can only be applied to apps that are installed on computers
running Windows operating systems that support Microsoft Store apps. However, Classic Windows applications
can be controlled in Windows Server 2008 R2 and Windows 7, in addition to those computers that support
Universal Windows apps. The rules for Classic Windows applications and Universal Windows apps can be
enforced together. The differences you should consider for Universal Windows apps are:
All Universal Windows apps can be installed by a standard user, whereas a number of Classic Windows
applications require administrative credentials to install. So in an environment where most of the users are
standard users, you might not need numerous exe rules, but you might want more explicit policies for
packaged apps.
Classic Windows applications can be written to change the system state if they run with administrative
credentials. Most Universal Windows apps cannot change the system state because they run with limited
permissions. When you design your AppLocker policies, it is important to understand whether an app that you
are allowing can make system-wide changes.
Universal Windows apps can be acquired through the Store, or they can be side-loaded by using Windows
PowerShell cmdlets. If you use Windows PowerShell cmdlets, a special Enterprise license is required to acquire
Universal Windows apps. Classic Windows applications can be acquired through traditional means, such as
through software vendors or retail distribution.
AppLocker controls Universal Windows apps and Classic Windows applications by using different rule collections.
You have the choice to control Universal Windows apps, Classic Windows applications, or both.
For more info, see Packaged apps and packaged app installer rules in AppLocker.
How do you currently control app usage in your organization?
Most organizations have evolved app control policies and methods over time. With heightened security concerns
and an emphasis on tighter IT control over desktop use, your organization might decide to consolidate app
control practices or design a comprehensive application control scheme. AppLocker includes improvements over
SRP in the architecture and management of application control policies.
Security polices (locally set or through Group Policy) Using AppLocker requires increased effort in planning to
create correct policies, but this results in a simpler distribution
method.
Non-Microsoft app control software Using AppLocker requires a complete app control policy
evaluation and implementation.
Managed usage by group or OU Using AppLocker requires a complete app control policy
evaluation and implementation.
POSSIBLE ANSWERS DESIGN CONSIDERATIONS
Authorization Manager or other role-based access Using AppLocker requires a complete app control policy
technologies evaluation and implementation.
Which Windows desktop and server operating systems are running in your organization?
If your organization supports multiple Windows operating systems, app control policy planning becomes more
complex. Your initial design decisions should consider the security and management priorities of applications that
are installed on each version of the operating system.
Your organization's computers are running a combination AppLocker rules are only applied to computers running
of the following operating systems: the supported versions of Windows, but SRP rules can be
applied to all versions of Windows beginning with
Windows 10 Windows XP and Windows Server 2003. For specific
Windows 8 operating system version requirements, see Requirements
to use AppLocker.
Windows 7
Windows Vista Note
If you are using the Basic User security level as assigned
Windows XP in SRP, those privileges are not supported on
Windows Server 2012 computers running that support AppLocker.
Your organization's computers are running only the Use AppLocker to create your application control policies.
following operating systems:
Windows 10
Windows 8.1
Windows 8
Windows 7
Windows Server 2012 R2
Windows Server 2012
Windows Server 2008 R2
Are there specific groups in your organization that need customized application control policies?
Most business groups or departments have specific security requirements that pertain to data access and the
applications used to access that data. You should consider the scope of the project for each group and the group’s
priorities before you deploy application control policies for the entire organization.
Yes For each group, you need to create a list that includes their
application control requirements. Although this may increase
the planning time, it will most likely result in a more effective
deployment.
If your GPO structure is not currently configured so that you
can apply different policies to specific groups, you can
alternatively apply AppLocker rules in a GPO to specific user
groups.
Does your IT department have resources to analyze application usage, and to design and manage the policies?
The time and resources that are available to you to perform the research and analysis can affect the detail of your
plan and processes for continuing policy management and maintenance.
Strict written policy or guidelines to follow You need to develop AppLocker rules that reflect those
policies, and then test and maintain the rules.
No process in place You need to determine if you have the resources to develop
an application control policy, and for which groups.
Yes You cannot use AppLocker to manage SRP settings, but you
can use SRP to manage application control policies on
computers running on any of the supported operating
systems listed in Requirements to use AppLocker. In addition,
if AppLocker and SRP settings are configured in the same
GPO, only the AppLocker settings will be enforced on
computers running those supported operating systems.
What are your organization's priorities when implementing application control policies?
Some organizations will benefit from application control policies as shown by an increase in productivity or
conformance, while others will be hindered in performing their duties. Prioritize these aspects for each group to
allow you to evaluate the effectiveness of AppLocker.
POSSIBLE ANSWERS DESIGN CONSIDERATIONS
Productivity: The organization assures that tools work and To meet innovation and productivity goals, some groups
required applications can be installed. require the ability to install and run a variety of software from
different sources, including software that they developed.
Therefore, if innovation and productivity is a high priority,
managing application control policies through an allowed list
might be time consuming and an impediment to progress.
Management: The organization is aware of and controls the In some business groups, application usage can be managed
apps it supports. from a central point of control. AppLocker policies can be built
into a GPO for that purpose. This shifts the burden of app
access to the IT department, but it also has the benefit of
controlling the number of apps that can be run and
controlling the versions of those apps
Security: The organization must protect data in part by AppLocker can help protect data by allowing a defined set of
ensuring that only approved apps are used. users access to apps that access the data. If security is the top
priority, the application control policies will be the most
restrictive.
Users run without administrative rights. Apps are installed by using an installation deployment
technology.
AppLocker can help reduce the total cost of ownership for Users must be able to install applications as needed.
business groups that typically use a finite set of apps, such as
human resources and finance departments. At the same time,
these departments access highly sensitive information, much
of which contains confidential and proprietary information. By
using AppLocker to create rules for specific apps that are
allowed to run, you can help limit unauthorized applications
from accessing this information.
**Note: **AppLocker can also be effective in helping create
standardized desktops in organizations where users run as
administrators. However, it is important to note that users
with administrative credentials can add new rules to the local
AppLocker policy.
Users currently have administrator access, and it would be Enforcing AppLocker rules is not suited for business groups
difficult to change this. that must be able to install apps as needed and without
approval from the IT department. If one or more OUs in your
organization has this requirement, you can choose not to
enforce application rules in those OUs by using AppLocker or
to implement the Audit only enforcement setting through
AppLocker.
Is the structure in Active Directory Domain Services based on the organization's hierarchy?
Designing application control policies based on an organizational structure that is already built into Active
Directory Domain Services (AD DS ) is easier than converting the existing structure to an organizational structure.
Because the effectiveness of application control policies is dependent on the ability to update policies, consider
what organizational work needs to be accomplished before deployment begins.
Applies to
Windows 10
Windows Server
This topic helps you with the decisions you need to make to determine what applications to control and how to
control them by comparing Software Restriction Policies (SRP ) and AppLocker.
AppLocker is very effective for organizations with app restriction requirements whose environments have a
simple topography and the application control policy goals are straightforward. For example, AppLocker can
benefit an environment where non-employees have access to computers connected to the organizational
network, such as a school or library. Large organizations also benefit from AppLocker policy deployment when
the goal is to achieve a detailed level of control on the PCs that they manage for a relatively small number of
apps.
There are management and maintenance costs associated with a list of allowed apps. In addition, the purpose of
application control policies is to allow or prevent employees from using apps that might actually be productivity
tools. Keeping employees or users productive while implementing the policies can cost time and effort. Lastly,
creating user support processes and network support processes to keep the organization productive are also
concerns.
Use the following table to develop your own objectives and determine which application control feature best
addresses those objectives.
Scope SRP policies can be applied to all AppLocker policies apply only to
Windows operating systems the support versions of Windows
beginning with Windows XP and listed in Requirements to use
Windows Server 2003. AppLocker.
Policy creation SRP policies are maintained AppLocker policies are maintained
through Group Policy and only the through Group Policy and only the
administrator of the GPO can administrator of the GPO can
update the SRP policy. The update the policy. The
administrator on the local administrator on the local
computer can modify the SRP computer can modify the
policies defined in the local GPO. AppLocker policies defined in the
local GPO.
AppLocker permits customization
of error messages to direct users to
a Web page for help.
APPLICATION CONTROL FUNCTION SRP APPLOCKER
Policy maintenance SRP policies must be updated by AppLocker policies can be updated
using the Local Security Policy by using the Local Security Policy
snap-in (if the policies are created snap-in (if the policies are created
locally) or the Group Policy locally), or the GPMC, or the
Management Console (GPMC). Windows PowerShell AppLocker
cmdlets.
Policy application SRP policies are distributed AppLocker policies are distributed
through Group Policy. through Group Policy.
Enforcement mode SRP works in the “deny list mode” AppLocker by default works in the
where administrators can create “allow list mode” where only those
rules for files that they do not want files are allowed to run for which
to allow in this Enterprise whereas there is a matching allow rule.
the rest of the file are allowed to
run by default.
SRP can also be configured in the
“allow list mode” such that the by
default all files are blocked and
administrators need to create allow
rules for files that they want to
allow.
File types that can be controlled SRP can control the following file AppLocker can control the
types: following file types:
Executables Executables
Dlls Dlls
Scripts Scripts
Windows Installers Windows Installers
SRP cannot control each file type Packaged apps and
separately. All SRP rules are in a installers
single rule collection.
AppLocker maintains a separate
rule collection for each of the five
file types.
Designated file types SRP supports an extensible list of AppLocker does not support this.
file types that are considered AppLocker currently supports the
executable. You can add extensions following file extensions:
for files that should be considered
executable. Executables (.exe, .com)
Dlls (.ocx, .dll)
Scripts (.vbs, .js, .ps1, .cmd,
.bat)
Windows Installers (.msi,
.mst, .msp)
Packaged app installers
(.appx)
APPLICATION CONTROL FUNCTION SRP APPLOCKER
Rule types SRP supports four types of rules: AppLocker supports three types of
rules:
Hash
Hash
Path
Path
Signature
Publisher
Internet zone
Editing the hash value SRP allows you to select a file to AppLocker computes the hash
hash. value itself. Internally it uses the
SHA2 Authenticode hash for
Portable Executables (Exe and Dll)
and Windows Installers and a SHA2
flat file hash for the rest.
Support for different security levels With SRP, you can specify the AppLocker does not support
permissions with which an app can security levels.
run. So, you can configure a rule
such that notepad always runs with
restricted permissions and never
with administrative privileges.
SRP on Windows Vista and earlier
supported multiple security levels.
On Windows 7, that list was
restricted to just two levels:
Disallowed and Unrestricted (Basic
User translates to Disallowed).
Manage Packaged apps and Unable .appx is a valid file type which
Packaged app installers. AppLocker can manage.
Targeting a rule to a user or a SRP rules apply to all users on a AppLocker rules can be targeted to
group of users particular computer. a specific user or a group of users.
Support for rule exceptions SRP does not support rule AppLocker rules can have
exceptions exceptions which allow
administrators to create rules such
as “Allow everything from
Windows except for Regedit.exe”.
Support for audit mode SRP does not support audit mode. AppLocker supports audit mode
The only way to test SRP policies is which allows administrators to test
to set up a test environment and the effect of their policy in the real
run a few experiments. production environment without
impacting the user experience.
Once you are satisfied with the
results, you can start enforcing the
policy.
APPLICATION CONTROL FUNCTION SRP APPLOCKER
Support for exporting and SRP does not support policy AppLocker supports the importing
importing policies import/export. and exporting of policies. This
allows you to create AppLocker
policy on a sample computer, test it
out and then export that policy
and import it back into the desired
GPO.
Rule enforcement Internally, SRP rules enforcement Internally, AppLocker rules for exes
happens in the user-mode which is and dlls are enforced in the kernel-
less secure. mode which is more secure than
enforcing them in the user-mode.
Applies to
Windows 10
Windows Server
This topic describes the process of gathering app usage requirements from each business group in order to
implement application control policies by using AppLocker.
Tip: If you run Application Verifier against a custom application with any AppLocker policies enabled, it might
prevent the application from running. You should either disable Application Verifier or AppLocker. You can
create an inventory of Universal Windows apps on a device by using two methods: the Get-AppxPackage
Windows PowerShell cmdlet or the AppLocker console.
The following topics in the AppLocker Step-by-Step Guide describe how to perform each method:
Automatically generating executable rules from a reference computer
Using auditing to track which apps are used
Prerequisites to completing the inventory
Identify the business group and each organizational unit (OU ) within that group to which you will apply
application control policies. In addition, you should have identified whether or not AppLocker is the most
appropriate solution for these policies. For info about these steps, see the following topics:
Understand AppLocker policy design decisions
Determine your application control objectives
Next steps
Identify and develop the list of apps. Record the name of the app, whether it is signed or not as indicated by the
publisher's name, and whether or not it is a mission critical, business productivity, optional, or personal
application. Record the installation path of the apps. For info about how to do this, see Document your app list.
After you have created the list of apps, the next step is to identify the rule collections, which will become the
policies. This information can be added to the table under columns labeled:
Use default rule or define new rule condition
Allow or deny
GPO name
To do this, see the following topics:
Select the types of rules to create
Determine the Group Policy structure and rule enforcement
Document your app list
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This planning topic describes the app information that you should document when you create a list of apps for
AppLocker policies.
ORGANIZATIONAL IMPLEMENT
BUSINESS GROUP UNIT APPLOCKER? APPS INSTALLATION PATH
Note: AppLocker only supports publisher rules for Universal Windows apps. Therefore, collecting the
installation path information for Universal Windows apps is not necessary.
Event processing
As you create your list of apps, you need to consider how to manage the events that are generated by user access,
or you need to deny running those apps to make your users as productive as possible. The following list is an
example of what to consider and what to record:
Will event forwarding be implemented for AppLocker events?
What is the location of the AppLocker event collection?
Should an event archival policy be implemented?
Will the events be analyzed and how often?
Should a security policy be in place for event collection?
Policy maintenance
As you create your list of apps, you need to consider how to manage and maintain the policies that you will
eventually create. The following list is an example of what to consider and what to record:
How will rules be updated for emergency app access and permanent access?
How will apps be removed?
How many older versions of the same app will be maintained?
How will new apps be introduced?
Next steps
After you have created the list of applications, the next step is to identify the rule collections, which will become the
application control policies. This information can be added to the table under the following columns:
Use default rule or define new rule condition
Allow or deny
GPO name
To identify the rule collections, see the following topics:
Select the types of rules to create
Determine Group Policy structure and rule enforcement
Select the types of rules to create
9/5/2018 • 4 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic lists resources you can use when selecting your application control policy rules by using AppLocker.
When determining what types of rules to create for each of your groups, you should also determine what
enforcement setting to use for each group. Different rule types are more applicable for some apps, depending on
the way that the applications are deployed in a specific business group.
The following topics provide additional information about AppLocker rules that can help you decide what rules to
use for your applications:
Understanding AppLocker rule behavior
Understanding AppLocker rule exceptions
Understanding AppLocker rule collections
Understanding AppLocker allow and deny actions on rules
Understanding AppLocker rule condition types
Understanding AppLocker default rules
Select the rule collection
The rules you create will be in one of the following rule collections:
Executable files: .exe and .com
Windows Installer files: .msi, .msp, and .mst
Scripts: .ps1, .bat, .cmd, .vbs, and .js
Packaged apps and packaged app installers: .appx
DLLs: .dll and .ocx
By default, the rules will allow a file to run based upon user or group privilege. If you use DLL rules, a DLL allow
rule has to be created for each DLL that is used by all of the allowed apps. The DLL rule collection is not enabled
by default.
In the Woodgrove Bank example, the line-of-business app for the Bank Tellers business group is C:\Program
Files\Woodgrove\Teller.exe, and this app needs to be included in a rule. In addition, because this rule is part of a
list of allowed applications, all the Windows files under C:\Windows must be included as well.
Determine the rule condition
A rule condition is criteria upon which an AppLocker rule is based and can only be one of the rule conditions in
the following table.
Publisher To use a publisher condition, the files For more info about this rule condition,
must be digitally signed by the see Understanding the publisher rule
software publisher, or you must do so condition in AppLocker.
by using an internal certificate. Rules
that are specified to the version level
might have to be updated when a new
version of the file is released.
Path Any file can be assigned this rule For more info about this rule condition,
condition; however, because path rules see Understanding the path rule
specify locations within the file system, condition in AppLocker.
any subdirectory will also be affected
by the rule (unless explicitly exempted).
File hash Any file can be assigned this rule For more info about this rule condition,
condition; however, the rule must be see Understanding the file hash rule
updated each time a new version of the condition in AppLocker.
file is released because the hash value is
based in part upon the version.
In the Woodgrove Bank example, the line-of-business app for the Bank Tellers business group is signed and is
located at C:\Program Files\Woodgrove\Teller.exe. Therefore, the rule can be defined with a publisher condition. If
the rule is defined to a specific version and above (for example, Teller.exe version 8.0 and above), then this will
allow any updates to this app to occur without interruption of access to the users if the app's name and signed
attributes stay the same.
Determine how to allow system files to run
Because AppLocker rules build a list of allowed apps, a rule or rules must be created to allow all Windows files to
run. AppLocker provides a means to ensure system files are properly considered in your rule collection by
generating the default rules for each rule collection. You can use the default rules (listed in AppLocker default
rules) as a template when creating your own rules. However, these rules are only meant to function as a starter
policy when you are first testing AppLocker rules so that the system files in the Windows folders will be allowed
to run. When a default rule is created, it is denoted with "(Default rule)" in its name as it appears in the rule
collection.
You can also create a rule for the system files based on the path condition. In the preceding example, for the Bank
Tellers group, all Windows files reside under C:\Windows and can be defined with the path rule condition type.
This will permit access to these files whenever updates are applied and the files change. If you require additional
application security, you might need to modify the rules created from the built-in default rule collection. For
example, the default rule to allow all users to run .exe files in the Windows folder is based on a path condition that
allows all files within the Windows folder to run. The Windows folder contains a Temp subfolder to which the
Users group is given the following permissions:
Traverse Folder/Execute File
Create Files/Write Data
Create Folders/Append Data
These permissions settings are applied to this folder for application compatibility. However, because any user can
create files in this location, allowing apps to be run from this location might conflict with your organization's
security policy.
Next steps
After you have selected the types of rules to create, record your findings as explained in Document your
AppLocker rules.
After recording your findings for the AppLocker rules to create, you will need to consider how to enforce the
rules. For info about how to do this, see Determine Group Policy structure and rule enforcement.
Document your AppLocker rules
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic describes what rule conditions to associate with each file, how to associate the rule conditions with each
file, the source of the rule, and whether the file should be included or excluded.
USE DEFAULT
RULE OR
DEFINE NEW
BUSINESS ORGANIZATIO IMPLEMENT INSTALLATION RULE ALLOW OR
GROUP NAL UNIT APPLOCKER? APPLICATIONS PATH CONDITION DENY
Next steps
For each rule, determine whether to use the allow or deny option. Then, three tasks remain:
Determine Group Policy structure and rule enforcement
Plan for AppLocker policy management
Determine the Group Policy structure and rule
enforcement
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This overview topic describes the process to follow when you are planning to deploy AppLocker rules.
In this section
TOPIC DESCRIPTION
Understand AppLocker enforcement settings This topic describes the AppLocker enforcement settings for
rule collections.
Understand AppLocker rules and enforcement setting This topic for the IT professional describes how application
inheritance in Group Policy control policies configured in AppLocker are applied through
Group Policy.
Document the Group Policy structure and AppLocker rule This planning topic describes what you need to investigate,
enforcement determine, and record in your application control policies
plan when you use AppLocker.
When you are determining how many Group Policy Objects (GPOs) to create when you apply an AppLocker
policy in your organization, you should consider the following:
Whether you are creating new GPOs or using existing GPOs
Whether you are implementing Software Restriction Policies (SRP ) policies and AppLocker policies in the
same GPO
GPO naming conventions
GPO size limits
Note: There is no default limit on the number of AppLocker rules that you can create. However, in Windows
Server 2008 R2, GPOs have a 2 MB size limit for performance. In subsequent versions, that limit is raised to
100 MB.
Understand AppLocker enforcement settings
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic describes the AppLocker enforcement settings for rule collections.
Rule enforcement is applied only to a collection of rules, not to individual rules. AppLocker divides the rules into
four collections: executable files, Windows Installer files, scripts, and DLL files. For more info about rule
collections, see Understanding AppLocker rule collections. By default, if enforcement is not configured and rules
are present in a rule collection, those rules are enforced. The following table details the three AppLocker rule
enforcement settings in Group Policy for each rule collection.
Enforce rules Rules are enforced for the rule collection, and all rule events
are audited.
Audit only Rule events are audited only. Use this value when planning
and testing AppLocker rules.
For the AppLocker policy to be enforced on a device, the Application Identity service must be running. For more
info about the Application Identity service, see Configure the Application Identity service.
When AppLocker policies from various GPOs are merged, the enforcement modes are merged by using the
standard Group Policy order of inheritance, which is local, domain, site, and organizational unit (OU ). The Group
Policy setting that was last written or applied by order of inheritance is used for the enforcement mode, and all
rules from linked GPOs are applied.
Understand AppLocker rules and enforcement
setting inheritance in Group Policy
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for the IT professional describes how application control policies configured in AppLocker are applied
through Group Policy.
Rule enforcement is applied only to collections of rules, not individual rules. AppLocker divides the rules into the
following collections: executable files, Windows Installer files, scripts, packaged apps and packaged app installers,
and DLL files. The options for rule enforcement are Not configured, Enforce rules, or Audit only. Together, all
AppLocker rule collections compose the application control policy, or AppLocker policy.
Group Policy merges AppLocker policy in two ways:
Rules. Group Policy does not overwrite or replace rules that are already present in a linked Group Policy
Object (GPO ). For example, if the current GPO has 12 rules and a linked GPO has 50 rules, 62 rules are
applied to all computers that receive the AppLocker policy.
Important: When determining whether a file is permitted to run, AppLocker processes rules in the
following order:
Applies to
Windows 10
Windows Server
This planning topic describes what you need to investigate, determine, and record in your application control
policies plan when you use AppLocker.
USE
DEFAULT
RULE OR
DEFINE NEW
BUSINESS ORGANIZATI IMPLEMENT INSTALLATI RULE ALLOW OR
GROUP ONAL UNIT APPLOCKER? APPS ON PATH CONDITION DENY GPO NAME
Next steps
After you have determined the Group Policy structure and rule enforcement strategy for each business group's
apps, the following tasks remain:
Plan for AppLocker policy management
Plan for AppLocker policy management
9/5/2018 • 9 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for describes the decisions you need to make to establish the processes for managing and maintaining
AppLocker policies.
Policy management
Before you begin the deployment process, consider how the AppLocker rules will be managed. Developing a
process for managing AppLocker rules helps assure that AppLocker continues to effectively control how
applications are allowed to run in your organization.
Application and user support policy
Developing a process for managing AppLocker rules helps assure that AppLocker continues to effectively control
how applications are allowed to run in your organization. Considerations include:
What type of end-user support is provided for blocked applications?
How are new rules added to the policy?
How are existing rules updated?
Are events forwarded for review?
Help desk support
If your organization has an established help desk support department in place, consider the following when
deploying AppLocker policies:
What documentation does your support department require for new policy deployments?
What are the critical processes in each business group both in work flow and timing that will be affected by
application control policies and how could they affect your support department's workload?
Who are the contacts in the support department?
How will the support department resolve application control issues between the end user and those who
maintain the AppLocker rules?
End-user support
Because AppLocker is preventing unapproved apps from running, it is important that your organization carefully
plan how to provide end-user support. Considerations include:
Do you want to use an intranet site as a first line of support for users who have tried to run a blocked app?
How do you want to support exceptions to the policy? Will you allow users to run a script to temporarily allow
access to a blocked app?
Using an intranet site
AppLocker can be configured to display the default message but with a custom URL. You can use this URL to
redirect users to a support site that contains information about why the user received the error and which
applications are allowed. If you do not display a custom URL for the message when an app is blocked, the default
URL is used.
The following image shows an example of the error message for a blocked app. You can use the Set a support
web link policy setting to customize the More information link.
For steps to display a custom URL for the message, see Display a custom URL message when users try to run a
blocked app.
AppLocker event management
Each time that a process requests permission to run, AppLocker creates an event in the AppLocker event log. The
event details which file tried to run, the attributes of that file, the user that initiated the request, and the rule GUID
that was used to make the AppLocker execution decision. The AppLocker event log is located in the following
path: Applications and Services Logs\Microsoft\Windows\AppLocker. The AppLocker log includes three
logs:
1. EXE and DLL. Contains events for all files affected by the executable and DLL rule collections (.exe, .com, .dll,
and .ocx).
2. MSI and Script. Contains events for all files affected by the Windows Installer and script rule collections (.msi,
.msp, .ps1, .bat, .cmd, .vbs, and .js).
3. Packaged app-Deployment or Packaged app-Execution, contains events for all Universal Windows apps
affected by the packaged app and packed app installer rule collection (.appx).
Collecting these events in a central location can help you maintain your AppLocker policy and troubleshoot rule
configuration problems. Event collection technologies such as those available in Windows allow administrators to
subscribe to specific event channels and have the events from source computers aggregated into a forwarded
event log on a Windows Server operating system collector. For more info about setting up an event subscription,
see Configure Computers to Collect and Forward Events.
Policy maintenance
As new apps are deployed or existing apps are updated by the software publisher, you will need to make revisions
to your rule collections to ensure that the policy is current.
You can edit an AppLocker policy by adding, changing, or removing rules. However, you cannot specify a version
for the policy by importing additional rules. To ensure version control when modifying an AppLocker policy, use
Group Policy management software that allows you to create versions of Group Policy Objects (GPOs). An
example of this type of software is the Advanced Group Policy Management feature from the Microsoft Desktop
Optimization Pack. For more info about Advanced Group Policy Management, see Advanced Group Policy
Management Overview (https://go.microsoft.com/fwlink/p/?LinkId=145013).
Caution: You should not edit an AppLocker rule collection while it is being enforced in Group Policy. Because
AppLocker controls what files are allowed to run, making changes to a live policy can create unexpected
behavior.
USE
DEFAULT
RULE OR
IMPLEMEN DEFINE
ORGANIZA T NEW RULE
BUSINESS TIONAL APPLOCKE INSTALLAT CONDITIO ALLOW OR SUPPORT
GROUP UNIT R? APPS ION PATH N DENY GPO NAME POLICY
The following two tables illustrate examples of documenting considerations to maintain and manage AppLocker
policies.
Event processing policy
One discovery method for app usage is to set the AppLocker enforcement mode to Audit only. This will write
events to the AppLocker logs, which can be managed and analyzed like other Windows logs. After apps have
been identified, you can begin to develop policies regarding the processing and access to AppLocker events.
The following table is an example of what to consider and record.
APPLOCKER EVENT
BUSINESS GROUP COLLECTION LOCATION ARCHIVAL POLICY ANALYZED? SECURITY POLICY
Policy maintenance policy When applications are identified and policies are created for application control,
then you can begin documenting how you intend to update those policies. The following table is an example of
what to consider and record.
APPLICATION
DECOMMISSION APPLICATION VERSION APPLICATION
BUSINESS GROUP RULE UPDATE POLICY POLICY POLICY DEPLOYMENT POLICY
Applies to
Windows 10
Windows Server
This topic for IT professionals introduces the concepts and describes the steps required to deploy AppLocker
policies.
This guide provides steps based on your design and planning investigation for deploying application control
policies by using AppLocker. It is intended for security architects, security administrators, and system
administrators. Through a sequential and iterative deployment process, you can create application control policies,
test and adjust the policies, and implement a method for maintaining those policies as the needs in your
organization change.
This guide covers the use of Software Restriction Policies (SRP ) in conjunction with AppLocker policies to control
application usage. For a comparison of SRP and AppLocker, see Using Software Restriction Policies and
AppLocker policies in this guide. To understand if AppLocker is the correct application control solution for you,
see Understand AppLocker policy design decisions.
In this section
TOPIC DESCRIPTION
Understand the AppLocker policy deployment process This planning and deployment topic for the IT professional
describes the process for using AppLocker when deploying
application control policies.
TOPIC DESCRIPTION
Requirements for Deploying AppLocker Policies This deployment topic for the IT professional lists the
requirements that you need to consider before you deploy
AppLocker policies.
Use Software Restriction Policies and AppLocker policies This topic for the IT professional describes how to use
Software Restriction Policies (SRP) and AppLocker policies in
the same Windows deployment.
Create Your AppLocker policies This overview topic for the IT professional describes the steps
to create an AppLocker policy and prepare it for deployment.
Deploy the AppLocker policy into production This topic for the IT professional describes the tasks that
should be completed before you deploy AppLocker
application control settings.
Understand the AppLocker policy deployment
process
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This planning and deployment topic for the IT professional describes the process for using AppLocker when
deploying application control policies.
To successfully deploy AppLocker policies, you need to identify your application control objectives and construct
the policies for those objectives. The key to the process is taking an accurate inventory of your organization's
applications, which requires investigation of all the targeted business groups. With an accurate inventory, you can
create rules and set enforcement criteria that will allow the organization to use the required applications and allow
the IT department to manage a controlled set of applications.
The following diagram shows the main points in the design, planning, and deployment process for AppLocker.
Resources to support the deployment process
The following topics contain information about designing, planning, deploying, and maintaining AppLocker
policies:
For info about the AppLocker policy design and planning requirements and process, see AppLocker Design
Guide.
For info about the AppLocker policy deployment requirements and process, see AppLocker deployment guide.
For info about AppLocker policy maintenance and monitoring, see Administer AppLocker.
For info about AppLocker policy architecture, components, and processing, see AppLocker technical reference.
Requirements for deploying AppLocker policies
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This deployment topic for the IT professional lists the requirements that you need to consider before you deploy
AppLocker policies.
The following requirements must be met or addressed before you deploy your AppLocker policies:
Deployment plan
Supported operating systems
Policy distribution mechanism
Event collection and analysis system
Deployment plan
An AppLocker policy deployment plan is the result of investigating which applications are required and necessary
in your organization, which apps are optional, and which apps are forbidden. To develop this plan, see AppLocker
Design Guide. The following table is an example of the data you need to collect and the decisions you need to
make to successfully deploy AppLocker policies on the supported operating systems (as listed in Requirements to
use AppLocker).
USE
DEFAULT
RULE OR
IMPLEMEN DEFINE
ORGANIZA T NEW RULE
BUSINESS TIONAL APPLOCKE INSTALLAT CONDITIO ALLOW OR SUPPORT
GROUP UNIT R? APPS ION PATH N DENY GPO NAME POLICY
APPLOCKER EVENT
BUSINESS GROUP COLLECTION LOCATION ARCHIVAL POLICY ANALYZED? SECURITY POLICY
See also
AppLocker deployment guide
Use Software Restriction Policies and AppLocker
policies
9/5/2018 • 3 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for the IT professional describes how to use Software Restriction Policies (SRP ) and AppLocker policies
in the same Windows deployment.
Important: As a best practice, use separate Group Policy Objects to implement your SRP and AppLocker
policies. To reduce troubleshooting issues, do not combine them in the same GPO.
The following scenario provides an example of how each type of policy would affect a bank teller software app,
where the app is deployed on different Windows desktop operating systems and managed by the Tellers GPO.
Windows 10, Windows 8.1, AppLocker policies in the Local AppLocker policies AppLocker policies in the
Windows 8,and Windows 7 GPO are applied, and they supersede policies generated GPO are applied, and they
supersede any local by SRP that are applied supersede the policies
AppLocker policies. through the GPO. generated by SRP in the
GPO and local AppLocker
policies or policies generated
by SRP.
TELLERS GPO WITH TELLERS GPO WITH
OPERATING SYSTEM APPLOCKER POLICY TELLERS GPO WITH SRP APPLOCKER POLICY AND SRP
Windows Vista AppLocker policies are not Policies generated by SRP in Policies generated by SRP in
applied. the GPO are applied, and the GPO are applied, and
they supersede local policies they supersede local policies
generated by SRP.AppLocker generated by SRP.
policies are not applied. AppLocker policies not
applied.
Windows XP AppLocker policies are not Policies generated by SRP in Policies generated by SRP in
applied. the GPO are applied, and the GPO are applied, and
they supersede local policies they supersede local policies
generated by SRP. generated by SRP.
AppLocker policies are not AppLocker policies not
applied. applied.
Note: For info about supported versions and editions of the Windows operating system, see Requirements to
use AppLocker.
Test and validate SRPs and AppLocker policies that are deployed in the
same environment
Because SRPs and AppLocker policies function differently, they should not be implemented in the same GPO. This
makes testing the result of the policy straightforward, which is critical to successfully controlling application usage
in the organization. Configuring a testing and policy distribution system can help you understand the result of a
policy. The effects of policies generated by SRP and AppLocker policies need to be tested separately and by using
different tools.
Step 1: Test the effect of SRPs
You can use the Group Policy Management Console (GPMC ) or the Resultant Set of Policy (RSoP ) snap-in to
determine the effect of applying SRPs by using GPOs.
Step 2: Test the effect of AppLocker policies
You can test AppLocker policies by using Windows PowerShell cmdlets. For info about investigating the result of a
policy, see:
Test an AppLocker policy by using Test-AppLockerPolicy
Monitor app usage with AppLocker
Another method to use when determining the result of a policy is to set the enforcement mode to Audit only.
When the policy is deployed, events will be written to the AppLocker logs as if the policy was enforced. For info
about using the Audit only mode, see:
Understand AppLocker enforcement settings
Configure an AppLocker policy for audit only
See also
AppLocker deployment guide
Create Your AppLocker policies
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This overview topic for the IT professional describes the steps to create an AppLocker policy and prepare it for
deployment.
Creating effective application control policies with AppLocker starts by creating the rules for each app. Rules are
grouped into one of five rule collections. The rule collection can be configured to be enforced or to run in Audit
only mode. An AppLocker policy includes the rules in the five rule collections and the enforcement settings for
each rule collection.
Next steps
Follow the steps described in the following topics to continue the deployment process:
1. Create Your AppLocker rules
2. Test and update an AppLocker policy
3. Deploy the AppLocker policy into production
See also
AppLocker deployment guide
Create Your AppLocker rules
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for the IT professional describes what you need to know about AppLocker rules and the methods that
you can to create rules.
Note: AppLocker includes default rules for each rule collection. These rules are intended to help ensure that
the files that are required for Windows to operate properly are allowed in an AppLocker rule collection. You
can also edit the default rules. For information about creating the default rules for the Windows operating
system, see Create AppLocker default rules.
Next steps
1. Import an AppLocker policy into a GPO
2. Import an AppLocker policy from another computer
3. Test and update an AppLocker policy
4. Deploy the AppLocker policy into production
Related topics
Create Your AppLocker policies
Deploy the AppLocker policy into production
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for the IT professional describes the tasks that should be completed before you deploy AppLocker
application control settings.
After successfully testing and modifying the AppLocker policy for each Group Policy Object (GPO ), you are ready
to deploy the enforcement settings into production. For most organizations, this means switching the AppLocker
enforcement setting from Audit only to Enforce rules. However, it is important to follow the deployment plan
that you created earlier. For more info, see the AppLocker Design Guide. Depending on the needs of different
business groups in your organization, you might deploy different enforcement settings for linked GPOs.
Understand your design decisions
Before you deploy an AppLocker policy, you should determine:
For each business group, which applications will be controlled and in what manner. For more info, see Create a
list of apps deployed to each business group.
How to handle requests for application access. For info about what to consider when developing your support
policies, see Plan for AppLocker policy management.
How to manage events, including forwarding events. For info about event management in AppLocker, see
Monitor app usage with AppLocker.
Your GPO structure, including how to include policies generated by Software Restriction Policies and
AppLocker policies. For more info, see Determine the Group Policy structure and rule enforcement.
For info about how AppLocker deployment is dependent on design decisions, see Understand AppLocker policy
design decisions.
AppLocker deployment methods
If you have configured a reference device, you can create and update your AppLocker policies on this device, test
the policies, and then export the policies to the appropriate GPO for distribution. Another method is to create the
policies and set the enforcement setting on Audit only, then observe the events that are generated.
Use a reference device to create and maintain AppLocker policies
This topic describes the steps to use an AppLocker reference computer to prepare application control
policies for deployment by using Group Policy or other means.
Deploy AppLocker policies by using the enforce rules setting
This topic describes the steps to deploy the AppLocker policy by changing the enforcement setting to
Audit only or to Enforce rules.
See also
AppLocker deployment guide
Use a reference device to create and maintain
AppLocker policies
9/5/2018 • 4 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for the IT professional describes the steps to create and maintain AppLocker policies by using a
reference computer.
Important: The reference device must be running one of the supported editions of Windows. For information
about operating system requirements for AppLocker, see Requirements to use AppLocker.
You can perform AppLocker policy testing on the reference device by using the Audit only enforcement setting or
Windows PowerShell cmdlets. You can also use the reference device as part of a testing configuration that includes
policies that are created by using Software Restriction Policies.
Note: If you run this wizard to create your first rules for a Group Policy Object (GPO ), after you complete the
wizard, you will be prompted to create the default rules, which allow critical system files to run. You can edit
the default rules at any time. If your organization has decided to edit the default rules or create custom rules to
allow the Windows system files to run, ensure that you delete the default rules after you replace them with
your custom rules.
Important: You can use the default rules as a template when you create your own rules. This allows files
within the Windows directory to run. However, these rules are only meant to function as a starter policy when
you are first testing AppLocker rules.
Step 3: Modify rules and the rule collection on the reference device
If AppLocker policies are currently running in your production environment, export the policies from the
corresponding GPOs and save them to the reference device. For the procedure to do this, see Export an
AppLocker policy from a GPO. If no AppLocker policies have been deployed, create the rules and develop the
policies by using the following procedures:
Create a rule that uses a publisher condition
Create a rule that uses a file hash condition
Create a rule that uses a path condition
Edit AppLocker rules
Add exceptions for an AppLocker rule
Delete an AppLocker rule
Enable the DLL rule collection
Enforce AppLocker rules
Caution: If you have set the enforcement setting on the rule collection to Enforce rules or you have not
configured the rule collection, the policy will be implemented when the GPO is updated in the next step. If you
have set the enforcement setting on the rule collection to Audit only, application access events are written to
the AppLocker log, and the policy will not take effect.
See also
Deploy the AppLocker policy into production
Determine which apps are digitally signed on a
reference device
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for the IT professional describes how to use AppLocker logs and tools to determine which applications
are digitally signed.
The Windows PowerShell cmdlet Get-AppLockerFileInformation can be used to determine which apps installed
on your reference devices are digitally signed. Perform the following steps on each reference computer that you
used to define the AppLocker policy. The device does not need to be joined to the domain.
Membership in the local Administrators group, or equivalent, is the minimum required to complete this
procedure.
To determine which apps are digitally signed on a reference device
1. Run Get-AppLockerFileInformation with the appropriate parameters.
The Get-AppLockerFileInformation cmdlet retrieves the AppLocker file information from a list of files or
from an event log. File information that is retrieved can include publisher information, file hash information,
and file path information. File information from an event log may not contain all of these fields. Files that are
not signed do not have any publisher information.
2. Analyze the publisher's name and digital signature status from the output of the command.
For command parameters, syntax, and examples, see Get-AppLockerFileInformation.
Related topics
Use a reference device to create and maintain AppLocker policies
Configure the AppLocker reference device
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for the IT professional describes the steps to create an AppLocker policy platform structure on a
reference computer.
An AppLocker reference device that is used for the development and deployment of AppLocker policies should
mimic the directory structure and corresponding applications in the organizational unit (OU ) or business group for
the production environment. On a reference device, you can:
Maintain an application list for each business group.
Develop AppLocker policies by creating individual rules or by creating a policy by automatically generating
rules.
Create the default rules to allow the Windows system files to run properly.
Run tests and analyze the event logs to determine the affect of the policies that you intend to deploy.
The reference device does not need to be joined to a domain, but it must be able to import and export AppLocker
policies in XML format. The reference computer must be running one of the supported editions of Windows as
listed in Requirements to use AppLocker.
Warning: Do not use operating system snapshots when creating AppLocker rules. If you take a snapshot of the
operating system, install an app, create AppLocker rules, and then revert to a clean snapshot and repeat the
process for another app, there is a chance that duplicate rule GUIDs can be created. If duplicate GUIDs are
present, AppLocker policies will not work as expected.
Note: If you have the Group Policy Management Console (GPMC ) installed on another device to test
your implementation of AppLocker policies, you can export the policies to that device
Applies to
Windows 10
Windows Server
This overview topic for IT professionals provides links to the topics in the technical reference. AppLocker
advances the application control features and functionality of Software Restriction Policies. AppLocker contains
new capabilities and extensions that allow you to create rules to allow or deny apps from running based on
unique identities of files and to specify which users or groups can run those apps.
In this section
TOPIC DESCRIPTION
What Is AppLocker? This topic for the IT professional describes what AppLocker is
and how its features differ from Software Restriction Policies.
Requirements to use AppLocker This topic for the IT professional lists software requirements
to use AppLocker on the supported Windows operating
systems.
AppLocker policy use scenarios This topic for the IT professional lists the various application
control scenarios in which AppLocker policies can be
effectively implemented.
How AppLocker works This topic for the IT professional provides links to topics
about AppLocker architecture and components, processes
and interactions, rules and policies.
AppLocker architecture and components This topic for IT professional describes AppLocker’s basic
architecture and its major components.
AppLocker processes and interactions This topic for the IT professional describes the process
dependencies and interactions when AppLocker evaluates
and enforces rules.
AppLocker functions This topic for the IT professional lists the functions and
security levels for the Software Restriction Policies (SRP) and
AppLocker features.
Security considerations for AppLocker This topic for the IT professional describes the security
considerations you need to address when implementing
AppLocker.
Tools to Use with AppLocker This topic for the IT professional describes the tools available
to create and administer AppLocker policies.
AppLocker Settings This topic for the IT professional lists the settings used by
AppLocker.
What Is AppLocker?
9/5/2018 • 4 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for the IT professional describes what AppLocker is and how its features differ from Software Restriction
Policies.
AppLocker advances the app control features and functionality of Software Restriction Policies. AppLocker
contains new capabilities and extensions that allow you to create rules to allow or deny apps from running based
on unique identities of files and to specify which users or groups can run those apps.
Using AppLocker, you can:
Control the following types of apps: executable files (.exe and .com), scripts (.js, .ps1, .vbs, .cmd, and .bat),
Windows Installer files (.mst, .msi and .msp), and DLL files (.dll and .ocx), and packaged apps and packaged app
installers (appx).
Define rules based on file attributes derived from the digital signature, including the publisher, product name,
file name, and file version. For example, you can create rules based on the publisher attribute that is persistent
through updates, or you can create rules for a specific version of a file.
Assign a rule to a security group or an individual user.
Create exceptions to rules. For example, you can create a rule that allows all Windows processes to run except
Registry Editor (Regedit.exe).
Use audit-only mode to deploy the policy and understand its impact before enforcing it.
Import and export rules. The import and export affects the entire policy. For example, if you export a policy, all
of the rules from all of the rule collections are exported, including the enforcement settings for the rule
collections. If you import a policy, all criteria in the existing policy are overwritten.
Streamline creating and managing AppLocker rules by using Windows PowerShell cmdlets.
AppLocker helps reduce administrative overhead and helps reduce the organization's cost of managing computing
resources by decreasing the number of help desk calls that result from users running unapproved apps
For information about the application control scenarios that AppLocker addresses, see AppLocker policy use
scenarios.
Rule conditions provided File hash, path, certificate, registry File hash, path, and publisher
path, and Internet zone
Rule types provided Defined by the security levels: Allow and deny
Disallowed
Basic User
Unrestricted
Operating system scope SRP policies can be applied to all AppLocker policies apply only to
Windows operating systems those supported operating system
beginning with Windows XP and versions and editions listed in
Windows Server 2003. Requirements to use AppLocker.
But these systems can also use SRP.
Note
Use different GPOs for SRP and
AppLocker rules.
APPLICATION CONTROL FUNCTION SRP APPLOCKER
User support SRP allows users to install AppLocker policies are maintained
applications as an administrator. through Group Policy, and only the
administrator of the device can
update an AppLocker policy.
AppLocker permits customization of
error messages to direct users to a
Web page for help.
Policy maintenance SRP policies are updated by using AppLocker policies are updated by
the Local Security Policy snap-in or using the Local Security Policy
the Group Policy Management snap-in or the GPMC.
Console (GPMC).
AppLocker supports a small set of
PowerShell cmdlets to aid in
administration and maintenance.
Policy management infrastructure To manage SRP policies, SRP uses To manage AppLocker policies,
Group Policy within a domain and AppLocker uses Group Policy within
the Local Security Policy snap-in for a domain and the Local Security
a local computer. Policy snap-in for a local computer.
Block malicious scripts Rules for blocking malicious scripts AppLocker rules can control the
prevents all scripts associated with following file formats: .ps1, .bat,
the Windows Script Host from .cmd, .vbs, and .js. In addition, you
running, except those that are can set exceptions to allow specific
digitally signed by your files to run.
organization.
Manage software installation SRP can prevent all Windows The Windows Installer rule
Installer packages from installing. It collection is a set of rules created
allows .msi files that are digitally for Windows Installer file types
signed by your organization to be (.mst, .msi and .msp) to allow you
installed. to control the installation of files on
client computers and servers.
Manage all software on the All software is managed in one rule Unlike SRP, each AppLocker rule
computer set. By default, the policy for collection functions as an allowed
managing all software on a device list of files. Only the files that are
disallows all software on the user's listed within the rule collection will
device, except software that is be allowed to run. This
installed in the Windows folder, configuration makes it easier for
Program Files folder, or subfolders. administrators to determine what
will occur when an AppLocker rule
is applied.
Different policies for different users Rules are applied uniformly to all On a device that is shared by
users on a particular device. multiple users, an administrator can
specify the groups of users who can
access the installed software. Using
AppLocker, an administrator can
specify the user to whom a specific
rule should apply.
Related topics
AppLocker technical reference
Requirements to use AppLocker
8/28/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for the IT professional lists software requirements to use AppLocker on the supported Windows
operating systems.
General requirements
To use AppLocker, you need:
A device running a supported operating system to create the rules. The computer can be a domain
controller.
For Group Policy deployment, at least one device with the Group Policy Management Console (GPMC ) or
Remote Server Administration Tools (RSAT) installed to host the AppLocker rules.
Devices running a supported operating system to enforce the AppLocker rules that you create.
Note: You can use Software Restriction Policies with AppLocker, but with some limitations. For more info,
see Use AppLocker and Software Restriction Policies in the same domain.
Windows RT No No N/A
AppLocker is not supported on versions of the Windows operating system not listed above. Software
Restriction Policies can be used with those versions. However, the SRP Basic User feature is not supported on
the above operating systems.
See also
Administer AppLocker
Monitor app usage with AppLocker
Optimize AppLocker performance
Use AppLocker and Software Restriction Policies in the same domain
Manage packaged apps with AppLocker
AppLocker Design Guide
AppLocker policy use scenarios
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for the IT professional lists the various application control scenarios in which AppLocker policies can be
effectively implemented.
AppLocker can help you improve the management of application control and the maintenance of application
control policies. Application control scenarios addressed by AppLocker can be categorized as follows:
1. App inventory
AppLocker has the ability to enforce its policy in an audit-only mode where all app access activity is
collected in event logs for further analysis. Windows PowerShell cmdlets are also available to help you
understand app usage and access.
2. Protection against unwanted software
AppLocker has the ability to deny apps from running simply by excluding them from the list of allowed
apps per business group or user. If an app is not specifically identified by its publisher, installation path, or
file hash, the attempt to run the application fails.
3. Licensing conformance
AppLocker can provide an inventory of software usage within your organization, so you can identify the
software that corresponds to your software licensing agreements and restrict application usage based on
licensing agreements.
4. Software standardization
AppLocker policies can be configured to allow only supported or approved apps to run on computers
within a business group. This permits a more uniform app deployment.
5. Manageability improvement
AppLocker policies can be modified and deployed through your existing Group Policy infrastructure and
can work in conjunction with policies created by using Software Restriction Policies. As you manage
ongoing change in your support of a business group's apps, you can modify policies and use the AppLocker
cmdlets to test the policies for the expected results. You can also design application control policies for
situations in which users share computers.
Use scenarios
The following are examples of scenarios in which AppLocker can be used:
Your organization implements a policy to standardize the applications used within each business group, so you
need to determine the expected usage compared to the actual usage.
The security policy for application usage has changed, and you need to evaluate where and when those
deployed apps are being accessed.
Your organization's security policy dictates the use of only licensed software, so you need to determine which
apps are not licensed or prevent unauthorized users from running licensed software.
An app is no longer supported by your organization, so you need to prevent it from being used by everyone.
Your organization needs to restrict the use of Universal Windows apps to just those your organization approves
of or develops.
The potential that unwanted software can be introduced in your environment is high, so you need to reduce
this threat.
The license to an app has been revoked or is expired in your organization, so you need to prevent it from being
used by everyone.
A new app or a new version of an app is deployed, and you need to allow certain groups to use it.
Specific software tools are not allowed within the organization, or only specific users have access to those tools.
A single user or small group of users needs to use a specific app that is denied for all others.
Some computers in your organization are shared by people who have different software usage needs.
In addition to other measures, you need to control the access to sensitive data through app usage.
Related topics
AppLocker technical reference
How AppLocker works
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for the IT professional provides links to topics about AppLocker architecture and components,
processes and interactions, rules and policies.
The following topics explain how AppLocker policies for each of the rule condition types are evaluated:
AppLocker architecture and components
AppLocker processes and interactions
The following topics explain how AppLocker rules and policies work:
Understanding AppLocker rule behavior
Understanding AppLocker rule exceptions
Understanding AppLocker rule collections
Understanding AppLocker allow and deny actions on rules
Understanding AppLocker rule condition types
Understanding the publisher rule condition in AppLocker
Understanding the path rule condition in AppLocker
Understanding the file hash rule condition in AppLocker
Understanding AppLocker default rules
Executable rules in AppLocker
Windows Installer rules in AppLocker
Script rules in AppLocker
DLL rules in AppLocker
Packaged apps and packaged app installer rules in AppLocker
Additional resources
AppLocker Design Guide
AppLocker deployment guide
Administer AppLocker
Understanding AppLocker rule behavior
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic describes how AppLocker rules are enforced by using the allow and deny options in AppLocker.
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. For example, if you configure a deny action for a file or folder path, the user can still run the file
from any other path.
Related topics
How AppLocker works
Understanding AppLocker rule exceptions
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic describes the result of applying AppLocker rule exceptions to rule collections.
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 app, you can
create a special rule for that subset.
For example, the rule "Allow Everyone to run Windows except Registry Editor" allows Everyone to run Windows
binaries, but does not allow anyone to run Registry Editor (by adding %WINDIR%\regedit.exe as a Path Exception
of the rule).
The effect of this rule would prevent users such as Helpdesk personnel from running the Registry Editor, 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" and add %WINDIR%\regedit.exe as an allowed path. 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.
Related topics
How AppLocker works
Understanding AppLocker rule collections
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic explains the five different types of AppLocker rules used to enforce AppLocker policies.
An AppLocker rule collection is a set of rules that apply to one of five types:
Executable files: .exe and .com
Windows Installer files: .msi, mst, and .msp
Scripts: .ps1, .bat, .cmd, .vbs, and .js
DLLs: .dll and .ocx
Packaged apps and packaged app installers: .appx
If you use DLL rules, a DLL allow rule has to be created for each DLL that is used by all of the allowed apps.
Important: Each app can load several DLLs, and AppLocker must check each DLL before it is allowed to run.
Therefore, creating DLL rules might cause performance problems on some computers. Denying some DLLs
from running can also create app compatibility problems. As a result, the DLL rule collection is not enabled by
default.
For info about how to enable the DLL rule collection, see Enable the DLL rule collection.
Related topics
How AppLocker works
Understanding AppLocker default rules
Understanding AppLocker allow and deny actions on
rules
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic explains the differences between allow and deny actions on AppLocker rules.
Publisher A user could modify the properties of a file (for example, re-
signing the file with a different certificate).
Path A user could move the denied file to a different location and
run it from there.
Important: If you choose to use the deny action on rules, you must ensure that you first create rules that
allow the Windows system files to run. AppLocker enforces rules for allowed applications by default, so after
one or more rules have been created for a rule collection (affecting the Windows system files), only the apps
that are listed as being allowed will be permitted to run. Therefore, creating a single rule in a rule collection to
deny a malicious file from running will also deny all other files on the computer from running.
Related topics
How AppLocker works
Understanding AppLocker rule condition types
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for the IT professional describes the three types of AppLocker 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
To use a publisher condition, the files must be digitally signed by the software publisher, or you must do so by
using an internal certificate. Rules that are specified to the version level might have to be updated when a new
version of the file is released. For more info about this rule condition, see Understanding the publisher rule
condition in AppLocker.
Path
Any file can be assigned this rule condition; however, because path rules specify locations within the file system,
any subdirectory will also be affected by the rule (unless explicitly exempted). For more info about this rule
condition, see Understanding the path rule condition in AppLocker.
File hash
Any file can be assigned this rule condition; however, the rule must be updated each time a new version of the file
is released because the hash value is unique to that the version of the file. For more info about this rule condition,
see Understanding the file hash rule condition in AppLocker.
Considerations
Selecting the appropriate condition for each rule depends on the overall application control policy goals of the
organization, the AppLocker rule maintenance goals, and the condition of the existing (or planned) application
deployment. The following questions can help you decide which rule condition to use.
1. Is the file digitally signed by a software publisher?
If the file is signed by a software publisher, we recommend that you create rules with publisher conditions.
You may still create file hash and path conditions for signed files. However, if the file is not digitally signed
by a software publisher, you can:
Sign the file by using an internal certificate.
Create a rule by using a file hash condition.
Create a rule by using a path condition.
Note: To determine how many applications on a reference computer are digitally signed, you
can use the Get-AppLockerFileInformation Windows PowerShell cmdlet for a directory of
files. For example, Get-AppLockerFileInformation –Directory C:\Windows\ -FileType EXE -recurse
displays the properties for all .exe and .com files within the Windows directory.
Note: For a list of supported operating system versions and editions to which SRP and AppLocker
rules can be applied, see Requirements to use AppLocker.
Related topics
How AppLocker works
Understanding the publisher rule condition in
AppLocker
9/5/2018 • 3 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic explains the AppLocker publisher rule condition, what controls are available, and how it is applied.
Publisher conditions can be made only for files that are digitally signed; this condition identifies an app based on
its digital signature and extended attributes. The digital signature contains information about the company that
created the app (the publisher). The extended attributes, which are obtained from the binary resource, contain the
name of the product that the app is part of and the version number of the app. The publisher may be a software
development company, such as Microsoft, or the Information Technology department of your organization.
Publisher conditions are easier to maintain than file hash conditions and are generally more secure than path
conditions. Rules that are specified to the version level might have to be updated when a new version of the file is
released. The following table describes the advantages and disadvantages of the publisher condition.
Wildcard characters can be used as values in the publisher rule fields according to the following specifications:
Publisher
The asterisk (*) character used by itself represents any publisher. When combined with any string value, the
rule is limited to the publisher with a value in the signed certificate that matches the character string. In
other words, the asterisk is not treated as a wildcard character if used with other characters in this field. For
example, using the characters "M*" limits the publisher name to only a publisher with the name "M*."
Using the characters "*x*" limits the publisher name only to the name “*x*”. A question mark (?) is not a
valid wildcard character in this field.
Product name
The asterisk (*) character used by itself represents any product name. When combined with any string
value, the rule is limited to the product of the publisher with a value in the signed certificate that matches
the character string. In other words, the asterisk is not treated as a wildcard character if used with other
characters in this field. A question mark (?) is not a valid wildcard character in this field.
File name
Either the asterisk (*) or question mark (?) characters used by themselves represent any and all file names.
When combined with any string value, the string is matched with any file name containing that string.
File version
The asterisk (*) character used by itself represents any file version. If you want to limit the file version to a
specific version or as a starting point, you can state the file version and then use the following options to
apply limits:
Exactly. The rule applies only to this version of the app
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.
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, product name, and file name Any version of the named file for the named product that is
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.
For an overview of the three types of AppLocker rule conditions and explanations of the advantages and
disadvantages of each, see Understanding AppLocker rule condition types.
Related topics
How AppLocker works
Understanding the path rule condition in AppLocker
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic explains the AppLocker path rule condition, the advantages and disadvantages, and how it is applied.
The path condition identifies an application by its location in the file system of the computer or on the network.
When creating a rule that uses a deny action, path conditions are less secure than publisher and file hash
conditions for preventing access to a file because a user could easily copy the file to a different location than the
location specified in the rule. Because path rules specify locations within the file system, you should ensure that
there are no subdirectories that are writable by non-administrators. For example, if you create a path rule for C:\
with the allow action, any file under that location will be allowed to run, including within users' profiles. The
following table describes the advantages and disadvantages of the path condition.
You can easily control many folders or a single file. It might be less secure if a rule that is configured
to use a folder path contains subfolders that are
You can use the asterisk (*) as a wildcard character writable by non-administrators.
within path rules.
You must specify the full path to a file or folder
when creating path rules so that the rule will be
properly enforced.
AppLocker does not enforce rules that specify paths with short names. You should always specify the full path to
a file or folder when creating path rules so that the rule will be properly enforced.
The asterisk (*) wildcard character can be used within Path field. The asterisk (*) character used by itself
represents any path. When combined with any string value, the rule is limited to the path of the file and all the
files under that path. For example, %ProgramFiles%\Internet Explorer\* indicates that all files and subfolders
within the Internet Explorer folder will be affected by the rule.
AppLocker uses path variables for well-known directories in Windows. Path variables are not environment
variables. The AppLocker engine can only interpret AppLocker path variables. The following table details these
path variables.
For an overview of the three types of AppLocker rule conditions and explanations of the advantages and
disadvantages of each, see Understanding AppLocker rule condition types.
Related topics
How AppLocker works
Understanding the file hash rule condition in
AppLocker
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic explains the AppLocker file hash rule condition, the advantages and disadvantages, and how it is
applied.
File hash rules use a system-computed cryptographic hash of the identified file. For files that are not digitally
signed, file hash rules are more secure than path rules. The following table describes the advantages and
disadvantages of the file hash condition.
Because each file has a unique hash, a file hash condition Each time that the file is updated (such as a security update
applies to only one file. or upgrade), the file's hash will change. As a result, you must
manually update file hash rules.
For an overview of the three types of AppLocker rule conditions and explanations of the advantages and
disadvantages of each, see Understanding AppLocker rule condition types.
Related topics
How AppLocker works
Understanding AppLocker default rules
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for IT professional describes the set of rules that can be used to ensure that required Windows system
files are allowed to run when the policy is applied.
AppLocker includes default rules for each rule collection. These rules are intended to help ensure that the files
that are required for Windows to operate properly are allowed in an AppLocker rule collection.
Important: You can use the default rules as a template when creating your own rules. However, these rules
are only meant to function as a starter policy when you are first testing AppLocker rules so that the system
files in the Windows folders will be allowed to run.
If you require additional app security, you might need to modify the rules created from the built-in default rule
collection. For example, the default rule to allow all users to run .exe files in the Windows folder is based on a
path condition that allows all files within the Windows folder to run. The Windows folder contains a Temp
subfolder to which the Users group is given the following permissions:
Traverse Folder/Execute File
Create Files/Write Data
Create Folders/Append Data
These permissions settings are applied to this folder for app compatibility. However, because any user can create
files in this location, allowing applications to be run from this location might conflict with your organization's
security policy.
In this section
TOPIC DESCRIPTION
Executable rules in AppLocker This topic describes the file formats and available default
rules for the executable rule collection.
Windows Installer rules in AppLocker This topic describes the file formats and available default
rules for the Windows Installer rule collection.
Script rules in AppLocker This topic describes the file formats and available default
rules for the script rule collection.
DLL rules in AppLocker This topic describes the file formats and available default
rules for the DLL rule collection.
Packaged apps and packaged app installer rules in This topic explains the AppLocker rule collection for packaged
AppLocker app installers and packaged apps.
Related topics
How AppLocker works
Create AppLocker default rules
Executable rules in AppLocker
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic describes the file formats and available default rules for the executable rule collection.
AppLocker defines executable rules as any files with the .exe and .com extensions that are associated with an app.
Because all of the default rules for the executable rule collection are based on folder paths, all files under those
paths will be allowed. The following table lists the default rules that are available for the executable rule collection.
Allow members of the local (Default Rule) All files BUILTIN\Administrators Path: *
Administrators group access
to run all executable files
Allow all users to run (Default Rule) All files located Everyone Path: %windir%*
executable files in the in the Windows folder
Windows folder
Allow all users to run (Default Rule) All files located Everyone Path: %programfiles%*
executable files in the in the Program Files folder
Program Files folder
Related topics
Understanding AppLocker Default Rules
Windows Installer rules in AppLocker
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic describes the file formats and available default rules for the Windows Installer rule collection.
AppLocker defines Windows Installer rules to include only the following file formats:
.msi
.msp
.mst
The purpose of this collection is to allow you to control the installation of files on client computers and servers
through Group Policy or the Local Security Policy snap-in. The following table lists the default rules that are
available for the Windows Installer rule collection.
Allow members of the local (Default Rule) All Windows BUILTIN\Administrators Path: *
Administrators group to run Installer files
all Windows Installer files
Allow all users to run (Default Rule) All digitally Everyone Publisher: * (all signed files)
Windows Installer files that signed Windows Installer
are digitally signed files
Allow all users to run (Default Rule) All Windows Everyone Path: %windir%\Installer*
Windows Installer files that Installer files in
are located in the Windows %systemdrive%\Windows\In
Installer folder staller
Related topics
Understanding AppLocker default rules
Script rules in AppLocker
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic describes the file formats and available default rules for the script rule collection.
AppLocker defines script rules to include only the following file formats:
.ps1
.bat
.cmd
.vbs
.js
The following table lists the default rules that are available for the script rule collection.
Allows members of the local (Default Rule) All scripts BUILTIN\Administrators Path: *
Administrators group to run
all scripts
Allow all users to run scripts (Default Rule) All scripts Everyone Path: %windir%*
in the Windows folder located in the Windows
folder
Allow all users to run scripts (Default Rule) All scripts Everyone Path: %programfiles%*
in the Program Files folder located in the Program Files
folder
Related topics
Understanding AppLocker default rules
DLL rules in AppLocker
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic describes the file formats and available default rules for the DLL rule collection.
AppLocker defines DLL rules to include only the following file formats:
.dll
.ocx
The following table lists the default rules that are available for the DLL rule collection.
BUILTIN\Administrators Path: *
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 apps
Caution: When DLL rules are used, AppLocker must check each DLL that an app loads. Therefore, users may
experience a reduction in performance if DLL rules are used.
Related topics
Understanding AppLocker default rules
Packaged apps and packaged app installer rules in
AppLocker
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic explains the AppLocker rule collection for packaged app installers and packaged apps.
Universal Windows apps can be installed through the Microsoft Store or can be sideloaded using the Windows
PowerShell cmdlets. Universal Windows apps can be installed by a standard user unlike some Classic Windows
applications that sometimes require administrative privileges for installation. Typically, an app consists of multiple
components – the installer used to install the app and one or more exes, dlls or scripts. With Classic Windows
applications, not all those components always share common attributes such as the publisher name, product
name and product version. Therefore, AppLocker has to control each of these components separately through
different rule collections – exe, dll, script and Windows Installers. In contrast, all the components of a Universal
Windows app share the same attributes: Publisher name, Package name and Package version. It is therefore
possible to control an entire app with a single rule.
AppLocker enforces rules for Universal Windows apps separately from Classic Windows applications. A single
AppLocker rule for a Universal Windows app can control both the installation and the running of an app. Because
all Universal Windows apps are signed, AppLocker supports only publisher rules for Universal Windows apps. A
publisher rule for a Universal Windows app is based on the following attributes of the app:
Publisher name
Package name
Package version
In summary, including AppLocker rules for Universal Windows apps in your policy design provides:
The ability to control the installation and running of the app
The ability to control all the components of the app with a single rule rather than controlling individual
binaries within the app
The ability to create application control policies that survive app updates
Management of Universal Windows apps through Group Policy.
AppLocker architecture and components
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for IT professional describes AppLocker’s basic architecture and its major components.
AppLocker relies on the Application Identity service to provide attributes for a file and to evaluate the AppLocker
policy for the file. AppLocker policies are conditional access control entries (ACEs), and policies are evaluated by
using the attribute-based access control SeAccessCheckWithSecurityAttributes or AuthzAccessCheck
functions.
AppLocker provides three ways to intercept and validate if a file is allowed to execute according to an AppLocker
policy.
A new process is created
When a new process is created, such as an executable file or a Universal Windows app is run, AppLocker invokes
the Application Identity component to calculate the attributes of the main executable file used to create a new
process. It then updates the new process's token with these attributes and checks the AppLocker policy to verify
that the executable file is allowed to run.
A DLL is loaded
When a new DLL loads, a notification is sent to AppLocker to verify that the DLL is allowed to load. AppLocker
calls the Application Identity component to calculate the file attributes. It duplicates the existing process token and
replaces those Application Identity attributes in the duplicated token with attributes of the loaded DLL. AppLocker
then evaluates the policy for this DLL, and the duplicated token is discarded. Depending on the result of this check,
the system either continues to load the DLL or stops the process.
A script is run
Before a script file is run, the script host (for example. for .ps1 files the script host is PowerShell) invokes
AppLocker to verify the script. AppLocker invokes the Application Identity component in user-mode with the file
name or file handle to calculate the file properties. The script file then is evaluated against the AppLocker policy to
verify that it is allowed to run. In each case, the actions taken by AppLocker are written to the event log.
Related topics
AppLocker technical reference
AppLocker processes and interactions
9/5/2018 • 5 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for the IT professional describes the process dependencies and interactions when AppLocker evaluates
and enforces rules.
Related topics
AppLocker technical reference
AppLocker functions
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for the IT professional lists the functions and security levels for the Software Restriction Policies (SRP )
and AppLocker features.
Functions
The following list includes the SRP functions beginning with Windows Server 2003 and AppLocker functions
beginning with Windows Server 2008 R2 and links to current documentation on MSDN:
SaferGetPolicyInformation Function
SaferCreateLevel Function
SaferCloseLevel Function
SaferIdentifyLevel Function
SaferComputeTokenFromLevel Function
SaferGetLevelInformation Function
SaferRecordEventLogEntry Function
SaferiIsExecutableFileType Function
Security level ID
AppLocker and SRP use the security level IDs to stipulate the access requirements to files listed in policies. The
following table shows those security levels supported in SRP and AppLocker.
Related topics
AppLocker technical reference
Security considerations for AppLocker
9/5/2018 • 4 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for the IT professional describes the security considerations you need to address when implementing
AppLocker.
The purpose of AppLocker is to restrict the access to software, and therefore, the data accessed by the software, to
a specific group of users or within a defined business group. The following are security considerations for
AppLocker:
AppLocker is deployed within an enterprise and administered centrally by those in IT with trusted credentials. This
makes its policy creation and deployment conform to similar policy deployment processes and security
restrictions.
AppLocker policies are distributed through known processes and by known means within the domain through
Group Policy. But AppLocker policies can also be set on individual computers if the person has administrator
privileges, and those policies might be contrary to the organization's written security policy. The enforcement
settings for local policies are overridden by the same AppLocker policies in a Group Policy Object (GPO ).
However, because AppLocker rules are additive, a local policy that is not in a GPO will still be evaluated for that
computer.
Microsoft does not provide a way to develop any extensions to AppLocker. The interfaces are not public. A user
with administrator credentials can automate some AppLocker processes by using Windows PowerShell cmdlets.
For info about the Windows PowerShell cmdlets for AppLocker, see the AppLocker Cmdlets in Windows
PowerShell.
AppLocker runs in the context of Administrator or LocalSystem, which is the highest privilege set. This security
context has the potential of misuse. If a user with administrative credentials makes changes to an AppLocker
policy on a local device that is joined to a domain, those changes could be overwritten or disallowed by the GPO
that contains the AppLocker rule for the same file (or path) that was changed on the local device. However,
because AppLocker rules are additive, a local policy that is not in a GPO will still be evaluated for that computer. If
the local computer is not joined to a domain and is not administered by Group Policy, a person with administrative
credentials can alter the AppLocker policy.
When securing files in a directory with a rule of the path condition type, whether using the allow or deny action on
the rule, it is still necessary and good practice to restrict access to those files by setting the access control lists
(ACLs) according to your security policy.
AppLocker does not protect against running 16-bit DOS binaries in the Virtual DOS Machine (NTVDM ). This
technology allows running legacy DOS and 16-bit Windows programs on computers that are using Intel 80386 or
later when there is already another operating system running and controlling the hardware. The result is that 16-
bit binaries can still run on Windows Server 2008 R2 and Windows 7 when AppLocker is configured to otherwise
block binaries and libraries. If it is a requirement to prevent 16-bit applications from running, you must configure
the Deny rule in the executable rule collection for NTVDM.exe.
You cannot use AppLocker (or Software Restriction Policies) to prevent code from running outside the Win32
subsystem. In particular, this applies to the (POSIX) subsystem in Windows NT. If it is a requirement to prevent
applications from running in the POSIX subsystem, you must disable the subsystem.
AppLocker can only control VBScript, JScript, .bat files, .cmd files, and Windows PowerShell scripts. It does not
control all interpreted code that runs within a host process, for example, Perl scripts and macros. Interpreted code
is a form of executable code that runs within a host process. For example, Windows batch files (*.bat) run within
the context of the Windows Command Host (cmd.exe). To control interpreted code by using AppLocker, the host
process must call AppLocker before it runs the interpreted code, and then enforce the decision returned by
AppLocker. Not all host processes call into AppLocker and, therefore, AppLocker cannot control every kind of
interpreted code, such as Microsoft Office macros.
Important: You should configure the appropriate security settings of these host processes if you must allow
them to run. For example, configure the security settings in Microsoft Office to ensure that only signed and
trusted macros are loaded.
AppLocker rules either allow or prevent an application from launching. AppLocker does not control the behavior
of applications after they are launched. Applications could contain flags passed to functions that signal AppLocker
to circumvent the rules and allow another .exe or .dll to be loaded. In practice, an application that is allowed by
AppLocker could use these flags to bypass AppLocker rules and launch child processes. You must thoroughly
examine each application before allowing them to run by using AppLocker rules.
Note: Two flags that illustrate this condition are SANDBOX_INERT , which can be passed to
CreateRestrictedToken , and LOAD_IGNORE_CODE_AUTHZ_LEVEL , which can be passed to LoadLibraryEx . Both of
these flags signal AppLocker to circumvent the rules and allow a child .exe or .dll to be loaded.
You can block the Windows Subsystem for Linux by blocking LxssManager.dll.
Related topics
AppLocker technical reference
Tools to use with AppLocker
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for the IT professional describes the tools available to create and administer AppLocker policies.
The following tools can help you administer the application control policies created by using AppLocker on the
local device or by using Group Policy. For info about the basic requirements for using AppLocker, see
Requirements to use AppLocker.
AppLocker Local Security Policy MMC snap-in
The AppLocker rules can be maintained by using the Local Security Policy snap-in (secpol.msc) of the
Microsoft Management Console (MMC ). For procedures to create, modify, and delete AppLocker rules, see
Working with AppLocker rules.
Generate Default Rules tool
AppLocker includes default rules for each rule collection accessed through the Local Security Policy snap-in.
These rules are intended to help ensure that the files that are required for Windows to operate properly are
allowed in an AppLocker rule collection. For info about how to use this tool, see Create AppLocker default
rules. For a list of the default rules, see AppLocker default rules.
Automatically Generate AppLocker Rules wizard
By using the Local Security Policy snap-in, you can automatically generate rules for all files within a folder.
The wizard will scan the specified folder and create the condition types that you choose for each file in that
folder. For info about how to use this wizard, see Run the Automatically Generate Rules wizard.
Group Policy
You can edit an AppLocker policy by adding, changing, or removing rules by using the Group Policy
Management Console (GPMC ).
If you want additional features to manage AppLocker policies, such as version control, use Group Policy
management software that allows you to create versions of Group Policy Objects (GPOs). An example of
this type of software is the Advanced Group Policy Management feature from the Microsoft Desktop
Optimization Pack.
Remote Server Administration Tools (RSAT)
You can use a device with a supported operating system that has the Remote Server Administration Tools
(RSAT) installed to create and maintain AppLocker policies.
Event Viewer
The AppLocker log contains information about applications that are affected by AppLocker rules. For info
about using Event Viewer to review the AppLocker logs, see Using Event Viewer with AppLocker, and
Monitor app usage with AppLocker.
AppLocker PowerShell cmdlets
The AppLocker Windows PowerShell cmdlets are designed to streamline the administration of AppLocker
policy. They can be used to help create, test, maintain, and troubleshoot an AppLocker policy. The cmdlets
are intended to be used in conjunction with the AppLocker user interface that is accessed through the Local
Security Policy snap-in and the GPMC. For information about the cmdlets, see the AppLocker PowerShell
Command Reference.
Related topics
AppLocker technical reference
Using Event Viewer with AppLocker
9/5/2018 • 3 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic lists AppLocker events and describes how to use Event Viewer with AppLocker.
The AppLocker log contains information about applications that are affected by AppLocker rules. Each event in the
log contains detailed info about:
Which file is affected and the path of that file
Which packaged app is affected and the package identifier of the app
Whether the file or packaged app is allowed or blocked
The rule type (path, file hash, or publisher)
The rule name
The security identifier (SID ) for the user or group identified in the rule
Review the entries in the Event Viewer to determine if any applications are not included in the rules that you
automatically generated. For instance, some line-of-business apps are installed to non-standard locations, such as
the root of the active drive (for example: %SystemDrive%).
For info about what to look for in the AppLocker event logs, see Monitor app usage with AppLocker.
To review the AppLocker log in Event Viewer
1. Open Event Viewer.
2. In the console tree under Application and Services Logs\Microsoft\Windows, click AppLocker.
The following table contains information about the events that you can use to determine which apps are affected
by AppLocker rules.
8000 Error Application Identity Policy Indicates that the policy was
conversion failed. Status * not applied correctly to the
<%1> * computer. The status
message is provided for
troubleshooting purposes.
8001 Information The AppLocker policy was Indicates that the AppLocker
applied successfully to this policy was successfully
computer. applied to the computer.
8002 Information *<File name> * was allowed Specifies that the .exe or .dll
to run. file is allowed by an
AppLocker rule.
EVENT ID LEVEL EVENT MESSAGE DESCRIPTION
8003 Warning *<File name> * was allowed Applied only when the
to run but would have been **Audit only ** enforcement
prevented from running if mode is enabled. Specifies
the AppLocker policy were that the .exe or .dll file would
enforced. be blocked if the **Enforce
rules ** enforcement mode
were enabled.
8005 Information *<File name> * was allowed Specifies that the script or
to run. .msi file is allowed by an
AppLocker rule.
8006 Warning *<File name> * was allowed Applied only when the
to run but would have been **Audit only ** enforcement
prevented from running if mode is enabled. Specifies
the AppLocker policy were that the script or .msi file
enforced. would be blocked if the
**Enforce rules **
enforcement mode were
enabled.
Related topics
Tools to use with AppLocker
AppLocker settings
9/5/2018 • 2 minutes to read • Edit Online
Applies to
Windows 10
Windows Server
This topic for the IT professional lists the settings used by AppLocker.
The following table describes the settings and values used by AppLocker.
SETTING VALUE
Related topics
AppLocker technical reference