Merge branch 'main' of https://github.com/MicrosoftDocs/windows-docs-pr into v-alemieux-working

This commit is contained in:
Aaron Czechowski
2023-10-02 11:42:34 -07:00
3480 changed files with 78270 additions and 67743 deletions

View File

@ -0,0 +1,47 @@
---
title: Windows Defender Application Control and virtualization-based code integrity
description: Hardware and software system integrity-hardening capabilities that can be deployed separately or in combination with Windows Defender Application Control (WDAC).
ms.prod: windows-client
ms.localizationpriority: medium
author: vinaypamnani-msft
ms.author: vinpa
manager: aaroncz
ms.technology: itpro-security
ms.date: 03/16/2023
ms.topic: article
---
# Windows Defender Application Control and virtualization-based protection of code integrity
**Applies to**
- Windows 10
- Windows 11
- Windows Server 2016 and higher
Windows includes a set of hardware and OS technologies that, when configured together, allow enterprises to "lock down" Windows systems so they behave more like mobile devices. In this configuration, [**Windows Defender Application Control (WDAC)**](/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control) is used to restrict devices to run only approved apps, while the OS is hardened against kernel memory attacks using [**memory integrity**](../../hardware-security/enable-virtualization-based-protection-of-code-integrity.md).
> [!NOTE]
> Memory integrity is sometimes referred to as *hypervisor-protected code integrity (HVCI)* or *hypervisor enforced code integrity*, and was originally released as part of *Device Guard*. Device Guard is no longer used except to locate memory integrity and VBS settings in Group Policy or the Windows registry.
WDAC policies and memory integrity are powerful protections that can be used separately. However, when these two technologies are configured to work together, they present a strong protection capability for Windows devices.
Using WDAC to restrict devices to only authorized apps has these advantages over other solutions:
1. The Windows kernel handles enforcement of WDAC policy and requires no other services or agents.
2. The WDAC policy takes effect early in the boot sequence before nearly all other OS code and before traditional antivirus solutions run.
3. WDAC lets you set application control policy for any code that runs on Windows, including kernel mode drivers and even code that runs as part of Windows.
4. Customers can protect the WDAC policy even from local administrator tampering by digitally signing the policy. Changing signed policy requires both administrative privilege and access to the organization's digital signing process. Using signed policies makes it difficult for an attacker, including one who has managed to gain administrative privilege, to tamper with WDAC policy.
5. You can protect the entire WDAC enforcement mechanism with memory integrity. Even if a vulnerability exists in kernel mode code, memory integrity greatly reduces the likelihood that an attacker could successfully exploit it. Without memory integrity, an attacker who compromises the kernel could normally disable most system defenses, including application control policies enforced by WDAC or any other application control solution.
There are no direct dependencies between WDAC and memory integrity. You can deploy them individually or together and there's no order in which they must be deployed.
Memory integrity relies on Windows virtualization-based security, and has hardware, firmware, and kernel driver compatibility requirements that some older systems can't meet.
WDAC has no specific hardware or software requirements.
## Related articles
- [Windows Defender Application Control](windows-defender-application-control/wdac.md)
- [Memory integrity](../../hardware-security/enable-virtualization-based-protection-of-code-integrity.md)
- [Driver compatibility with memory integrity](https://techcommunity.microsoft.com/t5/windows-hardware-certification/driver-compatibility-with-device-guard-in-windows-10/ba-p/364865)

View File

@ -0,0 +1,18 @@
items:
- name: Smart App Control
href: windows-defender-application-control/wdac.md
- name: Windows Defender Application Control
href: windows-defender-application-control/wdac.md
- name: Windows Defender Application Control and virtualization-based protection of code integrity
href: introduction-to-device-guard-virtualization-based-security-and-windows-defender-application-control.md
- name: User Account Control (UAC)
items:
- name: Overview
href: user-account-control/index.md
- name: How UAC works
href: user-account-control/how-it-works.md
- name: UAC settings and configuration
href: user-account-control/settings-and-configuration.md
- name: Microsoft Vulnerable Driver Blocklist
href: windows-defender-application-control/design/microsoft-recommended-driver-block-rules.md

View File

@ -0,0 +1,198 @@
---
title: How User Account Control works
description: Learn about User Account Control (UAC) components and how it interacts with the end users.
ms.collection:
- highpri
- tier2
ms.topic: concept-article
ms.date: 05/24/2023
---
# How User Account Control works
User Account Control (UAC) is a key part of Windows security. UAC reduces the risk of malware by limiting the ability of malicious code to execute with administrator privileges. This article describes how UAC works and how it interacts with the end-users.
## UAC process and interactions
With UAC, each application that requires the *administrator access token* must prompt the end user for consent. The only exception is the relationship that exists between parent and child processes. Child processes inherit the user's access token from the parent process. Both the parent and child processes, however, must have the same *integrity level*.
Windows protects processes by marking their integrity levels. Integrity levels are measurements of trust:
- A *high integrity application* is one that performs tasks that modify system data, such as a disk partitioning application
- A *low integrity application* is one that performs tasks that could potentially compromise the operating system, like as a Web brows
Applications with lower integrity levels can't modify data in applications with higher integrity levels. When a standard user attempts to run an app that requires an administrator access token, UAC requires that the user provides valid administrator credentials.
To better understand how this process works, let's take a closer look at the Windows sign in process.
## Sign in process
The following diagram shows how the sign in process for an administrator differs from the sign in process for a standard user.
:::image type="content" source="images/uac-windows-logon-process.gif" alt-text="Diagram that describes the UAC Windows logon process.":::
By default, both standard and administrator users access resources and execute apps in the security context of a standard user.\
When a user signs in, the system creates an access token for that user. The access token contains information about the level of access that the user is granted, including specific security identifiers (SIDs) and Windows privileges.
When an administrator logs on, two separate access tokens are created for the user: a *standard user access token* and an *administrator access token*. The standard user access token:
- Contains the same user-specific information as the administrator access token, but the administrative Windows privileges and SIDs are removed
- It's used to start applications that don't perform administrative tasks (standard user apps)
- It's used to display the desktop by executing the process *explorer.exe*. Explorer.exe is the parent process from which all other user-initiated processes inherit their access token. As a result, all apps run as a standard user unless a user provides consent or credentials to approve an app to use a full administrative access token
A user that is a member of the Administrators group can sign in, browse the Web, and read e-mail while using a standard user access token. When the administrator needs to perform a task that requires the administrator access token, Windows automatically prompts the user for approval. This prompt is called an *elevation prompt*, and its behavior can be configured via policy or registry.
## The UAC user experience
When UAC is enabled, the user experience for standard users is different from administrator users. The recommended and more secure method of running Windows, is to ensure your primary user account is a standard user. Running as a standard user helps to maximize security for a managed environment. With the built-in UAC elevation component, standard users can easily perform an administrative task by entering valid credentials for a local administrator account.
The default, built-in UAC elevation component for standard users is the *credential prompt*.
The alternative to running as a standard user is to run as an administrator in *Admin Approval Mode*. With the built-in UAC elevation component, members of the local Administrators group can easily perform an administrative task by providing approval.
The default, built-in UAC elevation component for an administrator account in Admin Approval Mode is called the *consent prompt*.
### The credential prompt
The credential prompt is presented when a standard user attempts to perform a task that requires a user's administrative access token. Administrators can also be required to provide their credentials by setting the **User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode** policy setting value to **Prompt for credentials**.
:::image type="content" source="images/uac-credential-prompt.png" alt-text="Screenshot showing the UAC credential prompt.":::
### The consent prompt
The consent prompt is presented when a user attempts to perform a task that requires a user's administrative access token.
:::image type="content" source="images/uac-consent-prompt-admin.png" alt-text="Screenshot showing the UAC consent prompt.":::
### UAC elevation prompts
The UAC elevation prompts are color-coded to be app-specific, enabling for easier identification of an application's potential security risk. When an app attempts to run with an administrator's full access token, Windows first analyzes the executable file to determine its publisher. Apps are first separated into three categories based on the file's publisher:
- Windows
- Publisher verified (signed)
- Publisher not verified (unsigned)
The elevation prompt color-coding is as follows:
- Gray background: The application is a Windows administrative app, such as a Control Panel item, or an application signed by a verified publisher
:::image type="content" source="images/uac-credential-prompt-signed.png" alt-text="Screenshot showing the UAC credential prompt with a signed executable.":::
- Yellow background: the application is unsigned or signed but isn't trusted
:::image type="content" source="images/uac-credential-prompt-unsigned.png" alt-text="Screenshot showing the UAC consent prompt with an unsigned executable.":::
### Shield icon
Some Control Panel items, such as **Date and Time**, contain a combination of administrator and standard user operations. Standard users can view the clock and change the time zone, but a full administrator access token is required to change the local system time. The following is a screenshot of the **Date and Time** Control Panel item.
:::image type="content" source="images/uac-shield-icon.png" alt-text="Screenshot showing the UAC Shield Icon in Date and Time Properties." border="false":::
The shield icon on the **Change date and time...** button indicates that the process requires a full administrator access token.
## Securing the elevation prompt
The elevation process is further secured by directing the prompt to the *secure desktop*. The consent and credential prompts are displayed on the secure desktop by default. Only Windows processes can access the secure desktop. For higher levels of security, we recommend keeping the **User Account Control: Switch to the secure desktop when prompting for elevation** policy setting enabled.
When an executable file requests elevation, the *interactive desktop*, also called the *user desktop*, is switched to the secure desktop. The secure desktop dims the user desktop and displays an elevation prompt that must be responded to before continuing. When the user selects **Yes** or **No**, the desktop switches back to the user desktop.
> [!NOTE]
> Starting in **Windows Server 2019**, it's not possible to paste the content of the clipboard on the secure desktop. This is the same behavior of the currently supported Windows client OS versions.
Malware can present an imitation of the secure desktop, but when the **User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode** policy setting is set to **Prompt for consent**, the malware doesn't gain elevation if the user selects **Yes** on the imitation. If the policy setting is set to **Prompt for credentials**, malware imitating the credential prompt may be able to gather the credentials from the user. However, the malware doesn't gain elevated privilege and the system has other protections that mitigate malware from taking control of the user interface even with a harvested password.
While malware could present an imitation of the secure desktop, this issue can't occur unless a user previously installed the malware on the PC. Because processes requiring an administrator access token can't silently install when UAC is enabled, the user must explicitly provide consent by selecting **Yes** or by providing administrator credentials. The specific behavior of the UAC elevation prompt is dependent upon security policies.
## UAC Architecture
The following diagram details the UAC architecture.
:::image type="content" source="images/uac-architecture.gif" alt-text="Diagram that describes the UAC architecture.":::
To better understand each component, review the following tables:
### User
|Component|Description|
|--- |--- |
|<p>User performs operation requiring privilege|<p>If the operation changes the file system or registry, Virtualization is called. All other operations call ShellExecute.|
|<p>ShellExecute|<p>ShellExecute calls CreateProcess. ShellExecute looks for the ERROR_ELEVATION_REQUIRED error from CreateProcess. If it receives the error, ShellExecute calls the Application Information service to attempt to perform the requested task with the elevated prompt.|
|<p>CreateProcess|<p>If the application requires elevation, CreateProcess rejects the call with ERROR_ELEVATION_REQUIRED.|
### System
|Component|Description|
|--- |--- |
|<p>Application Information service|<p>A system service that helps start apps that require one or more elevated privileges or user rights to run, such as local administrative tasks, and apps that require higher integrity levels. The Application Information service helps start such apps by creating a new process for the application with an administrative user's full access token when elevation is required. Depending on the configured policies, the user may give consent.|
|<p>Elevating an ActiveX install|<p>If ActiveX isn't installed, the system checks the UAC slider level. If ActiveX is installed, the **User Account Control: Switch to the secure desktop when prompting for elevation** Group Policy setting is checked.|
|<p>Check UAC slider level|<p>UAC has a slider to select from four levels of notification.<ul><li><p>**Always notify** will:<ul><li>Notify you when programs try to install software or make changes to your computer.</li><li>Notify you when you make changes to Windows settings.</li><li>Freeze other tasks until you respond.</li></ul><p>Recommended if you often install new software or visit unfamiliar websites.<br></li><li><p>**Notify me only when programs try to make changes to my computer** will:<ul><li>Notify you when programs try to install software or make changes to your computer.</li><li>Not notify you when you make changes to Windows settings.</li><li>Freeze other tasks until you respond.</li></ul><p>Recommended if you don't often install apps or visit unfamiliar websites.<br></li><li><p>**Notify me only when programs try to make changes to my computer (do not dim my desktop)** will:<ul><li>Notify you when programs try to install software or make changes to your computer.</li><li>Not notify you when you make changes to Windows settings.</li><li>Not freeze other tasks until you respond.</li></ul><p>Not recommended. Choose this only if it takes a long time to dim the desktop on your computer.<br></li><li><p>**Never notify (Disable UAC prompts)** will:<ul><li>Not notify you when programs try to install software or make changes to your computer.</li><li>Not notify you when you make changes to Windows settings.</li><li>Not freeze other tasks until you respond.</li></ul><p>Not recommended due to security concerns.|
|<p>Secure desktop enabled|<p>The **User Account Control: Switch to the secure desktop when prompting for elevation** policy setting is checked: <ul><li><p>If the secure desktop is enabled, all elevation requests go to the secure desktop regardless of prompt behavior policy settings for administrators and standard users.</li><li><p>If the secure desktop isn't enabled, all elevation requests go to the interactive user's desktop, and the per-user settings for administrators and standard users are used.|
|<p>CreateProcess|<p>CreateProcess calls AppCompat, Fusion, and Installer detection to assess if the app requires elevation. The file is then inspected to determine its requested execution level, which is stored in the application manifest for the file. CreateProcess fails if the requested execution level specified in the manifest doesn't match the access token and returns an error (ERROR_ELEVATION_REQUIRED) to ShellExecute.|
|<p>AppCompat|<p>The AppCompat database stores information in the application compatibility fix entries for an application.|
|<p>Fusion|<p>The Fusion database stores information from application manifests that describe the applications. The manifest schema is updated to add a new requested execution level field.|
|<p>Installer detection|<p>Installer detection detects setup files, which helps prevent installations from being run without the user's knowledge and consent.|
### Kernel
|Component|Description|
|--- |--- |
|<p>Virtualization|<p>Virtualization technology ensures that noncompliant apps don't silently fail to run or fail in a way that the cause can't be determined. UAC also provides file and registry virtualization and logging for applications that write to protected areas.|
|<p>File system and registry|<p>The per-user file and registry virtualization redirects per-computer registry and file write requests to equivalent per-user locations. Read requests are redirected to the virtualized per-user location first and to the per-computer location second.|
The slider never turns off UAC completely. If you set it to **Never notify**, it will:
- Keep the UAC service running
- Cause all elevation request initiated by administrators to be auto-approved without showing a UAC prompt
- Automatically deny all elevation requests for standard users
> [!IMPORTANT]
> In order to fully disable UAC you must disable the policy **User Account Control: Run all administrators in Admin Approval Mode**.
> [!WARNING]
> Some Universal Windows Platform apps may not work when UAC is disabled.
### Virtualization
Because system administrators in enterprise environments attempt to secure systems, many line-of-business (LOB) applications are designed to use only a standard user access token. As a result, you don't need to replace most apps when UAC is turned on.
Windows includes file and registry virtualization technology for apps that aren't UAC-compliant and that requires an administrator's access token to run correctly. When an administrative app that isn't UAC-compliant attempts to write to a protected folder, such as *Program Files*, UAC gives the app its own virtualized view of the resource it's attempting to change. The virtualized copy is maintained in the user's profile. This strategy creates a separate copy of the virtualized file for each user that runs the noncompliant app.
Most app tasks operate properly by using virtualization features. Although virtualization allows most applications to run, it's a short-term fix and not a long-term solution. App developers should modify their apps to be compliant as soon as possible, rather than relying on file, folder, and registry virtualization.
Virtualization isn't an option in the following scenarios:
- Virtualization doesn't apply to apps that are elevated and run with a full administrative access token
- Virtualization supports only 32-bit apps. Non-elevated 64-bit apps receive an access denied message when they attempt to acquire a handle (a unique identifier) to a Windows object. Native Windows 64-bit apps are required to be compatible with UAC and to write data into the correct locations
- Virtualization is disabled if the app includes an app manifest with a requested execution level attribute
### Request execution levels
An app manifest is an XML file that describes and identifies the shared and private side-by-side assemblies that an app should bind to at run time. The app manifest includes entries for UAC app compatibility purposes. Administrative apps that include an entry in the app manifest prompt the user for permission to access the user's access token. Although they lack an entry in the app manifest, most administrative app can run without modification by using app compatibility fixes. App compatibility fixes are database entries that enable applications that aren't UAC-compliant to work properly.
All UAC-compliant apps should have a requested execution level added to the application manifest. If the application requires administrative access to the system, marking the app with a requested execution level of *require administrator* ensures that the system identifies this program as an administrative app, and performs the necessary elevation steps. Requested execution levels specify the privileges required for an app.
### Installer detection technology
Installation programs are apps designed to deploy software. Most installation programs write to system directories and registry keys. These protected system locations are typically writeable only by an administrator in Installer detection technology, which means that standard users don't have sufficient access to install programs. Windows heuristically detects installation programs and requests administrator credentials or approval from the administrator user in order to run with access privileges. Windows also heuristically detects updates and programs that uninstall applications. One of the design goals of UAC is to prevent installations from being run without the user's knowledge and consent because installation programs write to protected areas of the file system and registry.
Installer detection only applies to:
- 32-bit executable files
- Applications without a requested execution level attribute
- Interactive processes running as a standard user with UAC enabled
Before a 32-bit process is created, the following attributes are checked to determine whether it's an installer:
- The file name includes keywords such as "install," "setup," or "update."
- Versioning Resource fields contain the following keywords: Vendor, Company Name, Product Name, File Description, Original Filename, Internal Name, and Export Name
- Keywords in the side-by-side manifest are embedded in the executable file
- Keywords in specific StringTable entries are linked in the executable file
- Key attributes in the resource script data are linked in the executable file
- There are targeted sequences of bytes within the executable file
> [!NOTE]
> The keywords and sequences of bytes were derived from common characteristics observed from various installer technologies.
> [!NOTE]
> The *User Account Control: Detect application installations and prompt for elevation* policy must be enabled for installer detection to detect installation programs. For more information, see [User Account Control settings list](settings-and-configuration.md#user-account-control-settings-list).
## Next steps
Learn more about [User Account Control settings and configuration](settings-and-configuration.md).

Binary file not shown.

After

Width:  |  Height:  |  Size: 25 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 375 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 310 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 192 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 73 KiB

View File

@ -0,0 +1,36 @@
---
title: User Account Control
description: Learn how User Account Control (UAC) helps to prevent unauthorized changes to Windows devices.
ms.collection:
- highpri
- tier2
ms.topic: overview
ms.date: 05/24/2023
---
# User Account Control overview
User Account Control (UAC) is a Windows security feature designed to protect the operating system from unauthorized changes. When changes to the system require administrator-level permission, UAC notifies the user, giving the opportunity to approve or deny the change. UAC improves the security of Windows devices by limiting the access that malicious code has to execute with administrator privileges. UAC empowers users to make informed decisions about actions that may affect the stability and security of their device.
Unless you disable UAC, malicious software is prevented from disabling or interfering with UAC settings. UAC is enabled by default, and you can configure it if you have administrative privileges.
## Benefits of UAC
UAC allows all users to sign in their devices using a *standard user account*. Processes launched using a *standard user token* may perform tasks using access rights granted to a standard user. For instance, Windows Explorer automatically inherits standard user level permissions. Any applications that are started using Windows Explorer (for example, by opening a shortcut) also run with the standard set of user permissions. Most applications, including the ones included with the operating system, are designed to work properly this way.\
Other applications, like ones that aren't designed with security settings in mind, may require more permissions to run successfully. These applications are referred to as *legacy apps*.
When a user tries to perform an action that requires administrative privileges, UAC triggers a *consent prompt*. The prompt notifies the user that a change is about to occur, asking for their permission to proceed:
- If the user approves the change, the action is performed with the highest available privilege
- If the user doesn't approve the change, the action isn't performed and the application that requested the change is prevented from running
:::image type="content" source="images/uac-consent-prompt-admin.png" alt-text="Screenshot showing the UAC consent prompt.":::
When an app requires to run with more than standard user rights, UAC allows users to run apps with their *administrator token* (that is, with administrative rights and permissions) instead of their default, standard user token. Users continue to operate in the standard user security context, while enabling certain apps to run with elevated privileges, if needed.
[!INCLUDE [user-account-control-uac](../../../../../includes/licensing/user-account-control-uac.md)]
## Next steps
- [How User Account Control works](how-it-works.md)
- [User Account Control settings and configuration](settings-and-configuration.md)

View File

@ -0,0 +1,102 @@
---
title: User Account Control settings and configuration
description: Learn about the User Account Control settings and how to configure them via Intune, CSP, group policy and registry.
ms.date: 07/31/2023
ms.topic: how-to
---
# User Account Control settings and configuration
## User Account Control settings list
The following table lists the available settings to configure the UAC behavior, and their default values.
|Setting name| Description|
|-|-|
|Admin Approval Mode for the Built-in Administrator account|Controls the behavior of Admin Approval Mode for the built-in Administrator account.<br><br>**Enabled**: The built-in Administrator account uses Admin Approval Mode. By default, any operation that requires elevation of privilege prompts the user to approve the operation.<br>**Disabled (default)**: The built-in Administrator account runs all applications with full administrative privilege.|
|Allow UIAccess applications to prompt for elevation without using the secure desktop|Controls whether User Interface Accessibility (UIAccess or UIA) programs can automatically disable the secure desktop for elevation prompts used by a standard user.<br><br>**Enabled**: UIA programs, including Remote Assistance, automatically disable the secure desktop for elevation prompts. If you don't disable the **Switch to the secure desktop when prompting for elevation** policy setting, the prompts appear on the interactive user's desktop instead of the secure desktop. This setting allows the remote administrator to provide the appropriate credentials for elevation. This policy setting doesn't change the behavior of the UAC elevation prompt for administrators. If you plan to enable this policy setting, you should also review the effect of the **Behavior of the elevation prompt for standard users** policy setting: if it's' configured as **Automatically deny elevation requests**, elevation requests aren't presented to the user.<br>**Disabled (default)**: The secure desktop can be disabled only by the user of the interactive desktop or by disabling the **Switch to the secure desktop when prompting for elevation** policy setting.|
|Behavior of the elevation prompt for administrators in Admin Approval Mode|Controls the behavior of the elevation prompt for administrators.<br><br>**Elevate without prompting**: Allows privileged accounts to perform an operation that requires elevation without requiring consent or credentials. **Use this option only in the most constrained environments**.<br>**Prompt for credentials on the secure desktop**: When an operation requires elevation of privilege, the user is prompted on the secure desktop to enter a privileged user name and password. If the user enters valid credentials, the operation continues with the user's highest available privilege.<br>**Prompt for consent on the secure desktop**: When an operation requires elevation of privilege, the user is prompted on the secure desktop to select either Permit or Deny. If the user selects Permit, the operation continues with the user's highest available privilege.<br>**Prompt for credentials**: When an operation requires elevation of privilege, the user is prompted to enter an administrative user name and password. If the user enters valid credentials, the operation continues with the applicable privilege.<br>**Prompt for consent**: When an operation requires elevation of privilege, the user is prompted to select either Permit or Deny. If the user selects Permit, the operation continues with the user's highest available privilege.<br>**Prompt for consent for non-Windows binaries (default)**: When an operation for a non-Microsoft application requires elevation of privilege, the user is prompted on the secure desktop to select either Permit or Deny. If the user selects Permit, the operation continues with the user's highest available privilege.|
|Behavior of the elevation prompt for standard users|Controls the behavior of the elevation prompt for standard users.<br><br>**Prompt for credentials (default)**: When an operation requires elevation of privilege, the user is prompted to enter an administrative user name and password. If the user enters valid credentials, the operation continues with the applicable privilege.<br>**Automatically deny elevation requests**: When an operation requires elevation of privilege, a configurable access denied error message is displayed. An enterprise that is running desktops as standard user may choose this setting to reduce help desk calls.<br>**Prompt for credentials on the secure desktop** When an operation requires elevation of privilege, the user is prompted on the secure desktop to enter a different user name and password. If the user enters valid credentials, the operation continues with the applicable privilege.|
|Detect application installations and prompt for elevation|Controls the behavior of application installation detection for the computer.<br><br>**Enabled (default)**: When an app installation package is detected that requires elevation of privilege, the user is prompted to enter an administrative user name and password. If the user enters valid credentials, the operation continues with the applicable privilege.<br>**Disabled**: App installation packages aren't detected and prompted for elevation. Enterprises that are running standard user desktops and use delegated installation technologies, such as Microsoft Intune, should disable this policy setting. In this case, installer detection is unnecessary. |
|Only elevate executables that are signed and validated|Enforces signature checks for any interactive applications that request elevation of privilege. IT admins can control which applications are allowed to run by adding certificates to the Trusted Publishers certificate store on local devices.<br><br>**Enabled**: Enforces the certificate certification path validation for a given executable file before it's permitted to run.<br>**Disabled (default)**: Doesn't enforce the certificate certification path validation before a given executable file is permitted to run.|
|Only elevate UIAccess applications that are installed in secure locations|Controls whether applications that request to run with a User Interface Accessibility (UIAccess) integrity level must reside in a secure location in the file system. Secure locations are limited to the following folders:<br>- `%ProgramFiles%`, including subfolders<br>- `%SystemRoot%\system32\`<br>- `%ProgramFiles(x86)%`, including subfolders<br><br><br>**Enabled (default)**: If an app resides in a secure location in the file system, it runs only with UIAccess integrity.<br>**Disabled**: An app runs with UIAccess integrity even if it doesn't reside in a secure location in the file system.<br><br>**Note:** Windows enforces a digital signature check on any interactive apps that requests to run with a UIAccess integrity level regardless of the state of this setting.|
|Run all administrators in Admin Approval Mode|Controls the behavior of all UAC policy settings.<br><br>**Enabled (default)**: Admin Approval Mode is enabled. This policy must be enabled and related UAC settings configured. The policy allows the built-in Administrator account and members of the Administrators group to run in Admin Approval Mode.<br>**Disabled**: Admin Approval Mode and all related UAC policy settings are disabled. Note: If this policy setting is disabled, **Windows Security** notifies you that the overall security of the operating system has been reduced.|
|Switch to the secure desktop when prompting for elevation|This policy setting controls whether the elevation request prompt is displayed on the interactive user's desktop or the secure desktop.<br><br>**Enabled (default)**: All elevation requests go to the secure desktop regardless of prompt behavior policy settings for administrators and standard users.<br>**Disabled**: All elevation requests go to the interactive user's desktop. Prompt behavior policy settings for administrators and standard users are used.|
|Virtualize File And Registry Write Failures To Per User Locations|Controls whether application write failures are redirected to defined registry and file system locations. This setting mitigates applications that run as administrator and write run-time application data to `%ProgramFiles%`, `%Windir%`, `%Windir%\system32`, or `HKLM\Software`.<br><br>**Enabled (default)**: App write failures are redirected at run time to defined user locations for both the file system and registry.<br>**Disabled**: Apps that write data to protected locations fail.|
## User Account Control configuration
To configure UAC, you can use:
- Microsoft Intune/MDM
- Group policy
- Registry
The following instructions provide details how to configure your devices. Select the option that best suits your needs.
#### [:::image type="icon" source="../../../images/icons/intune.svg" border="false"::: **Intune/MDM**](#tab/intune)
### Configure UAC with a Settings catalog policy
To configure devices using Microsoft Intune, [create a **Settings catalog** policy][MEM-2], and use the settings listed under the category **`Local Policies Security Options`**:
:::image type="content" source="images/uac-settings-catalog.png" alt-text="Screenshot that shows the UAC policies in the Intune settings catalog." lightbox="images/uac-settings-catalog.png" border="True":::
Assign the policy to a security group that contains as members the devices or users that you want to configure.
Alternatively, you can configure devices using a [custom policy][MEM-1] with the [LocalPoliciesSecurityOptions Policy CSP][WIN-1].\
The policy settings are located under: `./Device/Vendor/MSFT/Policy/Config/LocalPoliciesSecurityOptions`.
|Setting|
| - |
| **Setting name**: Admin Approval Mode for the built-in Administrator account<br>**Policy CSP name**: `UserAccountControl_UseAdminApprovalMode`|
| **Setting name**: Allow UIAccess applications to prompt for elevation without using the secure desktop<br>**Policy CSP name**: `UserAccountControl_AllowUIAccessApplicationsToPromptForElevation`|
| **Setting name**: Behavior of the elevation prompt for administrators in Admin Approval Mode<br>**Policy CSP name**: `UserAccountControl_BehaviorOfTheElevationPromptForAdministrators`|
| **Setting name**: Behavior of the elevation prompt for standard users<br>**Policy CSP name**: `UserAccountControl_BehaviorOfTheElevationPromptForStandardUsers`|
| **Setting name**: Detect application installations and prompt for elevation<br>**Policy CSP name**: `UserAccountControl_DetectApplicationInstallationsAndPromptForElevation`|
| **Setting name**: Only elevate executables that are signed and validated<br>**Policy CSP name**: `UserAccountControl_OnlyElevateExecutableFilesThatAreSignedAndValidated`|
| **Setting name**: Only elevate UIAccess applications that are installed in secure locations<br>**Policy CSP name**: `UserAccountControl_OnlyElevateUIAccessApplicationsThatAreInstalledInSecureLocations`|
| **Setting name**: Run all administrators in Admin Approval Mode<br>**Policy CSP name**: `UserAccountControl_RunAllAdministratorsInAdminApprovalMode`|
| **Setting name**: Switch to the secure desktop when prompting for elevation<br>**Policy CSP name**: `UserAccountControl_SwitchToTheSecureDesktopWhenPromptingForElevation`|
| **Setting name**: Virtualize file and registry write failures to per-user locations<br>**Policy CSP name**: `UserAccountControl_VirtualizeFileAndRegistryWriteFailuresToPerUserLocations`|
#### [:::image type="icon" source="../../../images/icons/group-policy.svg" border="false"::: **Group policy**](#tab/gpo)
You can use security policies to configure how User Account Control works in your organization. The policies can be configured locally by using the Local Security Policy snap-in (`secpol.msc`) or configured for the domain, OU, or specific groups by group policy.
The policy settings are located under: `Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options`.
| Group Policy setting |Default value|
| - | - |
|User Account Control: Admin Approval Mode for the built-in Administrator account| Disabled |
|User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop| Disabled |
|User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode| Prompt for consent for non-Windows binaries |
|User Account Control: Behavior of the elevation prompt for standard users | Prompt for credentials |
|User Account Control: Detect application installations and prompt for elevation| Enabled (default for home edition only)<br />Disabled (default) |
|User Account Control: Only elevate executables that are signed and validated| Disabled |
|User Account Control: Only elevate UIAccess applications that are installed in secure locations | Enabled |
|User Account Control: Run all administrators in Admin Approval Mode| Enabled |
|User Account Control: Switch to the secure desktop when prompting for elevation | Enabled |
|User Account Control: Virtualize file and registry write failures to per-user locations | Enabled |
#### [:::image type="icon" source="../../../images/icons/windows-os.svg" border="false"::: **Registry**](#tab/reg)
The registry keys are found under the key: `HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System`.
| Setting name | Registry key name | Value |
| - | - | - |
| Admin Approval Mode for the built-in Administrator account | `FilterAdministratorToken` | 0 (Default) = Disabled<br>1 = Enabled |
| Allow UIAccess applications to prompt for elevation without using the secure desktop | `EnableUIADesktopToggle` | 0 (Default) = Disabled<br>1 = Enabled |
| Behavior of the elevation prompt for administrators in Admin Approval Mode| `ConsentPromptBehaviorAdmin` | 0 = Elevate without prompting<br>1 = Prompt for credentials on the secure desktop<br>2 = Prompt for consent on the secure desktop<br>3 = Prompt for credentials<br>4 = Prompt for consent<br>5 (Default) = Prompt for consent for non-Windows binaries|
| Behavior of the elevation prompt for standard users | `ConsentPromptBehaviorUser` | 0 = Automatically deny elevation requests<br>1 = Prompt for credentials on the secure desktop<br>3 (Default) = Prompt for credentials |
| Detect application installations and prompt for elevation | `EnableInstallerDetection` | 1 = Enabled (default for home only)<br>0 = Disabled (default) |
| Only elevate executables that are signed and validated | `ValidateAdminCodeSignatures` | 0 (Default) = Disabled<br>1 = Enabled |
| Only elevate UIAccess applications that are installed in secure locations | `EnableSecureUIAPaths` | 0 = Disabled<br>1 (Default) = Enabled |
| Run all administrators in Admin Approval Mode | `EnableLUA` | 0 = Disabled<br>1 (Default) = Enabled |
| Switch to the secure desktop when prompting for elevation| `PromptOnSecureDesktop` | 0 = Disabled<br>1 (Default) = Enabled |
| Virtualize file and registry write failures to per-user locations | `EnableVirtualization` | 0 = Disabled<br>1 (Default) = Enabled |
[WIN-1]: /windows/client-management/mdm/policy-csp-localpoliciessecurityoptions
[MEM-1]: /mem/intune/configuration/custom-settings-windows-10
[MEM-2]: /mem/intune/configuration/settings-catalog

View File

@ -0,0 +1,38 @@
---
title: Testing and Debugging AppId Tagging Policies
description: Testing and Debugging AppId Tagging Policies to ensure your policies are deployed successfully.
ms.localizationpriority: medium
ms.date: 04/29/2022
ms.topic: article
---
# Testing and Debugging AppId Tagging Policies
> [!NOTE]
> Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
After deployment of the WDAC AppId Tagging policy, WDAC will log a 3099 policy deployed event in the [Event Viewer logs](../operations/event-id-explanations.md). You first should ensure that the policy has been successfully deployed onto the system by verifying the presence of the 3099 event.
## Verifying Tags on Running Processes
After verifying the policy has been deployed, the next step is to verify that the application processes you expect to pass the AppId Tagging policy have your tag set. Note that processes running at the time of policy deployment will need to be restarted since Windows Defender Application Control (WDAC) can only tag processes created after the policy has been deployed.
1. Download and Install the Windows Debugger
[Microsoft's WinDbg Preview application](https://www.microsoft.com/store/productId/9PGJGD53TN86) can be downloaded from the Store and used to verify tags on running processes.
2. Get the Process ID (PID) of the process under validation
Using Task Manager, or an equivalent process monitoring tool, locate the PID of the process you wish to inspect. In the example below, we've located the PID for the running process for Microsoft Edge to be 2260. The PID will be used in the next step.
![Using Task Manager to locate the process ID - PID.](../images/appid-pid-task-mgr.png)
3. Use WinDbg to inspect the process
After opening WinDbg. select File followed by `Attach to Process`, and select the process with the PID identified in the step prior. Finally, select `Attach` to connect to the process.
![Attach to the process using WinDbg.](../images/appid-pid-windbg.png)
Lastly, in the textbox, type `!token` and then press the Enter key to dump the security attributes on the process, including the _POLICYAPPID://_ followed by the key you set in the policy, and its corresponding value in the Value[0] field.
![Dump the security attributes on the process using WinDbg.](../images/appid-pid-windbg-token.png)

View File

@ -0,0 +1,42 @@
---
title: Deploying Windows Defender Application Control AppId tagging policies
description: How to deploy your WDAC AppId tagging policies locally and globally within your managed environment.
ms.localizationpriority: medium
ms.date: 04/29/2022
ms.topic: article
---
# Deploying Windows Defender Application Control AppId tagging policies
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. For more information, see [Windows Defender Application Control feature availability](../feature-availability.md).
Similar to Windows Defender Application Control (WDAC) policies, WDAC AppId tagging policies can be deployed locally and to your managed endpoints several ways. Once you've created your AppId tagging policy, use one of the following methods to deploy:
1. [Deploy AppId tagging policies with MDM](#deploy-appid-tagging-policies-with-mdm)
1. [Deploy policies with Configuration Manager](#deploy-appid-tagging-policies-with-configuration-manager)
1. [Deploy policies using scripting](#deploy-appid-tagging-policies-via-scripting)
1. [Deploy using the ApplicationControl CSP](#deploying-policies-via-the-applicationcontrol-csp)
## Deploy AppId tagging policies with MDM
Custom AppId tagging policies can be deployed to endpoints using [the OMA-URI feature in MDM](../deployment/deploy-wdac-policies-using-intune.md#deploy-wdac-policies-with-custom-oma-uri).
## Deploy AppId tagging policies with Configuration Manager
Custom AppId tagging policies can be deployed via Configuration Manager using the [deployment task sequences](../deployment/deploy-wdac-policies-with-memcm.md#deploy-custom-wdac-policies-using-packagesprograms-or-task-sequences), policies can be deployed to your managed endpoints and users.
### Deploy AppId tagging Policies via Scripting
Scripting hosts can be used to deploy AppId tagging policies as well. This approach is often best suited for local deployment, but works for deployment to managed endpoints and users too. For more information on how to deploy WDAC AppId tagging policies via scripting, see [Deploy WDAC policies using script](../deployment/deploy-wdac-policies-with-script.md). For AppId tagging policies, the only applicable method is deploying to version 1903 or later.
### Deploying policies via the ApplicationControl CSP
Multiple WDAC policies can be managed from an MDM server through ApplicationControl configuration service provider (CSP). The CSP also provides support for rebootless policy deployment.
However, when policies are unenrolled from an MDM server, the CSP will attempt to remove every policy from devices, not just the policies added by the CSP. The reason for this is that the ApplicationControl CSP doesn't track enrollment sources for individual policies, even though it will query all policies on a device, regardless if they were deployed by the CSP.
For more information, see [ApplicationControl CSP](/windows/client-management/mdm/applicationcontrol-csp) to deploy multiple policies, and optionally use Microsoft Intune's Custom OMA-URI capability.
> [!NOTE]
> WMI and GP don't currently support multiple policies. If you can't directly access the MDM stack, use the [ApplicationControl CSP via the MDM Bridge WMI Provider](/windows/client-management/mdm/applicationcontrol-csp#powershell-and-wmi-bridge-usage-guidance) to manage multiple policy format Windows Defender Application Control policies.

View File

@ -0,0 +1,104 @@
---
title: Create your Windows Defender Application Control AppId Tagging Policies
description: Create your Windows Defender Application Control AppId tagging policies for Windows devices.
ms.localizationpriority: medium
ms.date: 04/29/2022
ms.topic: article
---
# Creating your WDAC AppId Tagging Policies
> [!NOTE]
> Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
## Create the policy using the WDAC Wizard
You can use the Windows Defender Application Control (WDAC) Wizard and the PowerShell commands to create an application control policy and convert it to an AppIdTagging policy. The WDAC Wizard is available for download at the [WDAC Wizard Installer site](https://aka.ms/wdacwizard). These PowerShell commands are only available on the supported platforms listed in [AppId Tagging Guide](wdac-appid-tagging-guide.md).
1. Create a new base policy using the templates:
Start with the Policy Creator task and select Multiple Policy Format and Base Policy. Select the Base Template to use for the policy. The following example shows beginning with the [Default Windows Mode](../design/wdac-wizard-create-base-policy.md#template-base-policies) template and build on top of these rules.
![Configuring the policy base and template.](../images/appid-wdac-wizard-1.png)
> [!NOTE]
> If your AppId Tagging Policy does build off the base templates or does not allow Windows in-box processes, you will notice significant performance regressions, especially during boot. For this reason, it is strongly recommended to build off the base templates.
For more information on the issue, see the [AppId Tagging Known Issue](../operations/known-issues.md#slow-boot-and-performance-with-custom-policies).
2. Set the following rule-options using the Wizard toggles:
![Configuring the policy rule-options.](../images/appid-wdac-wizard-2.png)
3. Create custom rules:
Selecting the `+ Custom Rules` button opens the Custom Rules panel. The Wizard supports five types of file rules:
- Publisher rules: Create a rule based off the signing certificate hierarchy. Additionally, the original filename and version can be combined with the signing certificate for added security.
- Path rules: Create a rule based off the path to a file or a parent folder path. Path rules support wildcards.
- File attribute rules: Create a rule based off a file's immutable properties like the original filename, file description, product name or internal name.
- Package app name rules: Create a rule based off the package family name of an appx/msix.
- Hash rules: Create a rule based off the PE Authenticode hash of a file.
For more information on creating new policy file rules, see the guidelines provided in the [creating policy file rules section](../design/wdac-wizard-create-base-policy.md#creating-custom-file-rules).
4. Convert to AppId Tagging Policy:
After the Wizard builds the policy file, open the file in a text editor and remove the entire "Value=131" SigningScenario text block. The only remaining signing scenario should be "Value=12" which is the user mode application section. Next, open PowerShell in an elevated prompt and run the following command. Replace the AppIdTagging Key-Value pair for your scenario:
```powershell
Set-CIPolicyIdInfo -ResetPolicyID -FilePath .\AppIdPolicy.xml -AppIdTaggingPolicy -AppIdTaggingKey "MyKey" -AppIdTaggingValue "MyValue"
```
The policyID GUID is returned by the PowerShell command if successful.
## Create the policy using PowerShell
Using this method, you create an AppId Tagging policy directly using the WDAC PowerShell commands. These PowerShell commands are only available on the supported platforms listed in [AppId Tagging Guide](wdac-appid-tagging-guide.md). In an elevate PowerShell instance:
1. Create an AppId rule for the policy based on a combination of the signing certificate chain and version of the application. In the example below, the level has been set to SignedVersion. Any of the [WDAC File Rule Levels](../design/select-types-of-rules-to-create.md#table-2-windows-defender-application-control-policy---file-rule-levels) can be used in AppId rules:
```powershell
$rule = New-CiPolicyRule -Level SignedVersion -DriverFilePath <path_to_application>
```
2. Create the AppId Tagging Policy. Replace the AppIdTagging Key-Value pair for your scenario:
```powershell
New-CIPolicy -rules $rule -FilePath .\AppIdPolicy.xml -AppIdTaggingPolicy -AppIdTaggingKey "MyKey" -AppIdTaggingValue "MyValue"
```
3. Set the rule-options for the policy:
```powershell
Set-RuleOption -Option 0 .\AppIdPolicy.xml # Usermode Code Integrity (UMCI)
Set-RuleOption -Option 16 .\AppIdPolicy.xml # Refresh Policy no Reboot
Set-RuleOption -Option 18 .\AppIdPolicy.xml # (Optional) Disable FilePath Rule Protection
```
If you're using filepath rules, you may want to set option 18. Otherwise, there's no need.
4. Set the name and ID on the policy, which is helpful for future debugging:
```powershell
Set-CIPolicyIdInfo -ResetPolicyId -PolicyName "MyPolicyName" -PolicyId "MyPolicyId"" -AppIdTaggingPolicy -FilePath ".\AppIdPolicy.xml"
```
The policyID GUID is returned by the PowerShell command if successful.
## Deploy for Local Testing
After creating your AppId Tagging policy in the above steps, you can deploy the policy to your local machine for testing before broadly deploying the policy to your endpoints:
1. Depending on your deployment method, convert the xml to binary:
```powershell
Convertfrom-CIPolicy .\policy.xml ".\{PolicyIDGUID}.cip"
```
2. Optionally, deploy it for local testing:
```powershell
copy ".\{Policy ID}.cip" c:\windows\system32\codeintegrity\CiPolicies\Active\
./RefreshPolicy.exe
```
RefreshPolicy.exe is available for download from the [Microsoft Download Center](https://www.microsoft.com/download/details.aspx?id=102925).
## Next Steps
For more information on debugging and broad deployment of the AppId Tagging policy, see [Debugging AppId policies](debugging-operational-guide-appid-tagging-policies.md) and [Deploying AppId policies](deploy-appid-tagging-policies.md).

View File

@ -0,0 +1,35 @@
---
title: Designing, creating, managing and troubleshooting Windows Defender Application Control AppId Tagging policies
description: How to design, create, manage and troubleshoot your WDAC AppId Tagging policies
ms.localizationpriority: medium
ms.date: 04/27/2022
ms.topic: article
---
# WDAC Application ID (AppId) Tagging guide
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
## AppId Tagging Feature Overview
The Application ID (AppId) Tagging Policy feature, while based off Windows Defender Application Control (WDAC), does not control whether applications will run. AppId Tagging policies can be used to mark the processes of the running application with a customizable tag defined in the policy. Application processes that pass the AppId policy will receive the tag while failing applications won't.
## AppId Tagging Feature Availability
The WDAC AppId Tagging feature is available on the following versions of the Windows platform:
Client:
- Windows 10 20H1, 20H2 and 21H1 versions only
- Windows 11
Server:
- Windows Server 2022
## In this section
| Topic | Description |
| - | - |
| [Designing and Creating AppId Policies](design-create-appid-tagging-policies.md) | This topic covers how to design and create AppId Tagging policies. |
| [Deploying AppId Policies](deploy-appid-tagging-policies.md) | This topic covers how to deploy AppId Tagging policies. |
| [Debugging AppId Policies](debugging-operational-guide-appid-tagging-policies.md) | This topic covers how to debug and view events from AppId Tagging policies. |

View File

@ -0,0 +1,319 @@
- name: Application Control for Windows
href: index.yml
- name: About application control for Windows
href: wdac.md
expanded: true
items:
- name: WDAC and AppLocker Overview
href: wdac-and-applocker-overview.md
- name: WDAC and AppLocker Feature Availability
href: feature-availability.md
- name: Virtualization-based protection of code integrity
href: ../introduction-to-device-guard-virtualization-based-security-and-windows-defender-application-control.md
- name: WDAC design guide
href: design/wdac-design-guide.md
items:
- name: Plan for WDAC policy lifecycle management
href: design/plan-wdac-management.md
- name: Design your WDAC policy
items:
- name: Understand WDAC policy design decisions
href: design/understand-wdac-policy-design-decisions.md
- name: Understand WDAC policy rules and file rules
href: design/select-types-of-rules-to-create.md
items:
- name: Allow apps installed by a managed installer
href: design/configure-authorized-apps-deployed-with-a-managed-installer.md
- name: Allow reputable apps with Intelligent Security Graph (ISG)
href: design/use-wdac-with-intelligent-security-graph.md
- name: Allow COM object registration
href: design/allow-com-object-registration-in-wdac-policy.md
- name: Use WDAC with .NET hardening
href: design/wdac-and-dotnet.md
- name: Script enforcement with Windows Defender Application Control
href: design/script-enforcement.md
- name: Manage packaged apps with WDAC
href: design/manage-packaged-apps-with-wdac.md
- name: Use WDAC to control specific plug-ins, add-ins, and modules
href: design/use-wdac-policy-to-control-specific-plug-ins-add-ins-and-modules.md
- name: Understand WDAC policy settings
href: design/understanding-wdac-policy-settings.md
- name: Use multiple WDAC policies
href: design/deploy-multiple-wdac-policies.md
- name: Create your WDAC policy
items:
- name: Example WDAC base policies
href: design/example-wdac-base-policies.md
- name: Policy creation for common WDAC usage scenarios
href: design/common-wdac-use-cases.md
items:
- name: Create a WDAC policy for lightly managed devices
href: design/create-wdac-policy-for-lightly-managed-devices.md
- name: Create a WDAC policy for fully managed devices
href: design/create-wdac-policy-for-fully-managed-devices.md
- name: Create a WDAC policy for fixed-workload devices
href: design/create-wdac-policy-using-reference-computer.md
- name: Create a WDAC deny list policy
href: design/create-wdac-deny-policy.md
- name: Applications that can bypass WDAC and how to block them
href: design/applications-that-can-bypass-wdac.md
- name: Microsoft recommended driver block rules
href: design/microsoft-recommended-driver-block-rules.md
- name: Use the WDAC Wizard tool
href: design/wdac-wizard.md
items:
- name: Create a base WDAC policy with the Wizard
href: design/wdac-wizard-create-base-policy.md
- name: Create a supplemental WDAC policy with the Wizard
href: design/wdac-wizard-create-supplemental-policy.md
- name: Editing a WDAC policy with the Wizard
href: design/wdac-wizard-editing-policy.md
- name: Creating WDAC Policy Rules from WDAC Events
href: design/wdac-wizard-parsing-event-logs.md
- name: Merging multiple WDAC policies with the Wizard
href: design/wdac-wizard-merging-policies.md
- name: WDAC deployment guide
href: deployment/wdac-deployment-guide.md
items:
- name: Deploy WDAC policies with MDM
href: deployment/deploy-wdac-policies-using-intune.md
- name: Deploy WDAC policies with Configuration Manager
href: deployment/deploy-wdac-policies-with-memcm.md
- name: Deploy WDAC policies with script
href: deployment/deploy-wdac-policies-with-script.md
- name: Deploy WDAC policies with group policy
href: deployment/deploy-wdac-policies-using-group-policy.md
- name: Audit WDAC policies
href: deployment/audit-wdac-policies.md
- name: Merge WDAC policies
href: deployment/merge-wdac-policies.md
- name: Enforce WDAC policies
href: deployment/enforce-wdac-policies.md
- name: Use code signing for added control and protection with WDAC
href: deployment/use-code-signing-for-better-control-and-protection.md
items:
- name: Deploy catalog files to support WDAC
href: deployment/deploy-catalog-files-to-support-wdac.md
- name: Use signed policies to protect Windows Defender Application Control against tampering
href: deployment/use-signed-policies-to-protect-wdac-against-tampering.md
- name: "Optional: Create a code signing cert for WDAC"
href: deployment/create-code-signing-cert-for-wdac.md
- name: Disable WDAC policies
href: deployment/disable-wdac-policies.md
- name: LOB Win32 Apps on S Mode
href: deployment/LOB-win32-apps-on-s.md
- name: WDAC operational guide
href: operations/wdac-operational-guide.md
items:
- name: WDAC debugging and troubleshooting
href: operations/wdac-debugging-and-troubleshooting.md
- name: Understanding Application Control event IDs
href: operations/event-id-explanations.md
- name: Understanding Application Control event tags
href: operations/event-tag-explanations.md
- name: Query WDAC events with Advanced hunting
href: operations/querying-application-control-events-centrally-using-advanced-hunting.md
- name: Known Issues
href: operations/known-issues.md
- name: Managed installer and ISG technical reference and troubleshooting guide
href: operations/configure-wdac-managed-installer.md
- name: CITool.exe technical reference
href: operations/citool-commands.md
- name: Inbox WDAC policies
href: operations/inbox-wdac-policies.md
- name: WDAC AppId Tagging guide
href: AppIdTagging/wdac-appid-tagging-guide.md
items:
- name: Creating AppId Tagging Policies
href: AppIdTagging/design-create-appid-tagging-policies.md
- name: Deploying AppId Tagging Policies
href: AppIdTagging/deploy-appid-tagging-policies.md
- name: Testing and Debugging AppId Tagging Policies
href: AppIdTagging/debugging-operational-guide-appid-tagging-policies.md
- name: AppLocker
href: applocker\applocker-overview.md
items:
- name: Administer AppLocker
href: applocker\administer-applocker.md
items:
- name: Maintain AppLocker policies
href: applocker\maintain-applocker-policies.md
- name: Edit an AppLocker policy
href: applocker\edit-an-applocker-policy.md
- name: Test and update an AppLocker policy
href: applocker\test-and-update-an-applocker-policy.md
- name: Deploy AppLocker policies by using the enforce rules setting
href: applocker\deploy-applocker-policies-by-using-the-enforce-rules-setting.md
- name: Use the AppLocker Windows PowerShell cmdlets
href: applocker\use-the-applocker-windows-powershell-cmdlets.md
- name: Use AppLocker and Software Restriction Policies in the same domain
href: applocker\use-applocker-and-software-restriction-policies-in-the-same-domain.md
- name: Optimize AppLocker performance
href: applocker\optimize-applocker-performance.md
- name: Monitor app usage with AppLocker
href: applocker\monitor-application-usage-with-applocker.md
- name: Manage packaged apps with AppLocker
href: applocker\manage-packaged-apps-with-applocker.md
- name: Working with AppLocker rules
href: applocker\working-with-applocker-rules.md
items:
- name: Create a rule that uses a file hash condition
href: applocker\create-a-rule-that-uses-a-file-hash-condition.md
- name: Create a rule that uses a path condition
href: applocker\create-a-rule-that-uses-a-path-condition.md
- name: Create a rule that uses a publisher condition
href: applocker\create-a-rule-that-uses-a-publisher-condition.md
- name: Create AppLocker default rules
href: applocker\create-applocker-default-rules.md
- name: Add exceptions for an AppLocker rule
href: applocker\configure-exceptions-for-an-applocker-rule.md
- name: Create a rule for packaged apps
href: applocker\create-a-rule-for-packaged-apps.md
- name: Delete an AppLocker rule
href: applocker\delete-an-applocker-rule.md
- name: Edit AppLocker rules
href: applocker\edit-applocker-rules.md
- name: Enable the DLL rule collection
href: applocker\enable-the-dll-rule-collection.md
- name: Enforce AppLocker rules
href: applocker\enforce-applocker-rules.md
- name: Run the Automatically Generate Rules wizard
href: applocker\run-the-automatically-generate-rules-wizard.md
- name: Working with AppLocker policies
href: applocker\working-with-applocker-policies.md
items:
- name: Configure the Application Identity service
href: applocker\configure-the-application-identity-service.md
- name: Configure an AppLocker policy for audit only
href: applocker\configure-an-applocker-policy-for-audit-only.md
- name: Configure an AppLocker policy for enforce rules
href: applocker\configure-an-applocker-policy-for-enforce-rules.md
- name: Display a custom URL message when users try to run a blocked app
href: applocker\display-a-custom-url-message-when-users-try-to-run-a-blocked-application.md
- name: Export an AppLocker policy from a GPO
href: applocker\export-an-applocker-policy-from-a-gpo.md
- name: Export an AppLocker policy to an XML file
href: applocker\export-an-applocker-policy-to-an-xml-file.md
- name: Import an AppLocker policy from another computer
href: applocker\import-an-applocker-policy-from-another-computer.md
- name: Import an AppLocker policy into a GPO
href: applocker\import-an-applocker-policy-into-a-gpo.md
- name: Add rules for packaged apps to existing AppLocker rule-set
href: applocker\add-rules-for-packaged-apps-to-existing-applocker-rule-set.md
- name: Merge AppLocker policies by using Set-ApplockerPolicy
href: applocker\merge-applocker-policies-by-using-set-applockerpolicy.md
- name: Merge AppLocker policies manually
href: applocker\merge-applocker-policies-manually.md
- name: Refresh an AppLocker policy
href: applocker\refresh-an-applocker-policy.md
- name: Test an AppLocker policy by using Test-AppLockerPolicy
href: applocker\test-an-applocker-policy-by-using-test-applockerpolicy.md
- name: AppLocker design guide
href: applocker\applocker-policies-design-guide.md
items:
- name: Understand AppLocker policy design decisions
href: applocker\understand-applocker-policy-design-decisions.md
- name: Determine your application control objectives
href: applocker\determine-your-application-control-objectives.md
- name: Create a list of apps deployed to each business group
href: applocker\create-list-of-applications-deployed-to-each-business-group.md
items:
- name: Document your app list
href: applocker\document-your-application-list.md
- name: Select the types of rules to create
href: applocker\select-types-of-rules-to-create.md
items:
- name: Document your AppLocker rules
href: applocker\document-your-applocker-rules.md
- name: Determine the Group Policy structure and rule enforcement
href: applocker\determine-group-policy-structure-and-rule-enforcement.md
items:
- name: Understand AppLocker enforcement settings
href: applocker\understand-applocker-enforcement-settings.md
- name: Understand AppLocker rules and enforcement setting inheritance in Group Policy
href: applocker\understand-applocker-rules-and-enforcement-setting-inheritance-in-group-policy.md
- name: Document the Group Policy structure and AppLocker rule enforcement
href: applocker\document-group-policy-structure-and-applocker-rule-enforcement.md
- name: Plan for AppLocker policy management
href: applocker\plan-for-applocker-policy-management.md
- name: AppLocker deployment guide
href: applocker\applocker-policies-deployment-guide.md
items:
- name: Understand the AppLocker policy deployment process
href: applocker\understand-the-applocker-policy-deployment-process.md
- name: Requirements for Deploying AppLocker Policies
href: applocker\requirements-for-deploying-applocker-policies.md
- name: Use Software Restriction Policies and AppLocker policies
href: applocker\using-software-restriction-policies-and-applocker-policies.md
- name: Create Your AppLocker policies
href: applocker\create-your-applocker-policies.md
items:
- name: Create Your AppLocker rules
href: applocker\create-your-applocker-rules.md
- name: Deploy the AppLocker policy into production
href: applocker\deploy-the-applocker-policy-into-production.md
items:
- name: Use a reference device to create and maintain AppLocker policies
href: applocker\use-a-reference-computer-to-create-and-maintain-applocker-policies.md
items:
- name: Determine which apps are digitally signed on a reference device
href: applocker\determine-which-applications-are-digitally-signed-on-a-reference-computer.md
- name: Configure the AppLocker reference device
href: applocker\configure-the-appLocker-reference-device.md
- name: AppLocker technical reference
href: applocker\applocker-technical-reference.md
items:
- name: What Is AppLocker?
href: applocker\what-is-applocker.md
- name: Requirements to use AppLocker
href: applocker\requirements-to-use-applocker.md
- name: AppLocker policy use scenarios
href: applocker\applocker-policy-use-scenarios.md
- name: How AppLocker works
href: applocker\how-applocker-works-techref.md
items:
- name: Understanding AppLocker rule behavior
href: applocker\understanding-applocker-rule-behavior.md
- name: Understanding AppLocker rule exceptions
href: applocker\understanding-applocker-rule-exceptions.md
- name: Understanding AppLocker rule collections
href: applocker\understanding-applocker-rule-collections.md
- name: Understanding AppLocker allow and deny actions on rules
href: applocker\understanding-applocker-allow-and-deny-actions-on-rules.md
- name: Understanding AppLocker rule condition types
href: applocker\understanding-applocker-rule-condition-types.md
items:
- name: Understanding the publisher rule condition in AppLocker
href: applocker\understanding-the-publisher-rule-condition-in-applocker.md
- name: Understanding the path rule condition in AppLocker
href: applocker\understanding-the-path-rule-condition-in-applocker.md
- name: Understanding the file hash rule condition in AppLocker
href: applocker\understanding-the-file-hash-rule-condition-in-applocker.md
- name: Understanding AppLocker default rules
href: applocker\understanding-applocker-default-rules.md
items:
- name: Executable rules in AppLocker
href: applocker\executable-rules-in-applocker.md
- name: Windows Installer rules in AppLocker
href: applocker\windows-installer-rules-in-applocker.md
- name: Script rules in AppLocker
href: applocker\script-rules-in-applocker.md
- name: DLL rules in AppLocker
href: applocker\dll-rules-in-applocker.md
- name: Packaged apps and packaged app installer rules in AppLocker
href: applocker\packaged-apps-and-packaged-app-installer-rules-in-applocker.md
- name: AppLocker architecture and components
href: applocker\applocker-architecture-and-components.md
- name: AppLocker processes and interactions
href: applocker\applocker-processes-and-interactions.md
- name: AppLocker functions
href: applocker\applocker-functions.md
- name: Security considerations for AppLocker
href: applocker\security-considerations-for-applocker.md
- name: Tools to Use with AppLocker
href: applocker\tools-to-use-with-applocker.md
items:
- name: Using Event Viewer with AppLocker
href: applocker\using-event-viewer-with-applocker.md
- name: AppLocker Settings
href: applocker\applocker-settings.md

View File

@ -0,0 +1,18 @@
---
title: Add rules for packaged apps to existing AppLocker rule-set
description: This topic for IT professionals describes how to update your existing AppLocker policies for packaged apps using the Remote Server Administration Toolkit (RSAT).
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Add rules for packaged apps to existing AppLocker rule-set
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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 that allows you to edit the GPO or GPOs where your existing AppLocker policy is 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.

View File

@ -0,0 +1,62 @@
---
title: Administer AppLocker
description: This topic for IT professionals provides links to specific procedures to use when administering AppLocker policies.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 02/28/2019
---
# Administer AppLocker
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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](packaged-apps-and-packaged-app-installer-rules-in-applocker.md).
## In this section
| Topic | Description |
| - | - |
| [Maintain AppLocker policies](maintain-applocker-policies.md) | This topic describes how to maintain rules within AppLocker policies. |
| [Edit an AppLocker policy](edit-an-applocker-policy.md) | This topic for IT professionals describes the steps required to modify an AppLocker policy. |
| [Test and update an AppLocker policy](test-and-update-an-applocker-policy.md) | This topic discusses the steps required to test an AppLocker policy prior to deployment. |
| [Deploy AppLocker policies by using the enforce rules setting](deploy-applocker-policies-by-using-the-enforce-rules-setting.md) | This topic for IT professionals describes the steps to deploy AppLocker policies by using the enforcement setting method. |
| [Use the AppLocker Windows PowerShell cmdlets](use-the-applocker-windows-powershell-cmdlets.md) | This topic for IT professionals describes how each AppLocker Windows PowerShell cmdlet can help you administer your AppLocker application control policies. |
| [Use AppLocker and Software Restriction Policies in the same domain](use-applocker-and-software-restriction-policies-in-the-same-domain.md) | This topic for IT professionals describes concepts and procedures to help you manage your application control strategy using Software Restriction Policies and AppLocker. |
| [Optimize AppLocker performance](optimize-applocker-performance.md) | This topic for IT professionals describes how to optimize AppLocker policy enforcement. |
| [Monitor app usage with AppLocker](monitor-application-usage-with-applocker.md) | This topic for IT professionals describes how to monitor app usage when AppLocker policies are applied. |
| [Manage packaged apps with AppLocker](manage-packaged-apps-with-applocker.md) | 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](working-with-applocker-rules.md) | This topic for IT professionals describes AppLocker rule types and how to work with them for your application control policies. |
| [Working with AppLocker policies](working-with-applocker-policies.md) | This topic for IT professionals provides links to procedural topics about creating, maintaining, and testing AppLocker policies. |
## <a href="" id="bkmk-using-snapins"></a>Using the MMC snap-ins to administer AppLocker
You can administer AppLocker policies by using the Group Policy Management Console to create or edit a Group Policy Object (GPO), or to create or edit an AppLocker policy on a local computer by using the Local Group Policy Editor snap-in or the Local Security Policy snap-in (secpol.msc).
### Administer AppLocker using Group Policy
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. Also, the Group Policy Management feature must be installed on the computer.
1. Open the Group Policy Management Console (GPMC).
2. Locate the GPO that contains the AppLocker policy to modify, right-click the GPO, and then click **Edit**.
3. In the console tree, double-click **Application Control Policies**, double-click **AppLocker**, and then click the rule collection that you want to create the rule for.
### Administer AppLocker on the local PC
1. Click **Start**, type **local security policy**, and then click **Local Security Policy**.
2. If the **User Account Control** dialog box appears, confirm that the action it displays is what you want, and then click **Yes**.
3. In the console tree of the snap-in, double-click **Application Control Policies**, double-click **AppLocker**, and then click the rule collection that you want to create the rule for.
## Using Windows PowerShell to administer AppLocker
For how-to info about administering AppLocker with Windows PowerShell, see [Use the AppLocker Windows PowerShell Cmdlets](use-the-applocker-windows-powershell-cmdlets.md). For reference info and examples how to administer AppLocker with Windows PowerShell, see the [AppLocker cmdlets](/powershell/module/applocker/).

View File

@ -0,0 +1,34 @@
---
title: AppLocker architecture and components
description: This topic for IT professional describes AppLockers basic architecture and its major components.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# AppLocker architecture and components
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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's allowed to run. In each case, the actions taken by AppLocker are written to the event log.
## Related topics
- [AppLocker technical reference](applocker-technical-reference.md)

View File

@ -0,0 +1,46 @@
---
title: AppLocker functions
description: This article for the IT professional lists the functions and security levels for the Software Restriction Policies (SRP) and AppLocker features.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# AppLocker functions
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
This article for the IT professional lists the functions and security levels for the Software Restriction Policies (SRP) and AppLocker features.
## Functions
Here are the SRP functions beginning with Windows Server 2003 and AppLocker functions beginning with Windows Server 2008 R2:
- [SaferGetPolicyInformation Function](/windows/win32/api/winsafer/nf-winsafer-safergetpolicyinformation)
- [SaferCreateLevel Function](/windows/win32/api/winsafer/nf-winsafer-safercreatelevel)
- [SaferCloseLevel Function](/windows/win32/api/winsafer/nf-winsafer-safercloselevel)
- [SaferIdentifyLevel Function](/windows/win32/api/winsafer/nf-winsafer-saferidentifylevel)
- [SaferComputeTokenFromLevel Function](/windows/win32/api/winsafer/nf-winsafer-safercomputetokenfromlevel)
- [SaferGetLevelInformation Function](/windows/win32/api/winsafer/nf-winsafer-safergetlevelinformation)
- [SaferRecordEventLogEntry Function](/windows/win32/api/winsafer/nf-winsafer-saferrecordeventlogentry)
- [SaferiIsExecutableFileType Function](/windows/win32/api/winsafer/nf-winsafer-saferiisexecutablefiletype)
## Security level ID
AppLocker and SRP use the security level IDs to specify the access requirements to files listed in policies. The following table shows those security levels supported in SRP and AppLocker.
| Security level ID | SRP | AppLocker |
| - | - | - |
| SAFER_LEVELID_FULLYTRUSTED | Supported | Supported |
| SAFER_LEVELID_NORMALUSER | Supported | Not supported |
| SAFER_LEVELID_CONSTRAINED | Supported | Not supported |
| SAFER_LEVELID_UNTRUSTED | Supported | Not supported |
| SAFER_LEVELID_DISALLOWED | Supported | Supported |
>[!Note]
>URL zone ID isn't supported in AppLocker.
## Related articles
- [AppLocker technical reference](applocker-technical-reference.md)

View File

@ -0,0 +1,116 @@
---
title: AppLocker
description: This article provides a description of AppLocker and can help you decide if your organization can benefit from deploying AppLocker application control policies.
ms.collection:
- highpri
- tier3
- must-keep
ms.topic: conceptual
ms.localizationpriority: medium
ms.date: 06/07/2023
---
# AppLocker
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
This article 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.
> [!NOTE]
> AppLocker is unable to control processes running under the system account on any operating system.
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 aren't 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 configuration permits a more uniform app deployment.
- **Manageability improvement**: AppLocker includes many 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.
## When to use AppLocker
In many organizations, information is the most valuable asset, and ensuring that only approved users have access to that information is imperative. Access control technologies, such as Active Directory Rights Management Services (AD RMS) and access control lists (ACLs), help control what users are allowed to access.
However, when a user runs a process, that process has the same level of access to data that the user has. As a result, sensitive information could easily be deleted or transmitted out of the organization if a user knowingly or unknowingly runs malicious software. AppLocker can help mitigate these types of security breaches by restricting the files that users or groups are allowed to run. Software publishers are beginning to create more apps that can be installed by non-administrative users. This privilege could jeopardize an organization's written security policy and circumvent traditional app control solutions that rely on the inability of users to install apps. AppLocker creates an allowed list of approved files and apps to help prevent such per-user apps from running. Because AppLocker can control DLLs, it's also useful to control who can install and run ActiveX controls.
AppLocker is ideal for organizations that currently use Group Policy to manage their PCs.
The following are examples of scenarios in which AppLocker can be used:
- Your organization's security policy dictates the use of only licensed software, so you need to prevent users from running unlicensed software and also restrict the use of licensed software to authorized users.
- An app is no longer supported by your organization, so you need to prevent it from being used by everyone.
- 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 it's 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 prevent users from running the old version.
- Specific software tools aren't allowed within the organization, or only specific users should 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, and you need to protect specific apps.
- In addition to other measures, you need to control the access to sensitive data through app usage.
> [!NOTE]
> AppLocker is a defense-in-depth security feature and not a [security boundary](https://www.microsoft.com/msrc/windows-security-servicing-criteria). [Windows Defender Application Control](/windows/security/threat-protection/windows-defender-application-control/wdac-and-applocker-overview) should be used when the goal is to provide robust protection against a threat and there are expected to be no by-design limitations that would prevent the security feature from achieving this goal.
AppLocker can help you protect the digital assets within your organization, reduce the threat of malicious software being introduced into your environment, and improve the management of application control and the maintenance of application control policies.
## 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]
> 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.
### Using AppLocker on Server Core
AppLocker on Server Core installations isn't supported.
### Virtualization considerations
You can administer AppLocker policies by using a virtualized instance of Windows provided it meets all the system requirements listed previously. You can also run Group Policy in a virtualized instance. However, you do risk losing the policies that you created and maintain if the virtualized instance is removed or fails.
### Security considerations
Application control policies specify which apps are allowed to run on the local computer. The variety of forms that malicious software can take make it difficult for users to know what is safe to run. When activated, malicious software can damage content on a hard disk drive, flood a network with requests to cause a denial-of-service (DoS) attack, send confidential information to the Internet, or compromise the security of a computer.
The countermeasure is to create a sound design for your application control policies on PCs in your organization, and then thoroughly test the policies in a lab environment before you deploy them in a production environment. AppLocker can be part of your app control strategy because you can control what software is allowed to run on your computers.
A flawed application control policy implementation can disable necessary applications or allow malicious or unintended software to run. Therefore, it's important that organizations dedicate sufficient resources to manage and troubleshoot the implementation of such policies.
For more information about specific security issues, see [Security considerations for AppLocker](security-considerations-for-applocker.md). When you use AppLocker to create application control policies, you should be aware of the following security considerations:
- Who has the rights to set AppLocker policies?
- How do you validate that the policies are enforced?
- What events should you audit?
For reference in your security planning, the following table identifies the baseline settings for a PC with AppLocker installed:
| Setting | Default value |
|-----------------------------|---------------------------------------------------------------------------------------------------------------------------------------------|
| Accounts created | None |
| Authentication method | Not applicable |
| Management interfaces | AppLocker can be managed by using a Microsoft Management Console snap-in, Group Policy Management, and Windows PowerShell |
| Ports opened | None |
| 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. |
| Protocols used | Not applicable |
| Scheduled Tasks | Appidpolicyconverter.exe is put in a scheduled task to be run on demand. |
| Security Policies | None required. AppLocker creates security policies. |
| System Services required | Application Identity service (appidsvc) runs under LocalServiceAndNoImpersonation. |
| Storage of credentials | None |
## In this section
| Article | Description |
|----------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------|
| [Administer AppLocker](administer-applocker.md) | This article for IT professionals provides links to specific procedures to use when administering AppLocker policies. |
| [AppLocker design guide](applocker-policies-design-guide.md) | This article for the IT professional introduces the design and planning steps required to deploy application control policies by using AppLocker. |
| [AppLocker deployment guide](applocker-policies-deployment-guide.md) | This article for IT professionals introduces the concepts and describes the steps required to deploy AppLocker policies. |
| [AppLocker technical reference](applocker-technical-reference.md) | This overview article for IT professionals provides links to the articles in the technical reference. |

View File

@ -0,0 +1,47 @@
---
title: AppLocker deployment guide
description: This topic for IT professionals introduces the concepts and describes the steps required to deploy AppLocker policies.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# AppLocker deployment guide
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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's 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](using-software-restriction-policies-and-applocker-policies.md) in this guide. To understand if AppLocker is the correct application control solution for you, see [Understand AppLocker policy design decisions](understand-applocker-policy-design-decisions.md).
## Prerequisites to deploying AppLocker policies
The following are prerequisites or recommendations to deploying policies:
- Understand the capabilities of AppLocker:
- [AppLocker](applocker-overview.md)
- Document your application control policy deployment plan by addressing these tasks:
- [Understand the AppLocker policy deployment process](understand-the-applocker-policy-deployment-process.md)
- [Understand AppLocker policy design decisions](understand-applocker-policy-design-decisions.md)
- [Determine your application control objectives](determine-your-application-control-objectives.md)
- [Create list of apps deployed to each business group](create-list-of-applications-deployed-to-each-business-group.md)
- [Select types of rules to create](select-types-of-rules-to-create.md)
- [Determine Group Policy Structure and rule enforcement](determine-group-policy-structure-and-rule-enforcement.md)
- [Plan for AppLocker policy management](plan-for-applocker-policy-management.md)
## Contents of this guide
This guide provides steps based on your design and planning investigation for deploying application control policies created and maintained by AppLocker for computers running any of the supported versions of Windows listed in [Requirements to use AppLocker](requirements-to-use-applocker.md).
## In this section
| Topic | Description |
| - | - |
| [Understand the AppLocker policy deployment process](understand-the-applocker-policy-deployment-process.md) | This planning and deployment topic for the IT professional describes the process for using AppLocker when deploying application control policies. |
| [Requirements for Deploying AppLocker Policies](requirements-for-deploying-applocker-policies.md) | 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](using-software-restriction-policies-and-applocker-policies.md) | 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](create-your-applocker-policies.md) | 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](deploy-the-applocker-policy-into-production.md) | This topic for the IT professional describes the tasks that should be completed before you deploy AppLocker application control settings. |

View File

@ -0,0 +1,33 @@
---
title: AppLocker design guide
description: This topic for the IT professional introduces the design and planning steps required to deploy application control policies by using AppLocker.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# AppLocker design guide
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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's 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 doesn't 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](determine-your-application-control-objectives.md).
To understand if AppLocker is the correct application control solution for your organization, see [Understand AppLocker policy design decisions](understand-applocker-policy-design-decisions.md).
## In this section
| Topic | Description |
| - | - |
| [Understand AppLocker policy design decisions](understand-applocker-policy-design-decisions.md) | 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](determine-your-application-control-objectives.md) | 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](create-list-of-applications-deployed-to-each-business-group.md) | 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](select-types-of-rules-to-create.md) | 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](determine-group-policy-structure-and-rule-enforcement.md) | This overview topic describes the process to follow when you're planning to deploy AppLocker rules. |
| [Plan for AppLocker policy management](plan-for-applocker-policy-management.md) | This topic 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](applocker-policies-deployment-guide.md) covers the creation and testing of policies, deploying the enforcement setting, and managing and maintaining the policies.

View File

@ -0,0 +1,56 @@
---
title: AppLocker policy use scenarios
description: This topic for the IT professional lists the various application control scenarios in which AppLocker policies can be effectively implemented.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# AppLocker policy use scenarios
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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 isn't 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 configuration 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 aren't 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 apps 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 aren't 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](applocker-technical-reference.md)

View File

@ -0,0 +1,95 @@
---
title: AppLocker processes and interactions
description: This topic for the IT professional describes the process dependencies and interactions when AppLocker evaluates and enforces rules.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# AppLocker processes and interactions
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
This topic for the IT professional describes the process dependencies and interactions when AppLocker evaluates and enforces rules.
## How policies are implemented by AppLocker
AppLocker policies are collections of AppLocker rules that might contain any one of the enforcement settings configured. When applied, each rule is evaluated within the policy and the collection of rules is applied according to the enforcement setting and according to your Group Policy structure.
The AppLocker policy is enforced on a computer through the Application Identity service, which is the engine that evaluates the policies. If the service isn't running, policies won't be enforced. The Application Identity service returns the information from the binary -even if product or binary names are empty- to the results pane of the Local Security Policy snap-in.
AppLocker policies are stored in a security descriptor format according to Application Identity service requirements. It uses file path, hash, or fully qualified binary name attributes to form allow or deny actions on a rule. Each rule is stored as an access control entry (ACE) in the security descriptor and contains the following information:
- Either an allow or a deny ACE ("XA" or "XD" in security descriptor definition language (SDDL) form).
- The user security identifier (SID) that this rule is applicable to. (The default is the authenticated user SID, or "AU" in SDDL.)
- The rule condition containing the **appid** attributes.
For example, an SDDL for a rule that allows all files in the %windir% directory to run uses the following format: XA;;FX;;;AU;(APPID://PATH == "%windir%\\\*").
An AppLocker policy for DLLs and executable files is read and cached by kernel mode code, which is part of appid.sys. Whenever a new policy is applied, appid.sys is notified by a policy converter task. For other file types, the AppLocker policy is read every time a **SaferIdentifyLevel** call is made.
### Understanding AppLocker rules
An AppLocker rule is a control placed on a file to govern whether or not it's allowed to run for a specific user or group. Rules apply to five different types, or collections, of files:
- An executable rule controls whether a user or group can run an executable file. Executable files most often have the .exe or .com file name extensions and apply to applications.
- A script rule controls whether a user or group can run scripts with a file name extension of .ps1, .bat, .cmd, .vbs, and .js.
- A Windows Installer rule controls whether a user or group can run files with a file name extension of .msi, .mst and .msp (Windows Installer patch).
- A DLL rule controls whether a user or group can run files with a file name extension of .dll and .ocx.
- A packaged app and packaged app installer rule controls whether a user or group can run or install a packaged app. A Packaged app installer has the .appx extension.
There are three different types of conditions that can be applied to rules:
- A publisher condition on a rule controls whether a user or group can run files from a specific software publisher. The file must be signed.
- A path condition on a rule controls whether a user or group can run files from within a specific directory or its subdirectories.
- A file hash condition on a rule controls whether a user or group can run files with matching encrypted hashes.
- [Understanding AppLocker rule collections](understanding-applocker-rule-collections.md)
An AppLocker rule collection is a set of rules that apply to one of the following types: executable files, Windows Installer files, scripts, DLLs, and packaged apps.
- [Understanding AppLocker rule condition types](understanding-applocker-rule-condition-types.md)
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.
- [Understanding the publisher rule condition in AppLocker](understanding-the-publisher-rule-condition-in-applocker.md)
- [Understanding the path rule condition in AppLocker](understanding-the-path-rule-condition-in-applocker.md)
- [Understanding the file hash rule condition in AppLocker](understanding-the-file-hash-rule-condition-in-applocker.md)
- [Understanding AppLocker default rules](understanding-applocker-default-rules.md)
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.
- [Executable rules in AppLocker](executable-rules-in-applocker.md)
- [Windows Installer rules in AppLocker](windows-installer-rules-in-applocker.md)
- [Script rules in AppLocker](script-rules-in-applocker.md)
- [DLL rules in AppLocker](dll-rules-in-applocker.md)
- [Packaged apps and packaged app installer rules in AppLocker](packaged-apps-and-packaged-app-installer-rules-in-applocker.md)
- [Understanding AppLocker rule exceptions](understanding-applocker-rule-exceptions.md)
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 only a subset of a user group to use an application, you can create a special rule for that subset.
- [Understanding AppLocker rule behavior](understanding-applocker-rule-behavior.md) and [Understanding AppLocker allow and deny actions on Rules](understanding-applocker-allow-and-deny-actions-on-rules.md)
Each AppLocker rule collection functions as an allowed list of files.
### Understanding AppLocker policies
An AppLocker policy is a set of rule collections and their corresponding configured enforcement settings that have been applied to one or more computers.
- [Understand AppLocker enforcement settings](understand-applocker-enforcement-settings.md)
Rule enforcement is applied only to collections of rules, not individual rules. AppLocker divides the rules into four collections: executable files, Windows Installer files, scripts, 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. By default, if enforcement isn't configured and rules are present in a rule collection, those rules are enforced.
### Understanding AppLocker and Group Policy
Group Policy can be used to create, modify, and distribute AppLocker policies in separate objects or in combination with other policies.
- [Understand AppLocker rules and enforcement setting inheritance in Group Policy](understand-applocker-rules-and-enforcement-setting-inheritance-in-group-policy.md)
When Group Policy is used to distribute AppLocker policies, rule collections that aren't configured will be enforced. Group Policy doesn't overwrite or replace rules that are already present in a linked Group Policy Object (GPO) and applies the AppLocker rules in addition to existing rules.
AppLocker processes the explicit deny rule configuration before the allow rule configuration, and for rule enforcement, the last write to the GPO is applied.
## Related topics
- [AppLocker technical reference](applocker-technical-reference.md)

View File

@ -0,0 +1,30 @@
---
title: AppLocker settings
description: This topic for the IT professional lists the settings used by AppLocker.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# AppLocker settings
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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 |
| - | - |
| Registry path | Policies are stored in **HKEY_LOCAL_Machine\Software\Policies\Microsoft\Windows\SrpV2** |
| Firewall ports | Not applicable |
| Security policies | Custom created, no default |
| Group Policy settings | Custom created, no default |
| Network ports | Not applicable |
| Service accounts | Not applicable |
| Performance counters | Not applicable |
## Related topics
- [AppLocker technical reference](applocker-technical-reference.md)

View File

@ -0,0 +1,30 @@
---
title: AppLocker technical reference
description: This overview topic for IT professionals provides links to the topics in the technical reference.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# AppLocker technical reference
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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?](what-is-applocker.md) | This topic for the IT professional describes what AppLocker is and how its features differ from Software Restriction Policies. |
| [Requirements to use AppLocker](requirements-to-use-applocker.md) | This topic for the IT professional lists software requirements to use AppLocker on the supported Windows operating systems. |
| [AppLocker policy use scenarios](applocker-policy-use-scenarios.md) | This topic for the IT professional lists the various application control scenarios in which AppLocker policies can be effectively implemented. |
| [How AppLocker works](how-applocker-works-techref.md) | 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](applocker-architecture-and-components.md) | This topic for IT professional describes AppLocker's basic architecture and its major components. |
| [AppLocker processes and interactions](applocker-processes-and-interactions.md) | This topic for the IT professional describes the process dependencies and interactions when AppLocker evaluates and enforces rules. |
| [AppLocker functions](applocker-functions.md) | 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](security-considerations-for-applocker.md) | This topic for the IT professional describes the security considerations you need to address when implementing AppLocker. |
| [Tools to Use with AppLocker](tools-to-use-with-applocker.md) | This topic for the IT professional describes the tools available to create and administer AppLocker policies. |
| [AppLocker Settings](applocker-settings.md) | This topic for the IT professional lists the settings used by AppLocker. |

View File

@ -0,0 +1,27 @@
---
title: Configure an AppLocker policy for audit only
description: This topic for IT professionals describes how to set AppLocker policies to Audit only within your IT environment by using AppLocker.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 06/08/2018
---
# Configure an AppLocker policy for audit only
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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](administer-applocker.md#bkmk-using-snapins).
**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**.

View File

@ -0,0 +1,28 @@
---
title: Configure an AppLocker policy for enforce rules
description: This topic for IT professionals describes the steps to enable the AppLocker policy enforcement setting.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Configure an AppLocker policy for enforce rules
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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](understand-applocker-rules-and-enforcement-setting-inheritance-in-group-policy.md).
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](administer-applocker.md#bkmk-using-snapins).
**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're 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](monitor-application-usage-with-applocker.md).

View File

@ -0,0 +1,30 @@
---
title: Add exceptions for an AppLocker rule
description: This topic for IT professionals describes the steps to specify which apps can or cannot run as exceptions to an AppLocker rule.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Add exceptions for an AppLocker rule
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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](understanding-applocker-rule-exceptions.md).
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](administer-applocker.md#bkmk-using-snapins).
**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.

View File

@ -0,0 +1,44 @@
---
title: Configure the AppLocker reference device
description: This topic for the IT professional describes the steps to create an AppLocker policy platform structure on a reference computer.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Configure the AppLocker reference device
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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 effect of the policies that you intend to deploy.
The reference device doesn't 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](requirements-to-use-applocker.md).
>**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.
**To configure a reference device**
1. If the operating system isn't already installed, install one of the supported editions of Windows on the device.
>**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
2. Configure the administrator account.
To update local policies, you must be a member of the local Administrators group. To update domain policies, you must be a member of the Domain Admins group or have been delegated privileges to use Group Policy to update a Group Policy Object (GPO).
3. Install all apps that run in the targeted business group or OU by using the same directory structure.
The reference device should be configured to mimic the structure of your production environment. It depends on having the same apps in the same directories to accurately create the rules.
### See also
- After you configure the reference computer, you can create the AppLocker rule collections. You can build, import, or automatically generate the rules. For procedures to do this task, see [Working with AppLocker rules](working-with-applocker-rules.md).
- [Use a reference device to create and maintain AppLocker policies](use-a-reference-computer-to-create-and-maintain-applocker-policies.md)

View File

@ -0,0 +1,44 @@
---
title: Configure the Application Identity service
description: This topic for IT professionals shows how to configure the Application Identity service to start automatically or manually.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 07/01/2021
---
# Configure the Application Identity service
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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.
**To start the Application Identity service automatically using Group Policy**
1. On the **Start** screen, type **gpmc.msc** to open the Group Policy Management Console (GPMC).
2. Locate the GPO to edit, right-click the GPO, and then click **Edit**.
3. In the console tree under **Computer Configuration\\Windows Settings\\Security Settings**, click **System Services**.
4. In the details pane, double-click **Application Identity**.
5. In **Application Identity Properties**, configure the service to start automatically.
Membership in the local **Administrators** group, or equivalent, is the minimum access required to complete this procedure.
**To start the Application Identity service manually**
1. Right-click the taskbar, and click **Task Manager**.
2. Click the **Services** tab, right-click **AppIDSvc**, and then click **Start Service**.
3. Verify that the status for the Application Identity service is **Running**.
Starting with Windows 10, the Application Identity service is now a protected process. Because of this, you can no longer manually set the service **Startup type** to **Automatic** by using the Services snap-in. Try either of these methods instead:
- Open an elevated command prompt or PowerShell session and type:
```powershell
sc.exe config appidsvc start= auto
```
- Create a security template that configures appidsvc to be automatic start, and apply it using secedit.exe or LGPO.exe.

View File

@ -0,0 +1,53 @@
---
title: Create a rule for packaged apps
description: This article for IT professionals shows how to create an AppLocker rule for packaged apps with a publisher condition.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Create a rule for packaged apps
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
This article 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's 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 doesn't 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 and the package installers share these attributes. Therefore, an AppLocker rule for a packaged app controls both the installation and 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](understanding-the-publisher-rule-condition-in-applocker.md).
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](administer-applocker.md#bkmk-using-snapins).
**To create a packaged app rule**
1. Open the AppLocker console.
2. On the **Action** menu, or by right-clicking on **Packaged app Rules**, select **Create New Rule**.
3. On the **Before You Begin** page, select **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 select **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.
|Selection|Description|Example|
|--- |--- |--- |
|**Use an installed packaged app as a reference**|If selected, AppLocker requires you to choose an app that is already installed on which to base your new rule. AppLocker uses the publisher, package name and package version to define the rule.|You want the Sales group only to use the app named Microsoft.BingMaps for its outside sales calls. The Microsoft.BingMaps app is already installed on the device where you're 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 as a reference**|If selected, AppLocker requires you to choose an app installer on which to base your new rule. A packaged app installer has the .appx extension. AppLocker uses the publisher, package name, and package version of the installer to define the rule.|Your company has developed many internal line-of-business packaged apps. The app installers are stored on a common file share. Employees can install the required apps from that file share. You want to 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.
|Selection|Description|Example|
|--- |--- |--- |
|Applies to **Any publisher**|This setting is the least restrictive scope condition for an **Allow** rule. It permits every packaged app to run or install. <br/><br/>Conversely, if this setting is a **Deny** rule, then this option is the most restrictive because it denies all apps from installing or running. | You want the Sales group to use any packaged app from any signed publisher. You set the permissions to allow the Sales group to be able to run any app.|
|Applies to a specific **Publisher** | This setting scopes the rule to all apps published by a particular publisher. | You want to allow all your users to install apps published by the publisher of Microsoft.BingMaps. You could select Microsoft.BingMaps as a reference and choose this rule scope. |
|Applies to a **Package name** | This setting scopes the rule to all packages that share the publisher name and package name as the reference file. | You want to allow your Sales group to install any version of the Microsoft.BingMaps app. You could select the Microsoft.BingMaps app as a reference and choose this rule scope. |
|Applies to a **Package version** | This setting scopes the rule to a particular version of the package. | You want to be selective in what you allow. You don't 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 rule | Selecting the **Use custom values** check box allows you to adjust the scope fields for your particular circumstance. | You want to allow users to install all *Microsoft.Bing* applications, which include 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. Select **Next**.
7. (Optional) On the **Exceptions** page, specify conditions by which to exclude files from being affected by the rule. These conditions allow you to add exceptions based on the same rule reference and rule scope as you set before. Select **Next**.
8. On the **Name** page, either accept the automatically generated rule name or type a new rule name, and then select **Create**.

View File

@ -0,0 +1,35 @@
---
title: Create a rule that uses a file hash condition
description: This topic for IT professionals shows how to create an AppLocker rule with a file hash condition.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Create a rule that uses a file hash condition
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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](understanding-the-file-hash-rule-condition-in-applocker.md).
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](administer-applocker.md#bkmk-using-snapins).
**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**.

View File

@ -0,0 +1,37 @@
---
title: Create a rule that uses a path condition
description: This topic for IT professionals shows how to create an AppLocker rule with a path condition.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Create a rule that uses a path condition
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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](understanding-the-path-rule-condition-in-applocker.md).
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](administer-applocker.md#bkmk-using-snapins).
**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](understanding-the-path-rule-condition-in-applocker.md).
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**.

View File

@ -0,0 +1,34 @@
---
title: Create a rule that uses a publisher condition
description: This topic for IT professionals shows how to create an AppLocker rule with a publisher condition.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Create a rule that uses a publisher condition
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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](create-a-rule-for-packaged-apps.md).
For info about the publisher condition, see [Understanding the publisher rule condition in AppLocker](understanding-the-publisher-rule-condition-in-applocker.md).
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](administer-applocker.md#bkmk-using-snapins).
**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**.

View File

@ -0,0 +1,31 @@
---
title: Create AppLocker default rules
description: This topic for IT professionals describes the steps to create a standard set of AppLocker rules that will allow Windows system files to run.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Create AppLocker default rules
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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](administer-applocker.md#bkmk-using-snapins).
**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](understanding-applocker-default-rules.md)

View File

@ -0,0 +1,66 @@
---
title: Create a list of apps deployed to each business group
description: This topic describes the process of gathering app usage requirements from each business group to implement application control policies by using AppLocker.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Create a list of apps deployed to each business group
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
This topic describes the process of gathering app usage requirements from each business group in order to implement application control policies by using AppLocker.
## Determining app usage
For each business group, determine the following information:
- The complete list of apps used, including different versions of an app
- The full installation path of the app
- The publisher and signed status of each app
- The type of requirement the business groups set for each app, such as business critical, business productivity, optional, or personal. It might also be helpful during this effort to identify which apps are supported or unsupported by your IT department, or supported by others outside your control.
- A list of files or apps that require administrative credentials to install or run. If the file requires administrative credentials to install or run, users who can't provide administrative credentials will be prevented from running the file even if the file is explicitly allowed by an AppLocker policy. Even with AppLocker policies enforced, only members of the Administrators group can install or run files that require administrative credentials.
### How to perform the app usage assessment
You might already have a method in place to understand app usage for each business group. You'll need to use this information to help create your AppLocker rule collection. AppLocker includes the Automatically Generate
Rules wizard and the **Audit only** enforcement configuration to assist you with planning and creating your rule collection.
**Application inventory methods**
Using the Automatically Generate Rules wizard quickly creates rules for the applications you specify. The wizard is designed specifically to build a rule collection. You can use the Local Security Policy snap-in to view and edit the rules. This method is useful when creating rules from a reference computer and when creating and evaluating AppLocker policies in a testing environment. However, it does require that the files be accessible on the reference computer or through a network drive. This requirement might mean more work in setting up the reference computer and determining a maintenance policy for that computer.
Using the **Audit only** enforcement method permits you to view the logs because it collects information about every process on the computers receiving the Group Policy Object (GPO). Therefore, you can see what the enforcement will be on the computers in a business group. AppLocker includes Windows PowerShell cmdlets that you can use to analyze the events from the event log and cmdlets to create rules. However, when you use Group Policy to deploy to several computers, a means to collect events in a central location is important for manageability. Because AppLocker logs information about files that users or other processes start on a computer, you could miss creating some rules initially. Therefore, you should continue your evaluation until you can verify that all required applications that are allowed to run are accessed successfully.
> [!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 describe how to perform each method:
- [Run the Automatically Generate Rules wizard](run-the-automatically-generate-rules-wizard.md)
- [Configure an AppLocker policy for audit only](configure-an-applocker-policy-for-audit-only.md)
### Prerequisites to completing the inventory
Identify the business group and each organizational unit (OU) within that group to which you'll 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](understand-applocker-policy-design-decisions.md)
- [Determine your application control objectives](determine-your-application-control-objectives.md)
## Next steps
Identify and develop the list of apps. Record the name of the app, whether it's signed or not as indicated by the publisher's name, and whether or not it's a mission critical, business productivity, optional, or personal application. Record the installation path of the apps. For more information, see [Document your app list](document-your-application-list.md).
After you've 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
For guidance, see the following topics:
- [Select the types of rules to create](select-types-of-rules-to-create.md)
- [Determine the Group Policy structure and rule enforcement](determine-group-policy-structure-and-rule-enforcement.md)

View File

@ -0,0 +1,64 @@
---
title: Create Your AppLocker policies
description: This overview topic for the IT professional describes the steps to create an AppLocker policy and prepare it for deployment.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Create Your AppLocker policies
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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.
## Step 1: Use your plan
You can develop an application control policy plan to guide you in making successful deployment decisions. For more information about how to develop this policy and what you should consider, see the [AppLocker Design Guide](applocker-policies-design-guide.md). This guide is intended for security architects, security administrators, and system administrators. It contains the following topics to help you create an AppLocker policy deployment plan for your organization that will address your specific application control requirements by department, organizational unit, or business group:
1. [Understand the AppLocker policy deployment process](understand-the-applocker-policy-deployment-process.md)
2. [Understand AppLocker policy design decisions](understand-applocker-policy-design-decisions.md)
3. [Determine your application control objectives](determine-your-application-control-objectives.md)
4. [Create a list of apps deployed to each business group](create-list-of-applications-deployed-to-each-business-group.md)
5. [Select the types of rules to create](select-types-of-rules-to-create.md)
6. [Determine the Group Policy structure and rule enforcement](determine-group-policy-structure-and-rule-enforcement.md)
7. [Plan for AppLocker policy management](plan-for-applocker-policy-management.md)
## Step 2: Create your rules and rule collections
Each rule applies to one or more apps, and it imposes a specific rule condition on them. Rules can be created individually or they can be generated by the Automatically Generate Rules Wizard. For the steps to create the rules, see [Create Your AppLocker rules](create-your-applocker-rules.md).
## Step 3: Configure the enforcement setting
An AppLocker policy is a set of rule collections that are configured with a rule enforcement setting. The enforcement setting can be **Enforce rules**, **Audit only**, or **Not configured**. If an AppLocker policy has at least one rule, and it's set to **Not configured**, all the rules in that
policy will be enforced. For info about configuring the rule enforcement setting, see [Configure an AppLocker policy for audit only](configure-an-applocker-policy-for-audit-only.md) and [Configure an AppLocker policy for enforce rules](configure-an-applocker-policy-for-enforce-rules.md).
## Step 4: Update the GPO
AppLocker policies can be defined locally on a device or applied through Group Policy. To use Group Policy to apply AppLocker policies, you must create a new Group Policy Object (GPO), or you must update an existing GPO. You can create or modify AppLocker policies by using the Group Policy Management Console (GPMC), or you can import an AppLocker policy into a GPO. For the procedure to import this policy into a GPO, see [Import an AppLocker policy into a GPO](import-an-applocker-policy-into-a-gpo.md).
## Step 5: Test the effect of the policy
In a test environment or with the enforcement setting set at **Audit only**, verify that the results of the policy are what you intended. For info about testing a policy, see [Test and update an AppLocker policy](test-and-update-an-applocker-policy.md).
## Step 6: Implement the policy
Depending on your deployment method, import the AppLocker policy to the GPO in your production environment, or if the policy is already deployed, change the enforcement setting to your production environment value-**Enforce rules** or **Audit only**.
## Step 7: Test the effect of the policy and adjust
Validate the effect of the policy by analyzing the AppLocker logs for application usage, and then modify the policy as necessary. For information on how to do these tasks, see [Monitor app usage with AppLocker](monitor-application-usage-with-applocker.md).
## Next steps
Follow the steps described in the following topics to continue the deployment process:
1. [Create Your AppLocker rules](create-your-applocker-rules.md)
2. [Test and update an AppLocker policy](test-and-update-an-applocker-policy.md)
3. [Deploy the AppLocker policy into production](deploy-the-applocker-policy-into-production.md)
## See also
- [AppLocker deployment guide](applocker-policies-deployment-guide.md)

View File

@ -0,0 +1,71 @@
---
title: Create Your AppLocker rules
description: This topic for the IT professional describes what you need to know about AppLocker rules and the methods that you can to create rules.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Create Your AppLocker rules
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
This topic for the IT professional describes what you need to know about AppLocker rules and the methods that you can to create rules.
## Creating AppLocker rules
AppLocker rules apply to the targeted app, and they're the components that make up the AppLocker policy. Depending on your IT environment and the business group that requires application control policies, setting these access rules for each application can be time-consuming and prone to error. With AppLocker, you can generate rules automatically or create rules individually. Creating rules that are derived from your planning document can help you avoid unintended results. For info about this planning document and other planning activities, see [AppLocker Design Guide](applocker-policies-design-guide.md).
### Automatically generate your rules
You can use a reference device to automatically create a set of default rules for each of the installed apps, test and modify each rule as necessary, and deploy the policies. Creating most of the rules for all the installed apps gives you a starting point to build and test your policies. For info about performing this task, see the following topics:
- [Configure the AppLocker reference device](configure-the-appLocker-reference-device.md)
- [Run the Automatically Generate Rules wizard](run-the-automatically-generate-rules-wizard.md)
- [Create AppLocker default rules](create-applocker-default-rules.md)
- [Edit AppLocker rules](edit-applocker-rules.md)
- [Add exceptions for an AppLocker rule](configure-exceptions-for-an-applocker-rule.md)
### Create your rules individually
You can create rules and set the mode to **Audit only** for each installed app, test and update each rule as necessary, and then deploy the policies. Creating rules individually might be best when you're targeting a few applications within a business group.
>**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](create-applocker-default-rules.md).
For information about performing this task, see:
1. [Create a rule that uses a publisher condition](create-a-rule-that-uses-a-publisher-condition.md)
2. [Create a rule that uses a path condition](create-a-rule-that-uses-a-path-condition.md)
3. [Create a rule that uses a file hash condition](create-a-rule-that-uses-a-file-hash-condition.md)
4. [Edit AppLocker rules](edit-applocker-rules.md)
5. [Enforce AppLocker rules](enforce-applocker-rules.md)
6. [Configure an AppLocker policy for audit only](configure-an-applocker-policy-for-audit-only.md)
## About selecting rules
AppLocker policies are composed of distinct rules for specific apps. These rules are grouped by collection, and they're implemented through an AppLocker policy definition. AppLocker policies are managed by using Group Policy or by using the Local Security Policy snap-in for a single computer.
When you determine what types of rules to create for each of your business groups or organizational units (OUs), you should also determine what enforcement setting to use for each group. Certain rule types are more applicable for some apps, depending on how the apps are deployed in a specific business group.
For info about how to determine and document your AppLocker rules, see [AppLocker Design Guide](applocker-policies-design-guide.md).
For info about AppLocker rules and AppLocker policies, see the following topics:
- [Understanding AppLocker rule behavior](understanding-applocker-rule-behavior.md)
- [Understanding AppLocker rule exceptions](understanding-applocker-rule-exceptions.md)
- [Understanding AppLocker rule collections](understanding-applocker-rule-collections.md)
- [Understanding AppLocker allow and deny actions on rules](understanding-applocker-allow-and-deny-actions-on-rules.md)
- [Understanding AppLocker rule condition types](understanding-applocker-rule-condition-types.md)
- [Understanding AppLocker default rules](understanding-applocker-default-rules.md)
## Next steps
1. [Import an AppLocker policy into a GPO](import-an-applocker-policy-into-a-gpo.md)
2. [Import an AppLocker policy from another computer](import-an-applocker-policy-from-another-computer.md)
3. [Test and update an AppLocker policy](test-and-update-an-applocker-policy.md)
4. [Deploy the AppLocker policy into production](deploy-the-applocker-policy-into-production.md)
## Related topics
- [Create Your AppLocker policies](create-your-applocker-policies.md)

View File

@ -0,0 +1,69 @@
---
title: Delete an AppLocker rule
description: This article for IT professionals describes the steps to delete an AppLocker rule.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 03/10/2023
---
# Delete an AppLocker rule
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
This article for IT professionals describes the steps to delete AppLocker rules.
As older apps are retired and new apps are deployed in your organization, it's necessary to modify the application control policies. If an app is no longer supported by your organization, then deleting the rule or rules associated with that app prevents 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](test-an-applocker-policy-by-using-test-applockerpolicy.md).
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](administer-applocker.md#bkmk-using-snapins).
These steps apply only for locally managed devices. Any AppLocker policies delivered through MDM or Group Policy must be removed using those tools.
## To delete a rule in an AppLocker policy
1. Open the AppLocker console.
2. Select the appropriate rule collection for which you want to delete the rule.
3. In the details pane, right-click the rule to delete, select **Delete**, and then select **Yes**.
> [!NOTE]
>
> - When using Group Policy, the Group Policy Object must be distributed or refreshed for rule deletion to take effect on devices.
> - Application Identity service needs to be running for deleting Applocker rules. If you disable Applocker and delete Applocker rules, make sure to stop the Application Identity service after deleting Applocker rules. If the Application Identity service is stopped before deleting Applocker rules, and if Applocker blocks apps that are disabled, delete all of the files at `C:\Windows\System32\AppLocker`.
When the following procedure is performed on the local device, the AppLocker policy takes effect immediately.
## To clear AppLocker policies on a single system or remote systems
First import the AppLocker modules for PowerShell:
```powershell
PS C:\Users\Administrator> import-module AppLocker
```
Create a file called clear.xml with the following XML content and save it to your desktop.
```xml
<AppLockerPolicy Version="1" />
```
Then run the following command from an elevated PowerShell session to remove all local AppLocker policies from the device:
```powershell
C:\Users\Administrator> Set-AppLockerPolicy -XMLPolicy $env:USERPROFILE\Desktop\clear.xml
```
Run the following PowerShell commands to stop the AppLocker services and change their startup configuration.
```powershell
appidtel.exe stop [-mionly]
sc.exe config appid start=demand
sc.exe config appidsvc start=demand
sc.exe config applockerfltr start=demand
sc.exe stop applockerfltr
sc.exe stop appidsvc
sc.exe stop appid
```
All of these steps can be run on a single machine or deployed as a script to multiple devices.

View File

@ -0,0 +1,49 @@
---
title: Deploy AppLocker policies by using the enforce rules setting
description: This topic for IT professionals describes the steps to deploy AppLocker policies by using the enforcement setting method.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Deploy AppLocker policies by using the enforce rules setting
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
This topic for IT professionals describes the steps to deploy AppLocker policies by using the enforcement setting method.
## Background and prerequisites
These procedures assume that you have already deployed AppLocker policies with the enforcement set to **Audit only**, and you have been collecting data through the AppLocker event logs and other channels to determine what effect these policies have on your environment and the policy's adherence to your application control design.
For info about the AppLocker policy enforcement setting, see [Understand AppLocker enforcement settings](understand-applocker-enforcement-settings.md).
For info about how to plan an AppLocker policy deployment, see [AppLocker Design Guide](applocker-policies-design-guide.md).
## Step 1: Retrieve the AppLocker policy
Updating an AppLocker policy that is currently enforced in your production environment can have unintended results. Using Group Policy, you can export the policy from the Group Policy Object (GPO) and then update the rule or rules by using AppLocker on your AppLocker reference or test PC. For the procedure to do these tasks, see [Export an AppLocker policy from a GPO](export-an-applocker-policy-from-a-gpo.md) and [Import an AppLocker policy into a GPO](import-an-applocker-policy-into-a-gpo.md). For local AppLocker policies, you can update the rule or rules by using the Local Security policy snap-in (secpol.msc) on your AppLocker reference or test PC. For the procedures to do this task, see [Export an AppLocker policy to an XML file](export-an-applocker-policy-to-an-xml-file.md) and [Import an AppLocker policy from another computer](import-an-applocker-policy-from-another-computer.md).
## Step 2: Alter the enforcement setting
Rule enforcement is applied only to a collection of rules, not to individual rules. AppLocker divides the rules into collections: executable files, Windows Installer files, packaged apps, scripts, and DLL files. By default, if enforcement isn't configured and rules are present in a rule collection, those rules are enforced. For information about the enforcement setting, see [Understand AppLocker Enforcement Settings](understand-applocker-enforcement-settings.md). For the procedure to alter the enforcement setting, see [Configure an AppLocker policy for audit only](configure-an-applocker-policy-for-audit-only.md).
## Step 3: Update the policy
You can edit an AppLocker policy by adding, changing, or removing rules. However, you can't specify a version for the AppLocker policy by importing more rules. To ensure version control when modifying an AppLocker policy, use Group Policy management software that allows you to create versions of GPOs. An example of this type of software is the [Advanced Group Policy Management](/microsoft-desktop-optimization-pack/agpm/) feature from the Microsoft Desktop Optimization Pack.
> [!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](import-an-applocker-policy-into-a-gpo.md).
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](export-an-applocker-policy-to-an-xml-file.md) and [Import an AppLocker policy from another computer](import-an-applocker-policy-from-another-computer.md).
## Step 4: Monitor the effect of the policy
When a policy is deployed, it's important to monitor the actual implementation of that policy by monitoring your support organization's app access request activity and reviewing the AppLocker event logs. To monitor the effect of the policy, see [Monitor Application Usage with AppLocker](monitor-application-usage-with-applocker.md).
## Other resources
- For steps to perform other AppLocker policy tasks, see [Administer AppLocker](administer-applocker.md).

View File

@ -0,0 +1,43 @@
---
title: Deploy the AppLocker policy into production
description: This topic for the IT professional describes the tasks that should be completed before you deploy AppLocker application control settings.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Deploy the AppLocker policy into production
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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](applocker-policies-design-guide.md). 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](create-list-of-applications-deployed-to-each-business-group.md).
- How to handle requests for application access. For info about what to consider when developing your support policies, see [Plan for AppLocker policy management](plan-for-applocker-policy-management.md).
- How to manage events, including forwarding events. For info about event management in AppLocker, see [Monitor app usage with AppLocker](monitor-application-usage-with-applocker.md).
- 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](determine-group-policy-structure-and-rule-enforcement.md).
For info about how AppLocker deployment is dependent on design decisions, see [Understand AppLocker policy design decisions](understand-applocker-policy-design-decisions.md).
### 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](use-a-reference-computer-to-create-and-maintain-applocker-policies.md)
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](deploy-applocker-policies-by-using-the-enforce-rules-setting.md)
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](applocker-policies-deployment-guide.md)

View File

@ -0,0 +1,31 @@
---
title: Determine the Group Policy structure and rule enforcement
description: This overview topic describes the process to follow when you're planning to deploy AppLocker rules.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Determine the Group Policy structure and rule enforcement
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
This overview topic describes the process to follow when you're planning to deploy AppLocker rules.
## In this section
| Topic | Description |
| - | - |
| [Understand AppLocker enforcement settings](understand-applocker-enforcement-settings.md) | This topic describes the AppLocker enforcement settings for rule collections. |
| [Understand AppLocker rules and enforcement setting inheritance in Group Policy](understand-applocker-rules-and-enforcement-setting-inheritance-in-group-policy.md) | This topic for the IT professional describes how application control policies configured in AppLocker are applied through Group Policy.|
| [Document the Group Policy structure and AppLocker rule enforcement](document-group-policy-structure-and-applocker-rule-enforcement.md) | This planning topic describes what you need to investigate, determine, and record in your application control policies plan when you use AppLocker. |
When you're determining how many Group Policy Objects (GPOs) to create when you apply an AppLocker policy in your organization, you should consider the following points:
- Whether you're creating new GPOs or using existing GPOs
- Whether you're 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.

View File

@ -0,0 +1,31 @@
---
title: Find digitally signed apps on a reference device
description: This topic for the IT professional describes how to use AppLocker logs and tools to determine which applications are digitally signed.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Determine which apps are digitally signed on a reference device
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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 doesn't 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 aren't signed don't 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](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ee460961(v=technet.10)).
## Related topics
- [Use a reference device to create and maintain AppLocker policies](use-a-reference-computer-to-create-and-maintain-applocker-policies.md)

View File

@ -0,0 +1,41 @@
---
title: Determine your application control objectives
description: Determine which applications to control and how to control them by comparing Software Restriction Policies (SRP) and AppLocker.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Determine your application control objectives
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
This article helps with 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 effective for organizations with app restriction requirements whose environments have a simple topography and whose 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 a detailed level of control on the PCs 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.
|Application control function|SRP|AppLocker|
|--- |--- |--- |
|Scope|SRP policies can be applied to all Windows operating systems beginning with Windows XP and Windows Server 2003.|AppLocker policies apply only to the support versions of Windows listed in [Requirements to use AppLocker](requirements-to-use-applocker.md).|
|Policy creation|SRP policies are maintained through Group Policy and only the administrator of the GPO can update the SRP policy. The administrator on the local computer can modify the SRP policies defined in the local GPO.|AppLocker policies are maintained through Group Policy and only the administrator of the GPO can update the policy. The administrator on the local computer can modify the AppLocker policies defined in the local GPO.<br/><br/>AppLocker permits customization of error messages to direct users to a Web page for help.|
|Policy maintenance|SRP policies must be updated by using the Local Security Policy snap-in (if the policies are created locally) or the Group Policy Management Console (GPMC).|AppLocker policies can be updated by using the Local Security Policy snap-in, if the policies are created locally, or the GPMC, or the Windows PowerShell AppLocker cmdlets.|
|Policy application|SRP policies are distributed through Group Policy.|AppLocker policies are distributed through Group Policy.|
|Enforcement mode|SRP works in the "blocklist mode" where administrators can create rules for files that they don't want to allow in this Enterprise, but the rest of the files are allowed to run by default.<br/><br/>SRP can also be configured in the "allowlist mode" such that by default all files are blocked and administrators need to create allow rules for files that they want to allow.|By default, AppLocker works in allowlist mode. Only those files are allowed to run for which there's a matching allow rule.|
|File types that can be controlled|SRP can control the following file types:<li>Executables<li>DLLs<li>Scripts<li>Windows Installers<br/><br/>SRP can't control each file type separately. All SRP rules are in a single rule collection.|AppLocker can control the following file types:<li>Executables<li>DLLs<li>Scripts<li>Windows Installers<li>Packaged apps and installers<br/><br/>AppLocker maintains a separate rule collection for each of the five file types.|
|Designated file types|SRP supports an extensible list of file types that are considered executable. You can add extensions for files that should be considered executable.|AppLocker doesn't support this addition of extension. AppLocker currently supports the following file extensions:<li>Executables (.exe, .com)<li>DLLs (.ocx, .dll)<li>Scripts (.vbs, .js, .ps1, .cmd, .bat)<li>Windows Installers (.msi, .mst, .msp)<li>Packaged app installers (.appx)|
|Rule types|SRP supports four types of rules:<li>Hash<li>Path<li>Signature<br/><br/>Internet zone|AppLocker supports three types of rules:<li>Hash<li>Path<li>Publisher|
|Editing the hash value|SRP allows you to select a file to hash.|AppLocker computes the hash value itself. Internally it uses the SHA2 Authenticode hash for Portable Executables (exe and DLL) and Windows Installers and an SHA2 flat file hash for the rest.|
|Support for different security levels|With SRP, you can specify the permissions with which an app can run. Then configure a rule such that Notepad always runs with restricted permissions and never with administrative privileges.<br/><br/>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).|AppLocker doesn't support security levels.|
|Manage Packaged apps and Packaged app installers.|Unable|.appx is a valid file type which AppLocker can manage.|
|Targeting a rule to a user or a group of users|SRP rules apply to all users on a particular computer.|AppLocker rules can be targeted to a specific user or a group of users.|
|Support for rule exceptions|SRP doesn't support rule exceptions|AppLocker rules can have exceptions that allow administrators to create rules such as "Allow everything from Windows except for Regedit.exe".|
|Support for audit mode|SRP doesn't support audit mode. The only way to test SRP policies is to set up a test environment and run a few experiments.|AppLocker supports audit mode that allows administrators to test the effect of their policy in the real production environment without impacting the user experience. Once you're satisfied with the results, you can start enforcing the policy.|
|Support for exporting and importing policies|SRP doesn't support policy import/export.|AppLocker supports the importing and exporting of policies. This support by AppLocker 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 happens in user-mode, which is less secure.|Internally, AppLocker rules for exes and dlls are enforced in kernel-mode, which is more secure than enforcing them in the user-mode.|
For more general info, see <a href="applocker-overview.md" data-raw-source="[AppLocker](applocker-overview.md)">AppLocker</a>.

View File

@ -0,0 +1,28 @@
---
title: Display a custom URL message when users try to run a blocked app
description: This topic for IT professionals describes the steps for displaying a customized message to users when an AppLocker policy denies access to an app.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Display a custom URL message when users try to run a blocked app
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
This topic for IT professionals describes the steps for displaying a customized message to users when an AppLocker policy denies access to an app.
With the help of 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 don't display a custom message when an app 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.

View File

@ -0,0 +1,37 @@
---
title: DLL rules in AppLocker
description: This topic describes the file formats and available default rules for the DLL rule collection.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# DLL rules in AppLocker
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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.
| Purpose | Name | User | Rule condition type |
| - | - | - | - |
| Allows members of the local Administrators group to run all DLLs | (Default Rule) All DLLs| BUILTIN\Administrators | Path: *|
| Allow all users to run DLLs in the Windows folder| (Default Rule) Microsoft Windows DLLs | Everyone | Path: %windir%\*|
| Allow all users to run DLLs in the Program Files folder | (Default Rule) All DLLs located in the Program Files folder| Everyone | Path: %programfiles%\*|
> [!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](understanding-applocker-default-rules.md)

View File

@ -0,0 +1,41 @@
---
title: Document Group Policy structure & AppLocker rule enforcement
description: This planning topic describes what you need to investigate, determine, and record in your application control policies plan when you use AppLocker.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Document the Group Policy structure and AppLocker rule enforcement
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
This planning topic describes what you need to investigate, determine, and record in your application control policies plan when you use AppLocker.
## Record your findings
To complete this AppLocker planning document, you should first complete the following steps:
1. [Determine your application control objectives](determine-your-application-control-objectives.md)
2. [Create a list of apps deployed to each business group](create-list-of-applications-deployed-to-each-business-group.md)
3. [Select the types of rules to create](select-types-of-rules-to-create.md)
4. [Determine the Group Policy structure and rule enforcement](determine-group-policy-structure-and-rule-enforcement.md)
After you determine how to structure your Group Policy Objects (GPOs) so that you can apply AppLocker policies, you should record your findings. You can use the following table to determine how many GPOs to create (or edit) and which objects they're linked to. If you decided to create custom rules to allow system files to run, note the high-level rule configuration in the **Use default rule or define new rule condition** column.
The following table includes the sample data that was collected when you determined your enforcement settings and the GPO structure for your AppLocker policies.
|Business group|Organizational unit|Implement AppLocker?|Apps|Installation path|Use default rule or define new rule condition|Allow or deny|GPO name|
|--- |--- |--- |--- |--- |--- |--- |--- |
|Bank Tellers|Teller-East and Teller-West|Yes|Teller Software|C:\Program Files\Woodgrove\Teller.exe|File is signed; create a publisher condition|Allow|Tellers-AppLockerTellerRules|
||||Windows files|C:\Windows|Create a path exception to the default rule to exclude \Windows\Temp|Allow||
|Human Resources|HR-All|Yes|Check Payout|C:\Program Files\Woodgrove\HR\Checkcut.exe|File is signed; create a publisher condition|Allow|HR-AppLockerHRRules|
||||Time Sheet Organizer|C:\Program Files\Woodgrove\HR\Timesheet.exe|File isn't signed; create a file hash condition|Allow||
||||Internet Explorer 7|C:\Program Files\Internet Explorer</p>|File is signed; create a publisher condition|Deny||
||||Windows files|C:\Windows|Use a default rule for the Windows path|Allow||
## Next steps
After you've 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.md)

View File

@ -0,0 +1,70 @@
---
title: Document your app list
description: This planning topic describes the app information that you should document when you create a list of apps for AppLocker policies.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Document your app list
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
This planning topic describes the app information that you should document when you create a list of apps for AppLocker policies.
## Record your findings
**Apps**
Record the name of the app, whether it is signed as indicated by the publisher's name, and whether it is a mission critical, business productivity, optional, or personal app. Later, as you manage your rules, AppLocker displays this information in the format shown in the following example: *MICROSOFT OFFICE INFOPATH signed by O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US*.
**Installation path**
Record the installation path of the apps. For example, Microsoft Office 2016 installs files to *%programfiles%\\Microsoft Office\\Office16\\*, which is *C:\\Program Files\\Microsoft Office\\Office16\\* on most devices.
The following table provides an example of how to list applications for each business group at the early stage of designing your application control policies. Eventually, as more planning information is added to the list, the information can be used to build AppLocker rules.
|Business group|Organizational unit|Implement AppLocker?|Apps|Installation path|
|--- |--- |--- |--- |--- |
|Bank Tellers|Teller-East and Teller-West|Yes|Teller Software|C:\Program Files\Woodgrove\Teller.exe|
||||Windows files|C:\Windows|
|Human Resources|HR-All|Yes|Check Payout|C:\Program Files\Woodgrove\HR\Checkcut.exe|
||||Time Sheet Organizer|C:\Program Files\Woodgrove\HR\Timesheet.exe|
||||Internet Explorer 7|C:\Program Files\Internet Explorer</p>|
||||Windows files|C:\Windows|
>[!NOTE]
>AppLocker only supports publisher rules for Universal Windows apps. Therefore, collecting the installation path information for Universal Windows apps is not necessary.
<b>Event processing</b>
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](select-types-of-rules-to-create.md)
- [Determine Group Policy structure and rule enforcement](determine-group-policy-structure-and-rule-enforcement.md)

View File

@ -0,0 +1,45 @@
---
title: Document your AppLocker rules
description: Learn how to document your AppLocker rules and associate rule conditions with files, permissions, rule source, and implementation.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Document your AppLocker rules
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
This topic describes what AppLocker rule conditions to associate with each file, how to associate these rule conditions, the source of the rule, and whether the file should be included or excluded.
## Record your findings
To complete this AppLocker planning document, you should first complete the following steps:
1. [Determine your application control objectives](determine-your-application-control-objectives.md)
2. [Create a list of apps deployed to each business group](create-list-of-applications-deployed-to-each-business-group.md)
3. [Select the types of rules to create](select-types-of-rules-to-create.md)
Document the following items for each business group or organizational unit:
- Whether your organization will use the built-in default AppLocker rules to allow system files to run.
- The types of rule conditions that you will use to create rules, stated in order of preference.
The following table details sample data for documenting rule type and rule condition findings. In addition, you should now consider whether to allow an app to run or deny permission for it to run. For info about these settings, see [Understanding AppLocker allow and deny actions on rules](understanding-applocker-allow-and-deny-actions-on-rules.md).
|Business group|Organizational unit|Implement AppLocker?|Applications|Installation path|Use default rule or define new rule condition|Allow or deny|
|--- |--- |--- |--- |--- |--- |--- |
|Bank Tellers|Teller-East and Teller-West|Yes|Teller Software|C:\Program Files\Woodgrove\Teller.exe|File is signed; create a publisher condition||
||||Windows files|C:\Windows|Create a path exception to the default rule to exclude \Windows\Temp||
|Human Resources|HR-All|Yes|Check Payout|C:\Program Files\Woodgrove\HR\Checkcut.exe|File is signed; create a publisher condition||
||||Time Sheet Organizer|C:\Program Files\Woodgrove\HR\Timesheet.exe|File is not signed; create a file hash condition||
||||Internet Explorer 7|C:\Program Files\Internet Explorer</p>|File is signed; create a publisher condition||
||||Windows files|C:\Windows|Use the default rule for the Windows path||
## Next steps
For each rule, determine whether to use the allow or deny option, and then complete the following tasks:
- [Determine Group Policy structure and rule enforcement](determine-group-policy-structure-and-rule-enforcement.md)
- [Plan for AppLocker policy management](plan-for-applocker-policy-management.md)

View File

@ -0,0 +1,102 @@
---
title: Edit an AppLocker policy
description: This topic for IT professionals describes the steps required to modify an AppLocker policy.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Edit an AppLocker policy
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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 can't create a new version of the policy by importing more 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 can't 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](merge-applocker-policies-manually.md) or [Merge AppLocker policies by using Set-ApplockerPolicy](merge-applocker-policies-by-using-set-applockerpolicy.md).
There are three methods you can use to edit an AppLocker policy:
- [Editing an AppLocker policy by using Mobile Device Management (MDM)](#bkmk-editapppolinmdm)
- [Editing an AppLocker policy by using Group Policy](#bkmk-editapppolingpo)
- [Editing an AppLocker policy by using the Local Security Policy snap-in](#bkmk-editapplolnotingpo)
## <a href="" id="bkmk-editapppolinmdm"></a>Editing an AppLocker policy by using Mobile Device Management (MDM)
If you deployed the AppLocker policy using the AppLocker configuration service provider, you can edit the policies in your MDM solution by altering the content in the string value of the policy node.
For more information, see the [AppLocker CSP](/windows/client-management/mdm/applocker-csp).
## <a href="" id="bkmk-editapppolingpo"></a>Editing an AppLocker policy by using Group Policy
The steps to edit an AppLocker policy distributed by Group Policy include:
### Step 1: Use Group Policy management software to export the AppLocker policy from the GPO
AppLocker provides a feature to export and import AppLocker policies as an XML file. This feature allows you to modify an AppLocker policy outside your production environment. Because updating an AppLocker policy in a deployed GPO could have unintended consequences, you should first export the AppLocker policy to an XML file. For information on the procedure to export this policy, see [Export an AppLocker policy from a GPO](export-an-applocker-policy-from-a-gpo.md).
### Step 2: Import the AppLocker policy into the AppLocker reference PC or the PC you use for policy maintenance
After exporting the AppLocker policy to an XML file, you should import the XML file onto a reference PC so that you can edit the policy. For information on the procedure to import an AppLocker policy, see [Import an AppLocker policy from another computer](import-an-applocker-policy-from-another-computer.md).
>**Caution:** Importing a policy onto another PC will overwrite the existing policy on that PC.
### Step 3: Use AppLocker to modify and test the rule
AppLocker provides ways to modify, delete, or add rules to a policy by modifying the rules within the collection.
- For information on the procedure to modify a rule, see [Edit AppLocker rules](edit-applocker-rules.md).
- For information on the procedure to delete a rule, see [Delete an AppLocker rule](delete-an-applocker-rule.md).
- For procedures to create rules, see:
- [Create a rule that uses a publisher condition](create-a-rule-that-uses-a-publisher-condition.md)
- [Create a rule that uses a path condition](create-a-rule-that-uses-a-path-condition.md)
- [Create a rule that uses a file hash condition](create-a-rule-that-uses-a-file-hash-condition.md)
- [Enable the DLL rule collection](enable-the-dll-rule-collection.md)
- For information on the steps to test an AppLocker policy, see [Test and update an AppLocker policy](test-and-update-an-applocker-policy.md).
- For procedures to export the updated policy from the reference computer back into the GPO, see [Export an AppLocker policy to an XML file](export-an-applocker-policy-to-an-xml-file.md) and [Import an AppLocker policy into a GPO](import-an-applocker-policy-into-a-gpo.md).
### Step 4: Use AppLocker and Group Policy to import the AppLocker policy back into the GPO
For procedures to export the updated policy from the reference computer back into the GPO, see [Export an AppLocker policy to an XML file](export-an-applocker-policy-to-an-xml-file.md) and [Import an AppLocker policy into a GPO](import-an-applocker-policy-into-a-gpo.md).
>**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](test-and-update-an-applocker-policy.md).
>**Note:** If you are performing these steps by using Microsoft Advanced Group Policy Management (AGPM), check out the GPO before exporting the policy.
## <a href="" id="bkmk-editapplolnotingpo"></a>Editing an AppLocker policy by using the Local Security Policy snap-in
The steps to edit an AppLocker policy distributed by using the Local Security Policy snap-in (secpol.msc) include the following tasks.
### Step 1: Import the AppLocker policy
On the PC where you maintain policies, open the AppLocker snap-in from the Local Security Policy snap-in (secpol.msc). If you exported the AppLocker policy from another PC, use AppLocker to import it onto the PC.
After exporting the AppLocker policy to an XML file, you should import the XML file onto a reference PC so that you can edit the policy. For information on the procedure to import an AppLocker policy, see [Import an AppLocker policy from another computer](import-an-applocker-policy-from-another-computer.md).
>**Caution:** Importing a policy onto another PC will overwrite the existing policy on that PC.
### Step 2: Identify and modify the rule to change, delete, or add
AppLocker provides ways to modify, delete, or add rules to a policy by modifying the rules within the collection.
- For information on the procedure to modify a rule, see [Edit AppLocker rules](edit-applocker-rules.md).
- For information on the procedure to delete a rule, see [Delete an AppLocker rule](delete-an-applocker-rule.md).
- For procedures to create rules, see:
- [Create a rule that uses a publisher condition](create-a-rule-that-uses-a-publisher-condition.md)
- [Create a rule that uses a path condition](create-a-rule-that-uses-a-path-condition.md)
- [Create a rule that uses a file hash condition](create-a-rule-that-uses-a-file-hash-condition.md)
- [Enable the DLL rule collection](enable-the-dll-rule-collection.md)
### Step 3: Test the effect of the policy
For steps to test an AppLocker policy, see [Test and update an AppLocker policy](test-and-update-an-applocker-policy.md).
### Step 4: Export the policy to an XML file and propagate it to all targeted computers
For procedures to export the updated policy from the reference computer to targeted computers, see [Export an AppLocker policy to an XML file](export-an-applocker-policy-to-an-xml-file.md) and [Import an AppLocker policy from another computer](import-an-applocker-policy-from-another-computer.md).
## Other resources
- For steps to perform other AppLocker policy tasks, see [Administer AppLocker](administer-applocker.md).

View File

@ -0,0 +1,52 @@
---
title: Edit AppLocker rules
description: This topic for IT professionals describes the steps to edit a publisher rule, path rule, and file hash rule in AppLocker.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Edit AppLocker rules
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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](understanding-applocker-rule-condition-types.md).
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](administer-applocker.md#bkmk-using-snapins).
**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**.

View File

@ -0,0 +1,27 @@
---
title: Enable the DLL rule collection
description: This topic for IT professionals describes the steps to enable the DLL rule collection feature for AppLocker.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Enable the DLL rule collection
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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](dll-rules-in-applocker.md).
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](administer-applocker.md#bkmk-using-snapins).
**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.

View File

@ -0,0 +1,24 @@
---
title: Enforce AppLocker rules
description: This topic for IT professionals describes how to enforce application control rules by using AppLocker.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Enforce AppLocker rules
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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](configure-an-applocker-policy-for-enforce-rules.md).
>**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 only](configure-an-applocker-policy-for-audit-only.md)or [Test an AppLocker policy by Using Test-AppLockerPolicy](test-an-applocker-policy-by-using-test-applockerpolicy.md).

View File

@ -0,0 +1,26 @@
---
title: Executable rules in AppLocker
description: This topic describes the file formats and available default rules for the executable rule collection.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Executable rules in AppLocker
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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.
| Purpose | Name | User | Rule condition type |
| - | - | - | - |
| Allow members of the local Administrators group access to run all executable files | (Default Rule) All files| BUILTIN\Administrators | Path: * |
| Allow all users to run executable files in the Windows folder| (Default Rule) All files located in the Windows folder| Everyone| Path: %windir%\*|
| Allow all users to run executable files in the Program Files folder | (Default Rule) All files located in the Program Files folder| Everyone | Path: %programfiles%\*|
## Related topics
- [Understanding AppLocker Default Rules](understanding-applocker-default-rules.md)

View File

@ -0,0 +1,26 @@
---
title: Export an AppLocker policy from a GPO
description: 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.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Export an AppLocker policy from a GPO
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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**.

View File

@ -0,0 +1,21 @@
---
title: Export an AppLocker policy to an XML file
description: This topic for IT professionals describes the steps to export an AppLocker policy to an XML file for review or testing.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Export an AppLocker policy to an XML file
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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**.

View File

@ -0,0 +1,45 @@
---
title: How AppLocker works
description: This topic for the IT professional provides links to topics about AppLocker architecture and components, processes and interactions, rules and policies.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# How AppLocker works
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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-architecture-and-components.md)
- [AppLocker processes and interactions](applocker-processes-and-interactions.md)
The following topics explain how AppLocker rules and policies work:
- [Understanding AppLocker rule behavior](understanding-applocker-rule-behavior.md)
- [Understanding AppLocker rule exceptions](understanding-applocker-rule-exceptions.md)
- [Understanding AppLocker rule collections](understanding-applocker-rule-collections.md)
- [Understanding AppLocker allow and deny actions on rules](understanding-applocker-allow-and-deny-actions-on-rules.md)
- [Understanding AppLocker rule condition types](understanding-applocker-rule-condition-types.md)
- [Understanding the publisher rule condition in AppLocker](understanding-the-publisher-rule-condition-in-applocker.md)
- [Understanding the path rule condition in AppLocker](understanding-the-path-rule-condition-in-applocker.md)
- [Understanding the file hash rule condition in AppLocker](understanding-the-file-hash-rule-condition-in-applocker.md)
- [Understanding AppLocker default rules](understanding-applocker-default-rules.md)
- [Executable rules in AppLocker](executable-rules-in-applocker.md)
- [Windows Installer rules in AppLocker](windows-installer-rules-in-applocker.md)
- [Script rules in AppLocker](script-rules-in-applocker.md)
- [DLL rules in AppLocker](dll-rules-in-applocker.md)
- [Packaged apps and packaged app installer rules in AppLocker](packaged-apps-and-packaged-app-installer-rules-in-applocker.md)
## Additional resources
- [AppLocker Design Guide](applocker-policies-design-guide.md)
- [AppLocker deployment guide](applocker-policies-deployment-guide.md)
- [Administer AppLocker](administer-applocker.md)

View File

@ -0,0 +1,30 @@
---
title: Import an AppLocker policy from another computer
description: This topic for IT professionals describes how to import an AppLocker policy.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 12/31/2017
---
# Import an AppLocker policy from another computer
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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](export-an-applocker-policy-to-an-xml-file.md).
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.
**To import an AppLocker policy**
1. From the AppLocker console, right-click **AppLocker**, and then click **Import Policy**.
2. In the **Import Policy** dialog box, locate the file that you exported, and then click **Open**.
3. The **Import Policy** dialog box will warn you that importing a policy will overwrite the existing rules and enforcement settings. If acceptable, click **OK** to import and overwrite the policy.
4. The **AppLocker** dialog box will notify you of how many rules were overwritten and imported. Click **OK**.

View File

@ -0,0 +1,27 @@
---
title: Import an AppLocker policy into a GPO
description: This topic for IT professionals describes the steps to import an AppLocker policy into a Group Policy Object (GPO).
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Import an AppLocker policy into a GPO
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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](requirements-to-use-applocker.md).
>**Important:** Follow your organization's standard procedures for updating GPOs. For info about specific steps to follow for AppLocker policies, see [Maintain AppLocker policies](maintain-applocker-policies.md).
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**.

View File

@ -0,0 +1,104 @@
---
title: Maintain AppLocker policies
description: Learn how to maintain rules within AppLocker policies. View common AppLocker maintenance scenarios and see the methods to use to maintain AppLocker policies.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 12/31/2017
---
# Maintain AppLocker policies
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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)](#bkmk-applkr-use-mdm)
- [Maintaining AppLocker policies by using Group Policy](#bkmk-applkr-use-gp)
- [Maintaining AppLocker policies on the local computer](#bkmk-applkr-use-locsnapin)
## <a href="" id="bkmk-applkr-use-mdm"></a>Maintaining AppLocker policies by using Mobile Device Management (MDM)
Using the AppLocker configuration service provider, you can select which apps are allowed or blocked from running. Using the CSP, you can configure app restrictions based on grouping (such as EXE, MSI, DLL, Store apps and more) and then chose how to enforce different policies for different apps.
For more information, see the [AppLocker CSP](/windows/client-management/mdm/applocker-csp).
## <a href="" id="bkmk-applkr-use-gp"></a>Maintaining AppLocker policies by using Group Policy
For every scenario, the steps to maintain an AppLocker policy distributed by Group Policy include the following tasks.
As new apps are deployed or existing apps are removed by your organization or updated by the software publisher, you might need to make revisions to your rules and update the Group Policy Object (GPO) to ensure that your policy is current.
You can edit an AppLocker policy by adding, changing, or removing rules. However, you can't specify a version for the AppLocker policy by importing more rules. To ensure version control when modifying an AppLocker policy, use Group Policy management software that allows you to create
versions of GPOs.
>**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.
### Step 1: Understand the current behavior of the policy
Before modifying a policy, evaluate how the policy is currently implemented. For example, if a new version of the application is deployed, you can use **Test-AppLockerPolicy** to verify the effectiveness of your current policy for that app.
### Step 2: Export the AppLocker policy from the GPO
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 or test computer. To prepare an AppLocker policy for modification, see [Export an AppLocker policy from a GPO](export-an-applocker-policy-from-a-gpo.md).
### Step 3: Update the AppLocker policy by editing the appropriate AppLocker rule
After the AppLocker policy has been exported from the GPO into the AppLocker reference or test computer, or has been accessed on the local computer, the specific rules can be modified as required.
To modify AppLocker rules, see the following articles:
- [Edit AppLocker rules](edit-applocker-rules.md)
- [Merge AppLocker policies by using Set-ApplockerPolicy](merge-applocker-policies-by-using-set-applockerpolicy.md) or [Merge AppLocker policies manually](merge-applocker-policies-manually.md)
- [Delete an AppLocker rule](delete-an-applocker-rule.md)
- [Enforce AppLocker rules](enforce-applocker-rules.md)
### Step 4: Test the AppLocker policy
You should test each collection of rules to ensure that the rules perform as intended. (Because AppLocker rules are inherited from linked GPOs, you should deploy all rules for simultaneous testing in all test GPOs.) For steps to perform this testing, see [Test and update an AppLocker policy](test-and-update-an-applocker-policy.md).
### Step 5: Import the AppLocker policy into the GPO
After testing, import the AppLocker policy back into the GPO for implementation. To update the GPO with a modified AppLocker policy, see [Import an AppLocker policy into a GPO](import-an-applocker-policy-into-a-gpo.md).
### Step 6: Monitor the resulting policy behavior
After deploying a policy, evaluate the policy's effectiveness.
## <a href="" id="bkmk-applkr-use-locsnapin"></a>Maintaining AppLocker policies by using the Local Security Policy snap-in
For every scenario, the steps to maintain an AppLocker policy by using the Local Group Policy Editor or the Local Security Policy snap-in include the following tasks.
### Step 1: Understand the current behavior of the policy
Before modifying a policy, evaluate how the policy is currently implemented.
### Step 2: Update the AppLocker policy by modifying the appropriate AppLocker rule
Rules are grouped into a collection, which can have the policy enforcement setting applied to it. By default, AppLocker rules don't allow users to open or run any files that aren't allowed.
To modify AppLocker rules, see the appropriate topic listed on [Administer AppLocker](administer-applocker.md).
### Step 3: Test the AppLocker policy
You should test each collection of rules to ensure that the rules perform as intended. For steps to perform this testing, see [Test and update an AppLocker policy](test-and-update-an-applocker-policy.md).
### Step 4: Deploy the policy with the modified rule
You can export and then import AppLocker policies to deploy the policy to other computers running Windows 8 or later. To perform this task, see [Export an AppLocker policy to an XML file](export-an-applocker-policy-to-an-xml-file.md) and [Import an AppLocker policy from another computer](import-an-applocker-policy-from-another-computer.md).
### Step 5: Monitor the resulting policy behavior
After deploying a policy, evaluate the policy's effectiveness.
## Other resources
- For steps to perform other AppLocker policy tasks, see [Administer AppLocker](administer-applocker.md).

View File

@ -0,0 +1,71 @@
---
title: Manage packaged apps with AppLocker
description: Learn concepts and lists procedures to help you manage packaged apps with AppLocker as part of your overall application control strategy.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Manage packaged apps with AppLocker
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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.
## Understanding Packaged apps and Packaged app installers for AppLocker
Packaged apps, also known as Universal Windows apps, are based on a model that ensures all the files within an app package share the same identity. With classic Windows apps, each file within the app could have a unique identity.
With packaged apps, it's possible to control the entire app by using a single AppLocker rule.
> [!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.
### <a href="" id="bkmk-compareclassicmetro"></a>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 many 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're run with administrative privileges. Most packaged apps can't change the system state because they run with limited privileges. When you design your AppLocker policies, it's important to understand whether an app that you're 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](administer-applocker.md).
For more info about packaged apps, see [Packaged apps and packaged app installer rules in AppLocker](packaged-apps-and-packaged-app-installer-rules-in-applocker.md).
## Design and deployment decisions
You can use two methods to create an inventory of packaged apps on a computer: the AppLocker console or the **Get-AppxPackage** Windows PowerShell cmdlet.
> [!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](create-list-of-applications-deployed-to-each-business-group.md).
For info about how to use the **Get-AppxPackage** Windows PowerShell cmdlet, see the [AppLocker PowerShell Command Reference](/powershell/module/applocker/).
For info about creating rules for Packaged apps, see [Create a rule for packaged apps](create-a-rule-for-packaged-apps.md).
Consider the following info when you're designing and deploying apps:
- Because AppLocker supports only publisher rules for packaged apps, collecting the installation path information for packaged apps isn't necessary.
- You can't 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 weren't 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 wouldn't 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, which is 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.
## Using AppLocker to manage packaged apps
Just as there are differences in managing each rule collection, you need to manage the packaged apps with the following strategy:
1. Gather information about which Packaged apps are running in your environment. For information about how to gather this information, see [Create list of apps deployed to each business group](create-list-of-applications-deployed-to-each-business-group.md).
2. Create AppLocker rules for specific packaged apps based on your policy strategies. For more information, see [Create a rule for packaged apps](create-a-rule-for-packaged-apps.md) and [Understanding AppLocker default rules](understanding-applocker-default-rules.md).
3. Continue to update the AppLocker policies as new package apps are introduced into your environment. To do this update, see [Add rules for packaged apps to existing AppLocker rule-set](add-rules-for-packaged-apps-to-existing-applocker-rule-set.md).
4. Continue to monitor your environment to verify the effectiveness of the rules that are deployed in AppLocker policies. To do this monitoring, see [Monitor app usage with AppLocker](monitor-application-usage-with-applocker.md).

View File

@ -0,0 +1,34 @@
---
title: Merge AppLocker policies by using Set-ApplockerPolicy
description: This topic for IT professionals describes the steps to merge AppLocker policies by using Windows PowerShell.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Merge AppLocker policies by using Set-ApplockerPolicy
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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 isn't specified, then the new policy will overwrite the existing policy.
For info about using **Set-AppLockerPolicy**, including syntax descriptions and parameters, see [Set-AppLockerPolicy](/powershell/module/applocker/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](use-the-applocker-windows-powershell-cmdlets.md).
You can also manually merge AppLocker policies. For information on the procedure to do this merging, see [Merge AppLocker policies manually](merge-applocker-policies-manually.md).
**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](use-the-applocker-windows-powershell-cmdlets.md).
2. At the command prompt, type **C:\\PS&gt;Get-AppLockerPolicy -Local | Set-AppLockerPolicy -LDAP "LDAP: //***&lt;string&gt;***"** **-Merge** where *&lt;string&gt;* 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.
```powershell
C:\PS>Get-AppLockerPolicy -Local | Set-AppLockerPolicy -LDAP "LDAP://DC13.Contoso.com/CN={31B2F340-016D-11D2-945F-00C044FB984F9},CN=Policies,CN=System,DC=Contoso,DC=com" -Merge
```

View File

@ -0,0 +1,48 @@
---
title: Merge AppLocker policies manually
description: This topic for IT professionals describes the steps to manually merge AppLocker policies to update the Group Policy Object (GPO).
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Merge AppLocker policies manually
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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 can't 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](merge-applocker-policies-by-using-set-applockerpolicy.md).
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 collection | RuleCollection Type element |
| - | - |
| Executable rules| Exe|
| Windows Installer rules| Msi|
| Script rules | Script|
| DLL rules | Dll|
| Packaged apps and packaged app installers|Appx|
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:
| XML enforcement mode |Enforcement mode in Group Policy |
| - | - |
| NotConfigured | Not configured (rules are enforced)|
| AuditOnly | Audit only|
| Enabled | Enforce rules|
Each of the three condition types uses 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's functioning properly within the GPO.

View File

@ -0,0 +1,86 @@
---
title: Monitor app usage with AppLocker
description: This topic for IT professionals describes how to monitor app usage when AppLocker policies are applied.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Monitor app usage with AppLocker
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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's a good practice to determine if the policy implementation is what you expected.
### <a href="" id="bkmk-applkr-disc-effect-pol"></a>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 aren't enforced but are still evaluated to generate audit event data that is written to the AppLocker logs.
For more information on the procedure to access the log, see [View the AppLocker Log in Event Viewer](#bkmk-applkr-view-log).
- **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 more information on the procedure to do this configuration, see [Configure an AppLocker policy for audit only](configure-an-applocker-policy-for-audit-only.md).
- **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're using the audit-only enforcement mode) and how many times the event has occurred for each file.
For more information on the procedure to do this verification, see [Review AppLocker Events with Get-AppLockerFileInformation](#bkmk-applkr-review-events).
- **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 more information on the procedure to do this testing, see [Test an AppLocker policy by using Test-AppLockerPolicy](test-an-applocker-policy-by-using-test-applockerpolicy.md).
### <a href="" id="bkmk-applkr-review-events"></a>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.
**To review AppLocker events with Get-AppLockerFileInformation**
1. At the command prompt, type **PowerShell**, and then press ENTER.
2. Run the following command to review how many times a file would have been blocked from running if rules were enforced:
```powershell
Get-AppLockerFileInformation -EventLog -EventType Audited -Statistics
```
3. Run the following command to review how many times a file has been allowed to run or prevented from running:
```powershell
Get-AppLockerFileInformation -EventLog -EventType Allowed -Statistics
```
### <a href="" id="bkmk-applkr-view-log"></a>View the AppLocker Log 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 only evaluated but all events generated from that evaluation are written to the AppLocker log.
Membership in the local **Administrators** group, or equivalent, is the minimum required to complete this procedure.
**To view events in the AppLocker log by using Event Viewer**
1. To open Event Viewer, go to the **Start** menu, type **eventvwr.msc**, and then select ENTER.
2. In the console tree under **Application and Services Logs\\Microsoft\\Windows**, double-click **AppLocker**.
AppLocker events are listed in either the **EXE and DLL** log, the **MSI and Script** log, or the **Packaged app-Deployment** or **Packaged app-Execution** log. Event information includes the enforcement setting, file name, date and time, and user name. The logs can be exported to other file
formats for further analysis.
## Related topics
- [AppLocker](applocker-overview.md)

View File

@ -0,0 +1,29 @@
---
title: Optimize AppLocker performance
description: This topic for IT professionals describes how to optimize AppLocker policy enforcement.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Optimize AppLocker performance
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
This topic for IT professionals describes how to optimize AppLocker policy enforcement.
## Optimization of Group Policy
AppLocker policies can be implemented by organization unit (OU) using Group Policy. If so, your Group Policy infrastructure should be optimized and retested for performance when AppLocker policies are added to existing Group Policy Objects (GPOs) or new GPOs are created, as you do with adding any policies to your GPOs.
For more info, see the [Optimizing Group Policy Performance](/previous-versions/technet-magazine/cc137720(v=msdn.10)) article in TechNet Magazine.
### AppLocker rule limitations
The more rules per GPO, the longer AppLocker requires for evaluation. There is no set limitation on the number of rules per GPO, but the number of rules that can fit into a 100 MB GPO varies based on the complexity of the rule, such as the number of file hashes included in a single file hash
condition.
### Using the DLL rule collection
When the DLL rule collection is enabled, AppLocker must check each DLL that an application loads. The more DLLs, the longer AppLocker requires to complete the evaluation.

View File

@ -0,0 +1,30 @@
---
title: Packaged apps and packaged app installer rules in AppLocker
description: This topic explains the AppLocker rule collection for packaged app installers and packaged apps.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 10/13/2017
---
# Packaged apps and packaged app installer rules in AppLocker
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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's 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.

View File

@ -0,0 +1,158 @@
---
title: Plan for AppLocker policy management
description: This topic describes the decisions you need to make to establish the processes for managing and maintaining AppLocker policies.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Plan for AppLocker policy management
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
This topic 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 points 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 resources who maintain the AppLocker rules?
**End-user support**
Because AppLocker is preventing unapproved apps from running, it's important that your organization carefully plans 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 don't 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.
![applocker blocked application error message.](images/blockedappmsg.gif)
For steps to display a custom URL for the message, see [Display a custom URL message when users try to run a blocked app](display-a-custom-url-message-when-users-try-to-run-a-blocked-application.md).
**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 was the file that 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](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc748890(v=ws.11)).
### Policy maintenance
As new apps are deployed or existing apps are updated by the software publisher, you'll 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 can't specify a version for the policy by importing more 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 information, see [Advanced Group Policy Management Overview](/microsoft-desktop-optimization-pack/agpm/).
> [!IMPORTANT]
> 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.
**New version of a supported app**
When a new version of an app is deployed in the organization, you need to determine whether to continue to support the previous version of that app. To add the new version, you might only need to create a new rule for each file that is associated with the app. If you're using publisher conditions and the version isn't specified, then the existing rule or rules might be sufficient to allow the updated file to run. You must ensure, however, that the updated app hasn't altered the file names or added files to support new functionality. If so, then you must modify the existing rules or create new rules. To continue to reuse a publisher-based rule without a specific file version, you must also ensure that the file's digital signature is still identical to the previous version-the publisher, product name, and file name (if configured in your rule) must all match for the rule to be correctly applied.
To determine whether a file has been modified during an app update, review the publisher's release details provided with the update package. You can also review the publisher's web page to retrieve this information. Each file can also be inspected to determine the version.
For files that are allowed or denied with file hash conditions, you must retrieve the new file hash. To add support for a new version and maintain support for the older version, you can either create a new file hash rule for the new version or edit the existing rule and add the new file hash to the list of conditions.
For files with path conditions, you should verify that the installation path hasn't changed from what is stated in the rule. If the path has changed, you need to update the rule before installing the new version of the app
**Recently deployed app**
To support a new app, you must add one or more rules to the existing AppLocker policy.
**App is no longer supported**
If your organization has determined that it will no longer support an application that has AppLocker rules associated with it, the easiest way to prevent users from running the app is to delete these rules.
**App is blocked but should be allowed**
A file could be blocked for three reasons:
- The most common reason is that no rule exists to allow the app to run.
- There may be an existing rule that was created for the file that is too restrictive.
- A deny rule, which can't be overridden, is explicitly blocking the file.
Before editing the rule collection, first determine what rule is preventing the file from running. You can troubleshoot the problem by using the **Test-AppLockerPolicy** Windows PowerShell cmdlet. For more info about troubleshooting an AppLocker policy, see [Testing and Updating an AppLocker Policy](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ee791793(v=ws.10)).
## Record your findings
To complete this AppLocker planning document, you should first complete the following steps:
1. [Determine your application control objectives](determine-your-application-control-objectives.md)
2. [Create a list of apps deployed to each business group](create-list-of-applications-deployed-to-each-business-group.md)
3. [Select the types of rules to create](select-types-of-rules-to-create.md)
4. [Determine the Group Policy structure and rule enforcement](determine-group-policy-structure-and-rule-enforcement.md)
5. [Plan for AppLocker policy management](plan-for-applocker-policy-management.md)
The three key areas to determine for AppLocker policy management are:
1. Support policy
Document the process that you'll use for handling calls from users who have attempted to run a blocked app, and ensure that support personnel know recommended troubleshooting steps and escalation points for your policy.
2. Event processing
Document whether events will be collected in a central location, how that store will be archived, and whether the events will be processed for analysis.
3. Policy maintenance
Detail how rules will be added to the policy, in which Group Policy Object (GPO) the rules should be defined, and how to modify rules when apps are retired, updated, or added.
The following table contains the added sample data that was collected when determining how to maintain and manage AppLocker policies.
|Business group|Organizational unit|Implement AppLocker?|Apps|Installation path|Use default rule or define new rule condition|Allow or deny|GPO name|Support policy|
|--- |--- |--- |--- |--- |--- |--- |--- |--- |
|Bank Tellers|Teller-East and Teller-West|Yes|Teller Software|C:\Program Files\Woodgrove\Teller.exe|File is signed; create a publisher condition|Allow|Tellers-AppLockerTellerRules|Web help|
||||Windows files|C:\Windows|Create a path exception to the default rule to exclude \Windows\Temp|Allow||Help desk|
|Human Resources|HR-All|Yes|Check Payout|C:\Program Files\Woodgrove\HR\Checkcut.exe|File is signed; create a publisher condition|Allow|HR-AppLockerHRRules|Web help|
||||Time Sheet Organizer|C:\Program Files\Woodgrove\HR\Timesheet.exe|File isn't signed; create a file hash condition|Allow||Web help|
||||Internet Explorer 7|C:\Program Files\Internet Explorer</p>|File is signed; create a publisher condition|Deny||Web help|
||||Windows files|C:\Windows|Use the default rule for the Windows path|Allow||Help desk|
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 setting 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.
|Business group|AppLocker event collection location|Archival policy|Analyzed?|Security policy|
|--- |--- |--- |--- |--- |
|Bank Tellers|Forwarded to: AppLocker Event Repository on srvBT093|Standard|None|Standard|
|Human Resources|DO NOT FORWARD. srvHR004|60 months|Yes, summary reports monthly to managers|Standard|
<b>Policy maintenance policy</b>
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.
|Business group|Rule update policy|Application decommission policy|Application version policy|Application deployment policy|
|--- |--- |--- |--- |--- |
|Bank Tellers|Planned: Monthly through business office triage<p>Emergency: Request through help desk|Through business office triage<p>30-day notice required|General policy: Keep past versions for 12 months<p>List policies for each application|Coordinated through business office<p>30-day notice required|
|Human Resources|Planned: Monthly through HR triage<p>Emergency: Request through help desk|Through HR triage<p>30-day notice required|General policy: Keep past versions for 60 months<p>List policies for each application|Coordinated through HR<p>30-day notice required|

View File

@ -0,0 +1,53 @@
---
title: Refresh an AppLocker policy
description: This topic for IT professionals describes the steps to force an update for an AppLocker policy.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Refresh an AppLocker policy
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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.md)
[Edit an AppLocker policy](edit-an-applocker-policy.md) and [Use the AppLocker Windows PowerShell cmdlets](use-the-applocker-windows-powershell-cmdlets.md).
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 verification 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](edit-applocker-rules.md). 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-publisher-condition.md)
- [Create a rule that uses a file hash condition](create-a-rule-that-uses-a-file-hash-condition.md)
- [Create a rule that uses a path condition](create-a-rule-that-uses-a-path-condition.md)
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](edit-applocker-rules.md)
- [Delete an AppLocker rule](delete-an-applocker-rule.md)
- [Add exceptions for an AppLocker rule](configure-exceptions-for-an-applocker-rule.md)
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 these tasks, 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 information on the procedures to do this merging, see [Merge AppLocker policies manually](merge-applocker-policies-manually.md) and [Merge AppLocker policies by using Set-ApplockerPolicy](merge-applocker-policies-by-using-set-applockerpolicy.md).

View File

@ -0,0 +1,66 @@
---
title: Requirements for deploying AppLocker policies
description: This deployment topic for the IT professional lists the requirements that you need to consider before you deploy AppLocker policies.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Requirements for deploying AppLocker policies
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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](#bkmk-reqdepplan)
- [Supported operating systems](#bkmk-reqsupportedos)
- [Policy distribution mechanism](#bkmk-reqpolicydistmech)
- [Event collection and analysis system](#bkmk-reqeventcollectionsystem)
### <a href="" id="bkmk-reqdepplan"></a>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](applocker-policies-design-guide.md). 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](requirements-to-use-applocker.md)).
|Business group|Organizational unit|Implement AppLocker?|Apps|Installation path|Use default rule or define new rule condition|Allow or deny|GPO name|Support policy|
|--- |--- |--- |--- |--- |--- |--- |--- |--- |
|Bank Tellers|Teller-East and Teller-West|Yes|Teller software|C:\Program Files\Woodgrove\Teller.exe|File is signed; create a publisher condition|Allow|Tellers|Web help|
||||Windows files|C:\Windows|Create a path exception to the default rule to exclude \Windows\Temp|Allow||Help Desk|
||||Time Sheet Organizer|C:\Program Files\Woodgrove\HR\Timesheet.exe|File is not signed; create a file hash condition|Allow||Web help|
|Human Resources|HR-All|Yes|Check Payout|C:\Program Files\Woodgrove\HR\Checkcut.exe|File is signed; create a publisher condition|Allow|HR|Web help|
||||Internet Explorer 7|C:\Program Files\Internet Explorer</p>|File is signed; create a publisher condition|Deny||Help Desk|
||||Windows files|C:\Windows|Use the default rule for the Windows path|Allow||Help Desk|
<b>Event processing policy</b>
|Business group|AppLocker event collection location|Archival policy|Analyzed?|Security policy|
|--- |--- |--- |--- |--- |
|Bank Tellers|Forwarded to: srvBT093|Standard|None|Standard|
|Human Resources|Do not forward|60 months|Yes; summary reports monthly to managers|Standard|
<b>Policy maintenance policy</b>
|Business group|Rule update policy|App decommission policy|App version policy|App deployment policy|
|--- |--- |--- |--- |--- |
|Bank Tellers|Planned: Monthly through business office triage<p>Emergency: Request through Help Desk|Through business office triage; 30-day notice required|General policy: Keep past versions for 12 months<p>List policies for each application|Coordinated through business office; 30-day notice required|
|Human Resources|Planned: Through HR triage<p>Emergency: Request through Help Desk|Through HR triage; 30-day notice required|General policy: Keep past versions for 60 months<p>List policies for each application|Coordinated through HR; 30-day notice required|
### <a href="" id="bkmk-reqsupportedos"></a>Supported operating systems
AppLocker is supported only on certain operating systems. Some features are not available on all operating systems. For more information, see [Requirements to use AppLocker](requirements-to-use-applocker.md).
### <a href="" id="bkmk-reqpolicydistmech"></a>Policy distribution mechanism
You need a way to distribute the AppLocker policies throughout the targeted business groups. AppLocker uses Group Policy management architecture to effectively distribute application control policies. AppLocker policies can also be configured on individual computers by using the Local Security Policy snap-in.
### <a href="" id="bkmk-reqeventcollectionsystem"></a>Event collection and analysis system
Event processing is important to understand application usage. You must have a process in place to collect and analyze AppLocker events so that application usage is appropriately restricted and understood. For procedures to monitor AppLocker events, see:
- [Configure an AppLocker policy for audit only](configure-an-applocker-policy-for-audit-only.md)
- [Configure an AppLocker policy for enforce rules](configure-an-applocker-policy-for-enforce-rules.md)
- [Monitor app usage with AppLocker](monitor-application-usage-with-applocker.md)
## See also
- [AppLocker deployment guide](applocker-policies-deployment-guide.md)

View File

@ -0,0 +1,61 @@
---
title: Requirements to use AppLocker
description: This topic for the IT professional lists software requirements to use AppLocker on the supported Windows operating systems.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Requirements to use AppLocker
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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]
>As of [KB 5024351](https://support.microsoft.com/help/5024351), Windows 10 versions 2004 and newer and all Windows 11 versions no longer require a specific edition of Windows to enforce AppLocker policies
## Operating system requirements
The following table shows the Windows versions on which AppLocker features are supported.
| Version | Can be configured | Can be enforced | Available rules | Notes |
| - | - | - | - | - |
| Windows 10 and Windows 11| Yes| Yes| Packaged apps<br/>Executable<br/>Windows Installer<br/>Script<br/>DLL| Policies are supported on all editions Windows 10 version 2004 and newer with [KB 5024351](https://support.microsoft.com/help/5024351).<br><br>Windows versions older than version 2004, including Windows Server 2019:<br><ul><li>Policies deployed through GP are only supported on Enterprise and Server editions.</li><li>Policies deployed through MDM are supported on all editions.</li></ul> |
| Windows Server 2019<br/>Windows Server 2016<br/>Windows Server 2012 R2<br/>Windows Server 2012| Yes| Yes| Packaged apps<br/>Executable<br/>Windows Installer<br/>Script<br/>DLL| |
| Windows 8.1 Pro| Yes| No| N/A||
| Windows 8.1 Enterprise| Yes| Yes| Packaged apps<br/>Executable<br/>Windows Installer<br/>Script<br/>DLL| |
| Windows RT 8.1| No| No| N/A||
| Windows 8 Pro| Yes| No| N/A||
| Windows 8 Enterprise| Yes| Yes| Packaged apps<br/>Executable<br/>Windows Installer<br/>Script<br/>DLL||
| Windows RT| No| No| N/A| |
| Windows Server 2008 R2 Standard| Yes| Yes| Executable<br/>Windows Installer<br/>Script<br/>DLL| Packaged app rules won't be enforced.|
| Windows Server 2008 R2 Enterprise|Yes| Yes| Executable<br/>Windows Installer<br/>Script<br/>DLL| Packaged app rules won't be enforced.|
| Windows Server 2008 R2 Datacenter| Yes| Yes| Executable<br/>Windows Installer<br/>Script<br/>DLL| Packaged app rules won't be enforced.|
| Windows Server 2008 R2 for Itanium-Based Systems| Yes| Yes| Executable<br/>Windows Installer<br/>Script<br/>DLL| Packaged app rules won't be enforced.|
| Windows 7 Ultimate| Yes| Yes| Executable<br/>Windows Installer<br/>Script<br/>DLL| Packaged app rules won't be enforced.|
| Windows 7 Enterprise| Yes| Yes| Executable<br/>Windows Installer<br/>Script<br/>DLL| Packaged app rules won't be enforced.|
| Windows 7 Professional| Yes| No| Executable<br/>Windows Installer<br/>Script<br/>DLL| No AppLocker rules are enforced.|
AppLocker isn't 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 isn't supported on the above operating systems.
>[!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](use-applocker-and-software-restriction-policies-in-the-same-domain.md).
## See also
- [Administer AppLocker](administer-applocker.md)
- [Monitor app usage with AppLocker](monitor-application-usage-with-applocker.md)
- [Optimize AppLocker performance](optimize-applocker-performance.md)
- [Use AppLocker and Software Restriction Policies in the same domain](use-applocker-and-software-restriction-policies-in-the-same-domain.md)
- [Manage packaged apps with AppLocker](manage-packaged-apps-with-applocker.md)
- [AppLocker Design Guide](applocker-policies-design-guide.md)

View File

@ -0,0 +1,38 @@
---
title: Run the Automatically Generate Rules wizard
description: This topic for IT professionals describes steps to run the wizard to create AppLocker rules on a reference device.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Run the Automatically Generate Rules wizard
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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](administer-applocker.md#bkmk-using-snapins).
**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 folder is the Program Files folder.
5. Click **Select** to choose the security group in which the default rules should be applied. By default, this group 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've 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](understanding-applocker-rule-condition-types.md).
>**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 aren't 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.

View File

@ -0,0 +1,33 @@
---
title: Script rules in AppLocker
description: This article describes the file formats and available default rules for the script rule collection.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 06/15/2022
---
# Script rules in AppLocker
This article 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.
| Purpose | Name | User | Rule condition type |
| - | - | - | - |
| Allows members of the local Administrators group to run all scripts| (Default Rule) All scripts| BUILTIN\Administrators | Path: `*\` |
| Allow all users to run scripts in the Windows folder| (Default Rule) All scripts located in the Windows folder| Everyone | Path: `%windir%\*` |
| Allow all users to run scripts in the Program Files folder| (Default Rule) All scripts located in the Program Files folder|Everyone | Path: `%programfiles%\*`|
> [!NOTE]
> When a script runs that is not allowed by policy, AppLocker raises an event indicating that the script was "blocked". However, the actual script enforcement behavior is handled by the script host. In the case of PowerShell, "blocked" scripts will still run, but only in [Constrained Language Mode](/powershell/module/microsoft.powershell.core/about/about_language_modes). Authorized scripts run in Full Language Mode.
## Related articles
- [Understanding AppLocker default rules](understanding-applocker-default-rules.md)

View File

@ -0,0 +1,47 @@
---
title: Security considerations for AppLocker
description: This topic for the IT professional describes the security considerations you need to address when implementing AppLocker.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Security considerations for AppLocker
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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 resources in IT with trusted credentials. This system 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 isn't in a GPO will still be evaluated for that computer.
Microsoft doesn't provide a way to develop any extensions to AppLocker. The interfaces aren't 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](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ee460962(v=technet.10)).
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 isn't in a GPO will still be evaluated for that computer. If the local computer isn't joined to a domain and isn't administered by Group Policy, a person with administrative credentials can alter the AppLocker policy.
When files are being secured in a directory with a rule of the path condition type, whether using the allow or deny action on the rule, it's still necessary and good practice to restrict access to those files by setting the access control lists (ACLs) according to your security policy.
AppLocker doesn't 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's 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's a requirement to prevent 16-bit applications from running, you must configure the Deny rule in the executable rule collection for NTVDM.exe.
You can't use AppLocker (or Software Restriction Policies) to prevent code from running outside the Win32 subsystem. In particular, this rule applies to the (POSIX) subsystem in Windows NT. If it's 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 doesn't 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 can't 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 doesn't control the behavior of applications after they're 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](applocker-technical-reference.md)

View File

@ -0,0 +1,69 @@
---
title: Select the types of rules to create
description: This topic lists resources you can use when selecting your application control policy rules by using AppLocker.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Select the types of rules to create
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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-behavior.md)
- [Understanding AppLocker rule exceptions](understanding-applocker-rule-exceptions.md)
- [Understanding AppLocker rule collections](understanding-applocker-rule-collections.md)
- [Understanding AppLocker allow and deny actions on rules](understanding-applocker-allow-and-deny-actions-on-rules.md)
- [Understanding AppLocker rule condition types](understanding-applocker-rule-condition-types.md)
- [Understanding AppLocker default rules](understanding-applocker-default-rules.md)
### 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 isn't 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.
| Rule condition | Usage scenario | Resources |
| - | - | - |
| 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](understanding-the-publisher-rule-condition-in-applocker.md).
| 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](understanding-the-path-rule-condition-in-applocker.md). |
| 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 based in part upon the version.| For more info about this rule condition, see [Understanding the file hash rule condition in AppLocker](understanding-the-file-hash-rule-condition-in-applocker.md). |
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 rule 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](working-with-applocker-rules.md#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're 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's 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 rule will permit access to these files whenever updates are applied and the files change. If you require more 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've selected the types of rules to create, record your findings as explained in [Document your AppLocker rules](document-your-applocker-rules.md).
After recording your findings for the AppLocker rules to create, you'll need to consider how to enforce the rules. For information about how to do this enforcement, see [Determine Group Policy structure and rule enforcement](determine-group-policy-structure-and-rule-enforcement.md).

View File

@ -0,0 +1,40 @@
---
title: Test an AppLocker policy by using Test-AppLockerPolicy
description: 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.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Test an AppLocker policy by using Test-AppLockerPolicy
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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.
1. Open a Windows PowerShell command prompt window as an administrator.
2. 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>`
The following shows example input for **Test-AppLockerPolicy**:
```syntax
PS C:\ Get-AppLockerPolicy -Effective -XML > C:\Effective.xml
PS C:\ Get-ChildItem 'C:\Program Files\Microsoft Office\' -filter *.exe -Recurse | Convert-Path | Test-AppLockerPolicy -XMLPolicy C:\Effective.xml -User contoso\zwie -Filter Denied,DeniedByDefault | Export-CSV C:\BlockedFiles.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.

View File

@ -0,0 +1,57 @@
---
title: Test and update an AppLocker policy
description: This topic discusses the steps required to test an AppLocker policy prior to deployment.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Test and update an AppLocker policy
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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.
## Step 1: Enable the Audit only enforcement setting
By using the **Audit only** enforcement setting, you can ensure that the AppLocker rules that you have created are properly configured for your organization. This setting can be enabled on the **Enforcement** tab of the **AppLocker Properties** dialog box. For information on the procedure to do this configuration, see [Configure an AppLocker policy for audit only](configure-an-applocker-policy-for-audit-only.md).
## Step 2: Configure the Application Identity service to start automatically
Because AppLocker uses the Application Identity service to verify the attributes of a file, you must configure it to start automatically in any one GPO that applies AppLocker rules. For information on the procedure to do this configuration, see [Configure the Application Identity Service](configure-the-application-identity-service.md). For AppLocker policies that aren't managed by a GPO, you must ensure that the service is running on each PC in order for the policies to be applied.
## Step 3: Test the policy
Test the AppLocker policy to determine if your rule collection needs to be modified. Because you have created AppLocker rules, enabled the Application Identity service, and enabled the **Audit only** enforcement setting, the AppLocker policy should be present on all client PCs that are configured to receive your AppLocker policy.
The **Test-AppLockerPolicy** Windows PowerShell cmdlet can be used to determine whether any of the rules in your rule collection will be blocked on your reference PCs. For information on the procedure to do this testing, see [Test an AppLocker policy by using Test-AppLockerPolicy](test-an-applocker-policy-by-using-test-applockerpolicy.md).
## Step 4: Analyze AppLocker events
You can either manually analyze AppLocker events or use the **Get-AppLockerFileInformation** Windows PowerShell cmdlet to automate the analysis.
**To manually analyze AppLocker events**
You can view the events either in Event Viewer or a text editor and then sort those events to perform an analysis, such as looking for patterns in application usage events, access frequencies, or access by user groups. If you haven't configured an event subscription, then you'll have to review the logs on a sampling of computers in your organization. For more information about using Event Viewer, see [Monitor application usage with AppLocker](monitor-application-usage-with-applocker.md).
**To analyze AppLocker events by using Get-AppLockerFileInformation**
You can use the **Get-AppLockerFileInformation** Windows PowerShell cmdlet to analyze AppLocker events from a remote computer. If an app is being blocked and should be allowed, you can use the AppLocker cmdlets to help troubleshoot the problem.
For both event subscriptions and local events, you can use the **Get-AppLockerFileInformation** cmdlet to determine which files have been blocked or would have been blocked (if you're using the **Audit only** enforcement mode) and how many times the event has occurred for each file. For information on the procedure to do this monitoring, see [Monitor Application Usage with AppLocker](monitor-application-usage-with-applocker.md).
After using **Get-AppLockerFileInformation** to determine how many times that a file would have been blocked from running, you should review your rule list to determine whether a new rule should be created for the blocked file or whether an existing rule is too strictly defined. Ensure that you check which GPO is currently preventing the file from running. To determine this blocker GPO, you can use the Group Policy Results Wizard to view rule names.
## Step 5: Modify the AppLocker policy
After you've identified which rules need to be edited or added to the policy, you can use the Group Policy Management Console to modify the AppLocker rules in the relevant GPOs. For AppLocker policies that aren't managed by a GPO, you can use the Local Security Policy snap-in (secpol.msc). For info how to modify an AppLocker policy, see, [Edit an AppLocker policy](edit-an-applocker-policy.md).
## Step 6: Repeat policy testing, analysis, and policy modification
Repeat the previous steps 3-5 until all the rules perform as intended before applying enforcement.
## Other resources
- For steps to perform other AppLocker policy tasks, see [Administer AppLocker](administer-applocker.md).

View File

@ -0,0 +1,50 @@
---
title: Tools to use with AppLocker
description: This topic for the IT professional describes the tools available to create and administer AppLocker policies.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Tools to use with AppLocker
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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](requirements-to-use-applocker.md).
- **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](working-with-applocker-rules.md).
- **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](create-applocker-default-rules.md). For a list of the default rules, see [AppLocker default rules](working-with-applocker-rules.md#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](run-the-automatically-generate-rules-wizard.md).
- **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 more 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](using-event-viewer-with-applocker.md), and [Monitor app usage with AppLocker](monitor-application-usage-with-applocker.md).
- **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](/powershell/module/applocker/).
## Related topics
- [AppLocker technical reference](applocker-technical-reference.md)

View File

@ -0,0 +1,26 @@
---
title: Understand AppLocker enforcement settings
description: This topic describes the AppLocker enforcement settings for rule collections.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Understand AppLocker enforcement settings
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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](understanding-applocker-rule-collections.md). By default, if enforcement isn't 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.
| Enforcement setting | Description |
| - | - |
| Not configured | By default, enforcement isn't configured in a rule collection. If rules are present in the corresponding rule collection, they're enforced. If rule enforcement is configured in a higher-level linked Group Policy object (GPO), that enforcement value overrides the **Not configured** value.|
| 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](configure-the-application-identity-service.md).
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.

View File

@ -0,0 +1,179 @@
---
title: Understand AppLocker policy design decisions
description: Review some common considerations while you're planning to use AppLocker to deploy application control policies within a Windows environment.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 10/13/2017
---
# Understand AppLocker policy design decisions
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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](requirements-to-use-applocker.md).
- 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 aren't 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 applications because they access sensitive data, or you might have to exclude all applications except those applications that are sanctioned for business purposes. There might be certain business groups that require strict control, and others that promote independent application usage.
| Possible answers | Design considerations|
| - | - |
| Control all apps | AppLocker policies control applications by creating an allowed list of applications by file type. Exceptions are also possible. AppLocker policies can only be applied to applications installed on computers running one of the supported versions of Windows. For specific operating system version requirements, see [Requirements to use AppLocker](requirements-to-use-applocker.md).|
| Control specific apps | When you create AppLocker rules, a list of allowed apps is created. All applications on that list will be allowed to run (except those applications on the exception list). Applications that aren't 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](requirements-to-use-applocker.md).|
|Control only Classic Windows applications, only Universal Windows apps, or both| AppLocker policies control apps by creating an allowed list of 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.<br/>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](#bkmk-compareclassicmetro) 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.|
| Control apps by computer, not user | AppLocker is a computer-based policy implementation. If your domain or site organizational structure isn't based on a logical user structure, such as an OU, you might want to set up that structure before you begin your AppLocker planning. Otherwise, you'll have to identify users, their computers, and their app access requirements.|
|Understand app usage, but there's no need to control any apps yet | AppLocker policies can be set to audit app usage to help you 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 doesn't protect against running 16-bit DOS binaries in an 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's 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's a requirement to prevent 16-bit applications from running, you must configure the Deny rule in the Executable rule collection for NTVDM.exe.
- You can't use AppLocker to prevent code from running outside the Win32 subsystem. In particular, this rule applies to the (POSIX) subsystem in Windows NT. If it's 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 doesn't 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 can't 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 doesn't control the behavior of apps after they're 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](security-considerations-for-applocker.md).
### <a href="" id="bkmk-compareclassicmetro"></a>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 many 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 can't change the system state because they run with limited permissions. When you design your AppLocker policies, it's important to understand whether an app that you're 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](packaged-apps-and-packaged-app-installer-rules-in-applocker.md).
### 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.
| Possible answers | Design considerations |
| - | - |
| Security policies (locally set or through Group Policy) | Using AppLocker requires increased effort in planning to create correct policies, but this policy creation 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.|
| Authorization Manager or other role-based access technologies | Using AppLocker requires a complete app control policy evaluation and implementation.|
| Other | Using AppLocker requires a complete app control policy 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.
|Possible answers|Design considerations|
|--- |--- |
|Your organization's computers are running a combination of the following operating systems:<li>Windows 11<li>Windows 10<li>Windows 8<li>Windows 7<li>Windows Vista<li>Windows XP<li>Windows Server 2012<li>Windows Server 2008 R2<li>Windows Server 2008<li>Windows Server 2003|AppLocker rules are only applied to computers running the supported versions of Windows, but SRP rules can be applied to all versions of Windows beginning with Windows XP and Windows Server 2003. For specific operating system version requirements, see [Requirements to use AppLocker](requirements-to-use-applocker.md).<br/><br/> **Note:** If you're using the Basic User security level as assigned in SRP, those privileges aren't supported on computers running that support AppLocker.<br/><br/>AppLocker policies as applied through a GPO take precedence over SRP policies in the same or linked GPO. SRP policies can be created and maintained the same way.|
|Your organization's computers are running only the following operating systems:<li>Windows 11<li>Windows 10<li>Windows 8.1<li>Windows 8<li>Windows 7<li>Windows Server 2012 R2<li>Windows Server 2012<li>Windows Server 2008 R2|Use AppLocker to create your application control policies.|
### 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.
| Possible answers | Design considerations |
| - | - |
| Yes | For each group, you need to create a list that includes their application control requirements. Although this consideration may increase the planning time, it will most likely result in a more effective deployment.<br/>If your GPO structure isn't 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.|
| No | AppLocker policies can be applied globally to applications that are installed on PCs running the supported versions of Windows as listed in [Requirements to use AppLocker](requirements-to-use-applocker.md). Depending on the number of apps you need to control, managing all the rules and exceptions might be challenging.|
### 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.
| Possible answers | Design considerations |
| - | - |
| Yes | Invest the time to analyze your organization's application control requirements, and plan a complete deployment that uses rules that are as constructed as possible.|
| No | Consider a focused and phased deployment for specific groups by using a few rules. As you apply controls to applications in a specific group, learn from that deployment to plan your next deployment. |
### Does your organization have Help Desk support?
Preventing your users from accessing known, deployed, or personal applications will initially cause an increase in end-user support. It will be necessary to address the various support issues in your organization so security policies are followed and business workflow isn't hampered.
| Possible answers | Design considerations |
| - | - |
| Yes | Involve the support department early in the planning phase because your users may inadvertently be blocked from using their applications, or they may seek exceptions to use specific applications. |
| No | Invest time in developing online support processes and documentation before deployment. |
### Do you know what applications require restrictive policies?
Any successful application control policy implementation is based on your knowledge and understanding of app usage within the organization or business group. In addition, the application control design is dependent on the security requirements for data and the apps that access that data.
| Possible answers | Design considerations |
| - | - |
| Yes | You should determine the application control priorities for a business group and then attempt to design the simplest scheme for their application control policies. |
| No | You'll have to perform an audit and requirements gathering project to discover the application usage. AppLocker provides the means to deploy policies in **Audit only** mode, and tools to view the event logs.|
### How do you deploy or sanction applications (upgraded or new) in your organization?
Implementing a successful application control policy is based on your knowledge and understanding of application usage within the organization or business group. In addition, the application control design is dependent on the security requirements for data and the applications that access that data. Understanding the upgrade and deployment policy will help shape the construction of the application control policies.
| Possible answers | Design considerations |
| - | - |
| Ad hoc | You need to gather requirements from each group. Some groups might want unrestricted access or installation, while other groups might want strict controls.|
| 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. |
### Does your organization already have SRP deployed?
Although SRP and AppLocker have the same goal, AppLocker is a major revision of SRP.
| Possible answers | Design considerations |
| - | - |
| Yes | You can't 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](requirements-to-use-applocker.md). 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.<br/><br/>**Note:** If you're using the Basic User security level as assigned in SRP, those permissions aren't supported on computers running the supported operating systems.|
| No | Policies that are configured for AppLocker can only be applied to computers running the supported operating systems, but SRP is also available on those 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 required applications can be installed. | To meet innovation and productivity goals, some groups require the ability to install and run various softwares from different sources, including software that they developed. Therefore, if innovation and productivity are 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 applications it supports. | In some business groups, application usage can be managed from a central point of control. AppLocker policies can be built into a GPO for that purpose. This GPO shifts the burden of application access to the IT department, but it also has the benefit of controlling the number of applications that can be run and controlling the versions of those applications|
| Security: The organization must protect data in part by ensuring that only approved apps are used. | AppLocker can help protect data by allowing a defined set of users access to apps that access the data. If security is the top priority, the application control policies will be the most restrictive.|
### How are apps currently accessed in your organization?
AppLocker is effective for organizations that have application restriction requirements if they have environments with a simple topography and application control policy goals that are straightforward. For example, AppLocker can benefit an environment where non-employees have access to computers that are 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 desktop computers with a relatively small number of applications to manage, or when the applications are manageable with a few rules.
| Possible answers | Design considerations |
| - | - |
| Users run without administrative rights. | Apps are installed by using an installation deployment technology.|
| AppLocker can help reduce the total cost of ownership for 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.<br/><br/>**Note:** AppLocker can also be effective in helping create standardized desktops in organizations where users run as administrators. However, it's important to note that users with administrative credentials can add new rules to the local AppLocker policy.| Users must be able to install applications as needed.
| Users currently have administrator access, and it would be difficult to change this privilege.|Enforcing AppLocker rules isn't suited for business groups 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.
| Possible answers | Design considerations |
| - | - |
| Yes | AppLocker rules can be developed and implemented through Group Policy, based on your AD DS structure.|
| No | The IT department must create a scheme to identify how application control policies can be applied to the correct user or computer.|
## Record your findings
The next step in the process is to record and analyze your answers to the preceding questions. If AppLocker is the right solution for your goals, you can set your application control policy objectives and plan your AppLocker rules. This process culminates in creating your planning document.
- For info about setting your policy goals, see [Determine your application control objectives](determine-your-application-control-objectives.md).

View File

@ -0,0 +1,43 @@
---
title: Understand AppLocker rules and enforcement setting inheritance in Group Policy
description: This topic for the IT professional describes how application control policies configured in AppLocker are applied through Group Policy.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Understand AppLocker rules and enforcement setting inheritance in Group Policy
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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:
1. **Explicit deny.** An administrator created a rule to deny a file.
2. **Explicit allow.** An administrator created a rule to allow a file.
3. **Implicit deny.** This is also called the default deny because all files that are not affected by an allow rule are automatically blocked.
- **Enforcement settings.** The last write to the policy is applied. For example, if a higher-level GPO has the enforcement setting configured to **Enforce rules** and the closest GPO has the setting configured to **Audit only**, **Audit only** is enforced. If enforcement is not configured on the closest GPO, the setting from the closest linked GPO will be enforced.
Because a computer's effective policy includes rules from each linked GPO, duplicate rules or conflicting rules could be enforced on a user's computer. Therefore, you should carefully plan your deployment to ensure that only rules that are necessary are present in a GPO.
The following figure demonstrates how AppLocker rule enforcement is applied through linked GPOs.
![applocker rule enforcement inheritance chart.](images/applocker-plan-inheritance.gif)
In the preceding illustration, note that all GPOs linked to Contoso are applied in order as configured. The rules that are not configured are also applied. For example, the result of the Contoso and Human Resources GPOs is 33 rules enforced, as shown in the client HR-Term1. The Human Resources GPO contains 10 non-configured rules. When the rule collection is configured for **Audit only**, no rules are enforced.
When constructing the Group Policy architecture for applying AppLocker policies, it is important to remember:
- Rule collections that are not configured will be enforced.
- Group Policy does not overwrite or replace rules that are already present in a linked GPO.
- AppLocker processes the explicit deny rule configuration before the allow rule configuration.
- For rule enforcement, the last write to the GPO is applied.

View File

@ -0,0 +1,29 @@
---
title: Understand the AppLocker policy deployment process
description: This planning and deployment topic for the IT professional describes the process for using AppLocker when deploying application control policies.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Understand the AppLocker policy deployment process
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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.
![applocker quick reference guide.](images/applocker-plandeploy-quickreference.gif)
## 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](applocker-policies-design-guide.md).
- For info about the AppLocker policy deployment requirements and process, see [AppLocker deployment guide](applocker-policies-deployment-guide.md).
- For info about AppLocker policy maintenance and monitoring, see [Administer AppLocker](administer-applocker.md).
- For info about AppLocker policy architecture, components, and processing, see [AppLocker technical reference](applocker-technical-reference.md).

View File

@ -0,0 +1,36 @@
---
title: Understanding AppLocker allow and deny actions on rules
description: This topic explains the differences between allow and deny actions on AppLocker rules.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Understanding AppLocker allow and deny actions on rules
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
This topic explains the differences between allow and deny actions on AppLocker rules.
## Allow action versus deny action on rules
Unlike Software Restriction Policies (SRP), each AppLocker rule collection functions as an allowed list of files. Only the files that are listed within the rule collection are allowed to run. This **block by default, allow by exception** configuration makes it easier to determine what will occur when an AppLocker rule is applied.
You can also create rules that use the deny action. When applying rules, AppLocker first checks whether any explicit deny actions are specified in the rule list. If you have denied a file from running in a rule collection, the deny action will take precedence over any allow action, regardless of which Group Policy Object (GPO) the rule was originally applied in. Because AppLocker functions as an allowed list by default, if no rule explicitly allows or denies a file from running, AppLocker's default deny action will block the file.
### Deny rule considerations
Although you can use AppLocker to create a rule to allow all files to run and then use rules to deny specific files, this configuration is not recommended. The deny action is generally less secure than the allow action because a malicious user could modify the file to invalidate the rule. 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. The following table details security concerns for different rule conditions with deny actions.
| Rule condition | Security concern with deny action |
| - | - |
| Publisher | A user could modify the properties of a file (for example, re-signing the file with a different certificate).|
| File hash | A user could modify the hash for a file.|
| 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](how-applocker-works-techref.md)

View File

@ -0,0 +1,43 @@
---
title: Understanding AppLocker default rules
description: 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.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Understanding AppLocker default rules
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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](executable-rules-in-applocker.md) | This topic describes the file formats and available default rules for the executable rule collection. |
| [Windows Installer rules in AppLocker](windows-installer-rules-in-applocker.md) | This topic describes the file formats and available default rules for the Windows Installer rule collection.|
| [Script rules in AppLocker](script-rules-in-applocker.md) | This topic describes the file formats and available default rules for the script rule collection.|
| [DLL rules in AppLocker](dll-rules-in-applocker.md) | This topic describes the file formats and available default rules for the DLL rule collection.|
| [Packaged apps and packaged app installer rules in AppLocker](packaged-apps-and-packaged-app-installer-rules-in-applocker.md) | This topic explains the AppLocker rule collection for packaged app installers and packaged apps.|
## Related topics
- [How AppLocker works](how-applocker-works-techref.md)
- [Create AppLocker default rules](create-applocker-default-rules.md)

View File

@ -0,0 +1,27 @@
---
title: Understanding AppLocker rule behavior
description: This topic describes how AppLocker rules are enforced by using the allow and deny options in AppLocker.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Understanding AppLocker rule behavior
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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 aren't 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](how-applocker-works-techref.md)

View File

@ -0,0 +1,33 @@
---
title: Understanding AppLocker rule collections
description: This topic explains the five different types of AppLocker rules used to enforce AppLocker policies.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Understanding AppLocker rule collections
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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](enable-the-dll-rule-collection.md).
## Related topics
- [How AppLocker works](how-applocker-works-techref.md)
- [Understanding AppLocker default rules](understanding-applocker-default-rules.md)

View File

@ -0,0 +1,55 @@
---
title: Understanding AppLocker rule condition types
description: This topic for the IT professional describes the three types of AppLocker rule conditions.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Understanding AppLocker rule condition types
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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](understanding-the-publisher-rule-condition-in-applocker.md).
**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](understanding-the-path-rule-condition-in-applocker.md).
**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](understanding-the-file-hash-rule-condition-in-applocker.md).
### 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.
2. What rule condition type does your organization prefer?
If your organization is already using Software Restriction Policies (SRP) to restrict what files users can run, rules using file hash or path conditions are probably already in place.
> [!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](requirements-to-use-applocker.md).
## Related topics
- [How AppLocker works](how-applocker-works-techref.md)

View File

@ -0,0 +1,24 @@
---
title: Understanding AppLocker rule exceptions
description: This topic describes the result of applying AppLocker rule exceptions to rule collections.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Understanding AppLocker rule exceptions
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
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 doesn't allow anyone to run Registry Editor (by adding %WINDIR%\regedit.exe as a Path Exception for 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 doesn't 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](how-applocker-works-techref.md)

View File

@ -0,0 +1,26 @@
---
title: Understanding the file hash rule condition in AppLocker
description: This topic explains the AppLocker file hash rule condition, the advantages and disadvantages, and how it's applied.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Understanding the file hash rule condition in AppLocker
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
This topic explains the AppLocker file hash rule condition, the advantages and disadvantages, and how it's applied.
File hash rules use a system-computed cryptographic hash of the identified file. For files that aren't digitally signed, file hash rules are more secure than path rules. The following table describes the advantages and disadvantages of the file hash condition.
| File hash condition advantages | File hash condition disadvantages |
| - | - |
| Because each file has a unique hash, a file hash condition applies to only one file. | Each time that 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.|
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](understanding-applocker-rule-condition-types.md).
## Related topics
- [How AppLocker works](how-applocker-works-techref.md)

View File

@ -0,0 +1,43 @@
---
title: Understanding the path rule condition in AppLocker
description: This topic explains the AppLocker path rule condition, the advantages and disadvantages, and how it's applied.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Understanding the path rule condition in AppLocker
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
This topic explains the AppLocker path rule condition, the advantages and disadvantages, and how it's 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.
|Path condition advantages|Path condition disadvantages|
|--- |--- |
|<li>You can easily control many folders or a single file.<li>You can use the asterisk (*) as a wildcard character within path rules.|<li>It might be less secure if a rule that is configured to use a folder path contains subfolders that are writable by non-administrators.<li>You must specify the full path to a file or folder when creating path rules so that the rule will be properly enforced.|
AppLocker doesn't 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 aren't environment variables. The AppLocker engine can only interpret AppLocker path variables. The following table details these path variables.
| Windows directory or drive | AppLocker path variable | Windows environment variable |
|---------------------------------------------------------|-------------------------|----------------------------------------|
| Windows | %WINDIR% | %SystemRoot% |
| System32 and sysWOW64 | %SYSTEM32% | %SystemDirectory% |
| Windows installation directory | %OSDRIVE% | %SystemDrive% |
| Program Files | %PROGRAMFILES% | %ProgramFiles% and %ProgramFiles(x86)% |
| Removable media (for example, CD or DVD) | %REMOVABLE% | |
| Removable storage device (for example, USB flash drive) | %HOT% | |
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](understanding-applocker-rule-condition-types.md).
## Related topics
- [How AppLocker works](how-applocker-works-techref.md)

View File

@ -0,0 +1,63 @@
---
title: Understanding the publisher rule condition in AppLocker
description: This topic explains the AppLocker publisher rule condition, what controls are available, and how it's applied.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Understanding the publisher rule condition in AppLocker
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
This topic explains the AppLocker publisher rule condition, what controls are available, and how it's 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 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.
|Publisher condition advantages|Publisher condition disadvantages|
|--- |--- |
|<li>Frequent updating isn't required.<li>You can apply different values within a certificate.<li>A single rule can be used to allow an entire product suite.<li>You can use the asterisk (*) wildcard character within a publisher rule to specify that any value should be matched.|<li>The file must be signed.<li>Although a single rule can be used to allow an entire product suite, all files in the suite must be signed uniformly.|
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 isn't 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 (?) isn't 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 isn't treated as a wildcard character if used with other characters in this field. A question mark (?) isn't 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.
| Option | The publisher condition allows or denies...|
| - | - |
| **All signed files** | All files that are signed by a publisher.|
| **Publisher only** | All files that are signed by the named publisher.|
| **Publisher and product name** | All files for the specified product that are signed by the named publisher.|
| **Publisher, 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** | **Exactly**<br/>The specified 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**<br/>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**<br/>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](understanding-applocker-rule-condition-types.md).
## Related topics
- [How AppLocker works](how-applocker-works-techref.md)

View File

@ -0,0 +1,80 @@
---
title: Use a reference device to create and maintain AppLocker policies
description: This topic for the IT professional describes the steps to create and maintain AppLocker policies by using a reference computer.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Use a reference device to create and maintain AppLocker policies
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
This topic for the IT professional describes the steps to create and maintain AppLocker policies by using a reference computer.
## Background and prerequisites
An AppLocker reference device is a baseline device you can use to configure policies and can then be used to maintain AppLocker policies. For the procedure to configure a reference device, see [Configure the AppLocker reference device](configure-the-appLocker-reference-device.md).
An AppLocker reference device that is used to create and maintain AppLocker policies should contain the corresponding apps for each organizational unit (OU) to mimic your production environment.
>**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](requirements-to-use-applocker.md).
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.
## Step 1: Automatically generate rules on the reference device
With AppLocker, you can automatically generate rules for all files within a folder. AppLocker scans the specified folder and creates the condition types that you choose for each file in that folder. For information on how to automatically generate rules, see [Run the Automatically Generate Rules wizard](run-the-automatically-generate-rules-wizard.md).
>**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.
## Step 2: Create the default rules on the reference device
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 must run the default rules for each rule collection. For info about default rules and considerations for using them, see [Understanding AppLocker default rules](understanding-applocker-default-rules.md). For the procedure to create default rules, see [Create AppLocker default rules](create-applocker-default-rules.md).
>**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 information on how to export and save the policies, see [Export an AppLocker policy from a GPO](export-an-applocker-policy-from-a-gpo.md). 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-publisher-condition.md)
- [Create a rule that uses a file hash condition](create-a-rule-that-uses-a-file-hash-condition.md)
- [Create a rule that uses a path condition](create-a-rule-that-uses-a-path-condition.md)
- [Edit AppLocker rules](edit-applocker-rules.md)
- [Add exceptions for an AppLocker rule](configure-exceptions-for-an-applocker-rule.md)
- [Delete an AppLocker rule](delete-an-applocker-rule.md)
- [Enable the DLL rule collection](enable-the-dll-rule-collection.md)
- [Enforce AppLocker rules](enforce-applocker-rules.md)
## Step 4: Test and update AppLocker policy on the reference device
You should test each set of rules to ensure that they perform as intended. The **Test-AppLockerPolicy** Windows PowerShell cmdlet can be used to determine whether any of the rules in your rule collection will be blocked on your reference device. Perform the steps on each reference device that you used to define the AppLocker policy. Ensure that the reference device is joined to the domain and that it's receiving the AppLocker policy from the appropriate GPO. Because AppLocker rules are inherited from linked GPOs, you should deploy all of the rules to simultaneously test all of your test GPOs. Use the following procedures to complete this step:
- [Test an AppLocker Policy with Test-AppLockerPolicy](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ee791772(v=ws.10))
- [Discover the Effect of an AppLocker Policy](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ee791823(v=ws.10))
>**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.
## Step 5: Export and import the policy into production
When the AppLocker policy has been tested successfully, it can be imported into the GPO (or imported into individual computers that aren't managed by Group Policy) and checked for its intended effectiveness. To do these tasks, perform the following procedures:
- [Export an AppLocker policy to an XML file](export-an-applocker-policy-to-an-xml-file.md)
- [Import an AppLocker policy into a GPO](import-an-applocker-policy-into-a-gpo.md) or
- [Discover the Effect of an AppLocker Policy](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ee791823(v=ws.10))
If the AppLocker policy enforcement setting is **Audit only** and you're satisfied that the policy is fulfilling your intent, you can change it to **Enforce rules**. For info about how to change the enforcement setting, see [Configure an AppLocker policy for enforce rules](configure-an-applocker-policy-for-enforce-rules.md).
## Step 6: Monitor the effect of the policy in production
If more refinements or updates are necessary after a policy is deployed, use the appropriate following procedures to monitor and update the policy:
- [Monitor app usage with AppLocker](monitor-application-usage-with-applocker.md)
- [Edit an AppLocker policy](edit-an-applocker-policy.md)
- [Refresh an AppLocker policy](refresh-an-applocker-policy.md)
## See also
- [Deploy the AppLocker policy into production](deploy-the-applocker-policy-into-production.md)

View File

@ -0,0 +1,39 @@
---
title: Use AppLocker and Software Restriction Policies in the same domain
description: This article for IT professionals describes concepts and procedures to help you manage your application control strategy using Software Restriction Policies and AppLocker.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 11/07/2022
---
# Use AppLocker and Software Restriction Policies in the same domain
This article for IT professionals describes concepts and procedures to help you manage your application control strategy using Software Restriction Policies and AppLocker.
> [!IMPORTANT]
> Software Restriction Policies were deprecated beginning with Windows 10 build 1803 and above, and also applies to Windows Server 2019 and above. You should use Windows Defender Application Control (WDAC) or AppLocker to control what software runs.
## Using AppLocker and Software Restriction Policies in the same domain
AppLocker is supported on systems running Windows 8.1. Software Restriction Policies (SRP) is supported on systems running Windows Vista or earlier. You can continue to use SRP for application control on your pre-Windows 7 computers, but use AppLocker for computers running Windows Server 2008 R2, Windows 7 and later. It's recommended that you author AppLocker and SRP rules in separate GPOs and target the GPO with SRP policies to systems running Windows Vista or earlier. When both SRP and AppLocker policies are applied to computers running Windows Server 2008 R2, Windows 7 and later, the SRP policies are ignored.
The following table compares the features and functions of Software Restriction Policies (SRP) and AppLocker.
|Application control function|SRP|AppLocker|
|--- |--- |--- |
|Scope|SRP policies can be applied to all Windows operating systems beginning with Windows XP and Windows Server 2003.|AppLocker policies apply only to Windows Server 2008 R2, Windows 7, and later.|
|Policy creation|SRP policies are maintained through Group Policy and only the administrator of the GPO can update the SRP policy. The administrator on the local computer can modify the SRP policies defined in the local GPO.|AppLocker policies are maintained through Group Policy and only the administrator of the GPO can update the policy. The administrator on the local computer can modify the AppLocker policies defined in the local GPO.<br/><br/>AppLocker permits customization of error messages to direct users to a Web page for help.|
|Policy maintenance|SRP policies must be updated by using the Local Security Policy snap-in (if the policies are created locally) or the Group Policy Management Console (GPMC).|AppLocker policies can be updated by using the Local Security Policy snap-in (if the policies are created locally), or the GPMC, or the Windows PowerShell AppLocker cmdlets.|
|Policy application|SRP policies are distributed through Group Policy.|AppLocker policies are distributed through Group Policy.|
|Enforcement mode|SRP works in the "blocklist mode" where administrators can create rules for files that they don't want to allow in this Enterprise whereas the rest of the file is allowed to run by default.<br/><br/>SRP can also be configured in the "allowlist mode" so that by default all files are blocked. In "allowlist mode", administrators need to create allow rules for files that they want to run.|AppLocker by default works in the "allowlist mode" where only those files are allowed to run for which there's a matching allow rule.|
|File types that can be controlled|SRP can control the following file types:<li>Executables<li>Dlls<li>Scripts<li>Windows Installers<br/><br/>SRP can't control each file type separately. All SRP rules are in a single rule collection.|AppLocker can control the following file types:<li>Executables<li>Dlls<li>Scripts<li>Windows Installers<li>Packaged apps and installers<br/><br/>AppLocker maintains a separate rule collection for each of the five file types.|
|Designated file types|SRP supports an extensible list of file types that are considered executable. Administrators can add extensions for files that should be considered executable.|AppLocker currently supports the following file extensions:<li>Executables (.exe, .com)<li>Dlls (.ocx, .dll)<li>Scripts (.vbs, .js, .ps1, .cmd, .bat)<li>Windows Installers (.msi, .mst, .msp)<li>Packaged app installers (.appx)|
|Rule types|SRP supports four types of rules:<li>Hash<li>Path<li>Signature<li>Internet zone|AppLocker supports three types of rules:<li>File hash<li>Path<li>Publisher|
|Editing the hash value|In Windows XP, you could use SRP to provide custom hash values.<br/><br/>Beginning with Windows 7 and Windows Server 2008 R2, you can only select the file to hash, and not provide the hash value.|AppLocker computes the hash value itself. Internally, it uses the SHA2 Authenticode hash for Portable Executables (exe and dll) and Windows Installers and an SHA2 flat file hash for the rest.|
|Support for different security levels|With SRP, you can specify the permissions with which an app can run. So, you can configure a rule such that Notepad always runs with restricted permissions and never with administrative privileges.<br/><br/>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).|AppLocker doesn't support security levels.|
|Manage Packaged apps and Packaged app installers.|Not supported|.appx is a valid file type which AppLocker can manage.|
|Targeting a rule to a user or a group of users|SRP rules apply to all users on a particular computer.|AppLocker rules can be targeted to a specific user or a group of users.|
|Support for rule exceptions|SRP doesn't support rule exceptions.|AppLocker rules can have exceptions, which allow you to create rules such as "Allow everything from Windows except for regedit.exe".|
|Support for audit mode|SRP doesn't support audit mode. The only way to test SRP policies is to set up a test environment and run a few experiments.|AppLocker supports audit mode, which allows you to test the effect of their policy in the real production environment without impacting the user experience. Once you're satisfied with the results, you can start enforcing the policy.|
|Support for exporting and importing policies|SRP doesn't support policy import/export.|AppLocker supports the importing and exporting of policies. This support by AppLocker 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.|
|Rule enforcement|Internally, SRP rules enforcement happens in the user-mode, which is less secure.|Internally, AppLocker rules for .exe and .dll files are enforced in the kernel-mode, which is more secure than enforcing them in the user-mode.|

View File

@ -0,0 +1,49 @@
---
title: Use the AppLocker Windows PowerShell cmdlets
description: This topic for IT professionals describes how each AppLocker Windows PowerShell cmdlet can help you administer your AppLocker application control policies.
ms.localizationpriority: medium
ms.topic: conceptual
ms.date: 09/21/2017
---
# Use the AppLocker Windows PowerShell cmdlets
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
This topic for IT professionals describes how each AppLocker Windows PowerShell cmdlet can help you administer your AppLocker application control policies.
## AppLocker Windows PowerShell cmdlets
The five AppLocker cmdlets are designed to streamline the administration of an 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
Microsoft Management Console (MMC) snap-in extension to the Local Security Policy snap-in and Group Policy Management Console.
To edit or update a Group Policy Object (GPO) by using the AppLocker cmdlets, you must have Edit Setting permission. By default, members of the **Domain Admins** group, the **Enterprise Admins** group, and the **Group Policy Creator Owners** group have this permission. To perform tasks by using the
Local Security policy snap-in, you must be a member of the local **Administrators** group, or equivalent, on the computer.
### Retrieve application information
The [Get-AppLockerFileInformation](/powershell/module/applocker/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 aren't signed don't have any publisher information.
### Set AppLocker policy
The [Set-AppLockerPolicy](/powershell/module/applocker/set-applockerpolicy) cmdlet sets the specified GPO to contain the specified AppLocker policy. If no Lightweight Directory Access Protocol (LDAP) is specified, the local GPO is the default.
### Retrieve an AppLocker policy
The [Get-AppLockerPolicy](/powershell/module/applocker/get-applockerpolicy) cmdlet gets the AppLocker policy from the local GPO, from a specified GPO, or from the effective AppLocker policy on the device. The output of the AppLocker policy is an AppLockerPolicy object or an XML-formatted string.
### Generate rules for a given user or group
The [New-AppLockerPolicy](/powershell/module/applocker/new-applockerpolicy) cmdlet uses a list of file information to automatically generate rules for a given user or group. It can generate rules based on publisher, hash, or path information. Use **Get-AppLockerFileInformation** to create the
list of file information.
### Test the AppLocker Policy against a file set
The [Test-AppLockerPolicy](/powershell/module/applocker/test-applockerpolicy) cmdlet uses the specified AppLocker policy to test whether a specified list of files are allowed to run or not on the local device for a specific user.
## Other resources
- For steps to perform other AppLocker policy tasks, see [Administer AppLocker](administer-applocker.md).

Some files were not shown because too many files have changed in this diff Show More