Merge pull request #6782 from MicrosoftDocs/v-smandalika-5694287-B21

windows - v-smandalika - 5694287 - Acrolinx Enhancement Effort
This commit is contained in:
Stephanie Savell
2022-08-03 10:27:00 -05:00
committed by GitHub
30 changed files with 195 additions and 196 deletions

View File

@ -40,7 +40,7 @@ To complete this AppLocker planning document, you should first complete the foll
3. [Select the types of rules to create](select-types-of-rules-to-create.md)
4. [Determine the Group Policy structure and rule enforcement](determine-group-policy-structure-and-rule-enforcement.md)
After you determine how to structure your Group Policy Objects (GPOs) so that you can apply AppLocker policies, you should record your findings. You can use the following table to determine how many GPOs to create (or edit) and which objects they are linked to. If you decided to create custom rules to allow system files to run, note the high-level rule configuration in the **Use default rule or define new rule condition** column.
After you determine how to structure your Group Policy Objects (GPOs) so that you can apply AppLocker policies, you should record your findings. You can use the following table to determine how many GPOs to create (or edit) and which objects they're linked to. If you decided to create custom rules to allow system files to run, note the high-level rule configuration in the **Use default rule or define new rule condition** column.
The following table includes the sample data that was collected when you determined your enforcement settings and the GPO structure for your AppLocker policies.
@ -49,13 +49,13 @@ The following table includes the sample data that was collected when you determi
|Bank Tellers|Teller-East and Teller-West|Yes|Teller Software|C:\Program Files\Woodgrove\Teller.exe|File is signed; create a publisher condition|Allow|Tellers-AppLockerTellerRules|
||||Windows files|C:\Windows|Create a path exception to the default rule to exclude \Windows\Temp|Allow||
|Human Resources|HR-All|Yes|Check Payout|C:\Program Files\Woodgrove\HR\Checkcut.exe|File is signed; create a publisher condition|Allow|HR-AppLockerHRRules|
||||Time Sheet Organizer|C:\Program Files\Woodgrove\HR\Timesheet.exe|File is not signed; create a file hash condition|Allow||
||||Time Sheet Organizer|C:\Program Files\Woodgrove\HR\Timesheet.exe|File isn't signed; create a file hash condition|Allow||
||||Internet Explorer 7|C:\Program Files\Internet Explorer</p>|File is signed; create a publisher condition|Deny||
||||Windows files|C:\Windows|Use a default rule for the Windows path|Allow||
## Next steps
After you have determined the Group Policy structure and rule enforcement strategy for each business group's apps, the following tasks remain:
After you've determined the Group Policy structure and rule enforcement strategy for each business group's apps, the following tasks remain:
- [Plan for AppLocker policy management](plan-for-applocker-policy-management.md)

View File

