diff --git a/windows/keep-secure/executable-rules-in-applocker.md b/windows/keep-secure/executable-rules-in-applocker.md index b215d8ffe5..b74b7fe29a 100644 --- a/windows/keep-secure/executable-rules-in-applocker.md +++ b/windows/keep-secure/executable-rules-in-applocker.md @@ -2,55 +2,28 @@ title: Executable rules in AppLocker (Windows 10) description: This topic describes the file formats and available default rules for the executable rule collection. ms.assetid: 65e62f90-6caa-48f8-836a-91f8ac9018ee -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Executable rules in AppLocker + **Applies to** - Windows 10 + 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. - ------ - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
PurposeNameUserRule 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%\*

+ +| 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) -  -  + +- [Understanding AppLocker Default Rules](understanding-applocker-default-rules.md) diff --git a/windows/keep-secure/export-an-applocker-policy-from-a-gpo.md b/windows/keep-secure/export-an-applocker-policy-from-a-gpo.md index 565c1d0597..90c10baeee 100644 --- a/windows/keep-secure/export-an-applocker-policy-from-a-gpo.md +++ b/windows/keep-secure/export-an-applocker-policy-from-a-gpo.md @@ -2,23 +2,28 @@ title: Export an AppLocker policy from a GPO (Windows 10) 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.assetid: 7db59719-a8be-418b-bbfd-22cf2176c9c0 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Export an AppLocker policy from a GPO + **Applies to** - Windows 10 + 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**. -  -  diff --git a/windows/keep-secure/trusted-platform-module-services-group-policy-settings.md b/windows/keep-secure/trusted-platform-module-services-group-policy-settings.md index 4b274eecc5..4ded5c4844 100644 --- a/windows/keep-secure/trusted-platform-module-services-group-policy-settings.md +++ b/windows/keep-secure/trusted-platform-module-services-group-policy-settings.md @@ -2,230 +2,188 @@ title: TPM Group Policy settings (Windows 10) description: This topic for the IT professional describes the Trusted Platform Module (TPM) Services that can be controlled centrally by using Group Policy settings. ms.assetid: 54ff1c1e-a210-4074-a44e-58fee26e4dbd -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # TPM Group Policy settings + **Applies to** - Windows 10 + This topic for the IT professional describes the Trusted Platform Module (TPM) Services that can be controlled centrally by using Group Policy settings. + ## + The TPM Services Group Policy settings are located at: + **Computer Configuration\\Administrative Templates\\System\\Trusted Platform Module Services\\** - -------- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
SettingWindows 10Windows Server 2012 R2, Windows 8.1 and Windows RTWindows Server 2012, Windows 8 and Windows RTWindows Server 2008 R2 and Windows 7Windows Server 2008 and Windows Vista