@ -31,7 +31,7 @@ ms.technology: windows-sec
This topic for IT professionals describes the steps required to modify an AppLocker policy.
You can edit an AppLocker policy by adding, changing, or removing rules. However, you cannot create a new version of the policy by importing additional rules. To modify an AppLocker policy that is in production, you should use Group Policy management software that allows you to version Group Policy Objects (GPOs). If you have created multiple AppLocker policies and need to merge them to create one AppLocker policy, you can either manually merge the policies or use the Windows PowerShell cmdlets for AppLocker. You cannot automatically merge policies by using the AppLocker snap-in. You must create one rule collection from two or more policies. The AppLocker policy is saved in XML format, and the exported policy can be edited with any text or XML editor. For info about merging policies, see [Merge AppLocker policies manually](merge-applocker-policies-manually.md) or [Merge AppLocker policies by using Set-ApplockerPolicy](merge-applocker-policies-by-using-set-applockerpolicy.md).
You can edit an AppLocker policy by adding, changing, or removing rules. However, you can't create a new version of the policy by importing more rules. To modify an AppLocker policy that is in production, you should use Group Policy management software that allows you to version Group Policy Objects (GPOs). If you have created multiple AppLocker policies and need to merge them to create one AppLocker policy, you can either manually merge the policies or use the Windows PowerShell cmdlets for AppLocker. You can't automatically merge policies by using the AppLocker snap-in. You must create one rule collection from two or more policies. The AppLocker policy is saved in XML format, and the exported policy can be edited with any text or XML editor. For info about merging policies, see [Merge AppLocker policies manually](merge-applocker-policies-manually.md) or [Merge AppLocker policies by using Set-ApplockerPolicy](merge-applocker-policies-by-using-set-applockerpolicy.md).
There are three methods you can use to edit an AppLocker policy:
@ -46,16 +46,15 @@ For more information, see the [AppLocker CSP](/windows/client-management/mdm/app
## <a href="" id="bkmk-editapppolingpo"></a>Editing an AppLocker policy by using Group Policy
The steps to edit an AppLocker policy distributed by Group Policy include the following:
The steps to edit an AppLocker policy distributed by Group Policy include:
### Step 1: Use Group Policy management software to export the AppLocker policy from the GPO
AppLocker provides a feature to export and import AppLocker policies as an XML file. This allows you to modify an AppLocker policy outside your production environment. Because updating an AppLocker policy in a deployed GPO could have unintended consequences, you should first export the AppLocker
policy to an XML file. For the procedure to do this, see [Export an AppLocker policy from a GPO](export-an-applocker-policy-from-a-gpo.md).
AppLocker provides a feature to export and import AppLocker policies as an XML file. This feature allows you to modify an AppLocker policy outside your production environment. Because updating an AppLocker policy in a deployed GPO could have unintended consequences, you should first export the AppLocker policy to an XML file. For information on the procedure to export this policy, see [Export an AppLocker policy from a GPO](export-an-applocker-policy-from-a-gpo.md).
### Step 2: Import the AppLocker policy into the AppLocker reference PC or the PC you use for policy maintenance
After exporting the AppLocker policy to an XML file, you should import the XML file onto a reference PC so that you can edit the policy. For the procedure to import an AppLocker policy, see [Import an AppLocker policy from another computer](import-an-applocker-policy-from-another-computer.md).
After exporting the AppLocker policy to an XML file, you should import the XML file onto a reference PC so that you can edit the policy. For information on the procedure to import an AppLocker policy, see [Import an AppLocker policy from another computer](import-an-applocker-policy-from-another-computer.md).
>**Caution:**  Importing a policy onto another PC will overwrite the existing policy on that PC.
 
@ -63,8 +62,8 @@ After exporting the AppLocker policy to an XML file, you should import the XML f
AppLocker provides ways to modify, delete, or add rules to a policy by modifying the rules within the collection.
- For the procedure to modify a rule, see [Edit AppLocker rules](edit-applocker-rules.md).
- For the procedure to delete a rule, see [Delete an AppLocker rule](delete-an-applocker-rule.md).
- For information on the procedure to modify a rule, see [Edit AppLocker rules](edit-applocker-rules.md).
- For information on the procedure to delete a rule, see [Delete an AppLocker rule](delete-an-applocker-rule.md).
- For procedures to create rules, see:
- [Create a rule that uses a publisher condition](create-a-rule-that-uses-a-publisher-condition.md)
@ -72,7 +71,7 @@ AppLocker provides ways to modify, delete, or add rules to a policy by modifying
- [Create a rule that uses a file hash condition](create-a-rule-that-uses-a-file-hash-condition.md)
- [Enable the DLL rule collection](enable-the-dll-rule-collection.md)
- For steps to test an AppLocker policy, see [Test and update an AppLocker policy](test-and-update-an-applocker-policy.md).
- For information on the steps to test an AppLocker policy, see [Test and update an AppLocker policy](test-and-update-an-applocker-policy.md).
- For procedures to export the updated policy from the reference computer back into the GPO, see [Export an AppLocker policy to an XML file](export-an-applocker-policy-to-an-xml-file.md) and [Import an AppLocker policy into a GPO](import-an-applocker-policy-into-a-gpo.md).
### Step 4: Use AppLocker and Group Policy to import the AppLocker policy back into the GPO
@ -91,7 +90,7 @@ The steps to edit an AppLocker policy distributed by using the Local Security Po
On the PC where you maintain policies, open the AppLocker snap-in from the Local Security Policy snap-in (secpol.msc). If you exported the AppLocker policy from another PC, use AppLocker to import it onto the PC.
After exporting the AppLocker policy to an XML file, you should import the XML file onto a reference PC so that you can edit the policy. For the procedure to import an AppLocker policy, see [Import an AppLocker policy from another computer](import-an-applocker-policy-from-another-computer.md).
After exporting the AppLocker policy to an XML file, you should import the XML file onto a reference PC so that you can edit the policy. For information on the procedure to import an AppLocker policy, see [Import an AppLocker policy from another computer](import-an-applocker-policy-from-another-computer.md).
>**Caution:**  Importing a policy onto another PC will overwrite the existing policy on that PC.
 
@ -99,8 +98,8 @@ After exporting the AppLocker policy to an XML file, you should import the XML f
AppLocker provides ways to modify, delete, or add rules to a policy by modifying the rules within the collection.
- For the procedure to modify a rule, see [Edit AppLocker rules](edit-applocker-rules.md).
- For the procedure to delete a rule, see [Delete an AppLocker rule](delete-an-applocker-rule.md).
- For information on the procedure to modify a rule, see [Edit AppLocker rules](edit-applocker-rules.md).
- For information on the procedure to delete a rule, see [Delete an AppLocker rule](delete-an-applocker-rule.md).
- For procedures to create rules, see:
- [Create a rule that uses a publisher condition](create-a-rule-that-uses-a-publisher-condition.md)
@ -116,6 +115,6 @@ For steps to test an AppLocker policy, see [Test and update an AppLocker policy]
For procedures to export the updated policy from the reference computer to targeted computers, see [Export an AppLocker policy to an XML file](export-an-applocker-policy-to-an-xml-file.md) and [Import an AppLocker policy from another computer](import-an-applocker-policy-from-another-computer.md).
## Additional resources
## Other resources
- For steps to perform other AppLocker policy tasks, see [Administer AppLocker](administer-applocker.md).

View File

@ -57,7 +57,7 @@ For every scenario, the steps to maintain an AppLocker policy distributed by Gro
As new apps are deployed or existing apps are removed by your organization or updated by the software publisher, you might need to make revisions to your rules and update the Group Policy Object (GPO) to ensure that your policy is current.
You can edit an AppLocker policy by adding, changing, or removing rules. However, you cannot specify a version for the AppLocker policy by importing additional rules. To ensure version control when modifying an AppLocker policy, use Group Policy management software that allows you to create
You can edit an AppLocker policy by adding, changing, or removing rules. However, you can't specify a version for the AppLocker policy by importing more rules. To ensure version control when modifying an AppLocker policy, use Group Policy management software that allows you to create
versions of GPOs.
>**Caution:**  You should not edit an AppLocker rule collection while it is being enforced in Group Policy. Because AppLocker controls what files are allowed to run, making changes to a live policy can create unexpected behavior.
@ -74,7 +74,7 @@ Updating an AppLocker policy that is currently enforced in your production envir
After the AppLocker policy has been exported from the GPO into the AppLocker reference or test computer, or has been accessed on the local computer, the specific rules can be modified as required.
To modify AppLocker rules, see the following:
To modify AppLocker rules, see the following articles:
- [Edit AppLocker rules](edit-applocker-rules.md)
- [Merge AppLocker policies by using Set-ApplockerPolicy](merge-applocker-policies-by-using-set-applockerpolicy.md) or [Merge AppLocker policies manually](merge-applocker-policies-manually.md)
@ -101,7 +101,7 @@ Before modifying a policy, evaluate how the policy is currently implemented.
### Step 2: Update the AppLocker policy by modifying the appropriate AppLocker rule
Rules are grouped into a collection, which can have the policy enforcement setting applied to it. By default, AppLocker rules do not allow users to open or run any files that are not specifically allowed.
Rules are grouped into a collection, which can have the policy enforcement setting applied to it. By default, AppLocker rules don't allow users to open or run any files that aren't allowed.
To modify AppLocker rules, see the appropriate topic listed on [Administer AppLocker](administer-applocker.md).
@ -117,6 +117,6 @@ You can export and then import AppLocker policies to deploy the policy to other
After deploying a policy, evaluate the policy's effectiveness.
## Additional resources
## Other resources
- For steps to perform other AppLocker policy tasks, see [Administer AppLocker](administer-applocker.md).

View File

@ -34,7 +34,7 @@ This topic for IT professionals describes concepts and lists procedures to help
## Understanding Packaged apps and Packaged app installers for AppLocker
Packaged apps, also known as Universal Windows apps, are based on a model that ensures all the files within an app package share the same identity. With classic Windows apps, each file within the app could have a unique identity.
With packaged apps, it is possible to control the entire app by using a single AppLocker rule.
With packaged apps, it's possible to control the entire app by using a single AppLocker rule.
> [!NOTE]
> AppLocker supports only publisher rules for packaged apps. All packaged apps must be signed by the software publisher because Windows does not support unsigned packaged apps.
@ -46,8 +46,8 @@ Typically, an app consists of multiple components: the installer that is used to
AppLocker policies for packaged apps can only be applied to apps installed on computers running at least Windows Server 2012 or Windows 8, but classic Windows apps can be controlled on devices running at least Windows Server
2008 R2 or Windows 7. The rules for classic Windows apps and packaged apps can be enforced in tandem. The differences between packaged apps and classic Windows apps that you should consider include:
- **Installing the apps**   All packaged apps can be installed by a standard user, whereas a number of classic Windows apps require administrative privileges to install. In an environment where most of the users are standard users, you might not have numerous exe rules (because classic Windows apps require administrative privileges to install), but you might want to have more explicit policies for packaged apps.
- **Changing the system state**   Classic Windows apps can be written to change the system state if they are run with administrative privileges. Most packaged apps cannot change the system state because they run with limited privileges. When you design your AppLocker policies, it is important to understand whether an app that you are allowing can make system-wide changes.
- **Installing the apps**   All packaged apps can be installed by a standard user, whereas many classic Windows apps require administrative privileges to install. In an environment where most of the users are standard users, you might not have numerous exe rules (because classic Windows apps require administrative privileges to install), but you might want to have more explicit policies for packaged apps.
- **Changing the system state**   Classic Windows apps can be written to change the system state if they're run with administrative privileges. Most packaged apps can't change the system state because they run with limited privileges. When you design your AppLocker policies, it's important to understand whether an app that you're allowing can make system-wide changes.
- **Acquiring the apps**   Packaged apps can be acquired through the Store, or by loading using Windows PowerShell cmdlets (which requires a special enterprise license). Classic Windows apps can be acquired through traditional means.
AppLocker uses different rule collections to control packaged apps and classic Windows apps. You have the choice to control one type, the other type, or both.
@ -67,12 +67,12 @@ For info about how to use the **Get-AppxPackage** Windows PowerShell cmdlet, see
For info about creating rules for Packaged apps, see [Create a rule for packaged apps](create-a-rule-for-packaged-apps.md).
Consider the following info when you are designing and deploying apps:
Consider the following info when you're designing and deploying apps:
- Because AppLocker supports only publisher rules for packaged apps, collecting the installation path information for packaged apps is not necessary.
- You cannot create hash- or path-based rules for packaged apps because all packaged apps and packaged app installers are signed by the software publisher of the package. Classic Windows apps were not always consistently signed; therefore, AppLocker has to support hash- or path-based rules.
- By default, if there are no rules in a particular rule collection, AppLocker allows every file that is included in that rule collection. For example, if there are no Windows Installer rules, AppLocker allows all .msi, .msp, and .mst files to run. An existing AppLocker policy that was targeted at computers running Windows Server 2008 R2 and Windows 7 would not have rules for Packaged apps. Therefore, when a computer running at least Windows Server 2012 or
Windows 8 joins a domain where an AppLocker policy is already configured, users would be allowed to run any packaged app. This might be contrary to your design.
- Because AppLocker supports only publisher rules for packaged apps, collecting the installation path information for packaged apps isn't necessary.
- You can't create hash- or path-based rules for packaged apps because all packaged apps and packaged app installers are signed by the software publisher of the package. Classic Windows apps weren't always consistently signed; therefore, AppLocker has to support hash- or path-based rules.
- By default, if there are no rules in a particular rule collection, AppLocker allows every file that is included in that rule collection. For example, if there are no Windows Installer rules, AppLocker allows all .msi, .msp, and .mst files to run. An existing AppLocker policy that was targeted at computers running Windows Server 2008 R2 and Windows 7 wouldn't have rules for Packaged apps. Therefore, when a computer running at least Windows Server 2012 or
Windows 8 joins a domain where an AppLocker policy is already configured, users would be allowed to run any packaged app, which is contrary to your design.
To prevent all packaged apps from running on a newly domain-joined computer, by default AppLocker blocks all packaged apps on a computer running at least Windows Server 2012 or Windows 8 if the existing domain policy has rules configured in the exe rule collection. You must take explicit action to allow packaged apps in your enterprise. You can allow only a select set of packaged apps. Or if you want to allow all packaged apps, you can create a default rule for the packaged apps collection.
@ -80,10 +80,10 @@ Windows 8 joins a domain where an AppLocker policy is already configured, users
Just as there are differences in managing each rule collection, you need to manage the packaged apps with the following strategy:
1. Gather information about which Packaged apps are running in your environment. For information about how to do this, see [Create list of apps deployed to each business group](create-list-of-applications-deployed-to-each-business-group.md).
1. Gather information about which Packaged apps are running in your environment. For information about how to gather this information, see [Create list of apps deployed to each business group](create-list-of-applications-deployed-to-each-business-group.md).
2. Create AppLocker rules for specific packaged apps based on your policy strategies. For more information, see [Create a rule for packaged apps](create-a-rule-for-packaged-apps.md) and [Understanding AppLocker default rules](./understanding-applocker-default-rules.md).
3. Continue to update the AppLocker policies as new package apps are introduced into your environment. To do this, see [Add rules for packaged apps to existing AppLocker rule-set](add-rules-for-packaged-apps-to-existing-applocker-rule-set.md).
3. Continue to update the AppLocker policies as new package apps are introduced into your environment. To do this update, see [Add rules for packaged apps to existing AppLocker rule-set](add-rules-for-packaged-apps-to-existing-applocker-rule-set.md).
4. Continue to monitor your environment to verify the effectiveness of the rules that are deployed in AppLocker policies. To do this, see [Monitor app usage with AppLocker](monitor-application-usage-with-applocker.md).
4. Continue to monitor your environment to verify the effectiveness of the rules that are deployed in AppLocker policies. To do this monitoring, see [Monitor app usage with AppLocker](monitor-application-usage-with-applocker.md).

View File

@ -31,13 +31,13 @@ ms.technology: windows-sec
This topic for IT professionals describes the steps to merge AppLocker policies by using Windows PowerShell.
The **Set-AppLockerPolicy** cmdlet sets the specified Group Policy Object (GPO) to contain the specified AppLocker policy. If no Lightweight Directory Access Protocol (LDAP) is specified, the local GPO is the default. When the Merge parameter is used, rules in the specified AppLocker policy will be merged with the AppLocker rules in the target GPO specified in the LDAP path. The merging of policies will remove rules with duplicate rule IDs, and the enforcement setting specified by the AppLocker policy in the target GPO will be preserved. If the Merge parameter is not specified, then the new policy will overwrite the existing policy.
The **Set-AppLockerPolicy** cmdlet sets the specified Group Policy Object (GPO) to contain the specified AppLocker policy. If no Lightweight Directory Access Protocol (LDAP) is specified, the local GPO is the default. When the Merge parameter is used, rules in the specified AppLocker policy will be merged with the AppLocker rules in the target GPO specified in the LDAP path. The merging of policies will remove rules with duplicate rule IDs, and the enforcement setting specified by the AppLocker policy in the target GPO will be preserved. If the Merge parameter isn't specified, then the new policy will overwrite the existing policy.
For info about using **Set-AppLockerPolicy**, including syntax descriptions and parameters, see [Set-AppLockerPolicy](/powershell/module/applocker/set-applockerpolicy).
For info about using Windows PowerShell for AppLocker, including how to import the AppLocker cmdlets into Windows PowerShell, see [Use the AppLocker Windows PowerShell cmdlets](use-the-applocker-windows-powershell-cmdlets.md).
You can also manually merge AppLocker policies. For the procedure to do this, see [Merge AppLocker policies manually](merge-applocker-policies-manually.md).
You can also manually merge AppLocker policies. For information on the procedure to do this merging, see [Merge AppLocker policies manually](merge-applocker-policies-manually.md).
**To merge a local AppLocker policy with another AppLocker policy by using LDAP paths**
1. Open the PowerShell command window. For info about performing Windows PowerShell commands for AppLocker, see [Use the AppLocker Windows PowerShell cmdlets](use-the-applocker-windows-powershell-cmdlets.md).

View File

@ -31,7 +31,7 @@ ms.technology: windows-sec
This topic for IT professionals describes the steps to manually merge AppLocker policies to update the Group Policy Object (GPO).
If you have created multiple AppLocker policies and need to merge them to create one AppLocker policy, you can either manually merge the policies or use the Windows PowerShell cmdlets for AppLocker. You cannot automatically merge policies by using the AppLocker console. You must create one rule collection from two or more policies. For info about merging policies by using the cmdlet, see [Merge AppLocker policies by using Set-ApplockerPolicy](merge-applocker-policies-by-using-set-applockerpolicy.md).
If you have created multiple AppLocker policies and need to merge them to create one AppLocker policy, you can either manually merge the policies or use the Windows PowerShell cmdlets for AppLocker. You can't automatically merge policies by using the AppLocker console. You must create one rule collection from two or more policies. For info about merging policies by using the cmdlet, see [Merge AppLocker policies by using Set-ApplockerPolicy](merge-applocker-policies-by-using-set-applockerpolicy.md).
The AppLocker policy is saved in XML format, and the exported policy can be edited with any text or XML editor. Rule collections are specified within the **RuleCollection Type** element. The XML schema includes five attributes for the different rule collections, as shown in the following table:
@ -51,7 +51,7 @@ Rule enforcement is specified with the **EnforcementMode** element. The three en
| AuditOnly | Audit only|
| Enabled | Enforce rules|
Each of the three condition types use specific elements. For XML examples of the different rule types, see Merge AppLocker policies manually.
Each of the three condition types uses specific elements. For XML examples of the different rule types, see Merge AppLocker policies manually.
Membership in the local **Administrators** group, or equivalent, is the minimum required to complete this procedure.
@ -63,4 +63,4 @@ Membership in the local **Administrators** group, or equivalent, is the minimum
4. Open the policy where you want to add the copied rules.
5. Select and expand the rule collection where you want to add the rules.
6. At the bottom of the rule list for the collection, after the closing element, paste the rules that you copied from the first policy file. Verify that the opening and closing elements are intact, and then save the policy.
7. Upload the policy to a reference computer to ensure that it is functioning properly within the GPO.
7. Upload the policy to a reference computer to ensure that it's functioning properly within the GPO.

View File

@ -31,7 +31,7 @@ ms.technology: windows-sec
This topic for IT professionals describes how to monitor app usage when AppLocker policies are applied.
Once you set rules and deploy the AppLocker policies, it is good practice to determine if the policy implementation is what you expected.
Once you set rules and deploy the AppLocker policies, it's a good practice to determine if the policy implementation is what you expected.
### <a href="" id="bkmk-applkr-disc-effect-pol"></a>Discover the effect of an AppLocker policy
@ -39,27 +39,27 @@ You can evaluate how the AppLocker policy is currently implemented for documenta
- **Analyze the AppLocker logs in Event Viewer**
When AppLocker policy enforcement is set to **Enforce rules**, rules are enforced for the rule collection and all events are audited. When AppLocker policy enforcement is set to **Audit only**, rules are not enforced but are still evaluated to generate audit event data that is written to the AppLocker logs.
When AppLocker policy enforcement is set to **Enforce rules**, rules are enforced for the rule collection and all events are audited. When AppLocker policy enforcement is set to **Audit only**, rules aren't enforced but are still evaluated to generate audit event data that is written to the AppLocker logs.
For the procedure to access the log, see [View the AppLocker Log in Event Viewer](#bkmk-applkr-view-log).
For more information on the procedure to access the log, see [View the AppLocker Log in Event Viewer](#bkmk-applkr-view-log).
- **Enable the Audit only AppLocker enforcement setting**
By using the **Audit only** enforcement setting, you can ensure that the AppLocker rules are properly configured for your organization. When AppLocker policy enforcement is set to **Audit only**, rules are only evaluated but all events generated from that evaluation are written to the AppLocker log.
For the procedure to do this, see [Configure an AppLocker policy for audit only](configure-an-applocker-policy-for-audit-only.md).
For more information on the procedure to do this configuration, see [Configure an AppLocker policy for audit only](configure-an-applocker-policy-for-audit-only.md).
- **Review AppLocker events with Get-AppLockerFileInformation**
For both event subscriptions and local events, you can use the **Get-AppLockerFileInformation** Windows PowerShell cmdlet to determine which files have been blocked or would have been blocked (if you are using the audit-only enforcement mode) and how many times the event has occurred for each file.
For both event subscriptions and local events, you can use the **Get-AppLockerFileInformation** Windows PowerShell cmdlet to determine which files have been blocked or would have been blocked (if you're using the audit-only enforcement mode) and how many times the event has occurred for each file.
For the procedure to do this, see [Review AppLocker Events with Get-AppLockerFileInformation](#bkmk-applkr-review-events).
For more information on the procedure to do this verification, see [Review AppLocker Events with Get-AppLockerFileInformation](#bkmk-applkr-review-events).
- **Review AppLocker events with Test-AppLockerPolicy**
You can use the **Test-AppLockerPolicy** Windows PowerShell cmdlet to determine whether any of the rules in your rule collections will be blocked on your reference device or the device on which you maintain policies.
For the procedure to do this, see [Test an AppLocker policy by using Test-AppLockerPolicy](test-an-applocker-policy-by-using-test-applockerpolicy.md).
For more information on the procedure to do this testing, see [Test an AppLocker policy by using Test-AppLockerPolicy](test-an-applocker-policy-by-using-test-applockerpolicy.md).
### <a href="" id="bkmk-applkr-review-events"></a>Review AppLocker events with Get-AppLockerFileInformation
@ -93,7 +93,7 @@ Membership in the local **Administrators** group, or equivalent, is the minimum
**To view events in the AppLocker log by using Event Viewer**
1. Open Event Viewer. To do this, click **Start**, type **eventvwr.msc**, and then press ENTER.
1. To open Event Viewer, go to the **Start** menu, type **eventvwr.msc**, and then select ENTER.
2. In the console tree under **Application and Services Logs\\Microsoft\\Windows**, double-click **AppLocker**.
AppLocker events are listed in either the **EXE and DLL** log, the **MSI and Script** log, or the **Packaged app-Deployment** or **Packaged app-Execution** log. Event information includes the enforcement setting, file name, date and time, and user name. The logs can be exported to other file

View File

@ -32,7 +32,7 @@ ms.technology: windows-sec
This topic explains the AppLocker rule collection for packaged app installers and packaged apps.
Universal Windows apps can be installed through the Microsoft Store or can be sideloaded using the Windows PowerShell cmdlets. Universal Windows apps can be installed by a standard user unlike some Classic Windows applications that sometimes require administrative privileges for installation.
Typically, an app consists of multiple components the installer used to install the app and one or more exes, dlls or scripts. With Classic Windows applications, not all those components always share common attributes such as the publisher name, product name and product version. Therefore, AppLocker has to control each of these components separately through different rule collections exe, dll, script and Windows Installers. In contrast, all the components of a Universal Windows app share the same attributes: Publisher name, Package name and Package version. It is therefore possible to control an entire app with a single rule.
Typically, an app consists of multiple components the installer used to install the app and one or more exes, dlls or scripts. With Classic Windows applications, not all those components always share common attributes such as the publisher name, product name and product version. Therefore, AppLocker has to control each of these components separately through different rule collections exe, dll, script and Windows Installers. In contrast, all the components of a Universal Windows app share the same attributes: Publisher name, Package name and Package version. It's therefore possible to control an entire app with a single rule.
AppLocker enforces rules for Universal Windows apps separately from Classic Windows applications. A single AppLocker rule for a Universal Windows app can control both the installation and the running of an app. Because all Universal Windows apps are signed, AppLocker supports only publisher rules for Universal Windows apps. A publisher rule for a Universal Windows app is based on the following attributes of the app:

View File

@ -1,6 +1,6 @@
---
title: Plan for AppLocker policy management (Windows)
description: This topic for describes the decisions you need to make to establish the processes for managing and maintaining AppLocker policies.
description: This topic describes the decisions you need to make to establish the processes for managing and maintaining AppLocker policies.
ms.assetid: dccc196f-6ae0-4ae4-853a-a3312b18751b
ms.reviewer:
ms.author: dansimp
@ -29,7 +29,7 @@ ms.technology: windows-sec
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
This topic for describes the decisions you need to make to establish the processes for managing and maintaining AppLocker policies.
This topic describes the decisions you need to make to establish the processes for managing and maintaining AppLocker policies.
## Policy management
@ -46,23 +46,23 @@ Developing a process for managing AppLocker rules helps assure that AppLocker co
**Help desk support**
If your organization has an established help desk support department in place, consider the following when deploying AppLocker policies:
If your organization has an established help desk support department in place, consider the following points when deploying AppLocker policies:
- What documentation does your support department require for new policy deployments?
- What are the critical processes in each business group both in work flow and timing that will be affected by application control policies and how could they affect your support department's workload?
- Who are the contacts in the support department?
- How will the support department resolve application control issues between the end user and those who maintain the AppLocker rules?
- How will the support department resolve application control issues between the end user and those resources who maintain the AppLocker rules?
**End-user support**
Because AppLocker is preventing unapproved apps from running, it is important that your organization carefully plan how to provide end-user support. Considerations include:
Because AppLocker is preventing unapproved apps from running, it's important that your organization carefully plans how to provide end-user support. Considerations include:
- Do you want to use an intranet site as a first line of support for users who have tried to run a blocked app?
- How do you want to support exceptions to the policy? Will you allow users to run a script to temporarily allow access to a blocked app?
**Using an intranet site**
AppLocker can be configured to display the default message but with a custom URL. You can use this URL to redirect users to a support site that contains information about why the user received the error and which applications are allowed. If you do not display a custom URL for the message when an app is blocked, the default URL is used.
AppLocker can be configured to display the default message but with a custom URL. You can use this URL to redirect users to a support site that contains information about why the user received the error and which applications are allowed. If you don't display a custom URL for the message when an app is blocked, the default URL is used.
The following image shows an example of the error message for a blocked app. You can use the **Set a support web link** policy setting to customize the **More information** link.
@ -72,7 +72,7 @@ For steps to display a custom URL for the message, see [Display a custom URL mes
**AppLocker event management**
Each time that a process requests permission to run, AppLocker creates an event in the AppLocker event log. The event details which file tried to run, the attributes of that file, the user that initiated the request, and the rule GUID that was used to make the AppLocker execution decision. The
Each time that a process requests permission to run, AppLocker creates an event in the AppLocker event log. The event details which was the file that tried to run, the attributes of that file, the user that initiated the request, and the rule GUID that was used to make the AppLocker execution decision. The
AppLocker event log is located in the following path: **Applications and Services Logs\\Microsoft\\Windows\\AppLocker**. The AppLocker log includes three logs:
1. **EXE and DLL**. Contains events for all files affected by the executable and DLL rule collections (.exe, .com, .dll, and .ocx).
@ -83,22 +83,22 @@ Collecting these events in a central location can help you maintain your AppLock
### Policy maintenance
As new apps are deployed or existing apps are updated by the software publisher, you will need to make revisions to your rule collections to ensure that the policy is current.
As new apps are deployed or existing apps are updated by the software publisher, you'll need to make revisions to your rule collections to ensure that the policy is current.
You can edit an AppLocker policy by adding, changing, or removing rules. However, you cannot specify a version for the policy by importing additional rules. To ensure version control when modifying an AppLocker policy, use Group Policy management software that allows you to create versions of Group Policy Objects (GPOs). An example of this type of software is the Advanced Group Policy Management feature from the Microsoft Desktop Optimization Pack. For more info about Advanced Group Policy Management, see [Advanced Group Policy Management Overview](https://go.microsoft.com/fwlink/p/?LinkId=145013) (https://go.microsoft.com/fwlink/p/?LinkId=145013).
You can edit an AppLocker policy by adding, changing, or removing rules. However, you can't specify a version for the policy by importing more rules. To ensure version control when modifying an AppLocker policy, use Group Policy management software that allows you to create versions of Group Policy Objects (GPOs). An example of this type of software is the Advanced Group Policy Management feature from the Microsoft Desktop Optimization Pack. For more info about Advanced Group Policy Management, see [Advanced Group Policy Management Overview](https://go.microsoft.com/fwlink/p/?LinkId=145013) (https://go.microsoft.com/fwlink/p/?LinkId=145013).
> [!IMPORTANT]
> You should not edit an AppLocker rule collection while it is being enforced in Group Policy. Because AppLocker controls what files are allowed to run, making changes to a live policy can create unexpected behavior.
**New version of a supported app**
When a new version of an app is deployed in the organization, you need to determine whether to continue to support the previous version of that app. To add the new version, you might only need to create a new rule for each file that is associated with the app. If you are using publisher conditions and the version is not specified, then the existing rule or rules might be sufficient to allow the updated file to run. You must ensure, however, that the updated app has not altered the file names or added files to support new functionality. If so, then you must modify the existing rules or create new rules. To continue to reuse a publisher-based rule without a specific file version, you must also ensure that the file's digital signature is still identical to the previous version—the publisher, product name, and file name (if configured in your rule) must all match for the rule to be correctly applied.
When a new version of an app is deployed in the organization, you need to determine whether to continue to support the previous version of that app. To add the new version, you might only need to create a new rule for each file that is associated with the app. If you're using publisher conditions and the version isn't specified, then the existing rule or rules might be sufficient to allow the updated file to run. You must ensure, however, that the updated app hasn't altered the file names or added files to support new functionality. If so, then you must modify the existing rules or create new rules. To continue to reuse a publisher-based rule without a specific file version, you must also ensure that the file's digital signature is still identical to the previous version—the publisher, product name, and file name (if configured in your rule) must all match for the rule to be correctly applied.
To determine whether a file has been modified during an app update, review the publisher's release details provided with the update package. You can also review the publisher's web page to retrieve this information. Each file can also be inspected to determine the version.
For files that are allowed or denied with file hash conditions, you must retrieve the new file hash. To add support for a new version and maintain support for the older version, you can either create a new file hash rule for the new version or edit the existing rule and add the new file hash to the list of conditions.
For files with path conditions, you should verify that the installation path has not changed from what is stated in the rule. If the path has changed, you need to update the rule before installing the new version of the app
For files with path conditions, you should verify that the installation path hasn't changed from what is stated in the rule. If the path has changed, you need to update the rule before installing the new version of the app
**Recently deployed app**
@ -114,7 +114,7 @@ A file could be blocked for three reasons:
- The most common reason is that no rule exists to allow the app to run.
- There may be an existing rule that was created for the file that is too restrictive.
- A deny rule, which cannot be overridden, is explicitly blocking the file.
- A deny rule, which can't be overridden, is explicitly blocking the file.
Before editing the rule collection, first determine what rule is preventing the file from running. You can troubleshoot the problem by using the **Test-AppLockerPolicy** Windows PowerShell cmdlet. For more info about troubleshooting an AppLocker policy, see [Testing and Updating an AppLocker Policy](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ee791793(v=ws.10)) (https://go.microsoft.com/fwlink/p/?LinkId=160269).
@ -132,7 +132,7 @@ The three key areas to determine for AppLocker policy management are:
1. Support policy
Document the process that you will use for handling calls from users who have attempted to run a blocked app, and ensure that support personnel know recommended troubleshooting steps and escalation points for your policy.
Document the process that you'll use for handling calls from users who have attempted to run a blocked app, and ensure that support personnel know recommended troubleshooting steps and escalation points for your policy.
2. Event processing
@ -149,7 +149,7 @@ The following table contains the added sample data that was collected when deter
|Bank Tellers|Teller-East and Teller-West|Yes|Teller Software|C:\Program Files\Woodgrove\Teller.exe|File is signed; create a publisher condition|Allow|Tellers-AppLockerTellerRules|Web help|
||||Windows files|C:\Windows|Create a path exception to the default rule to exclude \Windows\Temp|Allow||Help desk|
|Human Resources|HR-All|Yes|Check Payout|C:\Program Files\Woodgrove\HR\Checkcut.exe|File is signed; create a publisher condition|Allow|HR-AppLockerHRRules|Web help|
||||Time Sheet Organizer|C:\Program Files\Woodgrove\HR\Timesheet.exe|File is not signed; create a file hash condition|Allow||Web help|
||||Time Sheet Organizer|C:\Program Files\Woodgrove\HR\Timesheet.exe|File isn't signed; create a file hash condition|Allow||Web help|
||||Internet Explorer 7|C:\Program Files\Internet Explorer</p>|File is signed; create a publisher condition|Deny||Web help|
||||Windows files|C:\Windows|Use the default rule for the Windows path|Allow||Help desk|
@ -157,7 +157,7 @@ The following two tables illustrate examples of documenting considerations to ma
**Event processing policy**
One discovery method for app usage is to set the AppLocker enforcement mode to **Audit only**. This will write events to the AppLocker logs, which can be managed and analyzed like other Windows logs. After apps have been identified, you can begin to develop policies regarding the processing and access to AppLocker events.
One discovery method for app usage is to set the AppLocker enforcement mode to **Audit only**. This setting will write events to the AppLocker logs, which can be managed and analyzed like other Windows logs. After apps have been identified, you can begin to develop policies regarding the processing and access to AppLocker events.
The following table is an example of what to consider and record.

View File

@ -42,7 +42,7 @@ To complete this procedure, you must have Edit Setting permission to edit a GPO
**To manually refresh the AppLocker policy by using Group Policy**
1. From a command prompt, type **gpupdate /force**, and then press ENTER.
2. When the command finishes, close the command prompt window, and then verify that the intended rule behavior is correct. You can do this by checking the AppLocker event logs for events that include "policy applied."
2. When the command finishes, close the command prompt window, and then verify that the intended rule behavior is correct. You can do this verification by checking the AppLocker event logs for events that include "policy applied."
To change a policy on an individual computer, or to implement that policy on other computers, without using Group Policy, you first need to update the rule within the rule collection. For information about updating existing rules, see [Edit AppLocker rules](edit-applocker-rules.md). For information
about creating a new rule for an existing policy, see:
@ -64,8 +64,8 @@ When finished, the policy is in effect.
To make the same change on another device, you can use any of the following methods:
- From the device that you made the change on, export the AppLocker policy, and then import the policy onto the other device. To do this, use the AppLocker **Export Policy** and **Import Policy** features to copy the rules from the changed computer.
- From the device that you made the change on, export the AppLocker policy, and then import the policy onto the other device. To do these tasks, use the AppLocker **Export Policy** and **Import Policy** features to copy the rules from the changed computer.
>**Caution:**  When importing rules from another computer, all the rules will be applied, not just the one that was updated. Merging policies allows both existing and updated (or new) rules to be applied.
 
- Merge AppLocker policies. For procedures to do this, see [Merge AppLocker policies manually](merge-applocker-policies-manually.md) and [Merge AppLocker policies by using Set-ApplockerPolicy](merge-applocker-policies-by-using-set-applockerpolicy.md).
- Merge AppLocker policies. For information on the procedures to do this merging, see [Merge AppLocker policies manually](merge-applocker-policies-manually.md) and [Merge AppLocker policies by using Set-ApplockerPolicy](merge-applocker-policies-by-using-set-applockerpolicy.md).

View File

@ -40,15 +40,15 @@ You can perform this task by using the Group Policy Management Console for an Ap
1. Open the AppLocker console.
2. Right-click the appropriate rule type for which you want to automatically generate rules. You can automatically generate rules for executable, Windows Installer, script and packaged app rules.
3. Click **Automatically Generate Rules**.
4. On the **Folder and Permissions** page, click **Browse** to choose the folder to be analyzed. By default, this is the Program Files folder.
5. Click **Select** to choose the security group in which the default rules should be applied. By default, this is the **Everyone** group.
6. The wizard provides a name in the **Name to identify this set of rules** box based on the name of the folder that you have selected. Accept the provided name or type a different name, and then click **Next**.
4. On the **Folder and Permissions** page, click **Browse** to choose the folder to be analyzed. By default, this folder is the Program Files folder.
5. Click **Select** to choose the security group in which the default rules should be applied. By default, this group is the **Everyone** group.
6. The wizard provides a name in the **Name to identify this set of rules** box based on the name of the folder that you've selected. Accept the provided name or type a different name, and then click **Next**.
7. On the **Rule Preferences** page, choose the conditions that you want the wizard to use while creating rules, and then click **Next**. For more info about rule conditions, see [Understanding AppLocker rule condition types](understanding-applocker-rule-condition-types.md).
>**Note:** The **Reduce the number of rules created by grouping similar files** check box is selected by default. This helps you organize AppLocker rules and reduce the number of rules that you create by performing the following operations for the rule condition that you select:
- One publisher condition is created for all files that have the same publisher and product name.
- One path condition is created for the folder that you select. For example, if you select *C:\\Program Files\\ProgramName\\* and the files in that folder are not signed, the wizard creates a rule for *%programfiles%\\ProgramName\\\**.
- One path condition is created for the folder that you select. For example, if you select *C:\\Program Files\\ProgramName\\* and the files in that folder aren't signed, the wizard creates a rule for *%programfiles%\\ProgramName\\\**.
- One file hash condition is created that contains all of the file hashes. When rule grouping is disabled, the wizard creates a file hash rule for each file.
8. Review the files that were analyzed and the rules that will be automatically created. To make changes, click **Previous** to return to the page where you can change your selections. After reviewing the rules, click **Create**.

View File

@ -34,26 +34,26 @@ This topic for the IT professional describes the security considerations you nee
The purpose of AppLocker is to restrict the access to software, and therefore, the data accessed by the software, to a specific group of users or within a defined business group. The following are security considerations for
AppLocker:
AppLocker is deployed within an enterprise and administered centrally by those in IT with trusted credentials. This makes its policy creation and deployment conform to similar policy deployment processes and security restrictions.
AppLocker is deployed within an enterprise and administered centrally by those resources in IT with trusted credentials. This system makes its policy creation and deployment conform to similar policy deployment processes and security restrictions.
AppLocker policies are distributed through known processes and by known means within the domain through Group Policy. But AppLocker policies can also be set on individual computers if the person has administrator privileges, and those policies might be contrary to the organization's written security policy. The enforcement settings for local policies are overridden by the same AppLocker policies in a Group Policy Object (GPO). However, because AppLocker rules are additive, a local policy that is not in a GPO will still be evaluated for that computer.
AppLocker policies are distributed through known processes and by known means within the domain through Group Policy. But AppLocker policies can also be set on individual computers if the person has administrator privileges, and those policies might be contrary to the organization's written security policy. The enforcement settings for local policies are overridden by the same AppLocker policies in a Group Policy Object (GPO). However, because AppLocker rules are additive, a local policy that isn't in a GPO will still be evaluated for that computer.
Microsoft does not provide a way to develop any extensions to AppLocker. The interfaces are not public. A user with administrator credentials can automate some AppLocker processes by using Windows PowerShell cmdlets. For info about the Windows PowerShell cmdlets for AppLocker, see the [AppLocker Cmdlets in Windows PowerShell](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ee460962(v=technet.10)).
Microsoft doesn't provide a way to develop any extensions to AppLocker. The interfaces aren't public. A user with administrator credentials can automate some AppLocker processes by using Windows PowerShell cmdlets. For info about the Windows PowerShell cmdlets for AppLocker, see the [AppLocker Cmdlets in Windows PowerShell](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ee460962(v=technet.10)).
AppLocker runs in the context of Administrator or LocalSystem, which is the highest privilege set. This security context has the potential of misuse. If a user with administrative credentials makes changes to an AppLocker policy on a local device that is joined to a domain, those changes could be overwritten or disallowed by the GPO that contains the AppLocker rule for the same file (or path) that was changed on the local device. However, because AppLocker rules are additive, a local policy that is not in a GPO will still be evaluated for that computer. If the local computer is not joined to a domain and is not administered by Group Policy, a person with administrative credentials can alter the AppLocker policy.
AppLocker runs in the context of Administrator or LocalSystem, which is the highest privilege set. This security context has the potential of misuse. If a user with administrative credentials makes changes to an AppLocker policy on a local device that is joined to a domain, those changes could be overwritten or disallowed by the GPO that contains the AppLocker rule for the same file (or path) that was changed on the local device. However, because AppLocker rules are additive, a local policy that isn't in a GPO will still be evaluated for that computer. If the local computer isn't joined to a domain and isn't administered by Group Policy, a person with administrative credentials can alter the AppLocker policy.
When securing files in a directory with a rule of the path condition type, whether using the allow or deny action on the rule, it is still necessary and good practice to restrict access to those files by setting the access control lists (ACLs) according to your security policy.
When files are being secured in a directory with a rule of the path condition type, whether using the allow or deny action on the rule, it's still necessary and good practice to restrict access to those files by setting the access control lists (ACLs) according to your security policy.
AppLocker does not protect against running 16-bit DOS binaries in the Virtual DOS Machine (NTVDM). This technology allows running legacy DOS and 16-bit Windows programs on computers that are using Intel 80386 or later when there is already another operating system running and controlling the hardware. The result is that 16-bit binaries can still run on Windows Server 2008 R2 and Windows 7 when AppLocker is configured to otherwise block binaries and libraries. If it is a requirement to prevent 16-bit applications from running, you must configure the Deny rule in the executable rule collection for NTVDM.exe.
AppLocker doesn't protect against running 16-bit DOS binaries in the Virtual DOS Machine (NTVDM). This technology allows running legacy DOS and 16-bit Windows programs on computers that are using Intel 80386 or later when there's already another operating system running and controlling the hardware. The result is that 16-bit binaries can still run on Windows Server 2008 R2 and Windows 7 when AppLocker is configured to otherwise block binaries and libraries. If it's a requirement to prevent 16-bit applications from running, you must configure the Deny rule in the executable rule collection for NTVDM.exe.
You cannot use AppLocker (or Software Restriction Policies) to prevent code from running outside the Win32 subsystem. In particular, this applies to the (POSIX) subsystem in Windows NT. If it is a requirement to prevent applications from running in the POSIX subsystem, you must disable the subsystem.
You can't use AppLocker (or Software Restriction Policies) to prevent code from running outside the Win32 subsystem. In particular, this rule applies to the (POSIX) subsystem in Windows NT. If it's a requirement to prevent applications from running in the POSIX subsystem, you must disable the subsystem.
AppLocker can only control VBScript, JScript, .bat files, .cmd files, and Windows PowerShell scripts. It does not control all interpreted code that runs within a host process, for example, Perl scripts and macros. Interpreted code is a form of executable code that runs within a host process. For example, Windows batch files (\*.bat) run within the context of the Windows Command Host (cmd.exe). To control interpreted code by using AppLocker, the host process must call AppLocker before it runs the interpreted code, and then enforce the decision returned by AppLocker. Not all host processes call into AppLocker and, therefore, AppLocker cannot control every kind of interpreted code, such as Microsoft Office macros.
AppLocker can only control VBScript, JScript, .bat files, .cmd files, and Windows PowerShell scripts. It doesn't control all interpreted code that runs within a host process, for example, Perl scripts and macros. Interpreted code is a form of executable code that runs within a host process. For example, Windows batch files (\*.bat) run within the context of the Windows Command Host (cmd.exe). To control interpreted code by using AppLocker, the host process must call AppLocker before it runs the interpreted code, and then enforce the decision returned by AppLocker. Not all host processes call into AppLocker and, therefore, AppLocker can't control every kind of interpreted code, such as Microsoft Office macros.
> [!IMPORTANT]
> You should configure the appropriate security settings of these host processes if you must allow them to run. For example, configure the security settings in Microsoft Office to ensure that only signed and trusted macros are loaded.
AppLocker rules either allow or prevent an application from launching. AppLocker does not control the behavior of applications after they are launched. Applications could contain flags passed to functions that signal AppLocker to circumvent the rules and allow another .exe or .dll to be loaded. In practice, an application that is allowed by AppLocker could use these flags to bypass AppLocker rules and launch child processes. You must thoroughly examine each application before allowing them to run by using AppLocker rules.
AppLocker rules either allow or prevent an application from launching. AppLocker doesn't control the behavior of applications after they're launched. Applications could contain flags passed to functions that signal AppLocker to circumvent the rules and allow another .exe or .dll to be loaded. In practice, an application that is allowed by AppLocker could use these flags to bypass AppLocker rules and launch child processes. You must thoroughly examine each application before allowing them to run by using AppLocker rules.
> [!NOTE]
> Two flags that illustrate this condition are `SANDBOX_INERT`, which can be passed to `CreateRestrictedToken`, and `LOAD_IGNORE_CODE_AUTHZ_LEVEL`, which can be passed to `LoadLibraryEx`. Both of these flags signal AppLocker to circumvent the rules and allow a child .exe or .dll to be loaded.

View File

@ -52,7 +52,7 @@ The rules you create will be in one of the following rule collections:
- Packaged apps and packaged app installers: .appx
- DLLs: .dll and .ocx
By default, the rules will allow a file to run based upon user or group privilege. If you use DLL rules, a DLL allow rule has to be created for each DLL that is used by all of the allowed apps. The DLL rule collection is not enabled by default.
By default, the rules will allow a file to run based upon user or group privilege. If you use DLL rules, a DLL allow rule has to be created for each DLL that is used by all of the allowed apps. The DLL rule collection isn't enabled by default.
In the Woodgrove Bank example, the line-of-business app for the Bank Tellers business group is C:\\Program Files\\Woodgrove\\Teller.exe, and this app needs to be included in a rule. In addition, because this rule is part of a list of allowed applications, all the Windows files under C:\\Windows must be included as well.
@ -66,13 +66,13 @@ A rule condition is criteria upon which an AppLocker rule is based and can only
| Path| Any file can be assigned this rule condition; however, because path rules specify locations within the file system, any subdirectory will also be affected by the rule (unless explicitly exempted).| For more info about this rule condition, see [Understanding the path rule condition in AppLocker](understanding-the-path-rule-condition-in-applocker.md). |
| File hash | Any file can be assigned this rule condition; however, the rule must be updated each time a new version of the file is released because the hash value is based in part upon the version.| For more info about this rule condition, see [Understanding the file hash rule condition in AppLocker](understanding-the-file-hash-rule-condition-in-applocker.md). |
In the Woodgrove Bank example, the line-of-business app for the Bank Tellers business group is signed and is located at C:\\Program Files\\Woodgrove\\Teller.exe. Therefore, the rule can be defined with a publisher condition. If the rule is defined to a specific version and above (for example, Teller.exe version 8.0 and above), then this will allow any updates to this app to occur without interruption of access to the users if the app's name and signed attributes stay the same.
In the Woodgrove Bank example, the line-of-business app for the Bank Tellers business group is signed and is located at C:\\Program Files\\Woodgrove\\Teller.exe. Therefore, the rule can be defined with a publisher condition. If the rule is defined to a specific version and above (for example, Teller.exe version 8.0 and above), then this rule will allow any updates to this app to occur without interruption of access to the users if the app's name and signed attributes stay the same.
### Determine how to allow system files to run
Because AppLocker rules build a list of allowed apps, a rule or rules must be created to allow all Windows files to run. AppLocker provides a means to ensure system files are properly considered in your rule collection by generating the default rules for each rule collection. You can use the default rules (listed in [AppLocker default rules](working-with-applocker-rules.md#applocker-default-rules)) as a template when creating your own rules. However, these rules are only meant to function as a starter policy when you are first testing AppLocker rules so that the system files in the Windows folders will be allowed to run. When a default rule is created, it is denoted with "(Default rule)" in its name as it appears in the rule collection.
Because AppLocker rules build a list of allowed apps, a rule or rules must be created to allow all Windows files to run. AppLocker provides a means to ensure system files are properly considered in your rule collection by generating the default rules for each rule collection. You can use the default rules (listed in [AppLocker default rules](working-with-applocker-rules.md#applocker-default-rules)) as a template when creating your own rules. However, these rules are only meant to function as a starter policy when you're first testing AppLocker rules so that the system files in the Windows folders will be allowed to run. When a default rule is created, it's denoted with "(Default rule)" in its name as it appears in the rule collection.
You can also create a rule for the system files based on the path condition. In the preceding example, for the Bank Tellers group, all Windows files reside under C:\\Windows and can be defined with the path rule condition type. This will permit access to these files whenever updates are applied and the files change. If you require additional application security, you might need to modify the rules created from the built-in default rule collection. For example, the default rule to allow all users to run .exe files in the Windows folder is based on a path condition that allows all files within the Windows folder to run. The Windows folder contains a Temp subfolder to which the Users group is given the following permissions:
You can also create a rule for the system files based on the path condition. In the preceding example, for the Bank Tellers group, all Windows files reside under C:\\Windows and can be defined with the path rule condition type. This rule will permit access to these files whenever updates are applied and the files change. If you require more application security, you might need to modify the rules created from the built-in default rule collection. For example, the default rule to allow all users to run .exe files in the Windows folder is based on a path condition that allows all files within the Windows folder to run. The Windows folder contains a Temp subfolder to which the Users group is given the following permissions:
- Traverse Folder/Execute File
- Create Files/Write Data
@ -82,6 +82,6 @@ These permissions settings are applied to this folder for application compatibil
## Next steps
After you have selected the types of rules to create, record your findings as explained in [Document your AppLocker rules](document-your-applocker-rules.md).
After you've selected the types of rules to create, record your findings as explained in [Document your AppLocker rules](document-your-applocker-rules.md).
After recording your findings for the AppLocker rules to create, you will need to consider how to enforce the rules. For info about how to do this, see [Determine Group Policy structure and rule enforcement](determine-group-policy-structure-and-rule-enforcement.md).
After recording your findings for the AppLocker rules to create, you'll need to consider how to enforce the rules. For information about how to do this enforcement, see [Determine Group Policy structure and rule enforcement](determine-group-policy-structure-and-rule-enforcement.md).

View File

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

View File

@ -49,7 +49,7 @@ The following tools can help you administer the application control policies cre
You can edit an AppLocker policy by adding, changing, or removing rules by using the Group Policy Management Console (GPMC).
If you want additional features to manage AppLocker policies, such as version control, use Group Policy management software that allows you to create versions of Group Policy Objects (GPOs). An example of this type of software is the Advanced Group Policy Management feature from the Microsoft Desktop Optimization Pack.
If you want more features to manage AppLocker policies, such as version control, use Group Policy management software that allows you to create versions of Group Policy Objects (GPOs). An example of this type of software is the Advanced Group Policy Management feature from the Microsoft Desktop Optimization Pack.
- **Remote Server Administration Tools (RSAT)**

View File

@ -31,11 +31,11 @@ ms.technology: windows-sec
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.
Rule enforcement is applied only to a collection of rules, not to individual rules. AppLocker divides the rules into four collections: executable files, Windows Installer files, scripts, and DLL files. For more info about rule collections, see [Understanding AppLocker rule collections](understanding-applocker-rule-collections.md). By default, if enforcement isn't configured and rules are present in a rule collection, those rules are enforced. The following table details the three AppLocker rule enforcement settings in Group Policy for each rule collection.
| Enforcement setting | Description |
| - | - |
| Not configured | By default, enforcement 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.|
| Not configured | By default, enforcement isn't configured in a rule collection. If rules are present in the corresponding rule collection, they're enforced. If rule enforcement is configured in a higher-level linked Group Policy object (GPO), that enforcement value overrides the **Not configured** value.|
| Enforce rules | Rules are enforced for the rule collection, and all rule events are audited.|
| Audit only | Rule events are audited only. Use this value when planning and testing AppLocker rules.|

View File

@ -1,6 +1,6 @@
---
title: Understand AppLocker policy design decisions (Windows)
description: Review some common considerations while you are planning to use AppLocker to deploy application control policies within a Windows environment.
description: Review some common considerations while you're planning to use AppLocker to deploy application control policies within a Windows environment.
ms.assetid: 3475def8-949a-4b51-b480-dc88b5c1e6e6
ms.reviewer:
ms.author: macapara
@ -42,34 +42,34 @@ You should consider using AppLocker as part of your organization's application c
- 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).
The following questions aren't in priority or sequential order. They should be considered when you deploy application control policies (as appropriate for your targeted environment).
### Which apps do you need to control in your organization?
You might need to control a limited number of 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.
You might need to control a limited number of applications because they access sensitive data, or you might have to exclude all applications except those applications that are sanctioned for business purposes. There might be certain business groups that require strict control, and others that promote independent application usage.
| Possible answers | Design considerations|
| - | - |
| Control all apps | AppLocker policies control applications by creating an allowed list of applications by file type. Exceptions are also possible. AppLocker policies can only be applied to applications installed on computers running one of the supported versions of Windows. For specific operating system version requirements, see [Requirements to use AppLocker](requirements-to-use-applocker.md).|
| Control specific apps | When you create AppLocker rules, a list of allowed apps is created. All 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 specific apps | When you create AppLocker rules, a list of allowed apps is created. All applications on that list will be allowed to run (except those applications on the exception list). Applications that aren't on the list will be prevented from running. AppLocker policies can only be applied to apps installed on computers running any of the supported versions of Windows. For specific operating system version requirements, see [Requirements to use AppLocker](requirements-to-use-applocker.md).|
|Control only Classic Windows applications, only Universal Windows apps, or both| AppLocker policies control apps by creating an allowed list of apps by file type. Because Universal Windows apps are categorized under the Publisher condition, Classic Windows applications and Universal Windows apps can be controlled together. AppLocker policies for Universal Windows apps can be applied only to apps that are installed on PCs that support the Microsoft Store, but Classic Windows applications can be controlled with AppLocker on all supported versions of Windows. The rules you currently have configured for Classic Windows applications can remain, and you can create new ones for Universal Windows apps.<br/>For a comparison of Classic Windows applications and Universal Windows apps, see [Comparing Classic Windows applications and Universal Windows apps for AppLocker policy design decisions](#bkmk-compareclassicmetro) in this topic.|
| Control apps by business group and user | AppLocker policies can be applied through a Group Policy Object (GPO) to computer objects within an organizational unit (OU). Individual AppLocker rules can be applied to individual users or to groups of users.|
| Control apps by computer, not user | AppLocker is a computer-based policy implementation. If your domain or site organizational structure 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.|
| Control apps by computer, not user | AppLocker is a computer-based policy implementation. If your domain or site organizational structure isn't based on a logical user structure, such as an OU, you might want to set up that structure before you begin your AppLocker planning. Otherwise, you'll have to identify users, their computers, and their app access requirements.|
|Understand app usage, but there's no need to control any apps yet | AppLocker policies can be set to audit app usage to help you track which apps are used in your organization. You can then use the AppLocker event log to create AppLocker policies.|
> [!IMPORTANT]
> The following list contains files or types of files that cannot be managed by AppLocker:
- AppLocker does not protect against running 16-bit DOS binaries in an NT Virtual DOS Machine (NTVDM). This technology allows running legacy DOS and 16-bit Windows programs on computers that are using Intel 80386 or higher when there 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.
- AppLocker doesn't protect against running 16-bit DOS binaries in an NT Virtual DOS Machine (NTVDM). This technology allows running legacy DOS and 16-bit Windows programs on computers that are using Intel 80386 or higher when there's already another operating system running and controlling the hardware. The result is that 16-bit binaries can still run on Windows Server 2008 R2 and Windows 7 when AppLocker is configured to otherwise block binaries and libraries. If it's a requirement to prevent 16-bit applications from running, you must configure the Deny rule in the Executable rule collection for NTVDM.exe.
- You 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.
- You can't use AppLocker to prevent code from running outside the Win32 subsystem. In particular, this rule applies to the (POSIX) subsystem in Windows NT. If it's a requirement to prevent applications from running in the POSIX subsystem, you must disable the subsystem.
- AppLocker can only control VBScript, JScript, .bat files, .cmd files and Windows PowerShell scripts. It 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.
- AppLocker can only control VBScript, JScript, .bat files, .cmd files and Windows PowerShell scripts. It doesn't control all interpreted code that runs within a host process, for example Perl scripts and macros. Interpreted code is a form of executable code that runs within a host process. For example, Windows batch files (\*.bat) run within the context of the Windows Command Host (cmd.exe). To use AppLocker to control interpreted code, the host process must call AppLocker before it runs the interpreted code, and then enforce the decision that is returned by AppLocker. Not all host processes call into AppLocker. Therefore, AppLocker can't control every kind of interpreted code, for example Microsoft Office macros.
> [!IMPORTANT]
> You should configure the appropriate security settings of these host processes if you must allow them to run. For example, configure the security settings in Microsoft Office to ensure that only signed and trusted macros are loaded.
- AppLocker rules allow or prevent an app from launching. AppLocker 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.
- AppLocker rules allow or prevent an app from launching. AppLocker doesn't control the behavior of apps after they're launched. Applications could contain flags that are passed to functions that signal AppLocker to circumvent the rules and allow another .exe or .dll file to be loaded. In practice, an app that is allowed by AppLocker could use these flags to bypass AppLocker rules and launch child processes. You must follow a process that best suits your needs to thoroughly vet each app before allowing them to run using AppLocker rules.
For more info, see [Security considerations for AppLocker](security-considerations-for-applocker.md).
@ -77,8 +77,8 @@ You might need to control a limited number of apps because they access sensitive
AppLocker policies for Universal Windows apps can only be applied to apps that are installed on computers running Windows operating systems that support Microsoft Store apps. However, Classic Windows applications can be controlled in Windows Server 2008 R2 and Windows 7, in addition to those computers that support Universal Windows apps. The rules for Classic Windows applications and Universal Windows apps can be enforced together. The differences you should consider for Universal Windows apps are:
- All Universal Windows apps can be installed by a standard user, whereas a number of Classic Windows applications require administrative credentials to install. So in an environment where most of the users are standard users, you might not need numerous exe rules, but you might want more explicit policies for packaged apps.
- Classic Windows applications can be written to change the system state if they run with administrative credentials. Most Universal Windows apps cannot change the system state because they run with limited permissions. When you design your AppLocker policies, it is important to understand whether an app that you are allowing can make system-wide changes.
- All Universal Windows apps can be installed by a standard user, whereas many Classic Windows applications require administrative credentials to install. So in an environment where most of the users are standard users, you might not need numerous exe rules, but you might want more explicit policies for packaged apps.
- Classic Windows applications can be written to change the system state if they run with administrative credentials. Most Universal Windows apps can't change the system state because they run with limited permissions. When you design your AppLocker policies, it's important to understand whether an app that you're allowing can make system-wide changes.
- Universal Windows apps can be acquired through the Store, or they can be side-loaded by using Windows PowerShell cmdlets. If you use Windows PowerShell cmdlets, a special Enterprise license is required to acquire Universal Windows apps. Classic Windows applications can be acquired through traditional means, such as through software vendors or retail distribution.
AppLocker controls Universal Windows apps and Classic Windows applications by using different rule collections. You have the choice to control Universal Windows apps, Classic Windows applications, or both.
@ -91,7 +91,7 @@ Most organizations have evolved app control policies and methods over time. With
| 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.|
| Security policies (locally set or through Group Policy) | Using AppLocker requires increased effort in planning to create correct policies, but this policy creation results in a simpler distribution method.|
| Non-Microsoft app control software | Using AppLocker requires a complete app control policy evaluation and implementation.|
| Managed usage by group or OU | Using AppLocker requires a complete app control policy evaluation and implementation.|
| Authorization Manager or other role-based access technologies | Using AppLocker requires a complete app control policy evaluation and implementation.|
@ -103,7 +103,7 @@ If your organization supports multiple Windows operating systems, app control po
|Possible answers|Design considerations|
|--- |--- |
|Your organization's computers are running a combination of the following operating systems:<li>Windows 11<li>Windows 10<li>Windows 8<li>Windows 7<li>Windows Vista<li>Windows XP<li>Windows Server 2012<li>Windows Server 2008 R2<li>Windows Server 2008<li>Windows Server 2003|AppLocker rules are only applied to computers running the supported versions of Windows, but SRP rules can be applied to all versions of Windows beginning with Windows XP and Windows Server 2003. For specific operating system version requirements, see [Requirements to use AppLocker](requirements-to-use-applocker.md).<br/><br/> **Note:** If you are using the Basic User security level as assigned in SRP, those privileges are not supported on computers running that support AppLocker.<br/><br/>AppLocker policies as applied through a GPO take precedence over SRP policies in the same or linked GPO. SRP policies can be created and maintained the same way.|
|Your organization's computers are running a combination of the following operating systems:<li>Windows 11<li>Windows 10<li>Windows 8<li>Windows 7<li>Windows Vista<li>Windows XP<li>Windows Server 2012<li>Windows Server 2008 R2<li>Windows Server 2008<li>Windows Server 2003|AppLocker rules are only applied to computers running the supported versions of Windows, but SRP rules can be applied to all versions of Windows beginning with Windows XP and Windows Server 2003. For specific operating system version requirements, see [Requirements to use AppLocker](requirements-to-use-applocker.md).<br/><br/> **Note:** If you're using the Basic User security level as assigned in SRP, those privileges aren't supported on computers running that support AppLocker.<br/><br/>AppLocker policies as applied through a GPO take precedence over SRP policies in the same or linked GPO. SRP policies can be created and maintained the same way.|
|Your organization's computers are running only the following operating systems:<li>Windows 11<li>Windows 10<li>Windows 8.1<li>Windows 8<li>Windows 7<li>Windows Server 2012 R2<li>Windows Server 2012<li>Windows Server 2008 R2|Use AppLocker to create your application control policies.|
### Are there specific groups in your organization that need customized application control policies?
@ -112,7 +112,7 @@ Most business groups or departments have specific security requirements that per
| 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.<br/>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.|
| Yes | For each group, you need to create a list that includes their application control requirements. Although this consideration may increase the planning time, it will most likely result in a more effective deployment.<br/>If your GPO structure isn't currently configured so that you can apply different policies to specific groups, you can alternatively apply AppLocker rules in a GPO to specific user groups.|
| No | AppLocker policies can be applied globally to applications that are installed on PCs running the supported versions of Windows as listed in [Requirements to use AppLocker](requirements-to-use-applocker.md). Depending on the number of apps you need to control, managing all the rules and exceptions might be challenging.|
### Does your IT department have resources to analyze application usage, and to design and manage the policies?
@ -121,12 +121,12 @@ The time and resources that are available to you to perform the research and ana
| 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. |
| Yes | Invest the time to analyze your organization's application control requirements, and plan a complete deployment that uses rules that are as constructed as possible.|
| No | Consider a focused and phased deployment for specific groups by using a few rules. As you apply controls to applications in a specific group, learn from that deployment to plan your next deployment. |
### Does your organization have Help Desk support?
Preventing your users from accessing known, deployed, or personal applications will initially cause an increase in end-user support. It will be necessary to address the various support issues in your organization so security policies are followed and business workflow is not hampered.
Preventing your users from accessing known, deployed, or personal applications will initially cause an increase in end-user support. It will be necessary to address the various support issues in your organization so security policies are followed and business workflow isn't hampered.
| Possible answers | Design considerations |
| - | - |
@ -140,7 +140,7 @@ Any successful application control policy implementation is based on your knowle
| 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.|
| No | You'll have to perform an audit and requirements gathering project to discover the application usage. AppLocker provides the means to deploy policies in **Audit only** mode, and tools to view the event logs.|
### How do you deploy or sanction applications (upgraded or new) in your organization?
@ -159,7 +159,7 @@ Although SRP and AppLocker have the same goal, AppLocker is a major revision of
| 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.<br/><br/>**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.|
| Yes | You can't use AppLocker to manage SRP settings, but you can use SRP to manage application control policies on computers running on any of the supported operating systems listed in [Requirements to use AppLocker](requirements-to-use-applocker.md). In addition, if AppLocker and SRP settings are configured in the same GPO, only the AppLocker settings will be enforced on computers running those supported operating systems.<br/><br/>**Note:** If you're using the Basic User security level as assigned in SRP, those permissions aren't supported on computers running the supported operating systems.|
| No | Policies that are configured for AppLocker can only be applied to computers running the supported operating systems, but SRP is also available on those operating systems. |
### What are your organization's priorities when implementing application control policies?
@ -168,19 +168,19 @@ Some organizations will benefit from application control policies as shown by an
| 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|
| Productivity: The organization assures that tools work and required applications can be installed. | To meet innovation and productivity goals, some groups require the ability to install and run various softwares from different sources, including software that they developed. Therefore, if innovation and productivity are a high priority, managing application control policies through an allowed list might be time consuming and an impediment to progress. |
| Management: The organization is aware of and controls the applications it supports. | In some business groups, application usage can be managed from a central point of control. AppLocker policies can be built into a GPO for that purpose. This GPO shifts the burden of application access to the IT department, but it also has the benefit of controlling the number of applications that can be run and controlling the versions of those applications|
| Security: The organization must protect data in part by ensuring that only approved apps are used. | AppLocker can help protect data by allowing a defined set of users access to apps that access the data. If security is the top priority, the application control policies will be the most restrictive.|
### How are apps currently accessed in your organization?
AppLocker is 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.
AppLocker is effective for organizations that have application restriction requirements if they have environments with a simple topography and application control policy goals that are straightforward. For example, AppLocker can benefit an environment where non-employees have access to computers that are connected to the organizational network, such as a school or library. Large organizations also benefit from AppLocker policy deployment when the goal is to achieve a detailed level of control on the desktop computers with a relatively small number of applications to manage, or when the applications are manageable with a few rules.
| Possible answers | Design considerations |
| - | - |
| Users run without administrative rights. | Apps are installed by using an installation deployment technology.|
| AppLocker can help reduce the total cost of ownership for business groups that typically use a finite set of apps, such as human resources and finance departments. At the same time, these departments access highly sensitive information, much of which contains confidential and proprietary information. By using AppLocker to create rules for specific apps that are allowed to run, you can help limit unauthorized applications from accessing this information.<br/><br/>**Note:** AppLocker can also be effective in helping create standardized desktops in organizations where users run as administrators. However, it 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.|
| AppLocker can help reduce the total cost of ownership for business groups that typically use a finite set of apps, such as human resources and finance departments. At the same time, these departments access highly sensitive information, much of which contains confidential and proprietary information. By using AppLocker to create rules for specific apps that are allowed to run, you can help limit unauthorized applications from accessing this information.<br/><br/>**Note:** AppLocker can also be effective in helping create standardized desktops in organizations where users run as administrators. However, it's important to note that users with administrative credentials can add new rules to the local AppLocker policy.| Users must be able to install applications as needed.
| Users currently have administrator access, and it would be difficult to change this privilege.|Enforcing AppLocker rules isn't suited for business groups that must be able to install apps as needed and without approval from the IT department. If one or more OUs in your organization has this requirement, you can choose not to enforce application rules in those OUs by using AppLocker or to implement the **Audit only** enforcement setting through AppLocker.|
### Is the structure in Active Directory Domain Services based on the organization's hierarchy?

View File

@ -36,7 +36,7 @@ If no AppLocker rules for a specific rule collection exist, all files with that
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.
- **Deny**. You can specify which files aren't allowed to run in your environment and for which users or groups of users. You can also configure exceptions to identify files that are excluded from the rule.
>**Important:**  You can use a combination of allow actions and deny actions. However, we recommend using allow actions with exceptions because deny actions override allow actions in all cases. Deny actions can also be circumvented. For example, if you configure a deny action for a file or folder path, the user can still run the file from any other path.
 

View File

@ -33,9 +33,9 @@ This topic describes the result of applying AppLocker rule exceptions to rule co
You can apply AppLocker rules to individual users or a group of users. If you apply a rule to a group of users, all users in that group are affected by that rule. If you need to allow a subset of a user group to use an app, you can create a special rule for that subset.
For example, the rule "Allow Everyone to run Windows except Registry Editor" allows Everyone to run Windows binaries, but does not allow anyone to run Registry Editor (by adding %WINDIR%\regedit.exe as a Path Exception of the rule).
For example, the rule "Allow Everyone to run Windows except Registry Editor" allows Everyone to run Windows binaries, but doesn't allow anyone to run Registry Editor (by adding %WINDIR%\regedit.exe as a Path Exception for the rule).
The effect of this rule would prevent users such as Helpdesk personnel from running the Registry Editor, a program that is necessary for their support tasks.
To resolve this problem, create a second rule that applies to the Helpdesk user group: "Allow Helpdesk to run Registry Editor" and add %WINDIR%\regedit.exe as an allowed path. If you create a deny rule that 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.
To resolve this problem, create a second rule that applies to the Helpdesk user group: "Allow Helpdesk to run Registry Editor" and add %WINDIR%\regedit.exe as an allowed path. If you create a deny rule that doesn't allow any users to run Registry Editor, the deny rule will override the second rule that allows the Helpdesk user group to run Registry Editor.
## Related topics

View File

@ -1,6 +1,6 @@
---
title: Understanding the file hash rule condition in AppLocker (Windows)
description: This topic explains the AppLocker file hash rule condition, the advantages and disadvantages, and how it is applied.
description: This topic explains the AppLocker file hash rule condition, the advantages and disadvantages, and how it's applied.
ms.assetid: 4c6d9af4-2b1a-40f4-8758-1a6f9f147756
ms.reviewer:
ms.author: macapara
@ -29,9 +29,9 @@ ms.technology: windows-sec
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
This topic explains the AppLocker file hash rule condition, the advantages and disadvantages, and how it is applied.
This topic explains the AppLocker file hash rule condition, the advantages and disadvantages, and how it's applied.
File hash rules use a system-computed cryptographic hash of the identified file. For files that 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 rules use a system-computed cryptographic hash of the identified file. For files that aren't digitally signed, file hash rules are more secure than path rules. The following table describes the advantages and disadvantages of the file hash condition.
| File hash condition advantages | File hash condition disadvantages |
| - | - |

View File

@ -1,6 +1,6 @@
---
title: Understanding the path rule condition in AppLocker (Windows)
description: This topic explains the AppLocker path rule condition, the advantages and disadvantages, and how it is applied.
description: This topic explains the AppLocker path rule condition, the advantages and disadvantages, and how it's applied.
ms.assetid: 3fa54ded-4466-4f72-bea4-2612031cad43
ms.reviewer:
ms.author: macapara
@ -29,7 +29,7 @@ ms.technology: windows-sec
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
This topic explains the AppLocker path rule condition, the advantages and disadvantages, and how it is applied.
This topic explains the AppLocker path rule condition, the advantages and disadvantages, and how it's applied.
The path condition identifies an application by its location in the file system of the computer or on the network.
@ -39,11 +39,11 @@ When creating a rule that uses a deny action, path conditions are less secure th
|--- |--- |
|<li>You can easily control many folders or a single file.<li>You can use the asterisk (*) as a wildcard character within path rules.|<li>It might be less secure if a rule that is configured to use a folder path contains subfolders that are writable by non-administrators.<li>You must specify the full path to a file or folder when creating path rules so that the rule will be properly enforced.|
AppLocker 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.
AppLocker doesn't enforce rules that specify paths with short names. You should always specify the full path to a file or folder when creating path rules so that the rule will be properly enforced.
The asterisk (\*) wildcard character can be used within **Path** field. The asterisk (\*) character used by itself represents any path. When combined with any string value, the rule is limited to the path of the file and all the files under that path. For example, %ProgramFiles%\\Internet Explorer\\\* indicates that all files and subfolders within the Internet Explorer folder will be affected by the rule.
AppLocker uses path variables for well-known directories in Windows. Path variables are not environment variables. The AppLocker engine can only interpret AppLocker path variables. The following table details these path variables.
AppLocker uses path variables for well-known directories in Windows. Path variables aren't environment variables. The AppLocker engine can only interpret AppLocker path variables. The following table details these path variables.
| Windows directory or drive | AppLocker path variable | Windows environment variable |

View File

@ -1,6 +1,6 @@
---
title: Understanding the publisher rule condition in AppLocker (Windows)
description: This topic explains the AppLocker publisher rule condition, what controls are available, and how it is applied.
description: This topic explains the AppLocker publisher rule condition, what controls are available, and how it's applied.
ms.assetid: df61ed8f-a97e-4644-9d0a-2169f18c1c4f
ms.reviewer:
ms.author: macapara
@ -29,25 +29,25 @@ ms.technology: windows-sec
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
This topic explains the AppLocker publisher rule condition, what controls are available, and how it is applied.
This topic explains the AppLocker publisher rule condition, what controls are available, and how it's applied.
Publisher conditions can be made only for files that are digitally signed; this condition identifies an app based on its digital signature and extended attributes. The digital signature contains information about the company that created the app (the publisher). The extended attributes, which are obtained from the binary resource, contain the name of the product that the app is part of and the version number of the app. The publisher may be a software development company, such as Microsoft, or the Information Technology department of your organization.
Publisher conditions are easier to maintain than file hash conditions and are 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
Publisher conditions are easier to maintain than file hash conditions and are more secure than path conditions. Rules that are specified to the version level might have to be updated when a new version of the file is released. The following table describes the advantages and disadvantages
of the publisher condition.
|Publisher condition advantages|Publisher condition disadvantages|
|--- |--- |
|<li>Frequent updating is not required.<li>You can apply different values within a certificate.<li>A single rule can be used to allow an entire product suite.<li>You can use the asterisk (*) wildcard character within a publisher rule to specify that any value should be matched.|<li>The file must be signed.<li>Although a single rule can be used to allow an entire product suite, all files in the suite must be signed uniformly.|
|<li>Frequent updating isn't required.<li>You can apply different values within a certificate.<li>A single rule can be used to allow an entire product suite.<li>You can use the asterisk (*) wildcard character within a publisher rule to specify that any value should be matched.|<li>The file must be signed.<li>Although a single rule can be used to allow an entire product suite, all files in the suite must be signed uniformly.|
Wildcard characters can be used as values in the publisher rule fields according to the following specifications:
- **Publisher**
The asterisk (\*) character used by itself represents any publisher. When combined with any string value, the rule is limited to the publisher with a value in the signed certificate that matches the character string. In other words, the asterisk 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.
The asterisk (\*) character used by itself represents any publisher. When combined with any string value, the rule is limited to the publisher with a value in the signed certificate that matches the character string. In other words, the asterisk isn't treated as a wildcard character if used with other characters in this field. For example, using the characters "M\*" limits the publisher name to only a publisher with the name "M\*." Using the characters "\*x\*" limits the publisher name only to the name “\*x\*”. A question mark (?) isn't a valid wildcard character in this field.
- **Product name**
The asterisk (\*) character used by itself represents any product name. When combined with any string value, the rule is limited to the product of the publisher with a value in the signed certificate that matches the character string. In other words, the asterisk 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.
The asterisk (\*) character used by itself represents any product name. When combined with any string value, the rule is limited to the product of the publisher with a value in the signed certificate that matches the character string. In other words, the asterisk isn't treated as a wildcard character if used with other characters in this field. A question mark (?) isn't a valid wildcard character in this field.
- **File name**

View File

@ -33,7 +33,7 @@ This topic for the IT professional describes the steps to create and maintain Ap
## 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 is a baseline device you can use to configure policies and can then be used to maintain AppLocker policies. For the procedure to configure a reference device, see [Configure the AppLocker reference device](configure-the-appLocker-reference-device.md).
An AppLocker reference device that is used to create and maintain AppLocker policies should contain the corresponding apps for each organizational unit (OU) to mimic your production environment.
@ -43,7 +43,7 @@ You can perform AppLocker policy testing on the reference device by using the **
## 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).
With AppLocker, you can automatically generate rules for all files within a folder. AppLocker scans the specified folder and creates the condition types that you choose for each file in that folder. For information on how to automatically generate rules, see [Run the Automatically Generate Rules wizard](run-the-automatically-generate-rules-wizard.md).
>**Note:**  If you run this wizard to create your first rules for a Group Policy Object (GPO), after you complete the wizard, you will be prompted to create the default rules, which allow critical system files to run. You can edit the default rules at any time. If your organization has decided to edit the default rules or create custom rules to allow the Windows system files to run, ensure that you delete the default rules after you replace them with your custom rules.
@ -55,7 +55,7 @@ AppLocker includes default rules for each rule collection. These rules are inten
## 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:
If AppLocker policies are currently running in your production environment, export the policies from the corresponding GPOs and save them to the reference device. For information on how to export and save the policies, see [Export an AppLocker policy from a GPO](export-an-applocker-policy-from-a-gpo.md). If no AppLocker policies have been deployed, create the rules and develop the policies by using the following procedures:
- [Create a rule that uses a publisher condition](create-a-rule-that-uses-a-publisher-condition.md)
- [Create a rule that uses a file hash condition](create-a-rule-that-uses-a-file-hash-condition.md)
@ -68,7 +68,7 @@ If AppLocker policies are currently running in your production environment, expo
## 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:
You should test each set of rules to ensure that they perform as intended. The **Test-AppLockerPolicy** Windows PowerShell cmdlet can be used to determine whether any of the rules in your rule collection will be blocked on your reference device. Perform the steps on each reference device that you used to define the AppLocker policy. Ensure that the reference device is joined to the domain and that it's receiving the AppLocker policy from the appropriate GPO. Because AppLocker rules are inherited from linked GPOs, you should deploy all of the rules to simultaneously test all of your test GPOs. Use the following procedures to complete this step:
- [Test an AppLocker Policy with Test-AppLockerPolicy](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ee791772(v=ws.10))
- [Discover the Effect of an AppLocker Policy](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ee791823(v=ws.10))
@ -77,17 +77,17 @@ You should test each set of rules to ensure that they perform as intended. The *
## 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:
When the AppLocker policy has been tested successfully, it can be imported into the GPO (or imported into individual computers that aren't managed by Group Policy) and checked for its intended effectiveness. To do these tasks, perform the following procedures:
- [Export an AppLocker policy to an XML file](export-an-applocker-policy-to-an-xml-file.md)
- [Import an AppLocker policy into a GPO](import-an-applocker-policy-into-a-gpo.md) or
- [Discover the Effect of an AppLocker Policy](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ee791823(v=ws.10))
If the AppLocker policy enforcement setting is **Audit only** and you 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).
If the AppLocker policy enforcement setting is **Audit only** and you're satisfied that the policy is fulfilling your intent, you can change it to **Enforce rules**. For info about how to change the enforcement setting, see [Configure an AppLocker policy for enforce rules](configure-an-applocker-policy-for-enforce-rules.md).
## Step 6: Monitor the effect of the policy in production
If additional refinements or updates are necessary after a policy is deployed, use the appropriate following procedures to monitor and update the policy:
If more refinements or updates are necessary after a policy is deployed, use the appropriate following procedures to monitor and update the policy:
- [Monitor app usage with AppLocker](monitor-application-usage-with-applocker.md)
- [Edit an AppLocker policy](edit-an-applocker-policy.md)

View File

@ -34,7 +34,7 @@ This topic for IT professionals describes concepts and procedures to help you ma
## 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 Server 2008 R2, Windows 7 and later. It's recommended that you author AppLocker and SRP rules in separate GPOs and target the GPO with SRP policies to systems running Windows Vista or earlier. When both SRP and AppLocker policies are applied to computers running Windows Server 2008 R2,
Windows 7 and later, the SRP policies are ignored.
The following table compares the features and functions of Software Restriction Policies (SRP) and AppLocker.
@ -45,15 +45,15 @@ The following table compares the features and functions of Software Restriction
|Policy creation|SRP policies are maintained through Group Policy and only the administrator of the GPO can update the SRP policy. The administrator on the local computer can modify the SRP policies defined in the local GPO.|AppLocker policies are maintained through Group Policy and only the administrator of the GPO can update the policy. The administrator on the local computer can modify the AppLocker policies defined in the local GPO.<br/><br/>AppLocker permits customization of error messages to direct users to a Web page for help.|
|Policy maintenance|SRP policies must be updated by using the Local Security Policy snap-in (if the policies are created locally) or the Group Policy Management Console (GPMC).|AppLocker policies can be updated by using the Local Security Policy snap-in (if the policies are created locally), or the GPMC, or the Windows PowerShell AppLocker cmdlets.|
|Policy application|SRP policies are distributed through Group Policy.|AppLocker policies are distributed through Group Policy.|
|Enforcement mode|SRP works in the “deny list mode” where administrators can create rules for files that they do not want to allow in this Enterprise whereas the rest of the file is allowed to run by default.<br/><br/>SRP can also be configured in the “allowlist mode” so that by default all files are blocked and administrators need to create allow rules for files that they want to allow.|AppLocker by default works in the “allowlist mode” where only those files are allowed to run for which there is a matching allow rule.|
|File types that can be controlled|SRP can control the following file types:<li>Executables<li>Dlls<li>Scripts<li>Windows Installers<br/><br/>SRP cannot control each file type separately. All SRP rules are in a single rule collection.|AppLocker can control the following file types:<li>Executables<li>Dlls<li>Scripts<li>Windows Installers<li>Packaged apps and installers<br/><br/>AppLocker maintains a separate rule collection for each of the five file types.|
|Enforcement mode|SRP works in the “blocklist mode” where administrators can create rules for files that they don't want to allow in this Enterprise whereas the rest of the file is allowed to run by default.<br/><br/>SRP can also be configured in the “allowlist mode” so that by default all files are blocked and administrators need to create allow rules for files that they want to allow.|AppLocker by default works in the “allowlist mode” where only those files are allowed to run for which there's a matching allow rule.|
|File types that can be controlled|SRP can control the following file types:<li>Executables<li>Dlls<li>Scripts<li>Windows Installers<br/><br/>SRP can't control each file type separately. All SRP rules are in a single rule collection.|AppLocker can control the following file types:<li>Executables<li>Dlls<li>Scripts<li>Windows Installers<li>Packaged apps and installers<br/><br/>AppLocker maintains a separate rule collection for each of the five file types.|
|Designated file types|SRP supports an extensible list of file types that are considered executable. Administrators can add extensions for files that should be considered executable.|AppLocker currently supports the following file extensions:<li>Executables (.exe, .com)<li>Dlls (.ocx, .dll)<li>Scripts (.vbs, .js, .ps1, .cmd, .bat)<li>Windows Installers (.msi, .mst, .msp)<li>Packaged app installers (.appx)|
|Rule types|SRP supports four types of rules:<li>Hash<li>Path<li>Signature<li>Internet zone|AppLocker supports three types of rules:<li>File hash<li>Path<li>Publisher|
|Editing the hash value|In Windows XP, you could use SRP to provide custom hash values.<br/><br/>Beginning with Windows 7 and Windows Server 2008 R2, you can only select the file to hash, not provide the hash value.|AppLocker computes the hash value itself. Internally, it uses the SHA2 Authenticode hash for Portable Executables (exe and dll) and Windows Installers and an SHA2 flat file hash for the rest.|
|Support for different security levels|With SRP, you can specify the permissions with which an app can run. So, you can configure a rule such that Notepad always runs with restricted permissions and never with administrative privileges.<br/><br/>SRP on Windows Vista and earlier supported multiple security levels. On Windows 7, that list was restricted to just two levels: Disallowed and Unrestricted (Basic User translates to Disallowed).|AppLocker does not support security levels.|
|Editing the hash value|In Windows XP, you could use SRP to provide custom hash values.<br/><br/>Beginning with Windows 7 and Windows Server 2008 R2, you can only select the file to hash, and not provide the hash value.|AppLocker computes the hash value itself. Internally, it uses the SHA2 Authenticode hash for Portable Executables (exe and dll) and Windows Installers and an SHA2 flat file hash for the rest.|
|Support for different security levels|With SRP, you can specify the permissions with which an app can run. So, you can configure a rule such that Notepad always runs with restricted permissions and never with administrative privileges.<br/><br/>SRP on Windows Vista and earlier supported multiple security levels. On Windows 7, that list was restricted to just two levels: Disallowed and Unrestricted (Basic User translates to Disallowed).|AppLocker doesn't support security levels.|
|Manage Packaged apps and Packaged app installers.|Not supported|.appx is a valid file type which AppLocker can manage.|
|Targeting a rule to a user or a group of users|SRP rules apply to all users on a particular computer.|AppLocker rules can be targeted to a specific user or a group of users.|
|Support for rule exceptions|SRP does not support rule exceptions.|AppLocker rules can have exceptions, which allow you to create rules such as “Allow everything from Windows except for regedit.exe”.|
|Support for audit mode|SRP does not support audit mode. The only way to test SRP policies is to set up a test environment and run a few experiments.|AppLocker supports audit mode, which allows you to test the effect of their policy in the real production environment without impacting the user experience. Once you are satisfied with the results, you can start enforcing the policy.|
|Support for exporting and importing policies|SRP does not support policy import/export.|AppLocker supports the importing and exporting of policies. This allows you to create AppLocker policy on a sample device, test it out and then export that policy and import it back into the desired GPO.|
|Support for rule exceptions|SRP doesn't support rule exceptions.|AppLocker rules can have exceptions, which allow you to create rules such as “Allow everything from Windows except for regedit.exe”.|
|Support for audit mode|SRP doesn't support audit mode. The only way to test SRP policies is to set up a test environment and run a few experiments.|AppLocker supports audit mode, which allows you to test the effect of their policy in the real production environment without impacting the user experience. Once you're satisfied with the results, you can start enforcing the policy.|
|Support for exporting and importing policies|SRP doesn't support policy import/export.|AppLocker supports the importing and exporting of policies. This support by AppLocker allows you to create AppLocker policy on a sample device, test it out and then export that policy and import it back into the desired GPO.|
|Rule enforcement|Internally, SRP rules enforcement happens in the user-mode, which is less secure.|Internally, AppLocker rules for .exe and .dll files are enforced in the kernel-mode, which is more secure than enforcing them in the user-mode.|

View File

@ -43,7 +43,7 @@ Local Security policy snap-in, you must be a member of the local **Administrator
The [Get-AppLockerFileInformation](/powershell/module/applocker/get-applockerfileinformation) cmdlet retrieves the AppLocker file information from a list of files or from an event log. File information that is retrieved can include publisher information, file hash information, and file path information.
File information from an event log may not contain all of these fields. Files that are not signed do not have any publisher information.
File information from an event log may not contain all of these fields. Files that aren't signed don't have any publisher information.
### Set AppLocker policy
@ -62,6 +62,6 @@ list of file information.
The [Test-AppLockerPolicy](/powershell/module/applocker/test-applockerpolicy) cmdlet uses the specified AppLocker policy to test whether a specified list of files are allowed to run or not on the local device for a specific user.
## Additional resources
## Other resources
- For steps to perform other AppLocker policy tasks, see [Administer AppLocker](administer-applocker.md).

View File

@ -39,7 +39,7 @@ The AppLocker log contains information about applications that are affected by A
- 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%).
Review the entries in the Event Viewer to determine if any applications aren't 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).
@ -52,14 +52,14 @@ The following table contains information about the events that you can use to de
| Event ID | Level | Event message | Description |
| - | - | - | - |
| 8000 | Error| Application Identity Policy conversion failed. Status *&lt;%1&gt; *| Indicates that the policy was not applied correctly to the computer. The status message is provided for troubleshooting purposes.|
| 8000 | Error| Application Identity Policy conversion failed. Status *&lt;%1&gt; *| Indicates that the policy wasn't 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| *&lt;File name&gt; * was allowed to run.| Specifies that the .exe or .dll file is allowed by an AppLocker rule.|
| 8003 | Warning| *&lt;File name&gt; * 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| *&lt;File name&gt; * was not allowed to run.| Access to *&lt;file name&gt;* 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.|
| 8003 | Warning| *&lt;File name&gt; * was allowed to run but would have been prevented from running if the AppLocker policy was 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| *&lt;File name&gt; * was not allowed to run.| Access to *&lt;file name&gt;* 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 can't run.|
| 8005| Information| *&lt;File name&gt; * was allowed to run.| Specifies that the script or .msi file is allowed by an AppLocker rule.|
| 8006 | Warning| *&lt;File name&gt; * 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| *&lt;File name&gt; * was not allowed to run.| Access to *&lt;file name&gt;* 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.|
| 8006 | Warning| *&lt;File name&gt; * was allowed to run but would have been prevented from running if the AppLocker policy was 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| *&lt;File name&gt; * was not allowed to run.| Access to *&lt;file name&gt;* 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 can't run.|
| 8008| 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.|
@ -68,12 +68,12 @@ The following table contains information about the events that you can use to de
| 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.|
| 8028 | Warning | * was allowed to run but would have been prevented if the Config CI policy were enforced.| Added in Windows Server 2016 and Windows 10.|
| 8028 | Warning | * was allowed to run but would have been prevented if the Config CI policy was enforced.| Added in Windows Server 2016 and Windows 10.|
| 8029 | Error | * was prevented from running due to Config CI policy.| Added in Windows Server 2016 and Windows 10.|
| 8030 | Information | ManagedInstaller check SUCCEEDED during Appid verification of * | Added in Windows Server 2016 and Windows 10.|
| 8031 | Information | SmartlockerFilter detected file * being written by process * | Added in Windows Server 2016 and Windows 10.|
| 8032 | Error | ManagedInstaller check FAILED during Appid verification of * | Added in Windows Server 2016 and Windows 10.|
| 8033 | Warning | ManagedInstaller check FAILED during Appid verification of * . Allowed to run due to Audit Applocker Policy. | Added in Windows Server 2016 and Windows 10.|
| 8033 | Warning | ManagedInstaller check FAILED during Appid verification of * . Allowed to run due to Audit AppLocker Policy. | Added in Windows Server 2016 and Windows 10.|
| 8034 | Information | ManagedInstaller Script check FAILED during Appid verification of * | Added in Windows Server 2016 and Windows 10.|
| 8035 | Error | ManagedInstaller Script check SUCCEEDED during Appid verification of * | Added in Windows Server 2016 and Windows 10.|
| 8036 | Error | * was prevented from running due to Config CI policy | Added in Windows Server 2016 and Windows 10.|

View File

@ -37,7 +37,7 @@ You might want to deploy application control policies in Windows operating syste
## 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).
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're 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.
@ -45,15 +45,15 @@ The following scenario provides an example of how each type of policy would affe
| 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.|
| 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 aren't applied.| Policies generated by SRP in the GPO are applied, and they supersede local policies generated by SRP.AppLocker policies aren't 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 aren't applied.| Policies generated by SRP in the GPO are applied, and they supersede local policies generated by SRP. AppLocker policies aren't 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).
## 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.
Because SRPs and AppLocker policies function differently, they shouldn't be implemented in the same GPO. This rule, when implemented, 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

View File

@ -76,10 +76,10 @@ The following table compares the application control functions of Software Restr
|User support|SRP allows users to install applications as an administrator.|AppLocker policies are maintained through Group Policy, and only the administrator of the device can update an AppLocker policy.<p>AppLocker permits customization of error messages to direct users to a Web page for help.|
|Policy maintenance|SRP policies are updated by using the Local Security Policy snap-in or the Group Policy Management Console (GPMC).|AppLocker policies are updated by using the Local Security Policy snap-in or the GPMC.<p>AppLocker supports a small set of PowerShell cmdlets to aid in administration and maintenance.|
|Policy management infrastructure|To manage SRP policies, SRP uses Group Policy within a domain and the Local Security Policy snap-in for a local computer.|To manage AppLocker policies, AppLocker uses Group Policy within a domain and the Local Security Policy snap-in for a local computer.|
|Block malicious scripts|Rules for blocking malicious scripts prevents all scripts associated with the Windows Script Host from running, except those that are digitally signed by your organization.|AppLocker rules can control the following file formats: .ps1, .bat, .cmd, .vbs, and .js. In addition, you can set exceptions to allow specific files to run.|
|Block malicious scripts|Rules for blocking malicious scripts prevent all scripts associated with the Windows Script Host from running, except those scripts that are digitally signed by your organization.|AppLocker rules can control the following file formats: .ps1, .bat, .cmd, .vbs, and .js. In addition, you can set exceptions to allow specific files to run.|
|Manage software installation|SRP can prevent all Windows Installer packages from installing. It allows .msi files that are digitally signed by your organization to be installed.|The Windows Installer rule collection is a set of rules created for Windows Installer file types (.mst, .msi and .msp) to allow you to control the installation of files on client computers and servers.|
|Manage all software on the computer|All software is managed in one rule set. By default, the policy for managing all software on a device disallows all software on the user's device, except software that is installed in the Windows folder, Program Files folder, or subfolders.|Unlike SRP, each AppLocker rule collection functions as an allowed list of files. Only the files that are listed within the rule collection will be allowed to run. This configuration makes it easier for administrators to determine what will occur when an AppLocker rule is applied.|
|Different policies for different users|Rules are applied uniformly to all users on a particular device.|On a device that is shared by multiple users, an administrator can specify the groups of users who can access the installed software. Using AppLocker, an administrator can specify the user to whom a specific rule should apply.|
|Different policies for different users|Rules are applied uniformly to all users on a particular device.|On a device that is shared by multiple users, an administrator can specify the groups of users who can access the installed software. An administrator uses AppLocker to specify the user to whom a specific rule should apply.|
## Related topics

View File

@ -37,7 +37,7 @@ This topic for IT professionals describes AppLocker rule types and how to work w
| [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.|
| [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 can't 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.|
@ -49,11 +49,11 @@ The three AppLocker enforcement modes are described in the following table. The
| 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.|
| **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|
| **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 aren't 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.
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.
@ -70,9 +70,9 @@ The AppLocker console is organized into rule collections, which are executable f
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).
The DLL rule collection isn't enabled by default. To learn how to enable the DLL rule collection, see [DLL rule collections](#bkmk-dllrulecollections).
EXE rules apply to portable executable (PE) files. AppLocker checks whether a file is a valid PE file, rather than just applying rules based on file extension, which attackers can easily change. Regardless of the file extension, the AppLocker EXE rule collection will work on a file as long as it is a valid PE file.
EXE rules apply to portable executable (PE) files. AppLocker checks whether a file is a valid PE file, rather than just applying rules based on file extension, which attackers can easily change. Regardless of the file extension, the AppLocker EXE rule collection will work on a file as long as it's a valid PE file.
## Rule conditions
@ -84,13 +84,13 @@ Rule conditions are criteria that help AppLocker identify the apps to which the
### <a href="" id="bkmk-publisher"></a>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.
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. If there's 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. If there are packaged apps and packaged app installers, these extended attributes contain the name and the version of the app package.
> **Note:** Rules created in the packaged apps and packaged app installers rule collection can only have publisher conditions since Windows does not support unsigned packaged apps and packaged app installers.
>
> **Note:** Use a publisher rule condition when possible because they can survive app updates as well as a change in the location of files.
When you select a reference file for a publisher condition, the wizard creates a rule that specifies the publisher, product, file name, and version number. You can make the rule more generic by moving the slider up or by using a wildcard character (\*) in the product, file name, or version number fields.
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 up the slider 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.
@ -108,8 +108,8 @@ The following table describes how a publisher condition is applied.
| **All signed files** | All files that are signed by any publisher.|
| **Publisher only**| All files that are signed by the named publisher.|
| **Publisher and product name**| All files for the specified product that are signed by the named publisher.|
| **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**<br/>The specified version of the named file or package for the named product that are signed by the publisher.|
| **Publisher and product name, and file name**| Any version of the named file or package for the named product that is signed by the publisher.|
| **Publisher, product name, file name, and file version**| **Exactly**<br/>The specified version of the named file or package for the named product that is signed by the publisher.|
| **Publisher, product name, file name, and file version**| **And above**<br/>The specified version of the named file 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**<br/>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.|
@ -184,13 +184,13 @@ A rule can be configured to use allow or deny actions:
## 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.
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 doesn't 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.
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 doesn't 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.
## <a href="" id="bkmk-dllrulecollections"></a>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.
Because the DLL rule collection isn't 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.
@ -208,21 +208,21 @@ Membership in the local **Administrators** group, or equivalent, is the minimum
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.
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 if there are 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
## Other 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:
- By default, AppLocker rules don't allow users to open or run any files that aren't allowed. Administrators should maintain an up-to-date list of allowed applications.
- There are two types of AppLocker conditions that don't 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.
- **A publisher condition with a specific product version set** If you create a publisher rule condition that uses the **Exactly** version option, the rule can't 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.
- If an app isn't digitally signed, you can't use a publisher rule condition for that app.
- AppLocker rules can't be used to manage computers running a Windows operating system earlier than Windows Server 2008 R2 or Windows 7. Software Restriction Policies must be used instead. If AppLocker rules are defined in a Group Policy Object (GPO), only those rules are applied. To ensure interoperability between Software Restriction Policies rules and AppLocker rules, define Software Restriction Policies rules and AppLocker rules in different GPOs.
- The packaged apps and packaged apps installer rule collection is available on devices running at least Windows Server 2012 and Windows 8.
- When the rules for the executable rule collection are enforced and the packaged apps and packaged app installers rule collection does not contain any rules, no packaged apps and packaged app installers are allowed to run. In order to allow any packaged apps and packaged app installers, you must create rules for the packaged apps and packaged app installers rule collection.
- When an AppLocker rule collection is set to **Audit only**, the rules are not enforced. When a user runs an application that is included in the rule, the app is opened and runs normally, and information about that app is added to the AppLocker event log.
- When the rules for the executable rule collection are enforced and the packaged apps and packaged app installers rule collection doesn't contain any rules, no packaged apps and packaged app installers are allowed to run. In order to allow any packaged apps and packaged app installers, you must create rules for the packaged apps and packaged app installers rule collection.
- When an AppLocker rule collection is set to **Audit only**, the rules aren't 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.
- Expect an increase in the number of Help Desk calls initially because of blocked apps until users understand that they can't run apps that aren't allowed.

View File

@ -33,7 +33,7 @@ Windows 10 (version 1703) introduced a new option for Windows Defender Applicati
## How does a managed installer work?
Managed installer uses a special rule collection in **AppLocker** to designate binaries that are trusted by your organization as an authorized source for application installation. When one of these trusted binaries runs, Windows monitors the binary's process (and processes it launches) and watches for files being written to disk. As files are written, they are tagged as originating from a managed installer.
Managed installer uses a special rule collection in **AppLocker** to designate binaries that are trusted by your organization as an authorized source for application installation. When one of these trusted binaries runs, Windows monitors the binary's process (and processes it launches) and watches for files being written to disk. As files are written, they're tagged as originating from a managed installer.
You can then configure WDAC to trust files that are installed by a managed installer by adding the "Enabled:Managed Installer" option to your WDAC policy. When that option is set, WDAC will check for managed installer origin information when determining whether or not to allow a binary to run. As long as there are no deny rules for the binary, WDAC will allow it to run based purely on its managed installer origin.
@ -45,7 +45,7 @@ Users with administrator privileges, or malware running as an administrator user
If a managed installer process runs in the context of a user with standard privileges, then it's possible that standard users or malware running as standard user may be able to circumvent the intent of Windows Defender Application Control.
Some application installers may automatically run the application at the end of the installation process. If this happens when the installer is run by a managed installer, then the managed installer's heuristic tracking and authorization will extend to all files that are created during the first run of the application. This could result in unintentional authorization of an executable. To avoid that, ensure that the method of application deployment that is used as a managed installer limits running applications as part of installation.
Some application installers may automatically run the application at the end of the installation process. If the application runs automatically, and the installer was run by a managed installer, then the managed installer's heuristic tracking and authorization will extend to all files that are created during the first run of the application. This extension could result in unintentional authorization of an executable. To avoid that, ensure that the method of application deployment that is used as a managed installer limits running applications as part of installation.
## Known limitations with managed installer
@ -64,11 +64,11 @@ To turn on managed installer tracking, you must:
### Create and deploy an AppLocker policy that defines your managed installer rules and enables services enforcement for executables and DLLs
Currently, neither the AppLocker policy creation UI in GPO Editor nor the PowerShell cmdlets allow for directly specifying rules for the Managed Installer rule collection. However, you can use an XML or text editor to convert an EXE rule collection policy into a ManagedInstaller rule collection.
Currently, both the AppLocker policy creation UI in GPO Editor and the PowerShell cmdlets allow for directly specifying rules for the Managed Installer rule collection. However, you can use an XML or text editor to convert an EXE rule collection policy into a ManagedInstaller rule collection.
> [!NOTE]
> Only EXE file types can be designated as managed installers.
1. Use [New-AppLockerPolicy](/powershell/module/applocker/new-applockerpolicy?view=win10-ps&preserve-view=true) to make an EXE rule for the file you are designating as a managed installer. This example creates a rule for Microsoft's Intune Management Extension using the Publisher rule type, but any AppLocker rule type can be used. You may need to reformat the output for readability.
1. Use [New-AppLockerPolicy](/powershell/module/applocker/new-applockerpolicy?view=win10-ps&preserve-view=true) to make an EXE rule for the file you're designating as a managed installer. This example creates a rule for Microsoft's Intune Management Extension using the Publisher rule type, but any AppLocker rule type can be used. You may need to reformat the output for readability.
```powershell
Get-ChildItem ${env:ProgramFiles(x86)}'\Microsoft Intune Management Extension\Microsoft.Management.Services.IntuneWindowsAgent.exe' | Get-AppLockerFileInformation | New-AppLockerPolicy -RuleType Publisher -User Everyone -Xml > AppLocker_MI_PS_ISE.xml
@ -123,7 +123,7 @@ Currently, neither the AppLocker policy creation UI in GPO Editor nor the PowerS
</RuleCollection>
```
4. Verify your AppLocker policy. The following example shows a complete AppLocker policy that sets Configuration Manager and Microsoft Endpoint Manager Intune as managed installers. Only those AppLocker rule collections that have actual rules defined are included in the final XML. This ensures the policy will merge successfully on devices which may already have an AppLocker policy in place.
4. Verify your AppLocker policy. The following example shows a complete AppLocker policy that sets Configuration Manager and Microsoft Endpoint Manager Intune as managed installers. Only those AppLocker rule collections that have actual rules defined are included in the final XML. This condition-based inclusion ensures the policy will merge successfully on devices that may already have an AppLocker policy in place.
```xml
<AppLockerPolicy Version="1">
@ -203,7 +203,7 @@ Currently, neither the AppLocker policy creation UI in GPO Editor nor the PowerS
## Enable the managed installer option in WDAC policy
In order to enable trust for the binaries laid down by managed installers, the "Enabled: Managed Installer" option must be specified in your WDAC policy.
This can be done by using the [Set-RuleOption cmdlet](/powershell/module/configci/set-ruleoption) with Option 13.
This setting can be defined by using the [Set-RuleOption cmdlet](/powershell/module/configci/set-ruleoption) with Option 13.
Below are steps to create a WDAC policy that allows Windows to boot and enables the managed installer option.
@ -230,7 +230,7 @@ Below are steps to create a WDAC policy that allows Windows to boot and enables
## Remove Managed Installer feature
To remove the Managed Installer feature from the device, you will need to remove the Managed Installer AppLocker policy from the device by following the instructions at [Delete an AppLocker rule: Clear AppLocker policies on a single system or remote systems](applocker/delete-an-applocker-rule.md#to-clear-applocker-policies-on-a-single-system-or-remote-systems).
To remove the Managed Installer feature from the device, you'll need to remove the Managed Installer AppLocker policy from the device by following the instructions at [Delete an AppLocker rule: Clear AppLocker policies on a single system or remote systems](applocker/delete-an-applocker-rule.md#to-clear-applocker-policies-on-a-single-system-or-remote-systems).
## Related articles