[Turn on TPM backup to Active Directory Domain Services](#bkmk-tpmgp-addsbu)

X

X

X

X

X

[Configure the list of blocked TPM commands](#bkmk-tpmgp-clbtc)

X

X

X

X

X

[Ignore the default list of blocked TPM commands](#bkmk-tpmgp-idlb)

X

X

X

X

X

[Ignore the local list of blocked TPM commands](#bkmk-tpmgp-illb)

X

X

X

X

X

[Configure the level of TPM owner authorization information available to the operating system](#bkmk-tpmgp-oauthos)

X

X

X

[Standard User Lockout Duration](#bkmk-tpmgp-suld)

X

X

X

[Standard User Individual Lockout Threshold](#bkmk-tpmgp-suilt)

X

X

X

[Standard User Total Lockout Threshold](#bkmk-tpmgpsutlt)

X

X

X

+ +| Setting | Windows 10 | Windows Server 2012 R2, Windows 8.1 and Windows RT | Windows Server 2012, Windows 8 and Windows RT | Windows Server 2008 R2 and Windows 7 | Windows Server 2008 and Windows Vista | +| - | - | - | - | - | - | +| [Turn on TPM backup to Active Directory Domain Services](#bkmk-tpmgp-addsbu) | X| X| X| X| X| +| [Configure the list of blocked TPM commands](#bkmk-tpmgp-clbtc)| X| X| X| X| X| +| [Ignore the default list of blocked TPM commands](#bkmk-tpmgp-idlb) | X| X| X| X| X| +| [Ignore the local list of blocked TPM commands](#bkmk-tpmgp-illb) | X| X| X| X| X| +| [Configure the level of TPM owner authorization information available to the operating system](#bkmk-tpmgp-oauthos)| X| X| X||| +| [Standard User Lockout Duration](#bkmk-tpmgp-suld)| X| X| X||| +| [Standard User Individual Lockout Threshold](#bkmk-tpmgp-suilt)| X| X| X||| +| [Standard User Total Lockout Threshold](#bkmk-tpmgpsutlt)| X| X| X||||   ### Turn on TPM backup to Active Directory Domain Services + This policy setting allows you to manage the Active Directory Domain Services (AD DS) backup of TPM owner information. -**Note**   -This policy setting applies to the Windows operating systems listed in the [version table](#bkmk-version-table). + +>**Note:**  This policy setting applies to the Windows operating systems listed in the [version table](#bkmk-version-table).   TPM owner information includes a cryptographic hash of the TPM owner password. Certain TPM commands can be run only by the TPM owner. This hash authorizes the TPM to run these commands. -**Important**   -To back up TPM owner information from a computer running Windows 10, Windows 8.1, or Windows 8, you might need to first set up appropriate schema extensions and access control settings on the domain so that the AD DS backup can succeed. Windows Server 2012 R2 and Windows Server 2012 include the required schema extensions by default. For more information, see [AD DS schema extensions to support TPM backup](ad-ds-schema-extensions-to-support-tpm-backup.md). + +>**Important:**  To back up TPM owner information from a computer running Windows 10, Windows 8.1, or Windows 8, you might need to first set up appropriate schema extensions and access control settings on the domain so that the AD DS backup can succeed. Windows Server 2012 R2 and Windows Server 2012 include the required schema extensions by default. For more information, see [AD DS schema extensions to support TPM backup](ad-ds-schema-extensions-to-support-tpm-backup.md).   The TPM cannot be used to provide enhanced security features for BitLocker Drive Encryption and other applications without first setting an owner. To take ownership of the TPM with an owner password, on a local computer at the command prompt, type **tpm.msc** to open the TPM Management Console and select the action to **Initialize TPM**. If the TPM owner information is lost or is not available, limited TPM management is possible by running **tpm.msc**. + If you enable this policy setting, TPM owner information will be automatically and silently backed up to AD DS when you use Windows to set or change a TPM owner password. When this policy setting is enabled, a TPM owner password cannot be set or changed unless the computer is connected to the domain and the AD DS backup succeeds. + If you disable or do not configure this policy setting, TPM owner information will not be backed up to AD DS. + ### Configure the list of blocked TPM commands + This policy setting allows you to manage the Group Policy list of Trusted Platform Module (TPM) commands that are blocked by Windows. -**Note**   -This policy setting applies to the Windows operating systems listed in the [version table](#bkmk-version-table). + +>**Note:**  This policy setting applies to the Windows operating systems listed in the [version table](#bkmk-version-table).   If you enable this policy setting, Windows will block the specified commands from being sent to the TPM on the computer. TPM commands are referenced by a command number. For example, command number 129 is **TPM\_OwnerReadInternalPub**, and command number 170 is **TPM\_FieldUpgrade**. To find the command number that is associated with each TPM command, at the command prompt, type **tpm.msc**to open the TPM Management Console and navigate to the **Command Management** section. + If you disable or do not configure this policy setting, only those TPM commands that are specified through the default or local lists can be blocked by Windows. The default list of blocked TPM commands is preconfigured by Windows. + - You can view the default list by typing **tpm.msc** at the command prompt, navigating to the **Command Management** section, and exposing the **On Default Block List** column. - The local list of blocked TPM commands is configured outside of Group Policy by running the TPM Management Console or scripting using the **Win32\_Tpm** interface. + For information how to enforce or ignore the default and local lists of blocked TPM commands, see + - [Ignore the default list of blocked TPM commands](#bkmk-tpmgp-idlb) - [Ignore the local list of blocked TPM commands](#bkmk-tpmgp-illb) ### Ignore the default list of blocked TPM commands + This policy setting allows you to enforce or ignore the computer's default list of blocked Trusted Platform Module (TPM) commands. -**Note**   -This policy setting applies to the Windows operating systems listed in the [version table](#bkmk-version-table). + +>**Note:**  This policy setting applies to the Windows operating systems listed in the [version table](#bkmk-version-table).   The default list of blocked TPM commands is preconfigured by Windows. You can view the default list by typing **tpm.msc** at the command prompt to open the TPM Management Console, navigating to the **Command Management** section, and exposing the **On Default Block List** column. Also see the related policy setting, [Configure the list of blocked TPM commands](#bkmk-tpmgp-clbtc). + If you enable this policy setting, the Windows operating system will ignore the computer's default list of blocked TPM commands, and it will block only those TPM commands that are specified by Group Policy or the local list. + If you disable or do not configure this policy setting, Windows will block the TPM commands in the default list, in addition to the commands that are specified by Group Policy and the local list of blocked TPM commands. + ### Ignore the local list of blocked TPM commands + This policy setting allows you to enforce or ignore the computer's local list of blocked Trusted Platform Module (TPM) commands. -**Note**   -This policy setting applies to the Windows operating systems listed in the [version table](#bkmk-version-table). + +>**Note:**  This policy setting applies to the Windows operating systems listed in the [version table](#bkmk-version-table).   The local list of blocked TPM commands is configured outside of Group Policy by typing **tpm.msc** at the command prompt to open the TPM Management Console, or scripting using the **Win32\_Tpm** interface. (The default list of blocked TPM commands is preconfigured by Windows.) Also see the related policy setting to **Configure the list of blocked TPM commands**. + If you enable this policy setting, the Windows operating system will ignore the computer's local list of blocked TPM commands, and it will block only those TPM commands that are specified by Group Policy or the default list. + If you disable or do not configure this policy setting, Windows will block the TPM commands in the local list, in addition to the commands that are specified in Group Policy and the default list of blocked TPM commands. + ### Configure the level of TPM owner authorization information available to the operating system + This policy setting configures how much of the TPM owner authorization information is stored in the registry of the local computer. Depending on the amount of TPM owner authorization information that is stored locally, the Windows operating system and TPM-based applications can perform certain actions in the TPM that require TPM owner authorization without requiring the user to enter the TPM owner password. -**Note**   -This policy setting applies to the Windows operating systems listed in the [version table](#bkmk-version-table). + +>**Note:**  This policy setting applies to the Windows operating systems listed in the [version table](#bkmk-version-table).   There are three TPM owner authentication settings that are managed by the Windows operating system. You can choose a value of **Full**, **Delegate**, or **None**. + - **Full**   This setting stores the full TPM owner authorization, the TPM administrative delegation blob, and the TPM user delegation blob in the local registry. With this setting, you can use the TPM without requiring remote or external storage of the TPM owner authorization value. This setting is appropriate for scenarios that do not require you to reset the TPM anti-hammering logic or change the TPM owner authorization value. Some TPM-based applications may require that this setting is changed before features that depend on the TPM anti-hammering logic can be used. - **Delegated**   This setting stores only the TPM administrative delegation blob and the TPM user delegation blob in the local registry. This setting is appropriate for use with TPM-based applications that depend on the TPM antihammering logic. When you use this setting, we recommend using external or remote storage for the full TPM owner authorization value—for example, backing up the value in Active Directory Domain Services (AD DS). - **None**   This setting provides compatibility with previous operating systems and applications. You can also use it for scenarios when TPM owner authorization cannot be stored locally. Using this setting might cause issues with some TPM-based applications. -**Note**   -If the operating system managed TPM authentication setting is changed from **Full** to **Delegated**, the full TPM owner authorization value will be regenerated, and any copies of the previously set TPM owner authorization value will be invalid. If you are backing up the TPM owner authorization value to AD DS, the new owner authorization value is automatically backed up to AD DS when it is changed. + +>**Note:**  If the operating system managed TPM authentication setting is changed from **Full** to **Delegated**, the full TPM owner authorization value will be regenerated, and any copies of the previously set TPM owner authorization value will be invalid. If you are backing up the TPM owner authorization value to AD DS, the new owner authorization value is automatically backed up to AD DS when it is changed.   **Registry information** + Registry key: HKEY\_LOCAL\_MACHINE\\SOFTWARE\\Policies\\Microsoft\\TPM + DWORD: OSManagedAuthLevel + The following table shows the TPM owner authorization values in the registry. - ---- - - - - - - - - - - - - - - - - - - - - -
Value DataSetting

0

None

2

Delegated

4

Full

+ +| Value Data | Setting | +| - | - | +| 0 | None| +| 2 | Delegated| +| 4 | Full|   If you enable this policy setting, the Windows operating system will store the TPM owner authorization in the registry of the local computer according to the TPM authentication setting you choose. -If you disable or do not configure this policy setting, and the **Turn on TPM backup to Active Directory Domain Services** policy setting is also disabled or not configured, the default setting is to store the full TPM authorization value in the local registry. If this policy is disabled or not configured, and the **Turn on TPM backup to Active Directory Domain Services** policy setting is enabled, only the administrative delegation and the user delegation blobs are stored in the local registry. + +If you disable or do not configure this policy setting, and the **Turn on TPM backup to Active Directory Domain Services** policy setting is also disabled or not configured, the default setting is to store the full TPM authorization value in the local registry. If this policy is disabled or not +configured, and the **Turn on TPM backup to Active Directory Domain Services** policy setting is enabled, only the administrative delegation and the user delegation blobs are stored in the local registry. + ### Standard User Lockout Duration -This policy setting allows you to manage the duration in minutes for counting standard user authorization failures for Trusted Platform Module (TPM) commands requiring authorization. An authorization failure occurs each time a standard user sends a command to the TPM and receives an error response that indicates an authorization failure occurred. Authorization failures that are older than the duration you set are ignored. If the number of TPM commands with an authorization failure within the lockout duration equals a threshold, a standard user is prevented from sending commands that require authorization to the TPM. -**Note**   -This policy setting applies to the Windows operating systems listed in the [version table](#bkmk-version-table). + +This policy setting allows you to manage the duration in minutes for counting standard user authorization failures for Trusted Platform Module (TPM) commands requiring authorization. An authorization failure occurs each time a standard user sends a command to the TPM and receives an error response that indicates an authorization failure occurred. Authorization failures that are older than the duration you set are ignored. If the number of TPM commands with an authorization failure within the lockout duration equals a threshold, a standard user is prevented from sending commands that require +authorization to the TPM. + +>**Note:**  This policy setting applies to the Windows operating systems listed in the [version table](#bkmk-version-table).   The TPM is designed to protect itself against password guessing attacks by entering a hardware lockout mode when it receives too many commands with an incorrect authorization value. When the TPM enters a lockout mode, it is global for all users (including administrators) and for Windows features such as BitLocker Drive Encryption. + The number of authorization failures that a TPM allows and how long it stays locked vary by TPM manufacturer. Some TPMs may enter lockout mode for successively longer periods of time, with fewer authorization failures, depending on past failures. Some TPMs may require a system restart to exit the lockout mode. Other TPMs may require that the system is on so enough clock cycles elapse before the TPM exits the lockout mode. + This setting helps administrators prevent the TPM hardware from entering a lockout mode by slowing the speed at which standard users can send commands that require authorization to the TPM. + For each standard user, two thresholds apply. Exceeding either threshold prevents the user from sending a command that requires authorization to the TPM. Use the following policy settings to set the lockout duration: + - [Standard User Individual Lockout Threshold](#bkmk-individual)   This value is the maximum number of authorization failures that each standard user can have before the user is not allowed to send commands that require authorization to the TPM. - [Standard User Total Lockout Threshold](#bkmk-total)   This value is the maximum total number of authorization failures that all standard users can have before all standard users are not allowed to send commands that require authorization to the TPM. + An administrator with the TPM owner password can fully reset the TPM's hardware lockout logic by using the TPM Management Console (tpm.msc). Each time an administrator resets the TPM's hardware lockout logic, all prior standard user TPM authorization failures are ignored. This allows standard users to immediately use the TPM normally. + If you do not configure this policy setting, a default value of 480 minutes (8 hours) is used. + ### Standard User Individual Lockout Threshold + This policy setting allows you to manage the maximum number of authorization failures for each standard user for the Trusted Platform Module (TPM). This value is the maximum number of authorization failures that each standard user can have before the user is not allowed to send commands that require authorization to the TPM. If the number of authorization failures for the user within the duration that is set for the **Standard User Lockout Duration** policy setting equals this value, the standard user is prevented from sending commands that require authorization to the Trusted Platform Module (TPM). -**Note**   -This policy setting applies to the Windows operating systems listed in the [version table](#bkmk-version-table). + +>**Note:**  This policy setting applies to the Windows operating systems listed in the [version table](#bkmk-version-table).   This setting helps administrators prevent the TPM hardware from entering a lockout mode by slowing the speed at which standard users can send commands that require authorization to the TPM. + An authorization failure occurs each time a standard user sends a command to the TPM and receives an error response indicating an authorization failure occurred. Authorization failures older than the duration are ignored. + An administrator with the TPM owner password can fully reset the TPM's hardware lockout logic by using the TPM Management Console (tpm.msc). Each time an administrator resets the TPM's hardware lockout logic, all prior standard user TPM authorization failures are ignored. This allows standard users to immediately use the TPM normally. + If you do not configure this policy setting, a default value of 4 is used. A value of zero means that the operating system will not allow standard users to send commands to the TPM, which might cause an authorization failure. + ### Standard User Total Lockout Threshold + This policy setting allows you to manage the maximum number of authorization failures for all standard users for the Trusted Platform Module (TPM). If the total number of authorization failures for all standard users within the duration that is set for the **Standard User Lockout Duration** policy equals this value, all standard users are prevented from sending commands that require authorization to the Trusted Platform Module (TPM). -**Note**   -This policy setting applies to the Windows operating systems listed in the [version table](#bkmk-version-table). + +>**Note:**  This policy setting applies to the Windows operating systems listed in the [version table](#bkmk-version-table).   This setting helps administrators prevent the TPM hardware from entering a lockout mode because it slows the speed standard users can send commands requiring authorization to the TPM. + An authorization failure occurs each time a standard user sends a command to the TPM and receives an error response indicating an authorization failure occurred. Authorization failures older than the duration are ignored. + For each standard user two thresholds apply. Exceeding either threshold will prevent the standard user from sending a command to the TPM that requires authorization. + 1. The standard user individual lockout value is the maximum number of authorization failures each standard user may have before the user is not allowed to send commands requiring authorization to the TPM. 2. The standard user total lockout threshold value is the maximum total number of authorization failures all standard users may have before all standard users are not allowed to send commands requiring authorization to the TPM. -The TPM is designed to protect itself against password guessing attacks by entering a hardware lockout mode when it receives too many commands with an incorrect authorization value. When the TPM enters a lockout mode, it is global for all users (including administrators) and for Windows features such as BitLocker Drive Encryption.. +The TPM is designed to protect itself against password guessing attacks by entering a hardware lockout mode when it receives too many commands with an incorrect authorization value. When the TPM enters a lockout mode, it is global for all users (including administrators) and for Windows features +such as BitLocker Drive Encryption.. + The number of authorization failures a TPM allows and how long it stays locked out vary by TPM manufacturer. Some TPMs may enter lockout mode for successively longer periods of time with fewer authorization failures depending on past failures. Some TPMs may require a system restart to exit the lockout mode. Other TPMs may require the system to be on so enough clock cycles elapse before the TPM exits the lockout mode. + An administrator with the TPM owner password can fully reset the TPM's hardware lockout logic by using the TPM Management Console (tpm.msc). Each time an administrator resets the TPM's hardware lockout logic, all prior standard user TPM authorization failures are ignored. This allows standard users to immediately use the TPM normally. + If you do not configure this policy setting, a default value of 9 is used. A value of zero means that the operating system will not allow standard users to send commands to the TPM, which might cause an authorization failure. + ## Additional resources -[Trusted Platform Module Technology Overview](trusted-platform-module-overview.md) -[TPM Cmdlets in Windows PowerShell](http://technet.microsoft.com/library/jj603116.aspx) -[Prepare your organization for BitLocker: Planning and Policies - TPM configurations](http://technet.microsoft.com/library/jj592683.aspx) -  -  + +- [Trusted Platform Module Technology Overview](trusted-platform-module-overview.md) +- [TPM Cmdlets in Windows PowerShell](http://technet.microsoft.com/library/jj603116.aspx) +- [Prepare your organization for BitLocker: Planning and Policies - TPM configurations](http://technet.microsoft.com/library/jj592683.aspx) diff --git a/windows/keep-secure/understand-applocker-enforcement-settings.md b/windows/keep-secure/understand-applocker-enforcement-settings.md index f62646c2e9..6ac72fe3f1 100644 --- a/windows/keep-secure/understand-applocker-enforcement-settings.md +++ b/windows/keep-secure/understand-applocker-enforcement-settings.md @@ -2,45 +2,28 @@ title: Understand AppLocker enforcement settings (Windows 10) description: This topic describes the AppLocker enforcement settings for rule collections. ms.assetid: 48773007-a343-40bf-8961-b3ff0a450d7e -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Understand AppLocker enforcement settings + **Applies to** - Windows 10 + 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 is not configured and rules are present in a rule collection, those rules are enforced. The following table details the three AppLocker rule enforcement settings in Group Policy for each rule collection. - ---- - - - - - - - - - - - - - - - - - - - - -
Enforcement settingDescription

Not configured

By default, enforcement is not configured in a rule collection. If rules are present in the corresponding rule collection, they are 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.

+ +| Enforcement setting | Description | +| - | - | +| Not configured | By default, enforcement is not configured in a rule collection. If rules are present in the corresponding rule collection, they are 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. -  -  diff --git a/windows/keep-secure/understand-applocker-policy-design-decisions.md b/windows/keep-secure/understand-applocker-policy-design-decisions.md index ea6833ec44..5687229616 100644 --- a/windows/keep-secure/understand-applocker-policy-design-decisions.md +++ b/windows/keep-secure/understand-applocker-policy-design-decisions.md @@ -2,123 +2,86 @@ title: Understand AppLocker policy design decisions (Windows 10) description: 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. ms.assetid: 3475def8-949a-4b51-b480-dc88b5c1e6e6 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Understand AppLocker policy design decisions + **Applies to** - Windows 10 + 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 are not in priority or sequential order. They should be considered when you deploy application control policies (as appropriate for your targeted environment). + ### Which apps do you need to control in your organization? + You might need to control a limited number of apps because they access sensitive data, or you might have to exclude all applications except those that are sanctioned for business purposes. There might be certain business groups that require strict control, and others that promote independent application usage. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Possible answersDesign 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 are created. All apps on that list will be allowed to run (except those on the exception list). Apps that are not on the list will be prevented from running. AppLocker policies can only be applied to apps installed on computers running any of the supported versions of Windows. For specific operating system version requirements, see [Requirements to use AppLocker](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 Windows Store, but Classic Windows applications can be controlled with AppLocker on all supported versions of Windows. The rules you currently have configured for Classic Windows applications can remain, and you can create new ones for Universal Windows apps.

-

For a comparison of Classic Windows applications and Universal Windows apps, see [Comparing Classic Windows applications and Universal Windows apps for AppLocker policy design decisions](#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 is not 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 will have to identify users, their computers, and their app access requirements.

Understand app usage, but there is 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.

+ +| 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 are created. All apps on that list will be allowed to run (except those on the exception list). Apps that are not on the list will be prevented from running. AppLocker policies can only be applied to apps installed on computers running any of the supported versions of Windows. For specific operating system version requirements, see [Requirements to use AppLocker](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 Windows Store, but Classic Windows applications can be controlled with AppLocker on all supported versions of Windows. The rules you currently have configured for Classic Windows applications can remain, and you can create new ones for Universal Windows apps.
For a comparison of Classic Windows applications and Universal Windows apps, see [Comparing Classic Windows applications and Universal Windows apps for AppLocker policy design decisions](#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 is not 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 will have to identify users, their computers, and their app access requirements.| +|Understand app usage, but there is 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: +>**Important:**  The following list contains files or types of files that cannot be managed by AppLocker: + - AppLocker does not protect against running 16-bit DOS binaries in a NT Virtual DOS Machine (NTVDM). This technology allows running legacy DOS and 16-bit Windows programs on computers that are using Intel 80386 or higher when there is already another operating system running and controlling the hardware. The result is that 16-bit binaries can still run on Windows Server 2008 R2 and Windows 7 when AppLocker is configured to otherwise block binaries and libraries. If it is a requirement to prevent 16-bit applications from running, you must configure the Deny rule in the Executable rule collection for NTVDM.exe. + - You cannot use AppLocker to prevent code from running outside the Win32 subsystem. In particular, this applies to the (POSIX) subsystem in Windows NT. If it is a requirement to prevent applications from running in the POSIX subsystem, you must disable the subsystem. + - AppLocker can only control VBScript, JScript, .bat files, .cmd files and Windows PowerShell scripts. It does not control all interpreted code that runs within a host process, for example Perl scripts and macros. Interpreted code is a form of executable code that runs within a host process. For example, Windows batch files (\*.bat) run within the context of the Windows Command Host (cmd.exe). To use AppLocker to control interpreted code, the host process must call AppLocker before it runs the interpreted code, and then enforce the decision that is returned by AppLocker. Not all host processes call into AppLocker. Therefore, AppLocker cannot control every kind of interpreted code, for example Microsoft Office macros. - **Important**   - You should configure the appropriate security settings of these host processes if you must allow them to run. For example, configure the security settings in Microsoft Office to ensure that only signed and trusted macros are loaded. + + >**Important:**  You should configure the appropriate security settings of these host processes if you must allow them to run. For example, configure the security settings in Microsoft Office to ensure that only signed and trusted macros are loaded.   - AppLocker rules allow or prevent an app from launching. AppLocker does not control the behavior of apps after they are launched. Applications could contain flags that are passed to functions that signal AppLocker to circumvent the rules and allow another .exe or .dll file to be loaded. In practice, an app that is allowed by AppLocker could use these flags to bypass AppLocker rules and launch child processes. You must follow a process that best suits your needs to thoroughly vet each app before allowing them to run using AppLocker rules. + For more info, see [Security considerations for AppLocker](security-considerations-for-applocker.md).   ### 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 Windows Store apps. However, Classic Windows applications can be controlled in Windows Server 2008 R2 and Windows 7, in addition to those computers that support Universal Windows apps. The rules for Classic Windows applications and Universal Windows apps can be enforced together. The differences you should consider for Universal Windows apps are: + - All Universal Windows apps can be installed by a standard user, whereas a number of Classic Windows applications require administrative credentials to install. So in an environment where most of the users are standard users, you might not need numerous exe rules, but you might want more explicit policies for packaged apps. - Classic Windows applications can be written to change the system state if they run with administrative credentials. Most Universal Windows apps cannot change the system state because they run with limited permissions. When you design your AppLocker policies, it is important to understand whether an app that you are allowing can make system-wide changes. - Universal Windows apps can be acquired through the Store, or they can be side-loaded by using Windows PowerShell cmdlets. If you use Windows PowerShell cmdlets, a special Enterprise license is required to acquire Universal Windows apps. Classic Windows applications can be acquired through traditional means, such as through software vendors or retail distribution. + AppLocker controls Universal Windows apps and Classic Windows applications by using different rule collections. You have the choice to control Universal Windows apps, Classic Windows applications, or both. + For more info, see [Packaged apps and packaged app installer rules in AppLocker](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 answersDesign considerations

Security polices (locally set or through Group Policy)

Using AppLocker requires increased effort in planning to create correct policies, but this results in a simpler distribution method.

Non-Microsoft app control software

Using AppLocker requires a complete app control policy evaluation and implementation.

Managed usage by group or OU

Using AppLocker requires a complete app control policy evaluation and implementation.

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.

+ +| Possible answers | Design considerations | +| - | - | +| Security polices (locally set or through Group Policy) | Using AppLocker requires increased effort in planning to create correct policies, but this results in a simpler distribution method.| +| Non-Microsoft app control software | Using AppLocker requires a complete app control policy evaluation and implementation.| +| Managed usage by group or OU | Using AppLocker requires a complete app control policy evaluation and implementation.| +| 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. @@ -172,259 +135,94 @@ If your organization supports multiple Windows operating systems, app control po
  ### 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 answersDesign considerations

Yes

-

For each group, you need to create a list that includes their application control requirements. Although this may increase the planning time, it will most likely result in a more effective deployment.

-

If your GPO structure is not currently configured so that you can apply different policies to specific groups, you can alternatively apply AppLocker rules in a GPO to specific user groups.

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.

+ +| Possible answers | Design considerations | +| - | - | +| Yes | For each group, you need to create a list that includes their application control requirements. Although this may increase the planning time, it will most likely result in a more effective deployment.
If your GPO structure is not currently configured so that you can apply different policies to specific groups, you can alternatively apply AppLocker rules in a GPO to specific user groups.| +| 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 answersDesign considerations

Yes

Invest the time to analyze your organization's application control requirements, and plan a complete deployment that uses rules that are as simply constructed as possible.

No

Consider a focused and phased deployment for specific groups by using a small number of rules. As you apply controls to applications in a specific group, learn from that deployment to plan your next deployment.

+ +| 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 simply constructed as possible.| +| No | Consider a focused and phased deployment for specific groups by using a small number of 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 is not hampered. - ---- - - - - - - - - - - - - - - - - -
Possible answersDesign 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.

+ +| 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 answersDesign 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 will 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.

+ +| 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 will 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 answersDesign 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.

+ +| 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 answersDesign considerations

Yes

You cannot use AppLocker to manage SRP settings, but you can use SRP to manage application control policies on computers running on any of the supported operating systems listed in [Requirements to use AppLocker](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.

-
-Note   -

If you are using the Basic User security level as assigned in SRP, those permissions are not 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.

+ +| Possible answers | Design considerations | +| - | - | +| Yes | You cannot use AppLocker to manage SRP settings, but you can use SRP to manage application control policies on computers running on any of the supported operating systems listed in [Requirements to use AppLocker](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.

**Note:** If you are using the Basic User security level as assigned in SRP, those permissions are not 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 answersDesign 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 a variety of software from different sources, including software that they developed. Therefore, if innovation and productivity is a high priority, managing application control policies through an allowed list might be time consuming and an impediment to progress.

Management: The organization is aware of and controls the apps 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 shifts the burden of app access to the IT department, but it also has the benefit of controlling the number of apps that can be run and controlling the versions of those apps

Security: The organization must protect data in part by 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.

+ +| 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 a variety of software from different sources, including software that they developed. Therefore, if innovation and productivity is a high priority, managing application control policies through an allowed list might be time consuming and an impediment to progress. | +| Management: The organization is aware of and controls the apps 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 shifts the burden of app access to the IT department, but it also has the benefit of controlling the number of apps that can be run and controlling the versions of those apps| +| Security: The organization must protect data in part by 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 very 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 small number of rules. - ---- - - - - - - - - - - - - - - - - -
Possible answersDesign 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.

-
-Note   -

AppLocker can also be effective in helping create standardized desktops in organizations where users run as administrators. However, it is important to note that users with administrative credentials can add new rules to the local AppLocker policy.

-
-
-  -

Users must be able to install applications as needed.

-

Users currently have administrator access, and it would be difficult to change this.

Enforcing AppLocker rules is not 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.

+ +| 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.
**Note: **AppLocker can also be effective in helping create standardized desktops in organizations where users run as administrators. However, it is important to note that users with administrative credentials can add new rules to the local AppLocker policy.| Users must be able to install applications as needed. +| Users currently have administrator access, and it would be difficult to change this.|Enforcing AppLocker rules is not 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 answersDesign 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.

+ +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, tyou 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). - For info about creating your planning document, see [Create your AppLocker planning document](create-your-applocker-planning-document.md). -  -  diff --git a/windows/keep-secure/understand-applocker-rules-and-enforcement-setting-inheritance-in-group-policy.md b/windows/keep-secure/understand-applocker-rules-and-enforcement-setting-inheritance-in-group-policy.md index c4438ba57b..066f32d60e 100644 --- a/windows/keep-secure/understand-applocker-rules-and-enforcement-setting-inheritance-in-group-policy.md +++ b/windows/keep-secure/understand-applocker-rules-and-enforcement-setting-inheritance-in-group-policy.md @@ -2,34 +2,43 @@ title: Understand AppLocker rules and enforcement setting inheritance in Group Policy (Windows 10) description: This topic for the IT professional describes how application control policies configured in AppLocker are applied through Group Policy. ms.assetid: c1c5a3d3-540a-4698-83b5-0dab5d27d871 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Understand AppLocker rules and enforcement setting inheritance in Group Policy + **Applies to** - Windows 10 + 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: + >**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. -  -  diff --git a/windows/keep-secure/understand-the-applocker-policy-deployment-process.md b/windows/keep-secure/understand-the-applocker-policy-deployment-process.md index 225dc8c0c2..76bbb8d904 100644 --- a/windows/keep-secure/understand-the-applocker-policy-deployment-process.md +++ b/windows/keep-secure/understand-the-applocker-policy-deployment-process.md @@ -2,21 +2,30 @@ title: Understand the AppLocker policy deployment process (Windows 10) description: This planning and deployment topic for the IT professional describes the process for using AppLocker when deploying application control policies. ms.assetid: 4cfd95c1-fbd3-41fa-8efc-d23c1ea6fb16 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Understand the AppLocker policy deployment process + **Applies to** - Windows 10 + 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). diff --git a/windows/keep-secure/understanding-applocker-allow-and-deny-actions-on-rules.md b/windows/keep-secure/understanding-applocker-allow-and-deny-actions-on-rules.md index 30f5de5bcc..b6d8502af0 100644 --- a/windows/keep-secure/understanding-applocker-allow-and-deny-actions-on-rules.md +++ b/windows/keep-secure/understanding-applocker-allow-and-deny-actions-on-rules.md @@ -2,52 +2,38 @@ title: Understanding AppLocker allow and deny actions on rules (Windows 10) description: This topic explains the differences between allow and deny actions on AppLocker rules. ms.assetid: ea0370fa-2086-46b5-a0a4-4a7ead8cbed9 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Understanding AppLocker allow and deny actions on rules + **Applies to** - Windows 10 + 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 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 conditionSecurity 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.

+ +| 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. +>**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) -  -  + +- [How AppLocker works](how-applocker-works-techref.md) diff --git a/windows/keep-secure/understanding-applocker-default-rules.md b/windows/keep-secure/understanding-applocker-default-rules.md index cf10480b26..76aa56e251 100644 --- a/windows/keep-secure/understanding-applocker-default-rules.md +++ b/windows/keep-secure/understanding-applocker-default-rules.md @@ -2,62 +2,45 @@ title: Understanding AppLocker default rules (Windows 10) 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.assetid: bdb03d71-05b7-41fb-96e3-a289ce1866e1 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Understanding AppLocker default rules + **Applies to** - Windows 10 + 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. + +>**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: +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 - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
TopicDescription

[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.

+ +| 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) + +- [How AppLocker works](how-applocker-works-techref.md)     diff --git a/windows/keep-secure/understanding-applocker-rule-behavior.md b/windows/keep-secure/understanding-applocker-rule-behavior.md index b065509210..2e1353c3ed 100644 --- a/windows/keep-secure/understanding-applocker-rule-behavior.md +++ b/windows/keep-secure/understanding-applocker-rule-behavior.md @@ -2,24 +2,29 @@ title: Understanding AppLocker rule behavior (Windows 10) description: This topic describes how AppLocker rules are enforced by using the allow and deny options in AppLocker. ms.assetid: 3e2738a3-8041-4095-8a84-45c1894c97d0 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Understanding AppLocker rule behavior + **Applies to** - Windows 10 + This topic describes how AppLocker rules are enforced by using the allow and deny options in AppLocker. + If no AppLocker rules for a specific rule collection exist, all files with that file format are allowed to run. However, when an AppLocker rule for a specific rule collection is created, only the files explicitly allowed in a rule are permitted to run. For example, if you create an executable rule that allows .exe files in *%SystemDrive%\\FilePath* to run, only executable files located in that path are allowed to run. + A rule can be configured to use either an allow or deny action: + - **Allow**. You can specify which files are allowed to run in your environment and for which users or groups of users. You can also configure exceptions to identify files that are excluded from the rule. - **Deny**. You can specify which files are not allowed to run in your environment and for which users or groups of users. You can also configure exceptions to identify files that are excluded from the rule. -**Important**   -You can use a combination of allow actions and deny actions. However, we recommend using allow actions with exceptions because deny actions override allow actions in all cases. Deny actions can also be circumvented. For example, if you configure a deny action for a file or folder path, the user can still run the file from any other path. + +>**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) -  -  + +- [How AppLocker works](how-applocker-works-techref.md) diff --git a/windows/keep-secure/understanding-applocker-rule-collections.md b/windows/keep-secure/understanding-applocker-rule-collections.md index 950a47ebfe..9c569f7f53 100644 --- a/windows/keep-secure/understanding-applocker-rule-collections.md +++ b/windows/keep-secure/understanding-applocker-rule-collections.md @@ -2,28 +2,34 @@ title: Understanding AppLocker rule collections (Windows 10) description: This topic explains the five different types of AppLocker rules used to enforce AppLocker policies. ms.assetid: 03c05466-4fb3-4880-8d3c-0f6f59fc5579 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Understanding AppLocker rule collections + **Applies to** - Windows 10 + 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. + +>**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) -  -  + +- [How AppLocker works](how-applocker-works-techref.md) diff --git a/windows/keep-secure/understanding-applocker-rule-condition-types.md b/windows/keep-secure/understanding-applocker-rule-condition-types.md index e6b6e8505a..d4e6ceaf84 100644 --- a/windows/keep-secure/understanding-applocker-rule-condition-types.md +++ b/windows/keep-secure/understanding-applocker-rule-condition-types.md @@ -2,39 +2,55 @@ title: Understanding AppLocker rule condition types (Windows 10) description: This topic for the IT professional describes the three types of AppLocker rule conditions. ms.assetid: c21af67f-60a1-4f7d-952c-a6f769c74729 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Understanding AppLocker rule condition types + **Applies to** - Windows 10 + 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. + + >**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). + + >**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) -  -  + +- [How AppLocker works](how-applocker-works-techref.md) diff --git a/windows/keep-secure/understanding-applocker-rule-exceptions.md b/windows/keep-secure/understanding-applocker-rule-exceptions.md index 0a89f17cc7..a99cb1f8cb 100644 --- a/windows/keep-secure/understanding-applocker-rule-exceptions.md +++ b/windows/keep-secure/understanding-applocker-rule-exceptions.md @@ -2,19 +2,24 @@ title: Understanding AppLocker rule exceptions (Windows 10) description: This topic describes the result of applying AppLocker rule exceptions to rule collections. ms.assetid: e6bb349f-ee60-4c8d-91cd-6442f2d0eb9c -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Understanding AppLocker rule exceptions + **Applies to** - Windows 10 + 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 in the organization to run Windows but does not allow anyone to run Registry Editor. The effect of this rule would prevent users such as help desk personnel from running a program that is necessary for their support tasks. To resolve this problem, create a second rule that applies to the Helpdesk user group: "Allow Helpdesk to run Registry Editor." If you create a deny rule that does not allow any users to run Registry Editor, the deny rule will override the second rule that allows the Helpdesk user group to run Registry Editor. + ## Related topics -[How AppLocker works](how-applocker-works-techref.md) -  -  + +- [How AppLocker works](how-applocker-works-techref.md) diff --git a/windows/keep-secure/understanding-the-file-hash-rule-condition-in-applocker.md b/windows/keep-secure/understanding-the-file-hash-rule-condition-in-applocker.md index 1be8c8cc55..b778f3c76d 100644 --- a/windows/keep-secure/understanding-the-file-hash-rule-condition-in-applocker.md +++ b/windows/keep-secure/understanding-the-file-hash-rule-condition-in-applocker.md @@ -2,38 +2,28 @@ title: Understanding the file hash rule condition in AppLocker (Windows 10) description: This topic explains the AppLocker file hash rule condition, the advantages and disadvantages, and how it is applied. ms.assetid: 4c6d9af4-2b1a-40f4-8758-1a6f9f147756 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Understanding the file hash rule condition in AppLocker + **Applies to** - Windows 10 + This topic explains the AppLocker file hash rule condition, the advantages and disadvantages, and how it is applied. + File hash rules use a system-computed cryptographic hash of the identified file. For files that are not digitally signed, file hash rules are more secure than path rules. The following table describes the advantages and disadvantages of the file hash condition. - ---- - - - - - - - - - - - - -
File hash condition advantagesFile 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.

+ +| 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) -  -  + +- [How AppLocker works](how-applocker-works-techref.md) diff --git a/windows/keep-secure/understanding-the-path-rule-condition-in-applocker.md b/windows/keep-secure/understanding-the-path-rule-condition-in-applocker.md index 2adb70d6c6..d62cf0c8b6 100644 --- a/windows/keep-secure/understanding-the-path-rule-condition-in-applocker.md +++ b/windows/keep-secure/understanding-the-path-rule-condition-in-applocker.md @@ -2,18 +2,24 @@ title: Understanding the path rule condition in AppLocker (Windows 10) description: This topic explains the AppLocker path rule condition, the advantages and disadvantages, and how it is applied. ms.assetid: 3fa54ded-4466-4f72-bea4-2612031cad43 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Understanding the path rule condition in AppLocker + **Applies to** - Windows 10 + This topic explains the AppLocker path rule condition, the advantages and disadvantages, and how it is applied. + The path condition identifies an application by its location in the file system of the computer or on the network. + When creating a rule that uses a deny action, path conditions are less secure than publisher and file hash conditions for preventing access to a file because a user could easily copy the file to a different location than the location specified in the rule. Because path rules specify locations within the file system, you should ensure that there are no subdirectories that are writable by non-administrators. For example, if you create a path rule for C:\\ with the allow action, any file under that location will be allowed to run, including within users' profiles. The following table describes the advantages and disadvantages of the path condition. + @@ -40,57 +46,22 @@ When creating a rule that uses a deny action, path conditions are less secure th
  AppLocker does not enforce rules that specify paths with short names. You should always specify the full path to a file or folder when creating path rules so that the rule will be properly enforced. + The asterisk (\*) wildcard character can be used within **Path** field. The asterisk (\*) character used by itself represents any path. When combined with any string value, the rule is limited to the path of the file and all the files under that path. For example, %ProgramFiles%\\Internet Explorer\\\* indicates that all files and subfolders within the Internet Explorer folder will be affected by the rule. + AppLocker uses path variables for well-known directories in Windows. Path variables are not environment variables. The AppLocker engine can only interpret AppLocker path variables. The following table details these path variables. - ----- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Windows directory or driveAppLocker path variableWindows environment variable

Windows

%WINDIR%

%SystemRoot%

System32

%SYSTEM32%

%SystemDirectory%

Windows installation directory

%OSDRIVE%

%SystemDrive%

Program Files

%PROGRAMFILES%

%ProgramFiles% and %ProgramFiles(x86)%

Removable media (for example, CD or DVD)

%REMOVABLE%

Removable storage device (for example, USB flash drive)

%HOT%

+ +| Windows directory or drive | AppLocker path variable | Windows environment variable | +| - | - | - | +| Windows | %WINDIR% | %SystemRoot% | +| System32 | %SYSTEM32%| %SystemDirectory%| +| Windows installation directory | %OSDRIVE%|%SystemDrive%| +| Program Files | %PROGRAMFILES%| %ProgramFiles% and %ProgramFiles(x86)%| +| Removable media (for example, CD or DVD) | %REMOVABLE%| | +| Removable storage device (for example, USB flash drive)| %HOT%|||   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) -  -  + +- [How AppLocker works](how-applocker-works-techref.md) diff --git a/windows/keep-secure/understanding-the-publisher-rule-condition-in-applocker.md b/windows/keep-secure/understanding-the-publisher-rule-condition-in-applocker.md index 053ee2e59c..34ac6444f3 100644 --- a/windows/keep-secure/understanding-the-publisher-rule-condition-in-applocker.md +++ b/windows/keep-secure/understanding-the-publisher-rule-condition-in-applocker.md @@ -2,18 +2,24 @@ title: Understanding the publisher rule condition in AppLocker (Windows 10) description: This topic explains the AppLocker publisher rule condition, what controls are available, and how it is applied. ms.assetid: df61ed8f-a97e-4644-9d0a-2169f18c1c4f -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Understanding the publisher rule condition in AppLocker + **Applies to** - Windows 10 + This topic explains the AppLocker publisher rule condition, what controls are available, and how it is applied. + Publisher conditions can be made only for files that are digitally signed; this condition identifies an app based on its digital signature and extended attributes. The digital signature contains information about the company that created the app (the publisher). The extended attributes, which are obtained from the binary resource, contain the name of the product that the app is part of and the version number of the app. The publisher may be a software development company, such as Microsoft, or the Information Technology department of your organization. -Publisher conditions are easier to maintain than file hash conditions and are generally more secure than path conditions. Rules that are specified to the version level might have to be updated when a new version of the file is released. The following table describes the advantages and disadvantages of the publisher condition. +Publisher conditions are easier to maintain than file hash conditions and are generally more secure than path conditions. Rules that are specified to the version level might have to be updated when a new version of the file is released. The following table describes the advantages and disadvantages +of the publisher condition. + @@ -42,70 +48,42 @@ Publisher conditions are easier to maintain than file hash conditions and are ge
  Wildcard characters can be used as values in the publisher rule fields according to the following specifications: + - **Publisher** + The asterisk (\*) character used by itself represents any publisher. When combined with any string value, the rule is limited to the publisher with a value in the signed certificate that matches the character string. In other words, the asterisk is not treated as a wildcard character if used with other characters in this field. For example, using the characters "M\*" limits the publisher name to only a publisher with the name "M\*." Using the characters "\*x\*" limits the publisher name only to the name “\*x\*”. A question mark (?) is not a valid wildcard character in this field. + - **Product name** + The asterisk (\*) character used by itself represents any product name. When combined with any string value, the rule is limited to the product of the publisher with a value in the signed certificate that matches the character string. In other words, the asterisk is not treated as a wildcard character if used with other characters in this field. A question mark (?) is not a valid wildcard character in this field. + - **File name** + Either the asterisk (\*) or question mark (?) characters used by themselves represent any and all file names. When combined with any string value, the string is matched with any file name containing that string. + - **File version** + The asterisk (\*) character used by itself represents any file version. If you want to limit the file version to a specific version or as a starting point, you can state the file version and then use the following options to apply limits: + - **Exactly**. The rule applies only to this version of the app - **And above**. The rule applies to this version and all later versions. - **And Below**. The rule applies to this version and all earlier versions. + The following table describes how a publisher condition is applied. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
OptionThe 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

-

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

-

The specified version of the named file and any new releases for the product that are signed by the publisher.

Publisher, product name, file name, and file version

And below

-

The specified version of the named file and any older versions for the product that are signed by the publisher.

Custom

You can edit the Publisher, Product name, File name, and Version fields to create a custom rule.

+ +| 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**
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**
The specified version of the named file and any new releases for the product that are signed by the publisher.| +| **Publisher, product name, file name, and file version**| **And below**
The specified version of the named file and any older versions for the product that are signed by the publisher.| +| **Custom** | You can edit the **Publisher**, **Product name**, **File name**, and **Version** fields to create a custom rule.|   For an overview of the three types of AppLocker rule conditions and explanations of the advantages and disadvantages of each, see [Understanding AppLocker rule condition types](understanding-applocker-rule-condition-types.md). + ## Related topics -[How AppLocker works](how-applocker-works-techref.md) -  -  + +- [How AppLocker works](how-applocker-works-techref.md) diff --git a/windows/keep-secure/use-a-reference-computer-to-create-and-maintain-applocker-policies.md b/windows/keep-secure/use-a-reference-computer-to-create-and-maintain-applocker-policies.md index 4b888e3d71..e9c7b0645e 100644 --- a/windows/keep-secure/use-a-reference-computer-to-create-and-maintain-applocker-policies.md +++ b/windows/keep-secure/use-a-reference-computer-to-create-and-maintain-applocker-policies.md @@ -2,35 +2,46 @@ title: Use a reference device to create and maintain AppLocker policies (Windows 10) description: This topic for the IT professional describes the steps to create and maintain AppLocker policies by using a reference computer. ms.assetid: 10c3597f-f44c-4c8e-8fe5-105d4ac016a6 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Use a reference device to create and maintain AppLocker policies + **Applies to** - Windows 10 + 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 subsequently 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). + +>**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 the procedure to do this, 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. + +>**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. + +>**Important:**  You can use the default rules as a template when you create your own rules. This allows files within the Windows directory to run. However, these rules are only meant to function as a starter policy when you are first testing AppLocker rules.   ## Step 3: Modify rules and the rule collection on the reference device + If AppLocker policies are currently running in your production environment, export the policies from the corresponding GPOs and save them to the reference device. For the procedure to do this, see [Export an AppLocker policy from a GPO](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) @@ -39,25 +50,34 @@ If AppLocker policies are currently running in your production environment, expo - [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 is 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](http://technet.microsoft.com/library/ee791772(WS.10).aspx) - [Discover the Effect of an AppLocker Policy](http://technet.microsoft.com/library/ee791823(WS.10).aspx) -**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. + +>**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 are not managed by Group Policy) and checked for its intended effectiveness. To do this, 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](http://technet.microsoft.com/library/ee791823(WS.10).aspx) + If the AppLocker policy enforcement setting is **Audit only** and you are 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 additional 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) -  -  + +- [Deploy the AppLocker policy into production](deploy-the-applocker-policy-into-production.md) diff --git a/windows/keep-secure/use-applocker-and-software-restriction-policies-in-the-same-domain.md b/windows/keep-secure/use-applocker-and-software-restriction-policies-in-the-same-domain.md index 01e857dfe3..ef970cd8df 100644 --- a/windows/keep-secure/use-applocker-and-software-restriction-policies-in-the-same-domain.md +++ b/windows/keep-secure/use-applocker-and-software-restriction-policies-in-the-same-domain.md @@ -2,18 +2,26 @@ title: Use AppLocker and Software Restriction Policies in the same domain (Windows 10) description: This topic for IT professionals describes concepts and procedures to help you manage your application control strategy using Software Restriction Policies and AppLocker. ms.assetid: 2b7e0cec-df62-49d6-a2b7-6b8e30180943 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Use AppLocker and Software Restriction Policies in the same domain + **Applies to** - Windows 10 + This topic for IT professionals describes concepts and procedures to help you manage your application control strategy using Software Restriction Policies and AppLocker. + ## Using AppLocker and Software Restriction Policies in the same domain -AppLocker is supported on systems running Windows 7 and above. 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 is 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. + +AppLocker is supported on systems running Windows 7 and above. 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 is 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. diff --git a/windows/keep-secure/use-the-applocker-windows-powershell-cmdlets.md b/windows/keep-secure/use-the-applocker-windows-powershell-cmdlets.md index 4ccedff7ca..cf988054c1 100644 --- a/windows/keep-secure/use-the-applocker-windows-powershell-cmdlets.md +++ b/windows/keep-secure/use-the-applocker-windows-powershell-cmdlets.md @@ -2,30 +2,51 @@ title: Use the AppLocker Windows PowerShell cmdlets (Windows 10) description: This topic for IT professionals describes how each AppLocker Windows PowerShell cmdlet can help you administer your AppLocker application control policies. ms.assetid: 374e029c-5c0a-44ab-a57a-2a9dd17dc57d -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Use the AppLocker Windows PowerShell cmdlets + **Applies to** - Windows 10 + 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. + +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](http://technet.microsoft.com/library/hh847209.aspx) cmdlet retrieves the AppLocker file information from a list of files or from an event log. File information that is retrieved can include publisher information, file hash information, and file path information. File information from an event log may not contain all of these fields. Files that are not signed do not have any publisher information. + +The [Get-AppLockerFileInformation](http://technet.microsoft.com/library/hh847209.aspx) cmdlet retrieves the AppLocker file information from a list of files or from an event log. File information that is retrieved can include publisher information, file hash information, and file path information. + +File information from an event log may not contain all of these fields. Files that are not signed do not have any publisher information. + ### Set AppLocker policy + The [Set-AppLockerPolicy](http://technet.microsoft.com/library/hh847212.aspx) 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](http://technet.microsoft.com/library/hh847214.aspx) 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](http://technet.microsoft.com/library/hh847211.aspx) 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. + +The [New-AppLockerPolicy](http://technet.microsoft.com/library/hh847211.aspx) 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](http://technet.microsoft.com/library/hh847213.aspx) 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. + ## Additional resources + - For steps to perform other AppLocker policy tasks, see [Administer AppLocker](administer-applocker.md). -  -  diff --git a/windows/keep-secure/use-windows-event-forwarding-to-assist-in-instrusion-detection.md b/windows/keep-secure/use-windows-event-forwarding-to-assist-in-instrusion-detection.md index cc7a0adbb4..060d693df1 100644 --- a/windows/keep-secure/use-windows-event-forwarding-to-assist-in-instrusion-detection.md +++ b/windows/keep-secure/use-windows-event-forwarding-to-assist-in-instrusion-detection.md @@ -2,22 +2,33 @@ title: Use Windows Event Forwarding to help with intrusion detection (Windows 10) description: Learn about an approach to collect events from devices in your organization. This article talks about events in both normal operations and when an intrusion is suspected. ms.assetid: 733263E5-7FD1-45D2-914A-184B9E3E6A3F -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: tedhardyMSFT --- + # Use Windows Event Forwarding to help with intrusion detection + **Applies to** - Windows 10 + Learn about an approach to collect events from devices in your organization. This article talks about events in both normal operations and when an intrusion is suspected. + Windows Event Forwarding (WEF) reads any operational or administrative event log on a device in your organization and forwards the events you choose to a Windows Event Collector (WEC) server. -To accomplish this, there are two different of subscriptions published to client devices - the Baseline subscription and the suspect subscription. The Baseline subscription enrolls all devices in your organization, and a Suspect subscription only includes devices that have been added by you. The Suspect subscription collects additional events to help build context for system activity and can quickly be updated to accommodate new events and/or scenarios as needed without impacting baseline operations. + +To accomplish this, there are two different of subscriptions published to client devices - the Baseline subscription and the suspect subscription. The Baseline subscription enrolls all devices in your organization, and a Suspect subscription only includes devices that have been added by you. The +Suspect subscription collects additional events to help build context for system activity and can quickly be updated to accommodate new events and/or scenarios as needed without impacting baseline operations. + This implementation helps differentiate where events are ultimately stored. Baseline events can be sent to devices with online analytical capability, such as Security Event Manager (SEM), while also sending events to a MapReduce system, such as HDInsight or Hadoop, for long-term storage and deeper analysis. Events from the Suspect subscription are sent directly to a MapReduce system due to volume and lower signal/noise ratio, they are largely used for host forensic analysis. + An SEM’s strength lies in being able to inspect, correlate events, and generate alerts for known patterns manner and alert security staff at machine speed. + A MapReduce system has a longer retention time (years versus months for an SEM), larger ingress ability (hundreds of terabytes per day), and the ability to perform more complex operations on the data like statistical and trend analysis, pattern clustering analysis, or apply Machine Learning algorithms. + Here's an approximate scaling guide for WEF events: + | Events/second range | Data store | |---------------------|----------------------------| | 0 - 5,000 | SQL or SEM | @@ -25,54 +36,91 @@ Here's an approximate scaling guide for WEF events: | 50,000+ | Hadoop/HDInsight/Data Lake |   Event generation on a device must be enabled either separately or as part of the GPO for the baseline WEF implementation, including enabling of disabled event logs and setting channel permissions. For more info, see [Appendix C - Event channel settings (enable and channel access) methods](#bkmk-appendixc). This is because WEF is a passive system with regards to the event log. It cannot change the size of event log files, enable disabled event channels, change channel permissions, or adjust a security audit policy. WEF only queries event channels for existing events. Additionally, having event generation already occurring on a device allows for more complete event collection building a complete history of system activity. Otherwise, you'll be limited to the speed of GPO and WEF subscription refresh cycles to make changes to what is being generated on the device. On modern devices, enabling additional event channels and expanding the size of event log files has not resulted in noticeable performance differences. + For the minimum recommended audit policy and registry system ACL settings, see [Appendix A - Minimum recommended minimum audit policy](#bkmk-appendixa) and [Appendix B - Recommended minimum registry system ACL policy](#bkmk-appendixb). -**Note**   -These are only minimum values need to meet what the WEF subscription selects. + +>**Note:**  These are only minimum values need to meet what the WEF subscription selects.   From a WEF subscription management perspective, the event queries provided should be used in two separate subscriptions for ease of maintenance; only machines meeting specific criteria would be allowed access to the targeted subscription, this access would be determined by an algorithm or an analysts’ direction. All devices should have access to the Baseline subscription. + This means you would create two base subscriptions: + - **Baseline WEF subscription**. Events collected from all hosts, this includes some role-specific events, which will only be emitted by those machines. - **Targeted WEF subscription**. Events collected from a limited set of hosts due to unusual activity and/or heightened awareness for those systems. + Each using the respective event query below. Note that for the Targeted subscription enabling the “read existing events” option should be set to true to allow collection of existing events from systems. By default, WEF subscriptions will only forward events generated after the WEF subscription was received by the client. + In [Appendix E – Annotated Baseline Subscription Event Query](#bkmk-appendixe) and [Appendix F – Annotated Suspect Subscription Event Query](#bkmk-appendixf), the event query XML is included when creating WEF subscriptions. These are annotated for query purpose and clarity. Individual <Query> element can be removed or edited without affecting the rest of the query. + ### Common WEF questions + This section addresses common questions from IT pros and customers. + ### Will the user notice if their machine is enabled for WEF or if WEF encounters an error? + The short answer is: No. + The longer answer is: The **Eventlog-forwardingPlugin/Operational** event channel logs the success, warning, and error events related to WEF subscriptions present on the device. Unless the user opens Event Viewer and navigates to that channel, they will not notice WEF either through resource consumption or Graphical User Interface pop-ups. Even if there is an issue with the WEF subscription, there is no user interaction or performance degradation. All success, warning, and failure events are logged to this operational event channel. + ### Is WEF Push or Pull? + A WEF subscription can be configured to be push or pull, but not both. The simplest, most flexible IT deployment with the greatest scalability can be achieved by using a push, or source initiated, subscription. WEF clients are configured by using a GPO and the built-in forwarding client is activated. For pull, collector initiated, the subscription on the WEC server is pre-configured with the names of the WEF Client devices from which events are to be selected. Those clients also have to be configured ahead of time to allow the credentials used in the subscription to access their event logs remotely (normally by adding the credential to the **Event Log Readers** built-in local security group.) A useful scenario: closely monitoring a specific set of machines. + ### Will WEF work over VPN or RAS? + WEF handles VPN, RAS, and DirectAccess scenarios well and will reconnect and send any accumulated backlog of events when the connection to the WEF Collector is re-established. + ### How is client progress tracked? -The WEC server maintains in its registry the bookmark information and last heartbeat time for each event source for each WEF subscription. When an event source re-connects to a WEC server, the last bookmark position is sent to the device to use as a starting point to resume forwarding events. If a WEF client has no events to send, the WEF client will connect periodically to send a Heartbeat to the WEC server to indicate it is active. This heartbeat value can be individually configured for each subscription. + +The WEC server maintains in its registry the bookmark information and last heartbeat time for each event source for each WEF subscription. When an event source re-connects to a WEC server, the last bookmark position is sent to the device to use as a starting point to resume forwarding events. If a +WEF client has no events to send, the WEF client will connect periodically to send a Heartbeat to the WEC server to indicate it is active. This heartbeat value can be individually configured for each subscription. + ### Will WEF work in an IPv4, IPv6, or mixed IPv4/IPv6 environment? + Yes. WEF is transport agnostic and will work over IPv4 or IPv6. + ### Are WEF events encrypted? I see an HTTP/HTTPS option! + In a domain setting, the connection used to transmit WEF events is encrypted using Kerberos, by default (with NTLM as a fallback option, which can be disabled by using a GPO). Only the WEF collector can decrypt the connection. Additionally, the connection between WEF client and WEC server is mutually authenticated regardless of authentication type (Kerberos or NTLM.) There are GPO options to force Authentication to use Kerberos Only. + This authentication and encryption is performed regardless if HTTP or HTTPS is selected. + The HTTPS option is available if certificate based authentication is used, in cases where the Kerberos based mutual authentication is not an option. The SSL certificate and provisioned client certificates are used to provide mutual authentication. + ### Do WEF Clients have a separate buffer for events? + The WEF client machines local event log is the buffer for WEF for when the connection to the WEC server is lost. To increase the “buffer size”, increase the maximum file size of the specific event log file where events are being selected. For more info, see [Appendix C – Event Channel Settings (enable and Channel Access) methods](#bkmk-appendixc). + When the event log overwrites existing events (resulting in data loss if the device is not connected to the Event Collector), there is no notification sent to the WEF collector that events are lost from the client. Neither is there an indicator that there was a gap encountered in the event stream. + ### What format is used for forwarded events? -WEF has two modes for forwarded events. The default is “Rendered Text” which includes the textual description of the event as you would see it in Event Viewer. This means that the event size is effectively doubled or tripled depending on the size of the rendered description. The alternative mode is “Events” (also sometimes referred to as “Binary” format) – which is just the event XML itself sent in binary XML format (as it would be written to the evtx file.) This is very compact and can more than double the event volume a single WEC server can accommodate. + +WEF has two modes for forwarded events. The default is “Rendered Text” which includes the textual description of the event as you would see it in Event Viewer. This means that the event size is effectively doubled or tripled depending on the size of the rendered description. The alternative mode is +“Events” (also sometimes referred to as “Binary” format) – which is just the event XML itself sent in binary XML format (as it would be written to the evtx file.) This is very compact and can more than double the event volume a single WEC server can accommodate. + A subscription “testSubscription” can be configured to use the Events format through the WECUTIL utility: + ``` syntax @rem required to set the DeliveryMaxItems or DeliveryMaxLatencyTime Wecutil ss “testSubscription” /cf:Events ``` + ### How frequently are WEF events delivered? + Event delivery options are part of the WEF subscription configuration parameters – There are three built-in subscription delivery options: Normal, Minimize Bandwidth, and Minimize Latency. A fourth, catch-all called “Custom” is available but cannot be selected or configured through the WEF UI by using Event Ciewer. The Custom delivery option must be selected and configured using the WECUTIL.EXE command-line application. All subscription options define a maximum event count and maximum event age, if either limit is exceeded then the accumulated events are sent to the event collector. + This table outlines the built-in delivery options: -| Event delivery optimization options | Description | -|-------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| Normal | This option ensures reliable delivery of events and does not attempt to conserve bandwidth. It is the appropriate choice unless you need tighter control over bandwidth usage or need forwarded events delivered as quickly as possible. It uses pull delivery mode, batches 5 items at a time and sets a batch timeout of 15 minutes. | -| Minimize bandwidth | This option ensures that the use of network bandwidth for event delivery is strictly controlled. It is an appropriate choice if you want to limit the frequency of network connections made to deliver events. It uses push delivery mode and sets a batch timeout of 6 hours. In addition, it uses a heartbeat interval of 6 hours. | -| Minimize latency | This option ensures that events are delivered with minimal delay. It is an appropriate choice if you are collecting alerts or critical events. It uses push delivery mode and sets a batch timeout of 30 seconds. | + +| Event delivery optimization options | Description | +| - | - | +| Normal | This option ensures reliable delivery of events and does not attempt to conserve bandwidth. It is the appropriate choice unless you need tighter control over bandwidth usage or need forwarded events delivered as quickly as possible. It uses pull delivery mode, batches 5 items at a time and sets a batch timeout of 15 minutes. | +| Minimize bandwidth | This option ensures that the use of network bandwidth for event delivery is strictly controlled. It is an appropriate choice if you want to limit the frequency of network connections made to deliver events. It uses push delivery mode and sets a batch timeout of 6 hours. In addition, it uses a heartbeat interval of 6 hours. | +| Minimize latency | This option ensures that events are delivered with minimal delay. It is an appropriate choice if you are collecting alerts or critical events. It uses push delivery mode and sets a batch timeout of 30 seconds. |   For more info about delivery options, see [Configure Advanced Subscription Settings](http://technet.microsoft.com/library/cc749167.aspx). + The primary difference is in the latency which events are sent from the client. If none of the built-in options meet your requirements you can set Custom event delivery options for a given subscription from an elevated command prompt: + ``` syntax @rem required to set the DeliveryMaxItems or DeliveryMaxLatencyTime Wecutil ss “SubscriptionNameGoesHere” /cm:Custom @@ -82,122 +130,209 @@ Wecutil ss “SubscriptionNameGoesHere” /dmi:1 Wecutil ss “SubscriptionNameGoesHere” /dmlt:10 ``` ### How do I control which devices have access to a WEF Subscription? + For source initiated subscriptions: Each WEF subscription on a WEC server has its own ACL for machine accounts or security groups containing machine accounts (not user accounts) that are explicitly allowed to participate in that subscription or are explicitly denied access. This ACL applies to only a single WEF subscription (since there can be multiple WEF subscriptions on a given WEC server), other WEF Subscriptions have their own separate ACL. + For collector initiated subscriptions: The subscription contains the list of machines from which the WEC server is to collect events. This list is managed at the WEC server, and the credentials used for the subscription must have access to read event logs from the WEF Clients – the credentials can be either the machine account or a domain account. + ### Can a client communicate to multiple WEF Event Collectors? + Yes. If you desire a High-Availability environment, simply configure multiple WEC servers with the same subscription configuration and publish both WEC Server URIs to WEF clients. WEF Clients will forward events simultaneously to the configured subscriptions on the WEC servers, if they have the appropriate access. + ### What are the WEC server’s limitations? + There are three factors that limit the scalability of WEC servers. The general rule for a stable WEC server on commodity hardware is “10k x 10k” – meaning, no more than 10,000 concurrently active WEF Clients per WEC server and no more than 10,000 events/second average event volume. + - **Disk I/O**. The WEC server does not process or validate the received event, but rather buffers the received event and then logs it to a local event log file (EVTX file). The speed of logging to the EVTX file is limited by the disk write speed. Isolating the EVTX file to its own array or using high speed disks can increase the number of events per second that a single WEC server can receive. - **Network Connections**. While a WEF source does not maintain a permanent, persistent connection to the WEC server, it does not immediately disconnect after sending its events. This means that the number of WEF sources that can simultaneously connect to the WEC server is limited to the open TCP ports available on the WEC server. - **Registry size**. For each unique device that connects to a WEF subscription, there is a registry key (corresponding to the FQDN of the WEF Client) created to store bookmark and source heartbeat information. If this is not pruned to remove inactive clients this set of registry keys can grow to an unmanageable size over time. + - When a subscription has >1000 WEF sources connect to it over its operational lifetime, also known as lifetime WEF sources, Event Viewer can become unresponsive for a few minutes when selecting the **Subscriptions** node in the left-navigation, but will function normally afterwards. - At >50,000 lifetime WEF sources, Event Viewer is no longer an option and wecutil.exe (included with Windows) must be used to configure and manage subscriptions. - At >100,000 lifetime WEF sources, the registry will not be readable and the WEC server will likely have to be rebuilt. + ## Subscription information + Below lists all of the items that each subscription collects, the actual subscription XML is available in an Appendix. These are separated out into Baseline and Targeted. The intent is to subscribe all hosts to Baseline, and then enroll (and remove) hosts on an as needed basis to the Targeted subscription. + ### Baseline subscription + While this appears to be the largest subscription, it really is the lowest volume on a per-device basis. (Exceptions should be allowed for unusual devices – a device performing complex developer related tasks can be expected to create an unusually high volume of process create and AppLocker events.) This subscription does not require special configuration on client devices to enable event channels or modify channel permissions. + The subscription is essentially a collection of query statements applied to the Event Log. This means that it is modular in nature and a given query statement can be removed or changed without impacting other query statement in the subscription. Additionally, suppress statements which filter out specific events, only apply within that query statement and are not to the entire subscription. + ### Baseline subscription requirements + To gain the most value out of the baseline subscription we recommend to have the following requirements set on the device to ensure that the clients are already generating the required events to be forwarded off the system. + - Apply a security audit policy that is a super-set of the recommended minimum audit policy. For more info, see [Appendix A – Minimum Recommended minimum Audit Policy](#bkmk-appendixa). This ensures that the security event log is generating the required events. - Apply at least an Audit-Only AppLocker policy to devices. + - If you are already whitelisting or blacklisting events by using AppLocker, then this requirement is met. - AppLocker events contain extremely useful information, such as file hash and digital signature information for executables and scripts. + - Enable disabled event channels and set the minimum size for modern event files. - Currently, there is no GPO template for enabling or setting the maximum size for the modern event files. This must be done by using a GPO. For more info, see [Appendix C – Event Channel Settings (enable and Channel Access) methods](#bkmk-appendixc). + The annotated event query can be found in the following. For more info, see [Appendix F – Annotated Baseline Subscription Event Query](#bkmk-appendixf). + - Anti-malware events from Microsoft Antimalware or Windows Defender. This can be configured for any given anti-malware product easily if it writes to the Windows event log. - Security event log Process Create events. - AppLocker Process Create events (EXE, script, packaged App installation and execution). - Registry modification events. For more info, see [Appendix B – Recommended minimum Registry System ACL Policy](#bkmk-appendixb). - OS startup and shutdown + - Startup event include operating system version, service pack level, QFE version, and boot mode. + - Service install + - Includes what the name of the service, the image path, and who installed the service. + - Certificate Authority audit events + - This is only applicable on systems with the Certificate Authority role installed. - Logs certificate requests and responses. + - User profile events + - Use of a temporary profile or unable to create a user profile may indicate an intruder is interactively logging into a device but not wanting to leave a persistent profile behind. + - Service start failure + - Failure codes are localized, so you have to check the message DLL for values. + - Network share access events + - Filter out IPC$ and /NetLogon file shares, which are expected and noisy. + - System shutdown initiate requests + - Find out what initiated the restart of a device. + - User initiated interactive logoff event - Remote Desktop Services session connect, reconnect, or disconnect. - EMET events, if EMET is installed. - Event forwarding plugin events + - For monitoring WEF subscription operations, particularly Partial Success events. This is useful for diagnosing deployment issues. + - Network share create and delete + - Enables detection of unauthorized share creation. - **Note**  All shares are re-created when the device starts. + >**Note:**  All shares are re-created when the device starts.   - Logon sessions + - Logon success for interactive (local and Remote Interactive/Remote Desktop) - Logon success for services for non-built-in accounts, such as LocalSystem, LocalNetwork, and so on. - Logon success for batch sessions - Logon session close, which are logoff events for non-network sessions. + - Windows Error Reporting (Application crash events only) + - This can help detect early signs of intruder not familiar with enterprise environment using targeted malware. + - Event log service events + - Errors, start events, and stop events for the Windows Event Log service. + - Event log cleared (including the Security Event Log) + - This could indicate an intruder that are covering their tracks. + - Special privileges assigned to new logon + - This indicates that at the time of logon a user is either an Administrator or has the sufficient access to make themselves Administrator. + - Outbound Remote Desktop Services session attempts + - Visibility into potential beachhead for intruder + - System time changed - SMB Client (mapped drive connections) - Account credential validation + - Local accounts or domain accounts on domain controllers + - A user was added or removed from the local Administrators security group. - Crypto API private key accessed + - Associated with signing objects using the locally stored private key. + - Task Scheduler task creation and delete + - Task Scheduler allows intruders to run code at specified times as LocalSystem. + - Logon with explicit credentials + - Detect credential use changes by intruders to access additional resources. + - Smartcard card holder verification events + - This detects when a smartcard is being used. + ### Suspect subscription + This adds some possible intruder-related activity to help analyst further refine their determinations about the state of the device. + - Logon session creation for network sessions + - Enables time-series analysis of network graphs. + - RADIUS and VPN events + - Useful if you use a Microsoft IAS RADIUS/VPN implementation. It shows user-> IP address assignment with remote IP address connecting to the enterprise. + - Crypto API X509 object and build chain events + - Detects known bad certificate, CA, or sub-CA - Detects unusual process use of CAPI + - Groups assigned to local logon + - Gives visibility to groups which enable account wide access - Allows better planning for remediation efforts - Excludes well known, built-in system accounts. + - Logon session exit + - Specific for network logon sessions. + - Client DNS lookup events + - Returns what process performed a DNS query and the results returned from the DNS server. + - Process exit + - Enables checking for processes terminating unexpectedly. + - Local credential validation or logon with explicit credentials + - Generated when the local SAM is authoritative for the account credentials being authenticated. - Noisy on domain controllers - On client devices this is only generated when local accounts log on. + - Registry modification audit events + - Only when a registry value is being created, modified, or deleted. + - Wireless 802.1x authentication + - Detect wireless connection with a peer MAC address + - Windows PowerShell logging + - Covers Windows PowerShell 2.0 and later and includes the Windows PowerShell 5.0 logging improvements for in-memory attacks using Windows PowerShell. - Includes Windows PowerShell remoting logging + - User Mode Driver Framework “Driver Loaded” event + - Can possibly detect a USB device loading multiple device drivers. For example, a USB\_STOR device loading the keyboard or network driver. + ## Appendix A - Minimum recommended minimum audit policy + If your organizational audit policy enables additional auditing to meet its needs, that is fine. The policy below is the minimum audit policy settings needed to enable events collected by both baseline and targeted subscriptions. + | Category | Subcategory | Audit settings | |--------------------|---------------------------------|---------------------| | Account Logon | Credential Validation | Success and Failure | @@ -232,28 +367,46 @@ If your organizational audit policy enables additional auditing to meet its need | System | System Integrity | Success and Failure |   ## Appendix B - Recommended minimum registry system ACL policy + The Run and RunOnce keys are useful for intruders and malware persistence. It allows code to be run (or run only once then removed, respectively) when a user logs into the system. + This can easily be extended to other Auto-Execution Start Points keys in the registry. + Use the following figures to see how you can configure those registry keys. -![default acl for run key](images/runkey.png)![default acl for runonce key](images/runoncekey.png) + +![default acl for run key](images/runkey.png) + +![default acl for runonce key](images/runoncekey.png) + ## Appendix C - Event channel settings (enable and channel access) methods + Some channels are disabled by default and have to be enabled. Others, such as Microsoft-Windows-CAPI2/Operational must have the channel access modified to allow the Event Log Readers built-in security group to read from it. + The recommended and most effective way to do this is to configure the baseline GPO to run a scheduled task to configure the event channels (enable, set maximum size, and adjust channel access.) This will take effect at the next GPO refresh cycle and has minimal impact on the client device. + The following GPO snippet performs the following: + - Enables the **Microsoft-Windows-Capi2/Operational** event channel. - Sets the maximum file size for **Microsoft-Windows-Capi2/Operational** to 100MB. - Sets the maximum file size for **Microsoft-Windows-AppLocker/EXE and DLL** to 100MB. - Sets the maximum channel access for **Microsoft-Windows-Capi2/Operational** to include the built-in Event Log Readers security group. - Enables the **Microsoft-Windows-DriverFrameworks-UserMode/Operational** event channel. - Sets the maximum file size for **Microsoft-Windows-DriverFrameworks-UserMode/Operational** to 50MB. + ![configure event channels](images/capi-gpo.png) + ## Appendix D - Minimum GPO for WEF Client configuration + Here are the minimum steps for WEF to operate: + 1. Configure the collector URI(s). 2. Start the WinRM service. 3. Add the Network Service account to the built-in Event Log Readers security group. This allows reading from secured event channel, such as the security event channel. + ![configure the wef client](images/wef-client-config.png) + ## Appendix E – Annotated baseline subscription event query + ``` syntax @@ -416,8 +569,11 @@ Here are the minimum steps for WEF to operate: ``` + ## Appendix F – Annotated Suspect Subscription Event Query + ``` syntax + @@ -486,10 +642,10 @@ Here are the minimum steps for WEF to operate: ``` ## Appendix G - Online resources + You can get more info with the following links: -- [Event Selection](http://msdn.microsoft.com/library/aa385231(VS.85).aspx) -- [Event Queries and Event XML](http://msdn.microsoft.com/library/bb399427(VS.90).aspx) -- [Event Query Schema](http://msdn.microsoft.com/library/aa385760(VS.85).aspx) + +- [Event Selection](http://msdn.microsoft.com/library/aa385231.aspx) +- [Event Queries and Event XML](http://msdn.microsoft.com/library/bb399427.aspx) +- [Event Query Schema](http://msdn.microsoft.com/library/aa385760.aspx) - [Windows Event Collector](http://msdn.microsoft.com/library/windows/desktop/bb427443.aspx) -  -  diff --git a/windows/keep-secure/user-account-control-admin-approval-mode-for-the-built-in-administrator-account.md b/windows/keep-secure/user-account-control-admin-approval-mode-for-the-built-in-administrator-account.md index 9f31ef56eb..a4fbc0126b 100644 --- a/windows/keep-secure/user-account-control-admin-approval-mode-for-the-built-in-administrator-account.md +++ b/windows/keep-secure/user-account-control-admin-approval-mode-for-the-built-in-administrator-account.md @@ -2,87 +2,83 @@ title: User Account Control Admin Approval Mode for the Built-in Administrator account (Windows 10) description: Describes the best practices, location, values, policy management and security considerations for the User Account Control Admin Approval Mode for the Built-in Administrator account security policy setting. ms.assetid: d465fc27-1cd2-498b-9cf6-7ad2276e5998 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # User Account Control: Admin Approval Mode for the Built-in Administrator account **Applies to** - Windows 10 + Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Admin Approval Mode for the Built-in Administrator account** security policy setting. + ## Reference + This policy setting determines the behavior of Admin Approval Mode for the built-in administrator account. When the Admin Approval Mode is enabled, the local administrator account functions like a standard user account, but it has the ability to elevate privileges without logging on by using a different account. In this mode, any operation that requires elevation of privilege displays a prompt that allows the administrator to permit or deny the elevation of privilege. If Admin Approval Mode is not enabled, the built-in Administrator account logs on in Windows XP Mode, and it runs all applications by default with full administrative privileges. By default, this setting is set to **Disabled**. -**Note**   -If a computer is upgraded from a previous version of the Windows operating system, and the administrator account is the only account on the computer, the built-in administrator account remains enabled, and this setting is also enabled. + +>**Note:**  If a computer is upgraded from a previous version of the Windows operating system, and the administrator account is the only account on the computer, the built-in administrator account remains enabled, and this setting is also enabled.   ### Possible values + - Enabled + The built-in administrator account logs on in Admin Approval Mode so that any operation that requires elevation of privilege displays a prompt that provides the administrator the option to permit or deny the elevation of privilege. + - Disabled + The built-in administrator account logs on in Windows XP Mode, and it runs all applications by default with full administrative privileges. + ### Best practices + - Do not enable the built-in administrator account on the client computer, but use the standard user account and User Account Control (UAC). + ### Location + Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options + ### Default values + The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. -
---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Server type or GPODefault value

Default Domain Policy

Not defined

Default Domain Controller Policy

Not defined

Stand-Alone Server Default Settings

Disabled

DC Effective Default Settings

Disabled

Member Server Effective Default Settings

Disabled

Client Computer Effective Default Settings

Disabled

+ +| Server type or GPO | Default value | +| - | - | +| Default Domain Policy| Not defined| +| Default Domain Controller Policy | Not defined| +| Stand-Alone Server Default Settings | Disabled| +| DC Effective Default Settings | Disabled| +| Member Server Effective Default Settings | Disabled| +| Client Computer Effective Default Settings | Disabled|   ## Policy management + This section describes features and tools that are available to help you manage this policy. + ### Restart requirement + None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy. + ## Security considerations + This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. + ### Vulnerability + One of the risks of the User Account Control (UAC) feature is that it is intended to mitigate malicious software running under elevated credentials without the user or administrator being aware of its activity. An attack vector for malicious programs is to discover the password of the administrator account because that user account was created for all installations of the Windows. To address this risk, the built-in administrator account is disabled in computers running at least Windows Vista. In computers running at least Windows Server 2008, the administrator account is enabled, and the password must be changed the first time the Administrator logs on. In a default installation of a computer running at least Windows Vista, accounts with administrative control over the computer are initially set up in one of two ways: + - If the computer is not joined to a domain, the first user account you create has the equivalent permissions as a local administrator. - If the computer is joined to a domain, no local administrator accounts are created. The enterprise or domain administrator must log on to the computer and create a local administrator account if one is warranted. + ### Countermeasure + Enable the **User Account Control: Admin Approval Mode for the Built-in Administrator account** setting if you have the built-in Administrator account enabled. + ### Potential impact + Users who log on by using the local administrator account are prompted for consent whenever a program requests an elevation in privilege. ## Related topics -[Security Options](security-options.md) -  -  + +- [Security Options](security-options.md) diff --git a/windows/keep-secure/user-account-control-allow-uiaccess-applications-to-prompt-for-elevation-without-using-the-secure-desktop.md b/windows/keep-secure/user-account-control-allow-uiaccess-applications-to-prompt-for-elevation-without-using-the-secure-desktop.md index 3215dba248..cc8ebe93f3 100644 --- a/windows/keep-secure/user-account-control-allow-uiaccess-applications-to-prompt-for-elevation-without-using-the-secure-desktop.md +++ b/windows/keep-secure/user-account-control-allow-uiaccess-applications-to-prompt-for-elevation-without-using-the-secure-desktop.md @@ -2,104 +2,118 @@ title: User Account Control Allow UIAccess applications to prompt for elevation without using the secure desktop (Windows 10) description: Describes the best practices, location, values, and security considerations for the User Account Control Allow UIAccess applications to prompt for elevation without using the secure desktop security policy setting. ms.assetid: fce20472-3c93-449d-b520-13c4c74a9892 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop + **Applies to** - Windows 10 + Describes the best practices, location, values, and security considerations for the **User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop** security policy setting. + ## Reference + This security setting controls whether User Interface Accessibility (UIAccess or UIA) programs can automatically disable the secure desktop for elevation prompts that are used by a standard user. -**Note**   -This setting does not change the behavior of the UAC elevation prompt for administrators. + +>**Note:**  This setting does not change the behavior of the UAC elevation prompt for administrators.   **Background** + User Interface Privilege Isolation (UIPI) implements restrictions in the Windows subsystem that prevent lower-privilege applications from sending messages or installing hooks in higher-privilege processes. Higher-privilege applications are permitted to send messages to lower-privilege processes. UIPI does not interfere with or change the behavior of messages between applications at the same privilege (or integrity) level. + Microsoft UI Automation is the current model to support accessibility requirements in the Windows operating systems. Applications that are designed to support an accessible user experience control the behavior of other Windows applications on behalf of the user. When all applications on the automation client computer and server are running as a standard user (that is, at a medium integrity level), the UIPI restrictions do not interfere with the Microsoft UI automation model. + However, there might be times when an administrative user runs an application with elevated privilege based on UAC in Admin Approval Mode. Microsoft UI Automation cannot drive the UI graphics of elevated applications on the desktop without the ability to bypass the restrictions that UIPI implements. The ability to bypass UIPI restrictions across privilege levels is available for UI automation programs by using UIAccess. -If an application presents a UIAccess attribute when it requests privileges, the application is stating a requirement to bypass UIPI restrictions for sending messages across privilege levels. Devices implement the following policy checks before starting an application with UIAccess privilege. + +If an application presents a UIAccess attribute when it requests privileges, the application is stating a requirement to bypass UIPI restrictions for sending messages across privilege levels. Devices implement the following policy +checks before starting an application with UIAccess privilege. + 1. The application must have a digital signature that can be verified by using a digital certificate that is associated with the Trusted Root Certification Authorities store on the local computer. 2. The application must be installed in a local folder that is writeable only by administrators, such as the Program Files directory. The allowed directories for UI automation applications are: + 1. %ProgramFiles% and its subdirectories. 2. %WinDir% and its subdirectories, except a few subdirectories that are excluded because standard users have write access. + **Resulting behavior** + When this setting is enabled, UIAccess programs (including Windows Remote Assistance) can automatically disable the secure desktop for elevation prompts. Unless you have also disabled elevation prompts, the prompts appear on the interactive user's desktop instead of on the secure desktop. The prompts also appear on the remote administrator's view of the desktop during a Windows Remote Assistance session, and the remote administrator can provide the appropriate credentials for elevation. + If you disable this setting, the secure desktop can only be disabled by the user of the interactive desktop or by disabling the [User Account Control: Switch to the secure desktop when prompting for elevation](user-account-control-switch-to-the-secure-desktop-when-prompting-for-elevation.md) setting, which by default is enabled. + ### Possible values + - Enabled + UIA programs can automatically disable the secure desktop for elevation prompts, and unless you have also disabled elevation prompts, the prompts appear on the interactive user's desktop instead of on the secure desktop. Prompts will also appear on the remote administrator's view of the desktop during a Windows Remote Assistance session, and the remote administrator can provide the appropriate credentials for elevation. + - Disabled + The secure desktop can be disabled only by the user of the interactive desktop or by disabling the **User Account Control: Switch to the secure desktop when prompting for elevation** policy setting. + ### Best practices + - Best practices are dependent on your security policies and your remote operational requirements. + ### Location + Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options + ### Default values + The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Server type or GPODefault value

Default Domain Policy

Not defined

Default Domain Controller Policy

Not defined

Stand-Alone Server Default Settings

Disabled

DC Effective Default Settings

Disabled

Member Server Effective Default Settings

Disabled

Client Computer Effective Default Settings

Disabled

+ +Server type or GPO| Default value | +| - | - | +| Default Domain Policy| Not defined| +| Default Domain Controller Policy | Not defined| +| Stand-Alone Server Default Settings | Disabled| +| DC Effective Default Settings | Disabled| +| Member Server Effective Default Settings | Disabled| +| Client Computer Effective Default Settings | Disabled|   ## Policy management + This section describes features and tools that are available to help you manage this policy. + ### Restart requirement + None. Changes to this policy become effective without a computer restart when they are saved locally or distributed through Group Policy. + ### Group Policy + All auditing capabilities are integrated in Group Policy. You can configure, deploy, and manage these settings in the Group Policy Management Console (GPMC) or Local Security Policy snap-in for a domain, site, or organizational unit (OU). + ### Policy interactions + If you plan to enable this setting, you should also review the effect of the [User Account Control: Behavior of the elevation prompt for standard users](user-account-control-behavior-of-the-elevation-prompt-for-standard-users.md) setting. If it is configured as **Automatically deny elevation requests**, elevation requests are not presented to the user. If you disable this setting, the secure desktop can only be disabled by the user of the interactive desktop or by disabling the [User Account Control: Switch to the secure desktop when prompting for elevation](user-account-control-switch-to-the-secure-desktop-when-prompting-for-elevation.md) setting, which by default is enabled. + ## Security considerations + This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. + ### Vulnerability + UIA programs are designed to interact with Windows and application programs on behalf of a user. This setting allows UIA programs to bypass the secure desktop to increase usability in certain cases, but it allows elevation requests to appear on the regular interactive desktop instead of on the secure desktop. This increases the risk that a malicious program could intercept data that is being transferred between the UI and the application. Because UIA programs must be able to respond to prompts regarding security issues, such as the UAC elevation prompt, UIA programs must be highly trusted. To be considered trusted, a UIA program must be digitally signed. By default, UIA programs can be run only from the following protected paths: + - ..\\Program Files\\ (and subfolders) - ..\\Program Files (x86)\\ (and subfolders, in 64-bit versions of Windows only) - ..\\Windows\\System32\\ + The requirement to be in a protected path can be disabled by the [User Account Control: Only elevate UIAccess applications that are installed in secure locations](user-account-control-only-elevate-uiaccess-applications-that-are-installed-in-secure-locations.md) setting. Although this setting applies to any UIA program, it is used primarily in certain Windows Remote Assistance scenarios. + ### Countermeasure + Disable the **User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop** setting. + ### Potential impact + If a user requests remote assistance from an administrator and the remote assistance session is established, elevation prompts appear on the interactive user's secure desktop and the administrator's remote session is paused. To avoid pausing the remote administrator’s session during elevation requests, the user can select the "Allow IT Expert to respond to User Account Control prompts" check box when setting up the remote assistance session. However, selecting this check box requires that the interactive user respond to an elevation prompt on the secure desktop. If the interactive user is a standard user, the user does not have the required credentials to allow elevation. + ## Related topics -[Security Options](security-options.md) -  -  + +- [Security Options](security-options.md) diff --git a/windows/keep-secure/user-account-control-behavior-of-the-elevation-prompt-for-administrators-in-admin-approval-mode.md b/windows/keep-secure/user-account-control-behavior-of-the-elevation-prompt-for-administrators-in-admin-approval-mode.md index 2f01c9ecc5..28718b33ae 100644 --- a/windows/keep-secure/user-account-control-behavior-of-the-elevation-prompt-for-administrators-in-admin-approval-mode.md +++ b/windows/keep-secure/user-account-control-behavior-of-the-elevation-prompt-for-administrators-in-admin-approval-mode.md @@ -2,94 +2,99 @@ title: User Account Control Behavior of the elevation prompt for administrators in Admin Approval Mode (Windows 10) description: Describes the best practices, location, values, policy management and security considerations for the User Account Control Behavior of the elevation prompt for administrators in Admin Approval Mode security policy setting. ms.assetid: 46a3c3a2-1d2e-4a6f-b5e6-29f9592f535d -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode + **Applies to** - Windows 10 + Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode** security policy setting. + ## Reference + This policy setting determines the behavior of the elevation prompt for accounts that have administrative credentials. + ### Possible values + - **Elevate without prompting** + Assumes that the administrator will permit an operation that requires elevation, and additional consent or credentials are not required. - **Note**   - Selecting **Elevate without prompting** minimizes the protection that is provided by UAC. We do not recommend selecting this value unless administrator accounts are tightly controlled and the operating environment is highly secure. + >**Note:**  Selecting **Elevate without prompting** minimizes the protection that is provided by UAC. We do not recommend selecting this value unless administrator accounts are tightly controlled and the operating environment is highly secure.   - **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. + - **Prompt for consent on the secure desktop** + When an operation requires elevation of privilege, the user is prompted on the secure desktop to select **Permit** or **Deny**. If the user selects **Permit**, the operation continues with the user's highest available privilege. + - **Prompt for credential**s + An operation that requires elevation of privilege prompts the administrator to type the user name and password. If the administrator enters valid credentials, the operation continues with the applicable privilege. + - **Prompt for consent** + An operation that requires elevation of privilege prompts the administrator to select **Permit** or **Deny**. If the administrator selects **Permit**, the operation continues with the administrator's highest available privilege. + - **Prompt for consent for non-Windows binaries** + This is the default. When an operation for a non-Microsoft application requires elevation of privilege, the user is prompted on the secure desktop to select **Permit** or **Deny**. If the user selects **Permit**, the operation continues with the user's highest available privilege. + ### Best practices + - Selecting the option **Elevate without prompting** minimizes the protection that is provided by UAC. We do not recommend selecting this value unless administrator accounts are tightly controlled and the operating environment is highly secure. + ### Location + Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options + ### Default values -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Server type or GPODefault value

Default Domain Policy

Not defined

Default Domain Controller Policy

Not defined

Stand-Alone Server Default Settings

Prompt for consent for non-Windows binaries

DC Effective Default Settings

Prompt for consent for non-Windows binaries

Member Server Effective Default Settings

Prompt for consent for non-Windows binaries

Client Computer Effective Default Settings

Prompt for consent for non-Windows binaries

+ + +| Server type or GPO Default value | +| - | - | +| Default Domain Policy | Not defined| +| Default Domain Controller Policy | Not defined | +| Stand-Alone Server Default Settings | Prompt for consent for non-Windows binaries| +| DC Effective Default Settings | Prompt for consent for non-Windows binaries| +| Member Server Effective Default Settings | Prompt for consent for non-Windows binaries| +| Client Computer Effective Default Settings | Prompt for consent for non-Windows binaries|   ## Policy management + This section describes features and tools that are available to help you manage this policy. + ### Restart requirement + None. Changes to this policy become effective without a computer restart when they are saved locally or distributed through Group Policy. + ### Group Policy + All auditing capabilities are integrated in Group Policy. You can configure, deploy, and manage these settings in the Group Policy Management Console (GPMC) or Local Security Policy snap-in for a domain, site, or organizational unit (OU). + ## Security considerations + This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. + ### Vulnerability + One of the risks that the UAC feature tries to mitigate is that of malicious software running under elevated credentials without the user or administrator being aware of its activity. This setting raises awareness to the administrator of elevated privilege operations, and it permits the administrator to prevent a malicious program from elevating its privilege when the program attempts to do so. + ### Countermeasure + Configure the **User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode** setting to **Prompt for consent**. + ### Potential impact + Administrators should be made aware that they will be prompted for consent when all binaries attempt to run. + ## Related topics -[Security Options](security-options.md) -  -  + +- [Security Options](security-options.md) diff --git a/windows/keep-secure/user-account-control-behavior-of-the-elevation-prompt-for-standard-users.md b/windows/keep-secure/user-account-control-behavior-of-the-elevation-prompt-for-standard-users.md index 727d8b7ba1..e382611db9 100644 --- a/windows/keep-secure/user-account-control-behavior-of-the-elevation-prompt-for-standard-users.md +++ b/windows/keep-secure/user-account-control-behavior-of-the-elevation-prompt-for-standard-users.md @@ -2,86 +2,88 @@ title: User Account Control Behavior of the elevation prompt for standard users (Windows 10) description: Describes the best practices, location, values, policy management and security considerations for the User Account Control Behavior of the elevation prompt for standard users security policy setting. ms.assetid: 1eae7def-8f6c-43b6-9474-23911fdc01ba -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # User Account Control: Behavior of the elevation prompt for standard users + **Applies to** - Windows 10 + Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Behavior of the elevation prompt for standard users** security policy setting. + ## Reference + This policy setting determines the behavior of the elevation prompt for standard users. + ### Possible values + - **Automatically deny elevation requests** + This option returns an “Access denied” error message to standard users when they try to perform an operation that requires elevation of privilege. Most organizations that run desktops as standard users configure this policy to reduce Help Desk calls. + - **Prompt for credentials on the secure desktop** + This is the default. 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. + - **Prompt for credentials** + An operation that requires elevation of privilege prompts the user to type an administrative user name and password. If the user enters valid credentials, the operation continues with the applicable privilege. + ### Best practices + 1. Configure the **User Account Control: Behavior of the elevation prompt for standard users** to **Automatically deny elevation requests**. This setting requires the user to log on with an administrative account to run programs that require elevation of privilege. 2. As a security best practice, standard users should not have knowledge of administrative passwords. However, if your users have both standard and administrator-level accounts, set **Prompt for credentials** so that the users do not choose to always log on with their administrator accounts, and they shift their behavior to use the standard user account. + ### Location + Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options + ### Default values + The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Server type or GPODefault value

Default Domain Policy

Not defined

Default Domain Controller Policy

Not defined

Stand-Alone Server Default Settings

Prompt for credentials on the secure desktop

DC Effective Default Settings

Prompt for credentials on the secure desktop

Member Server Effective Default Settings

Prompt for credentials on the secure desktop

Client Computer Effective Default Settings

Prompt for credentials on the secure desktop

+ +| Server type or GPO | Default value | +| - | - | +| Default Domain Policy | Not defined| +| Default Domain Controller Policy | Not defined| +| Stand-Alone Server Default Settings | Prompt for credentials on the secure desktop| +| DC Effective Default Settings | Prompt for credentials on the secure desktop| +| Member Server Effective Default Settings | Prompt for credentials on the secure desktop| +| Client Computer Effective Default Settings | Prompt for credentials on the secure desktop|   ## Policy management + This section describes features and tools that are available to help you manage this policy. + ### Restart requirement + None. Changes to this policy become effective without a computer restart when they are saved locally or distributed through Group Policy. + ### Group Policy + All auditing capabilities are integrated in Group Policy. You can configure, deploy, and manage these settings in the Group Policy Management Console (GPMC) or Local Security Policy snap-in for a domain, site, or organizational unit (OU). + ## Security considerations + This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. + ### Vulnerability + One of the risks that the UAC feature tries to mitigate is that of malicious programs running under elevated credentials without the user or administrator being aware of their activity. This setting raises awareness to the user that a program requires the use of elevated privilege operations, and it requires that the user supply administrative credentials for the program to run. + ### Countermeasure + Configure the **User Account Control: Behavior of the elevation prompt for standard users** to **Automatically deny elevation requests**. This setting requires the user to log on with an administrative account to run programs that require elevation of privilege. As a security best practice, standard users should not have knowledge of administrative passwords. However, if your users have both standard and administrator-level accounts, we recommend setting **Prompt for credentials** so that the users do not choose to always log on with their administrator accounts, and they shift their behavior to use the standard user account. + ### Potential impact + Users must provide administrative passwords to run programs with elevated privileges. This could cause an increased load on IT staff while the programs that are affected are identified and standard operating procedures are modified to support least privilege operations. + ## Related topics -[Security Options](security-options.md) -  -  + +- [Security Options](security-options.md) diff --git a/windows/keep-secure/user-account-control-detect-application-installations-and-prompt-for-elevation.md b/windows/keep-secure/user-account-control-detect-application-installations-and-prompt-for-elevation.md index 067ec3619c..178aa242b4 100644 --- a/windows/keep-secure/user-account-control-detect-application-installations-and-prompt-for-elevation.md +++ b/windows/keep-secure/user-account-control-detect-application-installations-and-prompt-for-elevation.md @@ -2,83 +2,81 @@ title: User Account Control Detect application installations and prompt for elevation (Windows 10) description: Describes the best practices, location, values, policy management and security considerations for the User Account Control Detect application installations and prompt for elevation security policy setting. ms.assetid: 3f8cb170-ba77-4c9f-abb3-c3ed1ef264fc -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # User Account Control: Detect application installations and prompt for elevation + **Applies to** - Windows 10 + Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Detect application installations and prompt for elevation** security policy setting. + ## Reference + This policy setting determines the behavior of application installation detection for the entire system. Some software might attempt to install itself after being given permission to run. The user may give permission for the program to run because the program is trusted. Then the user is prompted to install an unknown component. This security policy provides another way to identify and stop these attempted software installations before they can do damage. + ### Possible values + - **Enabled** + Application installation packages that require an elevation of privilege to install are detected and the user is prompted for administrative credentials. + - **Disabled** + Application installation packages that require an elevation of privilege to install are not detected and the user is not prompted for administrative credentials. + ### Best practices + 1. Installer detection is unnecessary when enterprises run standard user desktops that capitalize on delegated installation technologies like Group Policy Software Install (GPSI) or Configuration Manager. Therefore you can set this security policy to **Disabled**. 2. Enable the **User Account Control: Detect application installations and prompt for elevation** setting so standard users must provide administrative credentials before software is installed. + ### Location + Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options + ### Default values + The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Server type or GPODefault value

Default Domain Policy

Not defined

Default Domain Controller Policy

Not defined

Stand-Alone Server Default Settings

Enabled

DC Effective Default Settings

Enabled

Member Server Effective Default Settings

Enabled

Client Computer Effective Default Settings

Enabled

+ +| Server type or GPO | Default value | +| - | - | +| Default Domain Policy| Not defined| +| Default Domain Controller Policy | Not defined| +| Stand-Alone Server Default Settings | Enabled| +| DC Effective Default Settings | Enabled| +| Member Server Effective Default Settings| Enabled| +| Client Computer Effective Default Settings | Enabled|   ## Policy management + This section describes features and tools that are available to help you manage this policy. + ### Restart requirement + None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy. + ## Security considerations + This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. + ### Vulnerability + Some malicious software might attempt to install itself after being given permission to run, for example, malicious software with a trusted application shell. The user may give permission for the program to run because the program is trusted. Then the user is prompted to install an unknown component. This policy provides another way to trap the software before it can do damage. + ### Countermeasure + Enable the **User Account Control: Detect application installations and prompt for elevation** setting. + ### Potential impact + Users must provide administrative passwords to install programs. + ## Related topics -[Security Options](security-options.md) -  -  + +- [Security Options](security-options.md) diff --git a/windows/keep-secure/user-account-control-only-elevate-executables-that-are-signed-and-validated.md b/windows/keep-secure/user-account-control-only-elevate-executables-that-are-signed-and-validated.md index 7c3f3ccfae..19768449e0 100644 --- a/windows/keep-secure/user-account-control-only-elevate-executables-that-are-signed-and-validated.md +++ b/windows/keep-secure/user-account-control-only-elevate-executables-that-are-signed-and-validated.md @@ -2,87 +2,89 @@ title: User Account Control Only elevate executables that are signed and validated (Windows 10) description: Describes the best practices, location, values, policy management and security considerations for the User Account Control Only elevate executables that are signed and validated security policy setting. ms.assetid: 64950a95-6985-4db6-9905-1db18557352d -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # User Account Control: Only elevate executables that are signed and validated + **Applies to** - Windows 10 + Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Only elevate executables that are signed and validated** security policy setting. + ## Reference + This policy setting enforces public key infrastructure (PKI) signature checks on any interactive application that requests elevation of privilege. You can control the apps that are allowed to run through the population of certificates in the local computer's Trusted Publishers store. + A trusted publisher is a certificate issuer that the computer’s user has chosen to trust and that has certificate details that have been added to the store of trusted publishers. + Windows maintains certificates in certificate stores. These stores can be represented by containers in the file system or the registry, or they can be implemented as physical stores such as smart cards. Certificate stores are associated with the computer object or they are owned by a distinct user who has a security context and profile on that computer. In addition, services can have certificate stores. A certificate store will often contain numerous certificates, possibly issued from a number of different certification authorities (CAs). When certificate path discovery is initiated, Windows attempts to locate the issuing CA for the certificates, and it builds a certificate path to the trusted root certificate. Intermediate certificates are included as part of the application protocol or are picked up from Group Policy or through URLs that are specified in the Authority Information Access (AIA) extension. When the path is built, each certificate in the path is verified for validity with respect to various parameters, such as name, time, signature, revocation status, and other constraints. + ### Possible values + - **Enabled** + Enforces the PKI certificate chain validation of a given executable file before it is permitted to run. + - **Disabled** + Does not enforce PKI certificate chain validation before a given executable file is permitted to run. + ### Best practices + - Best practices are dependent on your security and performance goals. + ### Location + Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options + ### Default values + The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Server type or GPODefault value

Default Domain Policy

Not defined

Default Domain Controller Policy

Not defined

Stand-Alone Server Default Settings

Disabled

DC Effective Default Settings

Disabled

Member Server Effective Default Settings

Disabled

Client Computer Effective Default Settings

Disabled

+ +| Server type or GPO | Default value | +| - | - | +| Default Domain Policy| Not defined| +| Default Domain Controller Policy | Not defined| +| Stand-Alone Server Default Settings | Disabled| +| DC Effective Default Settings | Disabled| +| Member Server Effective Default Settings | Disabled| +| Client Computer Effective Default Settings | Disabled|   ## Policy management + This section describes features and tools that are available to help you manage this policy. + ### Restart requirement + None. Changes to this policy become effective without a computer restart when they are saved locally or distributed through Group Policy. + ### Group Policy + All auditing capabilities are integrated in Group Policy. You can configure, deploy, and manage these settings in the Group Policy Management Console (GPMC) or Local Security Policy snap-in for a domain, site, or organizational unit (OU). + ## Security considerations + This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. + ### Vulnerability + Intellectual property, personally identifiable information, and other confidential data are normally manipulated by applications on the computer, and elevated credentials are required to access the information. Users and administrators inherently trust applications that are used with these information sources, and they provide their credentials. If one of these applications is replaced by a rogue application that appears identical to the trusted application, the confidential data could be compromised and the user's administrative credentials would also be compromised. + ### Countermeasure + Enable the **User Account Control: Only elevate executables that are signed and validated**. + ### Potential impact + Enabling this setting requires that you have a PKI infrastructure and that your enterprise administrators have populated the Trusted Publishers store with the certificates for the allowed applications. Some older applications are not signed, and they cannot be used in an environment that is hardened with this setting. You should carefully test your applications in a preproduction environment before implementing this setting. Control over the applications that are installed on the desktops and the hardware that joins your domain should provide similar protection from the vulnerability that is addressed by this setting. Additionally, the level of protection that is provided by this setting is not an assurance that all rogue applications will be found. + ## Related topics -[Security Options](security-options.md) -  -  + +- [Security Options](security-options.md) diff --git a/windows/keep-secure/user-account-control-only-elevate-uiaccess-applications-that-are-installed-in-secure-locations.md b/windows/keep-secure/user-account-control-only-elevate-uiaccess-applications-that-are-installed-in-secure-locations.md index b79b29a94b..890ec0f2ff 100644 --- a/windows/keep-secure/user-account-control-only-elevate-uiaccess-applications-that-are-installed-in-secure-locations.md +++ b/windows/keep-secure/user-account-control-only-elevate-uiaccess-applications-that-are-installed-in-secure-locations.md @@ -2,103 +2,111 @@ title: User Account Control Only elevate UIAccess applications that are installed in secure locations (Windows 10) description: Describes the best practices, location, values, policy management and security considerations for the User Account Control Only elevate UIAccess applications that are installed in secure locations security policy setting. ms.assetid: 4333409e-a5be-4f2f-8808-618f53abd22c -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # User Account Control: Only elevate UIAccess applications that are installed in secure locations + **Applies to** - Windows 10 + Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Only elevate UIAccess applications that are installed in secure locations** security policy setting. + ## Reference + This policy setting enforces the requirement that apps that request running with a UIAccess integrity level (by means of a marking of UIAccess=true in their app manifest), must reside in a secure location on the file system. Relatively secure locations are limited to the following directories: + - \\Program Files\\ including subdirectories - \\Windows\\system32\\ - \\Program Files (x86)\\ including subdirectories for 64-bit versions of Windows -**Note**   -Windows enforces a PKI signature check on any interactive application that requests running with a UIAccess integrity level, regardless of the state of this security setting. + +>**Note:**  Windows enforces a PKI signature check on any interactive application that requests running with a UIAccess integrity level, regardless of the state of this security setting.   **Background** + User Interface Privilege Isolation (UIPI) implements restrictions in the Windows subsystem that prevent lower-privilege applications from sending messages or installing hooks in higher-privilege processes. Higher-privilege applications are permitted to send messages to lower-privilege processes. UIPI does not interfere with or change the behavior of messages between applications at the same privilege (or integrity) level. + Microsoft UI Automation is the current model to support accessibility requirements in the Windows operating systems. Applications that are designed to support an accessible user experience control the behavior of other Windows applications on behalf of the user. When all applications on the automation client computer and server are running as a standard user (that is, at a medium integrity level), the UIPI restrictions do not interfere with the Microsoft UI automation model. + However, there might be times when an administrative user runs an application with elevated privilege based on UAC in Admin Approval Mode. Microsoft UI Automation cannot drive the UI graphics of elevated applications on the desktop without the ability to bypass the restrictions that UIPI implements. The ability to bypass UIPI restrictions across privilege levels is available for UI automation programs by using UIAccess. + If an application presents a UIAccess attribute when it requests privileges, the application is stating a requirement to bypass UIPI restrictions for sending messages across privilege levels. Devices implement the following policy checks before starting an application with UIAccess privilege. + 1. The application must have a digital signature that can be verified by using a digital certificate that is associated with the Trusted Root Certification Authorities store on the local device 2. The application must be installed in a local folder that is writeable only by administrators, such as the Program Files directory. The allowed directories for UI automation applications are: + 1. %ProgramFiles% and its subdirectories. 2. %WinDir% and its subdirectories, except a few subdirectories that are excluded because standard users have write access. + ### Possible values + - **Enabled** + An application can start with UIAccess integrity only if it resides in a secure location in the file system. + - **Disabled** + An application can start with UIAccess integrity even if it does not reside in a secure location in the file system. + ### Best practices + - Set this policy to **Enabled** to permit applications that are located in one of the designated secure directories to run with UIAccess integrity. + ### Location + Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options + ### Default values + The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Server type or GPODefault value

Default Domain Policy

Not defined

Default Domain Controller Policy

Not defined

Stand-Alone Server Default Settings

Enabled

DC Effective Default Settings

Enabled

Member Server Effective Default Settings

Enabled

Client Computer Effective Default Settings

Enabled

+ +| Server type or GPO | Default value | +| - | - | +| Default Domain Policy| Not defined| +| Default Domain Controller Policy | Not defined| +| Stand-Alone Server Default Settings | Enabled| +| DC Effective Default Settings | Enabled| +| Member Server Effective Default Settings| Enabled| +| Client Computer Effective Default Settings | Enabled|   ## Policy management + This section describes features and tools that are available to help you manage this policy. + ### Restart requirement + None. Changes to this policy become effective without a device restart when they aresaved locally or distributed through Group Policy. + ### Group Policy + All auditing capabilities are integrated in Group Policy. You can configure, deploy, and manage these settings in the Group Policy Management Console (GPMC) or Local Security Policy snap-in for a domain, site, or organizational unit (OU). + ## Security considerations + This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. + ### Vulnerability + UIAccess integrity allows an application to bypass User Interface Privilege Isolation (UIPI) restrictions when an application is elevated in privilege from a standard user to an administrator. When this setting is enabled, an application that has the UIAccess flag set to true in its manifest can interchange information with applications that are running at a higher privilege level, such as logon prompts and privilege elevation prompts. This ability is required to support accessibility features such as screen readers that are transmitting user interfaces to alternative forms, but it is not required by most applications. A process that is started with UIAccess rights has the following abilities: + - Set the foreground window. - Drive any application window by using the SendInput function. - Use read input for all integrity levels by using low-level hooks, raw input, GetKeyState, GetAsyncKeyState, and GetKeyboardInput. - Set journal hooks. - Use AttachThreadInput to attach a thread to a higher integrity input queue. + ### Countermeasure + Enable the **User Account Control: Only elevate UIAccess applications that are installed in secure locations** setting. + ### Potential impact + If the application that requests UIAccess meets the UIAccess setting requirements, computers running at least the Windows Vista operating system start the application with the ability to bypass most of the UIPI restrictions. If the application does not meet the security restrictions, the application is started without UIAccess rights, and it can interact only with applications at the same or lower privilege level. + ## Related topics -[Security Options](security-options.md) -  -  + +- [Security Options](security-options.md) diff --git a/windows/keep-secure/user-account-control-run-all-administrators-in-admin-approval-mode.md b/windows/keep-secure/user-account-control-run-all-administrators-in-admin-approval-mode.md index 0c53ba8b97..63ac1e4a65 100644 --- a/windows/keep-secure/user-account-control-run-all-administrators-in-admin-approval-mode.md +++ b/windows/keep-secure/user-account-control-run-all-administrators-in-admin-approval-mode.md @@ -2,86 +2,85 @@ title: User Account Control Run all administrators in Admin Approval Mode (Windows 10) description: Describes the best practices, location, values, policy management and security considerations for the User Account Control Run all administrators in Admin Approval Mode security policy setting. ms.assetid: b838c561-7bfc-41ef-a7a5-55857259c7bf -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # User Account Control: Run all administrators in Admin Approval Mode + **Applies to** - Windows 10 + Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Run all administrators in Admin Approval Mode** security policy setting. + ## Reference + This policy setting determines the behavior of all User Account Control (UAC) policies for the entire system. This is the setting that turns UAC on or off. + ### Possible values + - **Enabled** + Admin Approval Mode and all other UAC policies are dependent on this option being enabled. Changing this setting requires restarting the system. + - **Disabled** + Admin Approval Mode and all related UAC policies are disabled. - **Note**   - If this security setting is configured to **Disabled**, the Security Center notifies the user that the overall security of the operating system has been reduced. + + >**Note:**  If this security setting is configured to **Disabled**, the Security Center notifies the user that the overall security of the operating system has been reduced.   ### Best practices + - Enable this policy to allow all other UAC features and policies to function. + ### Location + Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options + ### Default values + The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Server type or GPODefault value

Default Domain Policy

Not defined

Default Domain Controller Policy

Not defined

Stand-Alone Server Default Settings

Enabled

DC Effective Default Settings

Enabled

Member Server Effective Default Settings

Enabled

Client Computer Effective Default Settings

Enabled

+ +| Server type or GPO | Default value | +| - | - | +| Default Domain Policy| Not defined| +| Default Domain Controller Policy | Not defined| +| Stand-Alone Server Default Settings | Enabled| +| DC Effective Default Settings | Enabled| +| Member Server Effective Default Settings| Enabled| +| Client Computer Effective Default Settings | Enabled|   ## Policy management + This section describes features and tools that are available to help you manage this policy. + ### Restart requirement + A restart of the computer is required before this policy will be effective when changes to this policy are saved locally or distributed through Group Policy. + ### Group Policy + All auditing capabilities are integrated in Group Policy. You can configure, deploy, and manage these settings in the Group Policy Management Console (GPMC) or Local Security Policy snap-in for a domain, site, or organizational unit (OU). + ## Security considerations + This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. + ### Vulnerability + This is the setting that turns UAC on or off. If this setting is disabled, UAC is not used, and any security benefits and risk mitigations that are dependent on UAC are not present on the computer. + ### Countermeasure + Enable the **User Account Control: Run all users, including administrators, as standard users** setting. + ### Potential impact + Users and administrators must learn to work with UAC prompts and adjust their work habits to use least privilege operations. + ## Related topics -[Security Options](security-options.md) -  -  + +- [Security Options](security-options.md) diff --git a/windows/keep-secure/user-account-control-security-policy-settings.md b/windows/keep-secure/user-account-control-security-policy-settings.md index d1a286bf5e..569bf9892e 100644 --- a/windows/keep-secure/user-account-control-security-policy-settings.md +++ b/windows/keep-secure/user-account-control-security-policy-settings.md @@ -2,66 +2,95 @@ title: User Account Control security policy settings (Windows 10) description: You can use security policies to configure how User Account Control works in your organization. They 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. ms.assetid: 3D75A9AC-69BB-4EF2-ACB3-1769791E1B98 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: operate ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # User Account Control security policy settings + **Applies to** - Windows 10 + You can use security policies to configure how User Account Control works in your organization. They 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. + ## User Account Control: Admin Approval Mode for the Built-in Administrator account + This policy setting controls the behavior of Admin Approval Mode for the built-in Administrator account. + - **Enabled** The built-in Administrator account uses Admin Approval Mode. By default, any operation that requires elevation of privilege will prompt the user to approve the operation. - **Disabled** (Default) The built-in Administrator account runs all applications with full administrative privilege. + ## User Account Control: Allow UIAccess application to prompt for elevation without using the secure desktop + This policy setting controls whether User Interface Accessibility (UIAccess or UIA) programs can automatically disable the secure desktop for elevation prompts used by a standard user. + - **Enabled** UIA programs, including Windows Remote Assistance, automatically disable the secure desktop for elevation prompts. If you do not disable the "User Account Control: 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. - **Disabled** (Default) The secure desktop can be disabled only by the user of the interactive desktop or by disabling the "User Account Control: Switch to the secure desktop when prompting for elevation" policy setting. + ## User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode + This policy setting controls the behavior of the elevation prompt for administrators. + - **Elevate without prompting** Allows privileged accounts to perform an operation that requires elevation without requiring consent or credentials. - **Note**  Use this option only in the most constrained environments. + + >**Note:**  Use this option only in the most constrained environments.   - **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. - **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. - **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. - **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. - **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. + ## User Account Control: Behavior of the elevation prompt for standard users + This policy setting controls the behavior of the elevation prompt for standard users. + - **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. - **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. - **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. + ## User Account Control: Detect application installations and prompt for elevation + This policy setting controls the behavior of application installation detection for the computer. + - **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. - - **Disabled** App installation packages are not detected and prompted for elevation. Enterprises that are running standard user desktops and use delegated installation technologies, such as Group Policy or System Center Configuration Manager should disable this policy setting. In this case, installer detection is unnecessary. + ## User Account Control: Only elevate executable files that are signed and validated + This policy setting enforces public key infrastructure (PKI) signature checks for any interactive applications that request elevation of privilege. Enterprise administrators can control which applications are allowed to run by adding certificates to the Trusted Publishers certificate store on local computers. + - **Enabled** Enforces the certificate certification path validation for a given executable file before it is permitted to run. - **Disabled** (Default) Does not enforce the certificate certification path validation before a given executable file is permitted to run. + ## User Account Control: Only elevate UIAccess applications that are installed in secure locations + This policy setting 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: - …\\Program Files\\, including subfolders - …\\Windows\\system32\\ - …\\Program Files (x86)\\, including subfolders for 64-bit versions of Windows -**Note**   -Windows enforces a digital signature check on any interactive app that requests to run with a UIAccess integrity level regardless of the state of this security setting. + +>**Note:**  Windows enforces a digital signature check on any interactive app that requests to run with a UIAccess integrity level regardless of the state of this security setting.   - **Enabled** (Default) If an app resides in a secure location in the file system, it runs only with UIAccess integrity. - **Disabled** An app runs with UIAccess integrity even if it does not reside in a secure location in the file system. + ## User Account Control: Turn on Admin Approval Mode + This policy setting controls the behavior of all User Account Control (UAC) policy settings for the computer. If you change this policy setting, you must restart your computer. + - **Enabled** (Default) Admin Approval Mode is enabled. This policy must be enabled and related UAC policy settings must also be set appropriately to allow the built-in Administrator account and all other users who are members of the Administrators group to run in Admin Approval Mode. - **Disabled** Admin Approval Mode and all related UAC policy settings are disabled. Note: If this policy setting is disabled, the Security Center notifies you that the overall security of the operating system has been reduced. + ## User Account Control: 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. + - **Enabled** (Default) All elevation requests go to the secure desktop regardless of prompt behavior policy settings for administrators and standard users. - **Disabled** All elevation requests go to the interactive user's desktop. Prompt behavior policy settings for administrators and standard users are used. ## User Account Control: Virtualize file and registry write failures to per-user locations + This policy setting controls whether application write failures are redirected to defined registry and file system locations. This policy setting mitigates applications that run as administrator and write run-time application data to %ProgramFiles%, %Windir%, %Windir%\\system32, or HKLM\\Software. + - **Enabled** (Default) App write failures are redirected at run time to defined user locations for both the file system and registry. - **Disabled** Apps that write data to protected locations fail. -  -  diff --git a/windows/keep-secure/user-account-control-switch-to-the-secure-desktop-when-prompting-for-elevation.md b/windows/keep-secure/user-account-control-switch-to-the-secure-desktop-when-prompting-for-elevation.md index 9475c83eba..ee510bb52e 100644 --- a/windows/keep-secure/user-account-control-switch-to-the-secure-desktop-when-prompting-for-elevation.md +++ b/windows/keep-secure/user-account-control-switch-to-the-secure-desktop-when-prompting-for-elevation.md @@ -2,85 +2,88 @@ title: User Account Control Switch to the secure desktop when prompting for elevation (Windows 10) description: Describes the best practices, location, values, policy management and security considerations for the User Account Control Switch to the secure desktop when prompting for elevation security policy setting. ms.assetid: 77a067db-c70d-4b02-9861-027503311b8b -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # User Account Control: Switch to the secure desktop when prompting for elevation + **Applies to** - Windows 10 + Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Switch to the secure desktop when prompting for elevation** security policy setting. + ## Reference + This policy setting determines whether the elevation request prompts on the interactive user desktop or on the secure desktop. + The secure desktop presents the logon UI and restricts functionality and access to the system until the logon requirements are satisfied. + The secure desktop’s primary difference from the user desktop is that only trusted processes running as SYSTEM are allowed to run here (that is, nothing is running at the user’s privilege level). The path to get to the secure desktop from the user desktop must also be trusted through the entire chain. + ### Possible values + - **Enabled** + All elevation requests by default go to the secure desktop. + - **Disabled** + All elevation requests go to the interactive user desktop. + ### Best practices -- Enable the **User Account Control: Switch to the secure desktop when prompting for elevation setting**. The secure desktop helps protect against input and output spoofing by presenting the credentials dialog box in a protected section of memory that is accessible only by trusted system processes. + +- Enable the **User Account Control: Switch to the secure desktop when prompting for elevation setting**. The secure desktop helps protect against input and output spoofing by presenting the credentials dialog box in a protected section of memory that is accessible only by trusted system +processes. + ### Location + Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options + ### Default values + The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Server type or GPODefault value

Default Domain Policy

Not defined

Default Domain Controller Policy

Not defined

Stand-Alone Server Default Settings

Enabled

DC Effective Default Settings

Enabled

Member Server Effective Default Settings

Enabled

Client Computer Effective Default Settings

Enabled

+ +| Server type or GPO | Default value | +| - | - | +| Default Domain Policy| Not defined| +| Default Domain Controller Policy | Not defined| +| Stand-Alone Server Default Settings | Enabled| +| DC Effective Default Settings | Enabled| +| Member Server Effective Default Settings| Enabled| +| Client Computer Effective Default Settings | Enabled|   ## Policy management + This section describes features and tools that are available to help you manage this policy. + ### Restart requirement + None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy. + ### Group Policy + All auditing capabilities are integrated in Group Policy. You can configure, deploy, and manage these settings in the Group Policy Management Console (GPMC) or Local Security Policy snap-in for a domain, site, or organizational unit (OU). + ## Security considerations + This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. + ### Vulnerability + Elevation prompt dialog boxes can be spoofed, causing users to disclose their passwords to malicious software. Mouse cursors can be spoofed by hiding the real cursor and replacing it with an offset so the cursor is actually pointing to the **Allow** button. + ### Countermeasure + Enable the **User Account Control: Switch to the secure desktop when prompting for elevation setting**. The secure desktop helps protect against input and output spoofing by presenting the credentials dialog box in a protected section of memory that is accessible only by trusted system processes. + ### Potential impact + None. This is the default configuration. + ## Related topics -[Security Options](security-options.md) -  -  + +- [Security Options](security-options.md) diff --git a/windows/keep-secure/user-account-control-virtualize-file-and-registry-write-failures-to-per-user-locations.md b/windows/keep-secure/user-account-control-virtualize-file-and-registry-write-failures-to-per-user-locations.md index ffb892226b..afc3766b73 100644 --- a/windows/keep-secure/user-account-control-virtualize-file-and-registry-write-failures-to-per-user-locations.md +++ b/windows/keep-secure/user-account-control-virtualize-file-and-registry-write-failures-to-per-user-locations.md @@ -2,85 +2,86 @@ title: User Account Control Virtualize file and registry write failures to per-user locations (Windows 10) description: Describes the best practices, location, values, policy management and security considerations for the User Account Control Virtualize file and registry write failures to per-user locations security policy setting. ms.assetid: a7b47420-cc41-4b1c-b03e-f67a05221261 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # User Account Control: Virtualize file and registry write failures to per-user locations + **Applies to** - Windows 10 + Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Virtualize file and registry write failures to per-user locations** security policy setting. + ## Reference + This policy setting enables or disables the redirection of the write failures of earlier applications to defined locations in the registry and the file system. This feature mitigates applications that historically ran as administrator and wrote runtime application data to %ProgramFiles%, %Windir%, %Windir%\\system32, or HKEY\_LOCAL\_MACHINE\\Software\\. + This feature can be disabled for applications on devices running at least Windows Vista because it is unnecessary. + ### Possible values + - **Enabled** + Setting this value facilitates the runtime redirection of application write failures to defined user locations for the file system and the registry. + - **Disabled** + Applications that write data to protected locations fail. + ### Best practices + 1. If you run applications that are not Windows Vista-compliant, enable this security policy to prevent the possibility that these older applications could write data to unsecure locations. 2. If you only run at least Windows Vista–compliant applications, this feature is unnecessary so you can disable this policy. + ### Location + \\Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options + ### Default values + The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Server type or GPODefault value

Default Domain Policy

Not defined

Default Domain Controller Policy

Not defined

Stand-Alone Server Default Settings

Enabled

DC Effective Default Settings

Enabled

Member Server Effective Default Settings

Enabled

Client Computer Effective Default Settings

Enabled

+ +| Server type or GPO | Default value| +| - | - | +| Default Domain Policy| Not defined| +| Default Domain Controller Policy | Not defined| +| Stand-Alone Server Default Settings | Enabled| +| DC Effective Default Settings | Enabled| +| Member Server Effective Default Settings| Enabled| +| Client Computer Effective Default Settings | Enabled|   ## Policy management + This section describes features and tools that are available to help you manage this policy. + ### Restart requirement + None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy. + ### Group Policy + All auditing capabilities are integrated in Group Policy. You can configure, deploy, and manage these settings in the Group Policy Management Console (GPMC) or Local Security Policy snap-in for a domain, site, or organizational unit (OU). + ## Security considerations + This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. + ### Vulnerability + Earlier applications might not write data to secure locations. + ### Countermeasure + Enable the **User Account Control: Virtualize file and registry write failures to per-user locations** setting. + ### Potential impact + None. This is the default configuration. + ## Related topics -[Security Options](security-options.md) -  -  + +- [Security Options](security-options.md) diff --git a/windows/keep-secure/user-rights-assignment.md b/windows/keep-secure/user-rights-assignment.md index 3e96944b76..401613dde1 100644 --- a/windows/keep-secure/user-rights-assignment.md +++ b/windows/keep-secure/user-rights-assignment.md @@ -2,212 +2,75 @@ title: User Rights Assignment (Windows 10) description: Provides an overview and links to information about the User Rights Assignment security policy settings user rights that are available in Windows. ms.assetid: 99340252-60be-4c79-b0a5-56fbe1a9b0c5 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # User Rights Assignment + **Applies to** - Windows 10 + Provides an overview and links to information about the User Rights Assignment security policy settings user rights that are available in Windows. User rights govern the methods by which a user can log on to a system. User rights are applied at the local device level, and they allow users to perform tasks on a device or in a domain. User rights include logon rights and permissions. Logon rights control who is authorized to log on to a device and how they can log on. User rights permissions control access to computer and domain resources, and they can override permissions that have been set on specific objects. User rights are managed in Group Policy under the **User Rights Assignment** item. -Each user right has a constant name and a Group Policy name associated with it. The constant names are used when referring to the user right in log events. You can configure the user rights assignment settings in the following location within the Group Policy Management Console (GPMC) under **Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment**, or on the local device by using the Local Group Policy Editor (gpedit.msc). + +Each user right has a constant name and a Group Policy name associated with it. The constant names are used when referring to the user right in log events. You can configure the user rights assignment settings in the following location within the Group Policy Management Console (GPMC) under +**Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment**, or on the local device by using the Local Group Policy Editor (gpedit.msc). + For information about setting security policies, see [Configure security policy settings](how-to-configure-security-policy-settings.md). + The following table links to each security policy setting and provides the constant name for each. Setting descriptions contain reference information, best practices for configuring the policy setting, default values, differences between operating system versions, and considerations for policy management and security. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Group Policy SettingConstant Name

[Access Credential Manager as a trusted caller](access-credential-manager-as-a-trusted-caller.md)

SeTrustedCredManAccessPrivilege

[Access this computer from the network](access-this-computer-from-the-network.md)

SeNetworkLogonRight

[Act as part of the operating system](act-as-part-of-the-operating-system.md)

SeTcbPrivilege

[Add workstations to domain](add-workstations-to-domain.md)

SeMachineAccountPrivilege

[Adjust memory quotas for a process](adjust-memory-quotas-for-a-process.md)

SeIncreaseQuotaPrivilege

[Allow log on locally](allow-log-on-locally.md)

SeInteractiveLogonRight

[Allow log on through Remote Desktop Services](allow-log-on-through-remote-desktop-services.md)

SeRemoteInteractiveLogonRight

[Back up files and directories](back-up-files-and-directories.md)

SeBackupPrivilege

[Bypass traverse checking](bypass-traverse-checking.md)

SeChangeNotifyPrivilege

[Change the system time](change-the-system-time.md)

SeSystemtimePrivilege

[Change the time zone](change-the-time-zone.md)

SeTimeZonePrivilege

[Create a pagefile](create-a-pagefile.md)

SeCreatePagefilePrivilege

[Create a token object](create-a-token-object.md)

SeCreateTokenPrivilege

[Create global objects](create-global-objects.md)

SeCreateGlobalPrivilege

[Create permanent shared objects](create-permanent-shared-objects.md)

SeCreatePermanentPrivilege

[Create symbolic links](create-symbolic-links.md)

SeCreateSymbolicLinkPrivilege

[Debug programs](debug-programs.md)

SeDebugPrivilege

[Deny access to this computer from the network](deny-access-to-this-computer-from-the-network.md)

SeDenyNetworkLogonRight

[Deny log on as a batch job](deny-log-on-as-a-batch-job.md)

SeDenyBatchLogonRight

[Deny log on as a service](deny-log-on-as-a-service.md)

SeDenyServiceLogonRight

[Deny log on locally](deny-log-on-locally.md)

SeDenyInteractiveLogonRight

[Deny log on through Remote Desktop Services](deny-log-on-through-remote-desktop-services.md)

SeDenyRemoteInteractiveLogonRight

[Enable computer and user accounts to be trusted for delegation](enable-computer-and-user-accounts-to-be-trusted-for-delegation.md)

SeEnableDelegationPrivilege

[Force shutdown from a remote system](force-shutdown-from-a-remote-system.md)

SeRemoteShutdownPrivilege

[Generate security audits](generate-security-audits.md)

SeAuditPrivilege

[Impersonate a client after authentication](impersonate-a-client-after-authentication.md)

SeImpersonatePrivilege

[Increase a process working set](increase-a-process-working-set.md)

SeIncreaseWorkingSetPrivilege

[Increase scheduling priority](increase-scheduling-priority.md)

SeIncreaseBasePriorityPrivilege

[Load and unload device drivers](load-and-unload-device-drivers.md)

SeLoadDriverPrivilege

[Lock pages in memory](lock-pages-in-memory.md)

SeLockMemoryPrivilege

[Log on as a batch job](log-on-as-a-batch-job.md)

SeBatchLogonRight

[Log on as a service](log-on-as-a-service.md)

SeServiceLogonRight

[Manage auditing and security log](manage-auditing-and-security-log.md)

SeSecurityPrivilege

[Modify an object label](modify-an-object-label.md)

SeRelabelPrivilege

[Modify firmware environment values](modify-firmware-environment-values.md)

SeSystemEnvironmentPrivilege

[Perform volume maintenance tasks](perform-volume-maintenance-tasks.md)

SeManageVolumePrivilege

[Profile single process](profile-single-process.md)

SeProfileSingleProcessPrivilege

[Profile system performance](profile-system-performance.md)

SeSystemProfilePrivilege

[Remove computer from docking station](remove-computer-from-docking-station.md)

SeUndockPrivilege

[Replace a process level token](replace-a-process-level-token.md)

SeAssignPrimaryTokenPrivilege

[Restore files and directories](restore-files-and-directories.md)

SeRestorePrivilege

[Shut down the system](shut-down-the-system.md)

SeShutdownPrivilege

[Synchronize directory service data](synchronize-directory-service-data.md)

SeSyncAgentPrivilege

[Take ownership of files or other objects](take-ownership-of-files-or-other-objects.md)

SeTakeOwnershipPrivilege

+ +| Group Policy Setting | Constant Name | +| - | - | +| [Access Credential Manager as a trusted caller](access-credential-manager-as-a-trusted-caller.md) | SeTrustedCredManAccessPrivilege| +| [Access this computer from the network](access-this-computer-from-the-network.md) | SeNetworkLogonRight| +| [Act as part of the operating system](act-as-part-of-the-operating-system.md) | SeTcbPrivilege| +| [Add workstations to domain](add-workstations-to-domain.md) | SeMachineAccountPrivilege| +| [Adjust memory quotas for a process](adjust-memory-quotas-for-a-process.md) | SeIncreaseQuotaPrivilege| +| [Allow log on locally](allow-log-on-locally.md) | SeInteractiveLogonRight| +| [Allow log on through Remote Desktop Services](allow-log-on-through-remote-desktop-services.md)| SeRemoteInteractiveLogonRight| +| [Back up files and directories](back-up-files-and-directories.md) | SeBackupPrivilege| +| [Bypass traverse checking](bypass-traverse-checking.md) | SeChangeNotifyPrivilege| +| [Change the system time](change-the-system-time.md) | SeSystemtimePrivilege| +| [Change the time zone](change-the-time-zone.md) | SeTimeZonePrivilege| +| [Create a pagefile](create-a-pagefile.md) | SeCreatePagefilePrivilege| +| [Create a token object](create-a-token-object.md) | SeCreateTokenPrivilege| +| [Create global objects](create-global-objects.md) | SeCreateGlobalPrivilege| +| [Create permanent shared objects](create-permanent-shared-objects.md) | SeCreatePermanentPrivilege| +| [Create symbolic links](create-symbolic-links.md) | SeCreateSymbolicLinkPrivilege| +| [Debug programs](debug-programs.md) | SeDebugPrivilege| +| [Deny access to this computer from the network](deny-access-to-this-computer-from-the-network.md)| SeDenyNetworkLogonRight | +| [Deny log on as a batch job](deny-log-on-as-a-batch-job.md) | SeDenyBatchLogonRight| +| [Deny log on as a service](deny-log-on-as-a-service.md) | SeDenyServiceLogonRight | +| [Deny log on locally](deny-log-on-locally.md) | SeDenyInteractiveLogonRight| +| [Deny log on through Remote Desktop Services](deny-log-on-through-remote-desktop-services.md)| SeDenyRemoteInteractiveLogonRight| +| [Enable computer and user accounts to be trusted for delegation](enable-computer-and-user-accounts-to-be-trusted-for-delegation.md)| SeEnableDelegationPrivilege| +| [Force shutdown from a remote system](force-shutdown-from-a-remote-system.md) | SeRemoteShutdownPrivilege| +| [Generate security audits](generate-security-audits.md) | SeAuditPrivilege| +| [Impersonate a client after authentication](impersonate-a-client-after-authentication.md)| SeImpersonatePrivilege| +| [Increase a process working set](increase-a-process-working-set.md) | SeIncreaseWorkingSetPrivilege| +| [Increase scheduling priority](increase-scheduling-priority.md) | SeIncreaseBasePriorityPrivilege| +| [Load and unload device drivers](load-and-unload-device-drivers.md) | SeLoadDriverPrivilege| +| [Lock pages in memory](lock-pages-in-memory.md) | SeLockMemoryPrivilege| +| [Log on as a batch job](log-on-as-a-batch-job.md) | SeBatchLogonRight| +| [Log on as a service](log-on-as-a-service.md) | SeServiceLogonRight| +| [Manage auditing and security log](manage-auditing-and-security-log.md)| SeSecurityPrivilege| +| [Modify an object label](modify-an-object-label.md) | SeRelabelPrivilege| +| [Modify firmware environment values](modify-firmware-environment-values.md)| SeSystemEnvironmentPrivilege| +| [Perform volume maintenance tasks](perform-volume-maintenance-tasks.md) | SeManageVolumePrivilege| +| [Profile single process](profile-single-process.md) | SeProfileSingleProcessPrivilege| +| [Profile system performance](profile-system-performance.md) | SeSystemProfilePrivilege| +| [Remove computer from docking station](remove-computer-from-docking-station.md) | SeUndockPrivilege| +| [Replace a process level token](replace-a-process-level-token.md) | SeAssignPrimaryTokenPrivilege| +| [Restore files and directories](restore-files-and-directories.md) | SeRestorePrivilege | +| [Shut down the system](shut-down-the-system.md) | SeShutdownPrivilege| +| [Synchronize directory service data](synchronize-directory-service-data.md)| SeSyncAgentPrivilege| +| [Take ownership of files or other objects](take-ownership-of-files-or-other-objects.md) | SeTakeOwnershipPrivilege|   ## Related topics -[Security policy settings reference](security-policy-settings-reference.md) -  -  + +- [Security policy settings reference](security-policy-settings-reference.md) diff --git a/windows/keep-secure/using-advanced-security-auditing-options-to-monitor-dynamic-access-control-objects.md b/windows/keep-secure/using-advanced-security-auditing-options-to-monitor-dynamic-access-control-objects.md index fe7a396637..13d5fc93e5 100644 --- a/windows/keep-secure/using-advanced-security-auditing-options-to-monitor-dynamic-access-control-objects.md +++ b/windows/keep-secure/using-advanced-security-auditing-options-to-monitor-dynamic-access-control-objects.md @@ -2,71 +2,41 @@ title: Using advanced security auditing options to monitor dynamic access control objects (Windows 10) description: This guide explains the process of setting up advanced security auditing capabilities that are made possible through settings and events that were introduced in Windows 8 and Windows Server 2012. ms.assetid: 0d2c28ea-bdaf-47fd-bca2-a07dce5fed37 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Using advanced security auditing options to monitor dynamic access control objects + **Applies to** - Windows 10 + This guide explains the process of setting up advanced security auditing capabilities that are made possible through settings and events that were introduced in Windows 8 and Windows Server 2012. + These procedures can be deployed with the advanced security auditing capabilities described in [Deploy Security Auditing with Central Audit Policies (Demonstration Steps)](http://technet.microsoft.com/library/hh831542.aspx). + ## In this guide + Domain administrators can create and deploy expression-based security audit policies by using file classification information (resource attributes), user claims, and device claims to target specific users and resources to monitor potentially significant activities on one or more computers. These policies can be deployed centrally by using Group Policy, or directly on a computer, in a folder, or in individual files. + ## In this section - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
TopicDescription

[Monitor the central access policies that apply on a file server](monitor-the-central-access-policies-that-apply-on-a-file-server.md)

This topic for the IT professional describes how to monitor changes to the central access policies that apply to a file server when using advanced security auditing options to monitor dynamic access control objects. Central access policies are created on a domain controller and then applied to file servers through Group Policy management.

[Monitor the use of removable storage devices](monitor-the-use-of-removable-storage-devices.md)

This topic for the IT professional describes how to monitor attempts to use removable storage devices to access network resources. It describes how to use advanced security auditing options to monitor dynamic access control objects.

[Monitor resource attribute definitions](monitor-resource-attribute-definitions.md)

This topic for the IT professional describes how to monitor changes to resource attribute definitions when you are using advanced security auditing options to monitor dynamic access control objects.

[Monitor central access policy and rule definitions](monitor-central-access-policy-and-rule-definitions.md)

This topic for the IT professional describes how to monitor changes to central access policy and central access rule definitions when you use advanced security auditing options to monitor dynamic access control objects.

[Monitor user and device claims during sign-in](monitor-user-and-device-claims-during-sign-in.md)

This topic for the IT professional describes how to monitor user and device claims that are associated with a user’s security token when you are using advanced security auditing options to monitor dynamic access control objects.

[Monitor the resource attributes on files and folders](monitor-the-resource-attributes-on-files-and-folders.md)

This topic for the IT professional describes how to monitor attempts to change settings to the resource attributes on files when you are using advanced security auditing options to monitor dynamic access control objects.

[Monitor the central access policies associated with files and folders](monitor-the-central-access-policies-associated-with-files-and-folders.md)

This topic for the IT professional describes how to monitor changes to the central access policies that are associated with files and folders when you are using advanced security auditing options to monitor dynamic access control objects.

[Monitor claim types](monitor-claim-types.md)

This topic for the IT professional describes how to monitor changes to claim types that are associated with dynamic access control when you are using advanced security auditing options.

+ +| Topic | Description | +| - | - | +| [Monitor the central access policies that apply on a file server](monitor-the-central-access-policies-that-apply-on-a-file-server.md) | This topic for the IT professional describes how to monitor changes to the central access policies that apply to a file server when using advanced security auditing options to monitor dynamic access control objects. Central access policies are created on a domain controller and then applied to file servers through Group Policy management. | +| [Monitor the use of removable storage devices](monitor-the-use-of-removable-storage-devices.md) | This topic for the IT professional describes how to monitor attempts to use removable storage devices to access network resources. It describes how to use advanced security auditing options to monitor dynamic access control objects. | +| [Monitor resource attribute definitions](monitor-resource-attribute-definitions.md)| This topic for the IT professional describes how to monitor changes to resource attribute definitions when you are using advanced security auditing options to monitor dynamic access control objects.| +| [Monitor central access policy and rule definitions](monitor-central-access-policy-and-rule-definitions.md) | This topic for the IT professional describes how to monitor changes to central access policy and central access rule definitions when you use advanced security auditing options to monitor dynamic access control objects. | +| [Monitor user and device claims during sign-in](monitor-user-and-device-claims-during-sign-in.md)| This topic for the IT professional describes how to monitor user and device claims that are associated with a user’s security token when you are using advanced security auditing options to monitor dynamic access control objects. | +| [Monitor the resource attributes on files and folders](monitor-the-resource-attributes-on-files-and-folders.md)| This topic for the IT professional describes how to monitor attempts to change settings to the resource attributes on files when you are using advanced security auditing options to monitor dynamic access control objects. | +| [Monitor the central access policies associated with files and folders](monitor-the-central-access-policies-associated-with-files-and-folders.md)| This topic for the IT professional describes how to monitor changes to the central access policies that are associated with files and folders when you are using advanced security auditing options to monitor dynamic access control objects. | +| [Monitor claim types](monitor-claim-types.md) | This topic for the IT professional describes how to monitor changes to claim types that are associated with dynamic access control when you are using advanced security auditing options.|   -**Important**   -This procedure can be configured on computers running any of the supported Windows operating systems. The other monitoring procedures can be configured only as part of a functioning dynamic access control deployment. +>**Important:**  This procedure can be configured on computers running any of the supported Windows operating systems. The other monitoring procedures can be configured only as part of a functioning dynamic access control deployment.   ## Related topics -[Security auditing](security-auditing-overview.md) -  -  + +- [Security auditing](security-auditing-overview.md) diff --git a/windows/keep-secure/using-event-viewer-with-applocker.md b/windows/keep-secure/using-event-viewer-with-applocker.md index 304915e207..dcee6821bc 100644 --- a/windows/keep-secure/using-event-viewer-with-applocker.md +++ b/windows/keep-secure/using-event-viewer-with-applocker.md @@ -2,145 +2,61 @@ title: Using Event Viewer with AppLocker (Windows 10) description: This topic lists AppLocker events and describes how to use Event Viewer with AppLocker. ms.assetid: 109abb10-78b1-4c29-a576-e5a17dfeb916 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Using Event Viewer with AppLocker + **Applies to** - Windows 10 + This topic lists AppLocker events and describes how to use Event Viewer with AppLocker. + The AppLocker log contains information about applications that are affected by AppLocker rules. Each event in the log contains detailed info about: + - Which file is affected and the path of that file - Which packaged app is affected and the package identifier of the app - Whether the file or packaged app is allowed or blocked - The rule type (path, file hash, or publisher) - The rule name - The security identifier (SID) for the user or group identified in the rule + Review the entries in the Event Viewer to determine if any applications are not included in the rules that you automatically generated. For instance, some line-of-business apps are installed to non-standard locations, such as the root of the active drive (for example: %SystemDrive%). + For info about what to look for in the AppLocker event logs, see [Monitor app usage with AppLocker](monitor-application-usage-with-applocker.md). + **To review the AppLocker log in Event Viewer** + 1. Open Event Viewer. 2. In the console tree under **Application and Services Logs\\Microsoft\\Windows**, click **AppLocker**. + The following table contains information about the events that you can use to determine which apps are affected by AppLocker rules. - ------ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Event IDLevelEvent messageDescription

8000

Error

Application Identity Policy conversion failed. Status <%1>

Indicates that the policy was not applied correctly to the computer. The status message is provided for troubleshooting purposes.

8001

Information

The AppLocker policy was applied successfully to this computer.

Indicates that the AppLocker policy was successfully applied to the computer.

8002

Information

<File name> was allowed to run.

Specifies that the .exe or .dll file is allowed by an AppLocker rule.

8003

Warning

<File name> was allowed to run but would have been prevented from running if the AppLocker policy were enforced.

Applied only when the Audit only enforcement mode is enabled. Specifies that the .exe or .dll file would be blocked if the Enforce rules enforcement mode were enabled.

8004

Error

<File name> was not allowed to run.

Access to <file name> is restricted by the administrator. Applied only when the Enforce rules enforcement mode is set either directly or indirectly through Group Policy inheritance. The .exe or .dll file cannot run.

8005

Information

<File name> was allowed to run.

Specifies that the script or .msi file is allowed by an AppLocker rule.

8006

Warning

<File name> was allowed to run but would have been prevented from running if the AppLocker policy were enforced.

Applied only when the Audit only enforcement mode is enabled. Specifies that the script or .msi file would be blocked if the Enforce rules enforcement mode were enabled.

8007

Error

<File name> was not allowed to run.

Access to <file name> is restricted by the administrator. Applied only when the Enforce rules enforcement mode is set either directly or indirectly through Group Policy inheritance. The script or .msi file cannot run.

8007

Error

AppLocker disabled on the SKU.

Added in Windows Server 2012 and Windows 8.

8020

Information

Packaged app allowed.

Added in Windows Server 2012 and Windows 8.

8021

Information

Packaged app audited.

Added in Windows Server 2012 and Windows 8.

8022

Information

Packaged app disabled.

Added in Windows Server 2012 and Windows 8.

8023

Information

Packaged app installation allowed.

Added in Windows Server 2012 and Windows 8.

8024

Information

Packaged app installation audited.

Added in Windows Server 2012 and Windows 8.

8025

Warning

Packaged app installation disabled.

Added in Windows Server 2012 and Windows 8.

8027

Warning

No Packaged app rule configured.

Added in Windows Server 2012 and Windows 8.

+ +| Event ID | Level | Event message | Description | +| - | - | - | - | +| 8000 | Error| Application Identity Policy conversion failed. Status *<%1> *| Indicates that the policy was not applied correctly to the computer. The status message is provided for troubleshooting purposes.| +| 8001 | Information| The AppLocker policy was applied successfully to this computer.| Indicates that the AppLocker policy was successfully applied to the computer.| +| 8002 | Information| *<File name> * was allowed to run.| Specifies that the .exe or .dll file is allowed by an AppLocker rule.| +| 8003 | Warning| *<File name> * was allowed to run but would have been prevented from running if the AppLocker policy were enforced.| Applied only when the **Audit only ** enforcement mode is enabled. Specifies that the .exe or .dll file would be blocked if the **Enforce rules ** enforcement mode were enabled. | +| 8004 | Error| *<File name> * was not allowed to run.| Access to *<file name> * is restricted by the administrator. Applied only when the **Enforce rules ** enforcement mode is set either directly or indirectly through Group Policy inheritance. The .exe or .dll file cannot run.| +| 8005| Information| *<File name> * was allowed to run.| Specifies that the script or .msi file is allowed by an AppLocker rule.| +| 8006 | Warning| *<File name> * was allowed to run but would have been prevented from running if the AppLocker policy were enforced.| Applied only when the **Audit only ** enforcement mode is enabled. Specifies that the script or .msi file would be blocked if the **Enforce rules ** enforcement mode were enabled. | +| 8007 | Error| *<File name> * was not allowed to run.| Access to *<file name> * is restricted by the administrator. Applied only when the **Enforce rules ** enforcement mode is set either directly or indirectly through Group Policy inheritance. The script or .msi file cannot run.| +| 8007| Error| AppLocker disabled on the SKU.| Added in Windows Server 2012 and Windows 8.| +| 8020| Information| Packaged app allowed.| Added in Windows Server 2012 and Windows 8.| +| 8021| Information| Packaged app audited.| Added in Windows Server 2012 and Windows 8.| +| 8022| Information| Packaged app disabled.| Added in Windows Server 2012 and Windows 8.| +| 8023 | Information| Packaged app installation allowed.| Added in Windows Server 2012 and Windows 8.| +| 8024 | Information| Packaged app installation audited.| Added in Windows Server 2012 and Windows 8.| +| 8025 | Warning| Packaged app installation disabled.| Added in Windows Server 2012 and Windows 8.| +| 8027 | Warning| No Packaged app rule configured.| Added in Windows Server 2012 and Windows 8.|   ## Related topics -[Tools to use with AppLocker](tools-to-use-with-applocker.md) + +- [Tools to use with AppLocker](tools-to-use-with-applocker.md)     diff --git a/windows/keep-secure/using-software-restriction-policies-and-applocker-policies.md b/windows/keep-secure/using-software-restriction-policies-and-applocker-policies.md index e07957331b..54b12a4568 100644 --- a/windows/keep-secure/using-software-restriction-policies-and-applocker-policies.md +++ b/windows/keep-secure/using-software-restriction-policies-and-applocker-policies.md @@ -2,76 +2,60 @@ title: Use Software Restriction Policies and AppLocker policies (Windows 10) description: This topic for the IT professional describes how to use Software Restriction Policies (SRP) and AppLocker policies in the same Windows deployment. ms.assetid: c3366be7-e632-4add-bd10-9df088f74c6d -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Use Software Restriction Policies and AppLocker policies + **Applies to** - Windows 10 + This topic for the IT professional describes how to use Software Restriction Policies (SRP) and AppLocker policies in the same Windows deployment. + ## Understand the difference between SRP and AppLocker + You might want to deploy application control policies in Windows operating systems earlier than Windows Server 2008 R2 or Windows 7. You can use AppLocker policies only on the supported versions and editions of Windows as listed in [Requirements to use AppLocker](requirements-to-use-applocker.md). However, you can use SRP on those supported editions of Windows plus Windows Server 2003 and Windows XP. To compare features and functions in SRP and AppLocker so that you can determine when to use each technology to meet your application control objectives, see [Determine your application control objectives](determine-your-application-control-objectives.md). + ## Use SRP and AppLocker in the same domain + SRP and AppLocker use Group Policy for domain management. However, when policies are generated by SRP and AppLocker exist in the same domain, and they are applied through Group Policy, AppLocker policies take precedence over policies generated by SRP on computers that are running an operating system that supports AppLocker. For info about how inheritance in Group Policy applies to AppLocker policies and policies generated by SRP, see [Understand AppLocker rules and enforcement setting inheritance in Group Policy](understand-applocker-rules-and-enforcement-setting-inheritance-in-group-policy.md). -**Important**   -As a best practice, use separate Group Policy Objects to implement your SRP and AppLocker policies. To reduce troubleshooting issues, do not combine them in the same GPO. + +>**Important:**  As a best practice, use separate Group Policy Objects to implement your SRP and AppLocker policies. To reduce troubleshooting issues, do not combine them in the same GPO.   The following scenario provides an example of how each type of policy would affect a bank teller software app, where the app is deployed on different Windows desktop operating systems and managed by the Tellers GPO. - ------ - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Operating systemTellers GPO with AppLocker policyTellers GPO with SRPTellers GPO with AppLocker policy and SRP

Windows 10, Windows 8.1, Windows 8,and Windows 7

AppLocker policies in the GPO are applied, and they supersede any local AppLocker policies.

Local AppLocker policies supersede policies generated by SRP that are applied through the GPO.

AppLocker policies in the GPO are applied, and they supersede the policies generated by SRP in the GPO and local AppLocker policies or policies generated by SRP.

Windows Vista

AppLocker policies are not applied.

Policies generated by SRP in the GPO are applied, and they supersede local policies generated by SRP.AppLocker policies are not applied.

Policies generated by SRP in the GPO are applied, and they supersede local policies generated by SRP. AppLocker policies not applied.

Windows XP

AppLocker policies are not applied.

Policies generated by SRP in the GPO are applied, and they supersede local policies generated by SRP. AppLocker policies are not applied.

Policies generated by SRP in the GPO are applied, and they supersede local policies generated by SRP. AppLocker policies not applied.

+ +| Operating system | Tellers GPO with AppLocker policy | Tellers GPO with SRP | Tellers GPO with AppLocker policy and SRP | +| - | - | - | - | +| Windows 10, Windows 8.1, Windows 8,and Windows 7 | AppLocker policies in the GPO are applied, and they supersede any local AppLocker policies.| Local AppLocker policies supersede policies generated by SRP that are applied through the GPO. | AppLocker policies in the GPO are applied, and they supersede the policies generated by SRP in the GPO and local AppLocker policies or policies generated by SRP.| +| Windows Vista| AppLocker policies are not applied.| Policies generated by SRP in the GPO are applied, and they supersede local policies generated by SRP.AppLocker policies are not applied.| Policies generated by SRP in the GPO are applied, and they supersede local policies generated by SRP. AppLocker policies not applied.| +| Windows XP| AppLocker policies are not applied.| Policies generated by SRP in the GPO are applied, and they supersede local policies generated by SRP. AppLocker policies are not applied.| Policies generated by SRP in the GPO are applied, and they supersede local policies generated by SRP. AppLocker policies not applied.|   -**Note**   -For info about supported versions and editions of the Windows operating system, see [Requirements to use AppLocker](requirements-to-use-applocker.md). +>**Note:**  For info about supported versions and editions of the Windows operating system, see [Requirements to use AppLocker](requirements-to-use-applocker.md).   ## Test and validate SRPs and AppLocker policies that are deployed in the same environment + Because SRPs and AppLocker policies function differently, they should not be implemented in the same GPO. This makes testing the result of the policy straightforward, which is critical to successfully controlling application usage in the organization. Configuring a testing and policy distribution system can help you understand the result of a policy. The effects of policies generated by SRP and AppLocker policies need to be tested separately and by using different tools. + ### Step 1: Test the effect of SRPs + You can use the Group Policy Management Console (GPMC) or the Resultant Set of Policy (RSoP) snap-in to determine the effect of applying SRPs by using GPOs. + ### Step 2: Test the effect of AppLocker policies + You can test AppLocker policies by using Windows PowerShell cmdlets. For info about investigating the result of a policy, see: + - [Test an AppLocker policy by using Test-AppLockerPolicy](test-an-applocker-policy-by-using-test-applockerpolicy.md) - [Monitor app usage with AppLocker](monitor-application-usage-with-applocker.md) + Another method to use when determining the result of a policy is to set the enforcement mode to **Audit only**. When the policy is deployed, events will be written to the AppLocker logs as if the policy was enforced. For info about using the **Audit only** mode, see: -[Understand AppLocker enforcement settings](understand-applocker-enforcement-settings.md) -[Configure an AppLocker policy for audit only](configure-an-applocker-policy-for-audit-only.md) + +- [Understand AppLocker enforcement settings](understand-applocker-enforcement-settings.md) +- [Configure an AppLocker policy for audit only](configure-an-applocker-policy-for-audit-only.md) + ## See also -[AppLocker deployment guide](applocker-policies-deployment-guide.md) -  -  + +- [AppLocker deployment guide](applocker-policies-deployment-guide.md) diff --git a/windows/keep-secure/view-the-security-event-log.md b/windows/keep-secure/view-the-security-event-log.md index 3c67e1191b..745195b4f3 100644 --- a/windows/keep-secure/view-the-security-event-log.md +++ b/windows/keep-secure/view-the-security-event-log.md @@ -2,19 +2,22 @@ title: View the security event log (Windows 10) description: The security log records each event as defined by the audit policies you set on each object. ms.assetid: 20DD2ACD-241A-45C5-A92F-4BE0D9F198B9 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # View the security event log + **Applies to** - Windows 10 + The security log records each event as defined by the audit policies you set on each object. + **To view the security log** + 1. Open Event Viewer. 2. In the console tree, expand **Windows Logs**, and then click **Security**. The results pane lists individual security events. 3. If you want to see more details about a specific event, in the results pane, click the event. -  -  diff --git a/windows/keep-secure/what-is-applocker.md b/windows/keep-secure/what-is-applocker.md index cfa573d478..b4d758df7b 100644 --- a/windows/keep-secure/what-is-applocker.md +++ b/windows/keep-secure/what-is-applocker.md @@ -2,18 +2,24 @@ title: What Is AppLocker (Windows 10) description: This topic for the IT professional describes what AppLocker is and how its features differ from Software Restriction Policies. ms.assetid: 44a8a2bb-0f83-4f95-828e-1f364fb65869 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # What Is AppLocker? + **Applies to** - Windows 10 + This topic for the IT professional describes what AppLocker is and how its features differ from Software Restriction Policies. + AppLocker advances the app control features and functionality of Software Restriction Policies. AppLocker contains new capabilities and extensions that allow you to create rules to allow or deny apps from running based on unique identities of files and to specify which users or groups can run those apps. + Using AppLocker, you can: + - Control the following types of apps: executable files (.exe and .com), scripts (.js, .ps1, .vbs, .cmd, and .bat), Windows Installer files (.mst, .msi and .msp), and DLL files (.dll and .ocx), and packaged apps and packaged app installers (appx). - Define rules based on file attributes derived from the digital signature, including the publisher, product name, file name, and file version. For example, you can create rules based on the publisher attribute that is persistent through updates, or you can create rules for a specific version of a file. - Assign a rule to a security group or an individual user. @@ -21,11 +27,17 @@ Using AppLocker, you can: - Use audit-only mode to deploy the policy and understand its impact before enforcing it. - Import and export rules. The import and export affects the entire policy. For example, if you export a policy, all of the rules from all of the rule collections are exported, including the enforcement settings for the rule collections. If you import a policy, all criteria in the existing policy are overwritten. - Streamline creating and managing AppLocker rules by using Windows PowerShell cmdlets. + AppLocker helps reduce administrative overhead and helps reduce the organization's cost of managing computing resources by decreasing the number of help desk calls that result from users running unapproved apps + For information about the application control scenarios that AppLocker addresses, see [AppLocker policy use scenarios](applocker-policy-use-scenarios.md). + ## What features are different between Software Restriction Policies and AppLocker? + **Feature differences** + The following table compares AppLocker to Software Restriction Policies. + @@ -99,6 +111,7 @@ The following table compares AppLocker to Software Restriction Policies.
  **Application control function differences** + The following table compares the application control functions of Software Restriction Policies (SRP) and AppLocker. @@ -167,6 +180,7 @@ The following table compares the application control functions of Software Restr
  ## Related topics -[AppLocker technical reference](applocker-technical-reference.md) + +- [AppLocker technical reference](applocker-technical-reference.md)     diff --git a/windows/keep-secure/which-editions-of-windows-support-advanced-audit-policy-configuration.md b/windows/keep-secure/which-editions-of-windows-support-advanced-audit-policy-configuration.md index 35a67350b8..c60d303826 100644 --- a/windows/keep-secure/which-editions-of-windows-support-advanced-audit-policy-configuration.md +++ b/windows/keep-secure/which-editions-of-windows-support-advanced-audit-policy-configuration.md @@ -2,25 +2,30 @@ title: Which editions of Windows support advanced audit policy configuration (Windows 10) description: This reference topic for the IT professional describes which versions of the Windows operating systems support advanced security auditing policies. ms.assetid: 87c71cc5-522d-4771-ac78-34a2a0825f31 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Which editions of Windows support advanced audit policy configuration + **Applies to** - Windows 10 + This reference topic for the IT professional describes which versions of the Windows operating systems support advanced security auditing policies. + Versions of the Windows operating system that cannot join a domain do not have access to these features. There is no difference in security auditing support between 32-bit and 64-bit versions. + ## Are there any special considerations? + In addition, the following special considerations apply to the various tasks associated with advanced security auditing enhancements: + - **Creating an audit policy.** To create an advanced security auditing policy, you must use a computer running any supported version of Windows. You can use the Group Policy Management Console (GPMC) on a computer running a supported version of the Windows client operating system after installing the Remote Server Administration Tools. - **Applying audit policy settings.** If you are using Group Policy to apply the advanced audit policy settings and global object access settings, client computers must be running any supported version of the Windows server operating system or Windows client operating system. In addition, only computers running any of these supported operating systems can provide "reason for access" reporting data. - **Developing an audit policy model.** To plan advanced security audit settings and global object access settings, you must use the GPMC that targets a domain controller running a supported version of the Windows server operating system. -- **Distributing the audit policy.** After a Group Policy Object (GPO) that includes advanced security auditing settings is developed, it can be distributed by using domain controllers running any Windows Server operating system. However, if you cannot put client computers running a supported version of the Windows client operating system into a separate organizational unit (OU), you should use Windows Management Instrumentation (WMI) filtering to ensure that the advanced security auditing policy settings are applied only to client computers running a supported version of the Windows client operating system. -**Important**   -Using both the basic auditing policy settings under **Local Policies\\Audit Policy** and the advanced auditing policy settings under **Advanced Audit Policy Configuration** can cause unexpected results in audit reporting. Therefore, the two sets of audit policy settings should not be combined. If you use advanced audit policy configuration settings, you should enable the **Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings** policy setting under **Local Policies\\Security Options**. This will prevent conflicts between similar settings by forcing basic security auditing to be ignored.   -  -  -  +- **Distributing the audit policy.** After a Group Policy Object (GPO) that includes advanced security auditing settings is developed, it can be distributed by using domain controllers running any Windows Server operating system. +However, if you cannot put client computers running a supported version of the Windows client operating system into a separate organizational unit (OU), you should use Windows Management Instrumentation (WMI) filtering to ensure that the advanced security auditing policy settings are applied only to client computers running a supported version of the Windows client operating system. + +>**Important:**  Using both the basic auditing policy settings under **Local Policies\\Audit Policy** and the advanced auditing policy settings under **Advanced Audit Policy Configuration** can cause unexpected results in audit reporting. Therefore, the two sets of audit policy settings should not be combined. If you use advanced audit policy configuration settings, you should enable the **Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings** policy setting under **Local Policies\\Security Options**. This will prevent conflicts between similar settings by forcing basic security auditing to be ignored.   diff --git a/windows/keep-secure/windows-installer-rules-in-applocker.md b/windows/keep-secure/windows-installer-rules-in-applocker.md index 05f9214263..b12d94b8ef 100644 --- a/windows/keep-secure/windows-installer-rules-in-applocker.md +++ b/windows/keep-secure/windows-installer-rules-in-applocker.md @@ -2,59 +2,36 @@ title: Windows Installer rules in AppLocker (Windows 10) description: This topic describes the file formats and available default rules for the Windows Installer rule collection. ms.assetid: 3fecde5b-88b3-4040-81fa-a2d36d052ec9 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Windows Installer rules in AppLocker + **Applies to** - Windows 10 + This topic describes the file formats and available default rules for the Windows Installer rule collection. + AppLocker defines Windows Installer rules to include only the following file formats: + - .msi - .msp - .mst + The purpose of this collection is to allow you to control the installation of files on client computers and servers through Group Policy or the Local Security Policy snap-in. The following table lists the default rules that are available for the Windows Installer rule collection. - ------ - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
PurposeNameUserRule condition type

Allow members of the local Administrators group to run all Windows Installer files

(Default Rule) All Windows Installer files

BUILTIN\Administrators

Path: *

Allow all users to run Windows Installer files that are digitally signed

(Default Rule) All digitally signed Windows Installer files

Everyone

Publisher: * (all signed files)

Allow all users to run Windows Installer files that are located in the Windows Installer folder

(Default Rule) All Windows Installer files in %systemdrive%\Windows\Installer

Everyone

Path: %windir%\Installer\*

+ +| Purpose | Name | User | Rule condition type | +| - | - | - | - | +| Allow members of the local Administrators group to run all Windows Installer files| (Default Rule) All Windows Installer files| BUILTIN\Administrators| Path: *| +| Allow all users to run Windows Installer files that are digitally signed | (Default Rule) All digitally signed Windows Installer files| Everyone| Publisher: * (all signed files)| +| Allow all users to run Windows Installer files that are located in the Windows Installer folder | (Default Rule) All Windows Installer files in %systemdrive%\Windows\Installer| Everyone| Path: %windir%\Installer\*|   ## Related topics -[Understanding AppLocker default rules](understanding-applocker-default-rules.md) + +- [Understanding AppLocker default rules](understanding-applocker-default-rules.md)     diff --git a/windows/keep-secure/working-with-applocker-policies.md b/windows/keep-secure/working-with-applocker-policies.md index af1edcf35e..8963fa665b 100644 --- a/windows/keep-secure/working-with-applocker-policies.md +++ b/windows/keep-secure/working-with-applocker-policies.md @@ -2,83 +2,35 @@ title: Working with AppLocker policies (Windows 10) description: This topic for IT professionals provides links to procedural topics about creating, maintaining, and testing AppLocker policies. ms.assetid: 7062d2e0-9cbb-4cb8-aa8c-b24945c3771d -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Working with AppLocker policies + **Applies to** - Windows 10 + This topic for IT professionals provides links to procedural topics about creating, maintaining, and testing AppLocker policies. + ## In this section - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
TopicDescription

[Configure the Application Identity service](configure-the-application-identity-service.md)

This topic for IT professionals shows how to configure the Application Identity service to start automatically or manually.

[Configure an AppLocker policy for audit only](configure-an-applocker-policy-for-audit-only.md)

This topic for IT professionals describes how to set AppLocker policies to Audit only within your IT environment by using AppLocker.

[Configure an AppLocker policy for enforce rules](configure-an-applocker-policy-for-enforce-rules.md)

This topic for IT professionals describes the steps to enable the AppLocker policy enforcement setting.

[Display a custom URL message when users try to run a blocked app](display-a-custom-url-message-when-users-try-to-run-a-blocked-application.md)

This topic for IT professionals describes the steps for displaying a customized message to users when an AppLocker policy denies access to an app.

[Export an AppLocker policy from a GPO](export-an-applocker-policy-from-a-gpo.md)

This topic for IT professionals describes the steps to export an AppLocker policy from a Group Policy Object (GPO) so that it can be modified.

[Export an AppLocker policy to an XML file](export-an-applocker-policy-to-an-xml-file.md)

This topic for IT professionals describes the steps to export an AppLocker policy to an XML file for review or testing.

[Import an AppLocker policy from another computer](import-an-applocker-policy-from-another-computer.md)

This topic for IT professionals describes how to import an AppLocker policy.

[Import an AppLocker policy into a GPO](import-an-applocker-policy-into-a-gpo.md)

This topic for IT professionals describes the steps to import an AppLocker policy into a Group Policy Object (GPO).

[Add rules for packaged apps to existing AppLocker rule-set](add-rules-for-packaged-apps-to-existing-applocker-rule-set.md)

This topic for IT professionals describes how to update your existing AppLocker policies for packaged apps using the Remote Server Administration Toolkit (RSAT).

[Merge AppLocker policies by using Set-ApplockerPolicy](merge-applocker-policies-by-using-set-applockerpolicy.md)

This topic for IT professionals describes the steps to merge AppLocker policies by using Windows PowerShell.

[Merge AppLocker policies manually](merge-applocker-policies-manually.md)

This topic for IT professionals describes the steps to manually merge AppLocker policies to update the Group Policy Object (GPO).

[Refresh an AppLocker policy](refresh-an-applocker-policy.md)

This topic for IT professionals describes the steps to force an update for an AppLocker policy.

[Test an AppLocker policy by using Test-AppLockerPolicy](test-an-applocker-policy-by-using-test-applockerpolicy.md)

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.

-  -  -  + +| Topic | Description | +| - | - | +| [Configure the Application Identity service](configure-the-application-identity-service.md) | This topic for IT professionals shows how to configure the Application Identity service to start automatically or manually.| +| [Configure an AppLocker policy for audit only](configure-an-applocker-policy-for-audit-only.md) | This topic for IT professionals describes how to set AppLocker policies to **Audit only ** within your IT environment by using AppLocker.| +| [Configure an AppLocker policy for enforce rules](configure-an-applocker-policy-for-enforce-rules.md) | This topic for IT professionals describes the steps to enable the AppLocker policy enforcement setting.| +| [Display a custom URL message when users try to run a blocked app](display-a-custom-url-message-when-users-try-to-run-a-blocked-application.md) | This topic for IT professionals describes the steps for displaying a customized message to users when an AppLocker policy denies access to an app.| +| [Export an AppLocker policy from a GPO](export-an-applocker-policy-from-a-gpo.md) | This topic for IT professionals describes the steps to export an AppLocker policy from a Group Policy Object (GPO) so that it can be modified.| +| [Export an AppLocker policy to an XML file](export-an-applocker-policy-to-an-xml-file.md) | This topic for IT professionals describes the steps to export an AppLocker policy to an XML file for review or testing.| +| [Import an AppLocker policy from another computer](import-an-applocker-policy-from-another-computer.md) | This topic for IT professionals describes how to import an AppLocker policy.| +| [Import an AppLocker policy into a GPO](import-an-applocker-policy-into-a-gpo.md) | This topic for IT professionals describes the steps to import an AppLocker policy into a Group Policy Object (GPO).| +| [Add rules for packaged apps to existing AppLocker rule-set](add-rules-for-packaged-apps-to-existing-applocker-rule-set.md) | This topic for IT professionals describes how to update your existing AppLocker policies for packaged apps using the Remote Server Administration Toolkit (RSAT).| +| [Merge AppLocker policies by using Set-ApplockerPolicy](merge-applocker-policies-by-using-set-applockerpolicy.md) | This topic for IT professionals describes the steps to merge AppLocker policies by using Windows PowerShell.| +| [Merge AppLocker policies manually](merge-applocker-policies-manually.md) | This topic for IT professionals describes the steps to manually merge AppLocker policies to update the Group Policy Object (GPO).| +| [Refresh an AppLocker policy](refresh-an-applocker-policy.md) | This topic for IT professionals describes the steps to force an update for an AppLocker policy.| +| [Test an AppLocker policy by using Test-AppLockerPolicy](test-an-applocker-policy-by-using-test-applockerpolicy.md) | 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.| + diff --git a/windows/keep-secure/working-with-applocker-rules.md b/windows/keep-secure/working-with-applocker-rules.md index 9ee115544d..762d21c78a 100644 --- a/windows/keep-secure/working-with-applocker-rules.md +++ b/windows/keep-secure/working-with-applocker-rules.md @@ -2,338 +2,207 @@ title: Working with AppLocker rules (Windows 10) description: This topic for IT professionals describes AppLocker rule types and how to work with them for your application control policies. ms.assetid: 3966b35b-f2da-4371-8b5f-aec031db6bc9 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Working with AppLocker rules + **Applies to** - Windows 10 + This topic for IT professionals describes AppLocker rule types and how to work with them for your application control policies. + ## In this section - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
TopicDescription

[Create a rule that uses a file hash condition](create-a-rule-that-uses-a-file-hash-condition.md)

This topic for IT professionals shows how to create an AppLocker rule with a file hash condition.

[Create a rule that uses a path condition](create-a-rule-that-uses-a-path-condition.md)

This topic for IT professionals shows how to create an AppLocker rule with a path condition.

[Create a rule that uses a publisher condition](create-a-rule-that-uses-a-publisher-condition.md)

This topic for IT professionals shows how to create an AppLocker rule with a publisher condition.

[Create AppLocker default rules](create-applocker-default-rules.md)

This topic for IT professionals describes the steps to create a standard set of AppLocker rules that will allow Windows system files to run.

[Add exceptions for an AppLocker rule](configure-exceptions-for-an-applocker-rule.md)

This topic for IT professionals describes the steps to specify which apps can or cannot run as exceptions to an AppLocker rule.

[Create a rule for packaged apps](create-a-rule-for-packaged-apps.md)

This topic for IT professionals shows how to create an AppLocker rule for packaged apps with a publisher condition.

[Delete an AppLocker rule](delete-an-applocker-rule.md)

This topic for IT professionals describes the steps to delete an AppLocker rule.

[Edit AppLocker rules](edit-applocker-rules.md)

This topic for IT professionals describes the steps to edit a publisher rule, path rule, and file hash rule in AppLocker.

[Enable the DLL rule collection](enable-the-dll-rule-collection.md)

This topic for IT professionals describes the steps to enable the DLL rule collection feature for AppLocker.

[Enforce AppLocker rules](enforce-applocker-rules.md)

This topic for IT professionals describes how to enforce application control rules by using AppLocker.

[Run the Automatically Generate Rules wizard](run-the-automatically-generate-rules-wizard.md)

This topic for IT professionals describes steps to run the wizard to create AppLocker rules on a reference device.

+ +| Topic | Description | +| - | - | +| [Create a rule that uses a file hash condition](create-a-rule-that-uses-a-file-hash-condition.md) | This topic for IT professionals shows how to create an AppLocker rule with a file hash condition.| +| [Create a rule that uses a path condition](create-a-rule-that-uses-a-path-condition.md) | This topic for IT professionals shows how to create an AppLocker rule with a path condition.| +| [Create a rule that uses a publisher condition](create-a-rule-that-uses-a-publisher-condition.md) | This topic for IT professionals shows how to create an AppLocker rule with a publisher condition.| +| [Create AppLocker default rules](create-applocker-default-rules.md) | This topic for IT professionals describes the steps to create a standard set of AppLocker rules that will allow Windows system files to run.| +| [Add exceptions for an AppLocker rule](configure-exceptions-for-an-applocker-rule.md) | This topic for IT professionals describes the steps to specify which apps can or cannot run as exceptions to an AppLocker rule.| +| [Create a rule for packaged apps](create-a-rule-for-packaged-apps.md) | This topic for IT professionals shows how to create an AppLocker rule for packaged apps with a publisher condition.| +| [Delete an AppLocker rule](delete-an-applocker-rule.md) | This topic for IT professionals describes the steps to delete an AppLocker rule.| +| [Edit AppLocker rules](edit-applocker-rules.md) | This topic for IT professionals describes the steps to edit a publisher rule, path rule, and file hash rule in AppLocker.| +| [Enable the DLL rule collection](enable-the-dll-rule-collection.md) | This topic for IT professionals describes the steps to enable the DLL rule collection feature for AppLocker.| +| [Enforce AppLocker rules](enforce-applocker-rules.md) | This topic for IT professionals describes how to enforce application control rules by using AppLocker.| +| [Run the Automatically Generate Rules wizard](run-the-automatically-generate-rules-wizard.md) | This topic for IT professionals describes steps to run the wizard to create AppLocker rules on a reference device.|   The three AppLocker enforcement modes are described in the following table. The enforcement mode setting defined here can be overwritten by the setting derived from a linked Group Policy Object (GPO) with a higher precedence. - ---- - - - - - - - - - - - - - - - - - - - - -
Enforcement modeDescription

Not configured

This is the default setting which means that the rules defined here will be enforced unless a linked GPO with a higher precedence has a different value for this setting.

Enforce rules

Rules are enforced.

Audit only

Rules are audited but not enforced. When a user runs an app that is affected by an AppLocker rule, the app is allowed to run and the info about the app is added to the AppLocker event log. The Audit-only enforcement mode helps you determine which apps will be affected by the policy before the policy is enforced. When the AppLocker policy for a rule collection is set to Audit only, rules for that rule collection are not enforced

-  + +| Enforcement mode | Description | +| - | - | +| **Not configured** | This is the default setting which means that the rules defined here will be enforced unless a linked GPO with a higher precedence has a different value for this setting.| +| **Enforce rules** | Rules are enforced.| +| **Audit only** | Rules are audited but not enforced. When a user runs an app that is affected by an AppLocker rule, the app is allowed to run and the info about the app is added to the AppLocker event log. The Audit-only enforcement mode helps you determine which apps will be affected by the policy before the policy is enforced. When the AppLocker policy for a rule collection is set to **Audit only**, rules for that rule collection are not enforced| + When AppLocker policies from various GPOs are merged, the rules from all the GPOs are merged and the enforcement mode setting of the winning GPO is applied. ## Rule collections + The AppLocker console is organized into rule collections, which are executable files, scripts, Windows Installer files, packaged apps and packaged app installers, and DLL files. These collections give you an easy way to differentiate the rules for different types of apps. The following table lists the file formats that are included in each rule collection. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Rule collectionAssociated file formats

Executable files

.exe

-

.com

Scripts

.ps1

-

.bat

-

.cmd

-

.vbs

-

.js

Windows Installer files

.msi

-

.msp

-

.mst

Packaged apps and packaged app installers

.appx

DLL files

.dll

-

.ocx

+ +| Rule collection | Associated file formats | +| - | - | +| Executable files | .exe
.com| +| Scripts| .ps1
.bat
.cmd
.vbs
.js| +| Windows Installer files | .msi
.msp
.mst| +| Packaged apps and packaged app installers | .appx| +| DLL files | .dll
.ocx|   -**Important**   -If you use DLL rules, you need to create an allow rule for each DLL that is used by all of the allowed apps. +>**Important:**  If you use DLL rules, you need to create an allow rule for each DLL that is used by all of the allowed apps. + When DLL rules are used, AppLocker must check each DLL that an application loads. Therefore, users may experience a reduction in performance if DLL rules are used. + The DLL rule collection is not enabled by default. To learn how to enable the DLL rule collection, see [DLL rule collections](#bkmk-dllrulecollections).   ## Rule conditions + Rule conditions are criteria that help AppLocker identify the apps to which the rule applies. The three primary rule conditions are publisher, path, and file hash. + - [Publisher](#bkmk-publisher): Identifies an app based on its digital signature - [Path](#bkmk-path): Identifies an app by its location in the file system of the computer or on the network - [File hash](#bkmk-filehash): Represents the system computed cryptographic hash of the identified file + ### Publisher + This condition identifies an app based on its digital signature and extended attributes when available. The digital signature contains info about the company that created the app (the publisher). Executable files, dlls, Windows installers, packaged apps and packaged app installers also have extended attributes, which are obtained from the binary resource. In case of executable files, dlls and Windows installers, these attributes contain the name of the product that the file is a part of, the original name of the file as supplied by the publisher, and the version number of the file. In case of packaged apps and packaged app installers, these extended attributes contain the name and the version of the app package. -**Note**   -Rules created in the packaged apps and packaged app installers rule collection can only have publisher conditions since Windows does not support unsigned packaged apps and packaged app installers. + +>**Note:**  Rules created in the packaged apps and packaged app installers rule collection can only have publisher conditions since Windows does not support unsigned packaged apps and packaged app installers.   -**Note**   -Use a publisher rule condition when possible because they can survive app updates as well as a change in the location of files. +>**Note:**  Use a publisher rule condition when possible because they can survive app updates as well as a change in the location of files.   When you select a reference file for a publisher condition, the wizard creates a rule that specifies the publisher, product, file name, and version number. You can make the rule more generic by moving the slider up or by using a wildcard character (\*) in the product, file name, or version number fields. -**Note**   -To enter custom values for any of the fields of a publisher rule condition in the Create Rules Wizard, you must select the **Use custom values** check box. When this check box is selected, you cannot use the slider. + +>**Note:**  To enter custom values for any of the fields of a publisher rule condition in the Create Rules Wizard, you must select the **Use custom values** check box. When this check box is selected, you cannot use the slider.   The **File version** and **Package version** control whether a user can run a specific version, earlier versions, or later versions of the app. You can choose a version number and then configure the following options: + - **Exactly.** The rule applies only to this version of the app - **And above.** The rule applies to this version and all later versions. - **And below.** The rule applies to this version and all earlier versions. + The following table describes how a publisher condition is applied. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
OptionThe publisher condition allows or denies…

All signed files

All files that are signed by any publisher.

Publisher only

All files that are signed by the named publisher.

Publisher and product name

All files for the specified product that are signed by the named publisher.

Publisher and product name, and file name

Any version of the named file or package for the named product that are signed by the publisher.

Publisher, product name, file name, and file version

Exactly

-

The specified version of the named file or package for the named product that are signed by the publisher.

Publisher, product name, file name, and file version

And above

-

The specified version of the named file or package and any new releases for the product that are signed by the publisher.

Publisher, product name, file name, and file version

And below

-

The specified version of the named file or package and any earlier versions for the product that are signed by the publisher.

Custom

You can edit the Publisher, Product name, File name, Version Package name, and Package version fields to create a custom rule.

-  + + +| Option | The publisher condition allows or denies… | +| **All signed files** | All files that are signed by any publisher.| +| **Publisher only**| All files that are signed by the named publisher.| +| **Publisher and product name**| All files for the specified product that are signed by the named publisher.| +| **Publisher and product name, and file name**| Any version of the named file or package for the named product that are signed by the publisher.| +| **Publisher, product name, file name, and file version**| **Exactly**
The specified version of the named file or package for the named product that are signed by the publisher.| +| **Publisher, product name, file name, and file version**| **And above**
The specified version of the named file or package and any new releases for the product that are signed by the publisher.| +| **Publisher, product name, file name, and file version**| **And below**
The specified version of the named file or package and any earlier versions for the product that are signed by the publisher.| +| **Custom**| You can edit the **Publisher**, **Product name**, **File name**, **Version** **Package name**, and **Package version** fields to create a custom rule.| + ### Path + This rule condition identifies an application by its location in the file system of the computer or on the network. + AppLocker uses custom path variables for well-known paths, such as Program Files and Windows. + The following table details these path variables. - ----- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Windows directory or diskAppLocker path variableWindows environment variable

Windows

%WINDIR%

%SystemRoot%

System32

%SYSTEM32%

%SystemDirectory%

Windows installation directory

%OSDRIVE%

%SystemDrive%

Program Files

%PROGRAMFILES%

%ProgramFiles% and

-

%ProgramFiles(x86)%

Removable media (for example, a CD or DVD)

%REMOVABLE%

Removable storage device (for example, a USB flash drive)

%HOT%

+ +| Windows directory or disk | AppLocker path variable | Windows environment variable | +| - | - | - | +| Windows| %WINDIR%| %SystemRoot%| +| System32| %SYSTEM32%| %SystemDirectory%| +| Windows installation directory| %OSDRIVE%| %SystemDrive%| +| Program Files| %PROGRAMFILES%| %ProgramFiles% and %ProgramFiles(x86)% | +| Removable media (for example, a CD or DVD)| %REMOVABLE%| | +| Removable storage device (for example, a USB flash drive)| %HOT% | |   -**Important**   -Because a path rule condition can be configured to include a large number of folders and files, path conditions should be carefully planned. For example, if an allow rule with a path condition includes a folder location that non-administrators are allowed to write data into, a user can copy unapproved files into that location and run the files. For this reason, it is a best practice to not create path conditions for standard user writable locations, such as a user profile. +>**Important:**  Because a path rule condition can be configured to include a large number of folders and files, path conditions should be carefully planned. For example, if an allow rule with a path condition includes a folder location that non-administrators are allowed to write data into, a user can copy unapproved files into that location and run the files. For this reason, it is a best practice to not create path conditions for standard user writable locations, such as a user profile.   ### File hash + When you choose the file hash rule condition, the system computes a cryptographic hash of the identified file. The advantage of this rule condition is that because each file has a unique hash, a file hash rule condition applies to only one file. The disadvantage is that each time the file is updated (such as a security update or upgrade) the file's hash will change. As a result, you must manually update file hash rules. + ## AppLocker default rules + AppLocker allows you to generate default rules for each rule collection. + Executable default rule types include: + - Allow members of the local **Administrators** group to run all apps. - Allow members of the **Everyone** group to run apps that are located in the Windows folder. - Allow members of the **Everyone** group to run apps that are located in the Program Files folder. + Script default rule types include: + - Allow members of the local **Administrators** group to run all scripts. - Allow members of the **Everyone** group to run scripts that are located in the Program Files folder. - Allow members of the **Everyone** group to run scripts that are located in the Windows folder. + Windows Installer default rule types include: + - Allow members of the local **Administrators** group to run all Windows Installer files. - Allow members of the **Everyone** group to run all digitally signed Windows Installer files. - Allow members of the **Everyone** group to run all Windows Installer files that are located in the Windows\\Installer folder. + DLL default rule types: + - Allow members of the local **Administrators** group to run all DLLs. - Allow members of the **Everyone** group to run DLLs that are located in the Program Files folder. - Allow members of the **Everyone** group to run DLLs that are located in the Windows folder. + Packaged apps default rule types: + - Allow members of the **Everyone** group to install and run all signed packaged apps and packaged app installers. + ## AppLocker rule behavior + If no AppLocker rules for a specific rule collection exist, all files with that file format are allowed to run. However, when an AppLocker rule for a specific rule collection is created, only the files explicitly allowed in a rule are permitted to run. For example, if you create an executable rule that allows .exe files in *%SystemDrive%\\FilePath* to run, only executable files located in that path are allowed to run. + A rule can be configured to use allow or deny actions: + - **Allow.** You can specify which files are allowed to run in your environment, and for which users or groups of users. You can also configure exceptions to identify files that are excluded from the rule. - **Deny.** You can specify which files are *not* allowed to run in your environment, and for which users or groups of users. You can also configure exceptions to identify files that are excluded from the rule. -**Important**   -For a best practice, use allow actions with exceptions. You can use a combination of allow and deny actions but understand that deny actions override allow actions in all cases, and can be circumvented. + +>**Important:**  For a best practice, use allow actions with exceptions. You can use a combination of allow and deny actions but understand that deny actions override allow actions in all cases, and can be circumvented.   -**Important**   -If you join a computer running at least Windows Server 2012 or Windows 8 to a domain that already enforces AppLocker rules for executable files, users will not be able to run any packaged apps unless you also create rules for packaged apps. If you want to allow any packaged apps in your environment while continuing to control executable files, you should create the default rules for packaged apps and set the enforcement mode to Audit-only for the packaged apps rule collection. +>**Important:**  If you join a computer running at least Windows Server 2012 or Windows 8 to a domain that already enforces AppLocker rules for executable files, users will not be able to run any packaged apps unless you also create rules for packaged apps. If you want to allow any packaged apps in your environment while continuing to control executable files, you should create the default rules for packaged apps and set the enforcement mode to Audit-only for the packaged apps rule collection.   ## Rule exceptions + You can apply AppLocker rules to individual users or to a group of users. If you apply a rule to a group of users, all users in that group are affected by that rule. If you need to allow a subset of a user group to use an app, you can create a special rule for that subset. For example, the rule "Allow everyone to run Windows except Registry Editor" allows everyone in the organization to run the Windows operating system, but it does not allow anyone to run Registry Editor. + The effect of this rule would prevent users such as Help Desk personnel from running a program that is necessary for their support tasks. To resolve this problem, create a second rule that applies to the Help Desk user group: "Allow Help Desk to run Registry Editor." If you create a deny rule that does not allow any users to run Registry Editor, the deny rule will override the second rule that allows the Help Desk user group to run Registry Editor. + ## DLL rule collection + Because the DLL rule collection is not enabled by default, you must perform the following procedure before you can create and enforce DLL rules. + Membership in the local **Administrators** group, or equivalent, is the minimum required to complete this procedure. + **To enable the DLL rule collection** + 1. Click **Start**, type **secpol.msc**, and then press ENTER. 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, double-click **Application Control Policies**, right-click **AppLocker**, and then click **Properties**. 4. 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. + + >**Important:**  Before you enforce DLL rules, make sure that there are allow rules for each DLL that is used by any of the allowed apps.   ## AppLocker wizards + You can create rules by using two AppLocker wizards: + 1. The Create Rules Wizard enables you to create one rule at a time. 2. The Automatically Generate Rules Wizard allows you to create multiple rules at one time. You can either select a folder and let the wizard create rules for the relevant files within that folder or in case of packaged apps let the wizard create rules for all packaged apps installed on the computer. You can also specify the user or group to which to apply the rules. This wizard automatically generates allow rules only. + ## Additional considerations + - By default, AppLocker rules do not allow users to open or run any files that are not specifically allowed. Administrators should maintain an up-to-date list of allowed applications. - There are two types of AppLocker conditions that do not persist following an update of an app: + - **A file hash condition** File hash rule conditions can be used with any app because a cryptographic hash value of the app is generated at the time the rule is created. However, the hash value is specific to that exact version of the app. If there are several versions of the application in use within the organization, you need to create file hash conditions for each version in use and for any new versions that are released. + - **A publisher condition with a specific product version set** If you create a publisher rule condition that uses the **Exactly** version option, the rule cannot persist if a new version of the app is installed. A new publisher condition must be created, or the version must be edited in the rule to be made less specific. + - If an app is not digitally signed, you cannot use a publisher rule condition for that app. - AppLocker rules cannot be used to manage computers running a Windows operating system earlier than Windows Server 2008 R2 or Windows 7. Software Restriction Policies must be used instead. If AppLocker rules are defined in a Group Policy Object (GPO), only those rules are applied. To ensure interoperability between Software Restriction Policies rules and AppLocker rules, define Software Restriction Policies rules and AppLocker rules in different GPOs. - The packaged apps and packaged apps installer rule collection is available on devices running at least Windows Server 2012 and Windows 8. @@ -341,5 +210,3 @@ You can create rules by using two AppLocker wizards: - When an AppLocker rule collection is set to **Audit only**, the rules are not enforced. When a user runs an application that is included in the rule, the app is opened and runs normally, and information about that app is added to the AppLocker event log. - A custom configured URL can be included in the message that is displayed when an app is blocked. - Expect an increase in the number of Help Desk calls initially because of blocked apps until users understand that they cannot run apps that are not allowed. -  -