Update App Control for Business redirect links

This commit is contained in:
Vinay Pamnani (from Dev Box)
2024-09-11 13:08:45 -06:00
parent 9fbf7abbcd
commit ce67c73e1f
72 changed files with 1028 additions and 1068 deletions

View File

@ -1,24 +1,23 @@
---
title: WDAC debugging and troubleshooting guide
description: Learn how to debug and troubleshoot app and script failures when using WDAC
title: App Control debugging and troubleshooting guide
description: Learn how to debug and troubleshoot app and script failures when using App Control
ms.topic: how-to
ms.date: 04/06/2023
---
# WDAC debugging and troubleshooting
# App Control debugging and troubleshooting
> [!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).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
This article describes how to debug and troubleshoot app and script failures when using Windows Defender Application Control (WDAC).
This article describes how to debug and troubleshoot app and script failures when using App Control for Business.
## 1 - Gather WDAC diagnostic data
## 1 - Gather App Control diagnostic data
Before debugging and troubleshooting WDAC issues, you must collect information from a device exhibiting the problem behavior.
Before debugging and troubleshooting App Control issues, you must collect information from a device exhibiting the problem behavior.
Run the following commands from an elevated PowerShell window to collect the diagnostic information you may need:
1. Gather general WDAC diagnostic data and copy it to %userprofile%\AppData\Local\Temp\DiagOutputDir\CiDiag:
1. Gather general App Control diagnostic data and copy it to %userprofile%\AppData\Local\Temp\DiagOutputDir\CiDiag:
```powershell
cidiag.exe /stop
@ -26,9 +25,9 @@ Run the following commands from an elevated PowerShell window to collect the dia
If CiDiag.exe isn't present in your version of Windows, gather this information manually:
- WDAC policy binaries from the [Windows and EFI system partitions](known-issues.md#wdac-policy-file-locations)
- [WDAC event logs](#core-wdac-event-logs)
- [AppLocker event logs](#core-wdac-event-logs)
- App Control policy binaries from the [Windows and EFI system partitions](known-issues.md#app-control-policy-file-locations)
- [App Control event logs](#core-app-control-event-logs)
- [AppLocker event logs](#core-app-control-event-logs)
- [Other event logs that may contain useful information](#other-windows-event-logs-that-may-be-useful) from other Windows apps and services
2. Save the device's System Information to the CiDiag folder:
@ -37,7 +36,7 @@ Run the following commands from an elevated PowerShell window to collect the dia
msinfo32.exe /report $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\SystemInformation.txt
```
3. Use [CiTool.exe](citool-commands.md) to inventory the list of WDAC policies on the device. Skip this step if CiTool.exe isn't present in your version of Windows.
3. Use [CiTool.exe](citool-commands.md) to inventory the list of App Control policies on the device. Skip this step if CiTool.exe isn't present in your version of Windows.
```powershell
citool.exe -lp -json > $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\CiToolOutput.json
@ -76,9 +75,9 @@ Run the following commands from an elevated PowerShell window to collect the dia
sc.exe query appid > $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerServices.txt; sc.exe query appidsvc >> $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerServices.txt; sc.exe query applockerfltr >> $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerServices.txt
```
### Core WDAC event logs
### Core App Control event logs
WDAC events are generated under two locations:
App Control events are generated under two locations:
- Applications and Services logs - Microsoft - Windows - CodeIntegrity - Operational
- Applications and Services logs - Microsoft - Windows - AppLocker - MSI and Script
@ -87,7 +86,7 @@ Within the CiDiag output directory, these event logs are called CIOperational.ev
### Other Windows event logs that may be useful
Sometimes, you may be able to supplement the information contained in the core WDAC event logs with information found in these other event logs. CIDiag.exe doesn't collect the ones shown in *italics*.
Sometimes, you may be able to supplement the information contained in the core App Control event logs with information found in these other event logs. CIDiag.exe doesn't collect the ones shown in *italics*.
- Applications and Services logs - Microsoft - Windows - CodeIntegrity - Verbose
- Applications and Services logs - Microsoft - Windows - AppLocker - EXE and DLL
@ -104,61 +103,61 @@ Sometimes, you may be able to supplement the information contained in the core W
Having gathered the necessary diagnostic information from a device, you're ready to begin your analysis of the diagnostic data collected in the previous section.
1. Verify the set of WDAC policies that are active and enforced. Confirm that only those policies you expect to be active are currently active. Be aware of the [Windows inbox policies](inbox-appcontrol-policies.md) that may also be active. You can use either of these methods:
1. Verify the set of App Control policies that are active and enforced. Confirm that only those policies you expect to be active are currently active. Be aware of the [Windows inbox policies](inbox-appcontrol-policies.md) that may also be active. You can use either of these methods:
- Review the output from *CiTool.exe -lp*, if applicable, which was saved to the CIDiag output directory as CiToolOutput.json. See [use Microsoft Edge to view the formatted json file](/microsoft-edge/devtools-guide-chromium/json-viewer/json-viewer).
- Review all [policy activation events](/windows/security/threat-protection/windows-defender-application-control/event-id-explanations#wdac-policy-activation-events) from the core WDAC event log found at **Applications and Services logs - Microsoft - Windows - CodeIntegrity - Operational**. Within the CIDiag output directory, this event log is called CIOperational.evtx.
- Review all [policy activation events](event-id-explanations.md#app-control-policy-activation-events) from the core App Control event log found at **Applications and Services logs - Microsoft - Windows - CodeIntegrity - Operational**. Within the CIDiag output directory, this event log is called CIOperational.evtx.
2. Review any [block events for executables, dlls, and drivers](/windows/security/threat-protection/windows-defender-application-control/event-id-explanations#wdac-block-events-for-executables-dlls-and-drivers) from the core WDAC event log found at **Applications and Services logs - Microsoft - Windows - CodeIntegrity - Operational**. Within the CIDiag output directory, this event log is called CIOperational.evtx. Use information from the block events and their correlated 3089 signature details event(s) to investigate any blocks that are unexplained or unexpected. See the blocked executable example described later in this article for reference.
3. Review any [block events for packaged apps, MSI installers, scripts, and COM objects](/windows/security/threat-protection/windows-defender-application-control/event-id-explanations#wdac-block-events-for-packaged-apps-msi-installers-scripts-and-com-objects) from the core script enforcement event log found at **Applications and Services logs - Microsoft - Windows - AppLocker - MSI and Script**. Within the CIDiag output directory, this event log is called ALMsiAndScript.evtx. Use information from the block events and their correlated 8038 signature details event(s) to investigate any blocks that are unexplained or unexpected.
2. Review any [block events for executables, dlls, and drivers](event-id-explanations.md#app-control-block-events-for-executables-dlls-and-drivers) from the core App Control event log found at **Applications and Services logs - Microsoft - Windows - CodeIntegrity - Operational**. Within the CIDiag output directory, this event log is called CIOperational.evtx. Use information from the block events and their correlated 3089 signature details event(s) to investigate any blocks that are unexplained or unexpected. See the blocked executable example described later in this article for reference.
3. Review any [block events for packaged apps, MSI installers, scripts, and COM objects](event-id-explanations.md#app-control-block-events-for-packaged-apps-msi-installers-scripts-and-com-objects) from the core script enforcement event log found at **Applications and Services logs - Microsoft - Windows - AppLocker - MSI and Script**. Within the CIDiag output directory, this event log is called ALMsiAndScript.evtx. Use information from the block events and their correlated 8038 signature details event(s) to investigate any blocks that are unexplained or unexpected.
Most WDAC-related issues, including app and script failures, can be diagnosed using the preceding steps.
Most App Control-related issues, including app and script failures, can be diagnosed using the preceding steps.
### Event analysis for an example blocked executable
Here's an example of detailed EventData from a typical WDAC enforcement mode block event 3077, and one of its correlated 3089 signature information events. The tables that follow each event screenshot describe some of the elements contained in the events. Following the event descriptions is a step-by-step walkthrough explaining how to use the events to understand why the block occurred.
Here's an example of detailed EventData from a typical App Control enforcement mode block event 3077, and one of its correlated 3089 signature information events. The tables that follow each event screenshot describe some of the elements contained in the events. Following the event descriptions is a step-by-step walkthrough explaining how to use the events to understand why the block occurred.
#### Event 3077 - WDAC enforcement block event
#### Event 3077 - App Control enforcement block event
![Example 3077 block event for PowerShell.exe.](../images/event-3077.png)
| Element name | Description |
| ----- | ----- |
| System - Correlation - \[ActivityID\] | **Not shown in screenshot** <br> Use the correlation ActivityID to match a WDAC block event with one or more 3089 signature events. |
| File Name | The file's path and name on disk that was blocked from running. Since the name on disk is mutable, this value **isn't** the one used when creating WDAC file rules with `-Level FileName`. Instead, see the OriginalFileName element later in this table. |
| System - Correlation - \[ActivityID\] | **Not shown in screenshot** <br> Use the correlation ActivityID to match a App Control block event with one or more 3089 signature events. |
| File Name | The file's path and name on disk that was blocked from running. Since the name on disk is mutable, this value **isn't** the one used when creating App Control file rules with `-Level FileName`. Instead, see the OriginalFileName element later in this table. |
| Process Name | The path and name of the file that attempted to run the blocked file. Also called the parent process. |
| Requested Signing Level | The Windows signing authorization level the code needed to pass in order to run. See [Requested and validated signing level](/windows/security/threat-protection/windows-defender-application-control/event-tag-explanations#requested-and-validated-signing-level). |
| Validated Signing Level | The Windows signing authorization level the code was given. See [Requested and validated signing level](/windows/security/threat-protection/windows-defender-application-control/event-tag-explanations#requested-and-validated-signing-level). |
| Requested Signing Level | The Windows signing authorization level the code needed to pass in order to run. See [Requested and validated signing level](event-tag-explanations.md#requested-and-validated-signing-level). |
| Validated Signing Level | The Windows signing authorization level the code was given. See [Requested and validated signing level](event-tag-explanations.md#requested-and-validated-signing-level). |
| Status | Windows NT status code. You can use `certutil.exe -error <status>` to look up the meaning of the status code. |
| SHA1 Hash | The SHA1 Authenticode hash for the blocked file. |
| SHA256 Hash | The SHA256 Authenticode hash for the blocked file. |
| SHA1 Flat Hash | The SHA1 flat file hash for the blocked file. |
| SHA256 Flat Hash | The SHA256 flat file hash for the blocked file. |
| PolicyName | The friendly name of the WDAC policy that caused the block event. A separate 3077 block event (or 3076 audit block event) is shown for each policy that blocks the file from running. |
| PolicyId | The friendly ID value of the WDAC policy that caused the block event. |
| PolicyHash | The SHA256 Authenticode hash of the WDAC policy binary that caused the block event. |
| OriginalFileName | The immutable file name set by the developer in the blocked file's resource header. This value is the one used when creating WDAC file rules with `-Level FileName`. |
| PolicyName | The friendly name of the App Control policy that caused the block event. A separate 3077 block event (or 3076 audit block event) is shown for each policy that blocks the file from running. |
| PolicyId | The friendly ID value of the App Control policy that caused the block event. |
| PolicyHash | The SHA256 Authenticode hash of the App Control policy binary that caused the block event. |
| OriginalFileName | The immutable file name set by the developer in the blocked file's resource header. This value is the one used when creating App Control file rules with `-Level FileName`. |
| InternalName | Another immutable value set by the developer in the blocked file's resource header. You can substitute this value for the OriginalFileName in file rules with `-Level FileName -SpecificFileNameLevel InternalName`. |
| FileDescription | Another immutable value set by the developer in the blocked file's resource header. You can substitute this value for the OriginalFileName in file rules with `-Level FileName -SpecificFileNameLevel FileDescription`. |
| ProductName | Another immutable value set by the developer in the blocked file's resource header. You can substitute this value for the OriginalFileName in file rules with `-Level FileName -SpecificFileNameLevel ProductName`. |
| FileVersion | The policy's VersionEx value used to enforce version control over signed policies. |
| PolicyGUID | The PolicyId of the WDAC policy that caused the block event. |
| PolicyGUID | The PolicyId of the App Control policy that caused the block event. |
| UserWriteable | A boolean value indicating if the file was in a user-writeable location. This information is useful for diagnosing issues when allowing by FilePath rules. |
| PackageFamilyName | The Package Family Name for the packaged app (MSIX) that includes the blocked file. |
#### Event 3089 - WDAC signature information event
#### Event 3089 - App Control signature information event
![Example 3089 signature information event for PowerShell.exe.](../images/event-3089.png)
| Element name | Description |
| ----- | ----- |
| System - Correlation - \[ActivityID\] | Use the correlation ActivityID to match a WDAC signature event with its block event. |
| System - Correlation - \[ActivityID\] | Use the correlation ActivityID to match a App Control signature event with its block event. |
| TotalSignatureCount | The total number of signatures detected for the blocked file. |
| Signature | The index count, starting at 0, of the current signature shown in this 3089 event. If the file had multiple signatures, you'll find other 3089 events for the other signatures. |
| Hash | The hash value that WDAC used to match the file. This value should match one of the four hashes shown on the 3077 or 3076 block event. If no signatures were found for the file (TotalSignatureCount = 0), then only the hash value is shown. |
| SignatureType | The [type of signature](/windows/security/threat-protection/windows-defender-application-control/event-tag-explanations#signaturetype). |
| ValidatedSigningLevel | The Windows signing authorization level the signature met. See [Requested and validated signing level](/windows/security/threat-protection/windows-defender-application-control/event-tag-explanations#requested-and-validated-signing-level). |
| VerificationError | The reason this particular signature failed to pass the WDAC policy. See [VerificationError](/windows/security/threat-protection/windows-defender-application-control/event-tag-explanations#verificationerror). |
| Hash | The hash value that App Control used to match the file. This value should match one of the four hashes shown on the 3077 or 3076 block event. If no signatures were found for the file (TotalSignatureCount = 0), then only the hash value is shown. |
| SignatureType | The [type of signature](event-tag-explanations.md#signaturetype). |
| ValidatedSigningLevel | The Windows signing authorization level the signature met. See [Requested and validated signing level](event-tag-explanations.md#requested-and-validated-signing-level). |
| VerificationError | The reason this particular signature failed to pass the App Control policy. See [VerificationError](event-tag-explanations.md#verificationerror). |
| PublisherName | The common name (CN) value from the leaf certificate. |
| IssuerName | The CN value from the highest available certificate in the certificate chain. This level is typically one certificate below the root. |
| PublisherTBSHash | The TBS hash of the leaf certificate. |
@ -166,7 +165,7 @@ Here's an example of detailed EventData from a typical WDAC enforcement mode blo
#### Step-by-step walkthrough of the example 3077 and 3089 events
Now let's walk through how to use the event data in the example 3077 and 3089 events to understand why the WDAC policy blocked this file.
Now let's walk through how to use the event data in the example 3077 and 3089 events to understand why the App Control policy blocked this file.
##### Understand what file is being blocked and the block context
@ -174,11 +173,11 @@ Referring to the 3077 event, locate the information that identifies the policy,
In the example, the file being blocked is PowerShell.exe, which is part of Windows and would normally be expected to run. However, in this case, the policy was based off of the Windows in S mode policy template, which doesn't allow script hosts to run as a way to limit the attack surface. For S mode, this block event is a success. But let's assume the policy author was unaware of that constraint when they chose the template, and treat this block as unexpected.
##### Determine why WDAC rejected the file
##### Determine why App Control rejected the file
Again referring to the 3077 event, we see the Requested Signing Level of 2 means the code must pass the WDAC policy. But the Validated Signing Level of 1 means the code was treated as though unsigned. "Unsigned" could mean the file was truly unsigned, signed but with an invalid certificate, or signed but without any certificates allowed by the WDAC policy.
Again referring to the 3077 event, we see the Requested Signing Level of 2 means the code must pass the App Control policy. But the Validated Signing Level of 1 means the code was treated as though unsigned. "Unsigned" could mean the file was truly unsigned, signed but with an invalid certificate, or signed but without any certificates allowed by the App Control policy.
Now, let's inspect the correlated 3089 event(s) for the blocked file. In the example, we're looking at only the first signature (Signature index 0) found on a file that had multiple signatures. For this signature, the ValidatedSigningLevel is 12, meaning it has a Microsoft Windows product signature. The VerificationError of 21 means that the signature didn't pass the WDAC policy.
Now, let's inspect the correlated 3089 event(s) for the blocked file. In the example, we're looking at only the first signature (Signature index 0) found on a file that had multiple signatures. For this signature, the ValidatedSigningLevel is 12, meaning it has a Microsoft Windows product signature. The VerificationError of 21 means that the signature didn't pass the App Control policy.
It's important to review the information for each correlated 3089 event as each signature may have a different ValidatedSigningLevel and VerificationError.
@ -191,11 +190,11 @@ It's important to review the information for each correlated 3089 event as each
## 3 - Resolve common problems
Having analyzed the WDAC diagnostic data, you can take steps to resolve the issue or do more debugging steps. Following are some common problems and steps you can try to resolve or further isolate the root issue:
Having analyzed the App Control diagnostic data, you can take steps to resolve the issue or do more debugging steps. Following are some common problems and steps you can try to resolve or further isolate the root issue:
### Issue: A file was blocked that you want to allow
- Use data from the core WDAC event logs to add rules to allow the blocked file.
- Use data from the core App Control event logs to add rules to allow the blocked file.
- Redeploy the file or app using a managed installer if your policy trusts managed installers.
### Issue: A policy is active that is unexpected
@ -208,51 +207,51 @@ This condition may exist if:
- A policy was incorrectly deployed to the device.
- An attacker with administrator access has applied a policy to cause denial of service for some critical processes.
To resolve such an issue, follow the instructions to [Remove WDAC policies](/windows/security/threat-protection/windows-defender-application-control/disable-windows-defender-application-control-policies) for the identified policy.
To resolve such an issue, follow the instructions to [Remove App Control policies](../deployment/disable-appcontrol-policies.md) for the identified policy.
### Issue: An unhandled app failure is occurring and no WDAC events are observed
### Issue: An unhandled app failure is occurring and no App Control events are observed
Some apps alter their behavior when a user mode WDAC policy is active, which can result in unexpected failures. It can also be a side-effect of script enforcement for apps that don't properly handle the enforcement behaviors implemented by the script hosts.
Some apps alter their behavior when a user mode App Control policy is active, which can result in unexpected failures. It can also be a side-effect of script enforcement for apps that don't properly handle the enforcement behaviors implemented by the script hosts.
Try to isolate the root cause by doing the following actions:
- Check the other event logs listed in section 1 of this article for events corresponding with the unexpected app failures.
- Temporarily replace the WDAC policy with another policy that [disables script enforcement](/windows/security/threat-protection/windows-defender-application-control/design/script-enforcement) and retest.
- Temporarily replace the WDAC policy with another policy that [allows all COM objects](/windows/security/threat-protection/windows-defender-application-control/allow-com-object-registration-in-windows-defender-application-control-policy) and retest.
- Temporarily replace the WDAC policy with another policy that relaxes other [policy rules](/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create#windows-defender-application-control-policy-rules) and retest.
- Temporarily replace the App Control policy with another policy that [disables script enforcement](../design/script-enforcement.md) and retest.
- Temporarily replace the App Control policy with another policy that [allows all COM objects](../design/allow-com-object-registration-in-appcontrol-policy.md) and retest.
- Temporarily replace the App Control policy with another policy that relaxes other [policy rules](../design/select-types-of-rules-to-create.md#app-control-for-business-policy-rules) and retest.
### Issue: An app deployed by a managed installer isn't working
To debug issues using managed installer, try these steps:
- Check that the WDAC policy that is blocking the app includes the option to enable managed installer.
- Check that the effective AppLocker policy $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLocker.xml is correct as described in [Automatically allow apps deployed by a managed installer](/windows/security/threat-protection/windows-defender-application-control/configure-authorized-apps-deployed-with-a-managed-installer#create-and-deploy-an-applocker-policy-that-defines-your-managed-installer-rules-and-enables-services-enforcement-for-executables-and-dlls).
- Check that the App Control policy that is blocking the app includes the option to enable managed installer.
- Check that the effective AppLocker policy $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLocker.xml is correct as described in [Automatically allow apps deployed by a managed installer](../design/configure-authorized-apps-deployed-with-a-managed-installer.md#create-and-deploy-an-applocker-policy-that-defines-your-managed-installer-rules-and-enables-services-enforcement-for-executables-and-dlls).
- Check that the AppLocker services are running. This information is found in $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerServices.txt created in section 1 of this article.
- Check that an AppLocker file exists called MANAGEDINSTALLER.APPLOCKER exists in the CiDiag folder created earlier. If not, repeat the steps to deploy and enable the managed installer AppLocker configuration.
- Restart the managed installer process and check that an 8002 event is observed in the **AppLocker - EXE and DLL** event log for the managed installer process with PolicyName = MANAGEDINSTALLER. If instead you see an event with 8003 or 8004 with PolicyName = MANAGEDINSTALLER, then check the ManagedInstaller rules in the AppLocker policy XML and ensure a rule matches the managed installer process.
- [Use fsutil.exe](/windows/security/threat-protection/windows-defender-application-control/configure-wdac-managed-installer#using-fsutil-to-query-extended-attributes-for-managed-installer-mi) to verify files written by the managed installer process have the managed installer origin extended attribute. If not, redeploy the files with the managed installer and check again.
- [Use fsutil.exe](configure-appcontrol-managed-installer.md#using-fsutil-to-query-extended-attributes-for-managed-installer-mi) to verify files written by the managed installer process have the managed installer origin extended attribute. If not, redeploy the files with the managed installer and check again.
- Test installation of a different app using the managed installer.
- Add another managed installer to your AppLocker policy and test installation using the other managed installer.
- Check if the app is encountering a [known limitation with managed installer](/windows/security/threat-protection/windows-defender-application-control/configure-authorized-apps-deployed-with-a-managed-installer#known-limitations-with-managed-installer). If so, you must authorize the app using other means.
- Check if the app is encountering a [known limitation with managed installer](../design/configure-authorized-apps-deployed-with-a-managed-installer.md#known-limitations-with-managed-installer). If so, you must authorize the app using other means.
### Issue: An app you expected the Intelligent Security Graph (ISG) to allow isn't working
To debug issues using ISG, try these steps:
- Check that the WDAC policy that is blocking the app includes the option to enable the intelligent security graph.
- Check that the App Control policy that is blocking the app includes the option to enable the intelligent security graph.
- Check that the AppLocker services are running. This information is found in $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerServices.txt created in section 1 of this article.
- [Use fsutil.exe](/windows/security/threat-protection/windows-defender-application-control/configure-wdac-managed-installer#using-fsutil-to-query-extended-attributes-for-intelligent-security-graph-isg) to verify files have the ISG origin extended attribute. If not, redeploy the files with the managed installer and check again.
- Check if the app is encountering a [known limitation with ISG](/windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-intelligent-security-graph#known-limitations-with-using-the-isg).
- [Use fsutil.exe](configure-appcontrol-managed-installer.md#using-fsutil-to-query-extended-attributes-for-intelligent-security-graph-isg) to verify files have the ISG origin extended attribute. If not, redeploy the files with the managed installer and check again.
- Check if the app is encountering a [known limitation with ISG](../design/use-appcontrol-with-intelligent-security-graph.md#known-limitations-with-using-the-isg).
## 4 - Report issues to Microsoft, if appropriate
If after following the guidance covered by this article you believe you've identified a product issue, report the issue to Microsoft.
- Customers with Microsoft Premier Support should log a service request through normal channels.
- All other customers can report issues directly to the WDAC product team via the Windows [Feedback Hub](feedback-hub:?contextid=790&tabid=2&newFeedback=true). Select the category **Security & Privacy - Application Control** to ensure the issue is properly routed to the WDAC product team.
- All other customers can report issues directly to the App Control product team via the Windows [Feedback Hub](feedback-hub:?contextid=790&tabid=2&newFeedback=true). Select the category **Security & Privacy - Application Control** to ensure the issue is properly routed to the App Control product team.
When reporting issues, be sure to provide the following information:
- All [WDAC diagnostic data](#1---gather-wdac-diagnostic-data) described earlier.
- All [App Control diagnostic data](#1---gather-app-control-diagnostic-data) described earlier.
- If possible, the blocked file(s).
- Clear instructions to reproduce the problem.

View File

@ -1,27 +1,26 @@
---
title: Managing and troubleshooting Windows Defender Application Control policies
description: Gather information about how your deployed Windows Defender Application Control policies are behaving.
title: Managing and troubleshooting App Control for Business policies
description: Gather information about how your deployed App Control for Business policies are behaving.
ms.localizationpriority: medium
ms.date: 03/30/2023
ms.topic: how-to
---
# Windows Defender Application Control operational guide
# App Control for Business operational guide
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
You now understand how to design and deploy your Windows Defender Application Control (WDAC) policies. This guide explains how to understand the effects your policies have and how to troubleshoot when they aren't behaving as expected. It contains information on where to find events and what they mean, and also querying these events with Microsoft Defender for Endpoint Advanced Hunting feature.
You now understand how to design and deploy your App Control for Business policies. This guide explains how to understand the effects your policies have and how to troubleshoot when they aren't behaving as expected. It contains information on where to find events and what they mean, and also querying these events with Microsoft Defender for Endpoint Advanced Hunting feature.
## In this section
| Article | Description |
| - | - |
| [Debugging and troubleshooting](/windows/security/threat-protection/windows-defender-application-control/operations/wdac-debugging-and-troubleshooting) | This article explains how to debug app and script failures with WDAC. |
| [Understanding Application Control event IDs](/windows/security/threat-protection/windows-defender-application-control/event-id-explanations) | This article explains the meaning of different WDAC event IDs. |
| [Understanding Application Control event tags](/windows/security/threat-protection/windows-defender-application-control/event-tag-explanations) | This article explains the meaning of different WDAC event tags. |
| [Query WDAC events with Advanced hunting](/windows/security/threat-protection/windows-defender-application-control/querying-application-control-events-centrally-using-advanced-hunting) | This article covers how to view WDAC events centrally from all systems that are connected to Microsoft Defender for Endpoint. |
| [Admin Tips & Known Issues](/windows/security/threat-protection/windows-defender-application-control/operations/known-issues) | This article describes some WDAC Admin Tips & Known Issues. |
| [Managed installer and ISG technical reference and troubleshooting guide](/windows/security/threat-protection/windows-defender-application-control/configure-wdac-managed-installer) | This article provides technical details and debugging steps for managed installer and ISG. |
| [CITool.exe technical reference](/windows/security/threat-protection/windows-defender-application-control/operations/citool-commands) | This article explains how to use CITool.exe. |
| [Inbox WDAC policies](/windows/security/threat-protection/windows-defender-application-control/operations/inbox-wdac-policies) | This article describes the WDAC policies that ship with Windows and when they're active. |
| [Debugging and troubleshooting](appcontrol-debugging-and-troubleshooting.md) | This article explains how to debug app and script failures with App Control. |
| [Understanding Application Control event IDs](event-id-explanations.md) | This article explains the meaning of different App Control event IDs. |
| [Understanding Application Control event tags](event-tag-explanations.md) | This article explains the meaning of different App Control event tags. |
| [Query App Control events with Advanced hunting](querying-application-control-events-centrally-using-advanced-hunting.md) | This article covers how to view App Control events centrally from all systems that are connected to Microsoft Defender for Endpoint. |
| [Admin Tips & Known Issues](known-issues.md) | This article describes some App Control Admin Tips & Known Issues. |
| [Managed installer and ISG technical reference and troubleshooting guide](configure-appcontrol-managed-installer.md) | This article provides technical details and debugging steps for managed installer and ISG. |
| [CITool.exe technical reference](citool-commands.md) | This article explains how to use CITool.exe. |
| [Inbox App Control policies](inbox-appcontrol-policies.md) | This article describes the App Control policies that ship with Windows and when they're active. |

View File

@ -9,7 +9,7 @@ appliesto:
# CiTool technical reference
CiTool makes Windows Defender Application Control (WDAC) policy management easier for IT admins. You can use this tool to manage Windows Defender Application Control policies and CI tokens. This article describes how to use CiTool to update and manage policies. It's currently included as part of the Windows image in Windows 11, version 22H2.
CiTool makes App Control for Business policy management easier for IT admins. You can use this tool to manage App Control for Business policies and CI tokens. This article describes how to use CiTool to update and manage policies. It's currently included as part of the Windows image in Windows 11, version 22H2.
## Policy commands
@ -35,7 +35,7 @@ CiTool makes Windows Defender Application Control (WDAC) policy management easie
| Command | Description | Alias |
|--------|---------|---------|
| `--device-id` | Dump the code integrity device ID. | `-id` |
| `--refresh` | Attempt to refresh WDAC policies. | `-r` |
| `--refresh` | Attempt to refresh App Control policies. | `-r` |
| `--help` | Display the tool's help menu. | `-h` |
## Output attributes and descriptions
@ -69,25 +69,25 @@ CiTool makes Windows Defender Application Control (WDAC) policy management easie
## Examples
### Deploy a WDAC policy
### Deploy a App Control policy
```powershell
CiTool --update-policy "\Windows\Temp\{BF61FE40-8929-4FDF-9EC2-F7A767717F0B}.cip"
```
### Refresh the WDAC policies on the system
### Refresh the App Control policies on the system
```powershell
CiTool --refresh
```
### Remove a specific WDAC policy by its policy ID
### Remove a specific App Control policy by its policy ID
```powershell
CiTool --remove-policy "{BF61FE40-8929-4FDF-9EC2-F7A767717F0B}"
```
### List the actively enforced WDAC policies on the system
### List the actively enforced App Control policies on the system
```powershell
# Check each policy's IsEnforced state and return only the enforced policies

View File

@ -8,8 +8,7 @@ ms.topic: troubleshooting
# Managed installer and ISG technical reference and troubleshooting guide
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Application Control feature availability](../feature-availability.md).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
## Enabling managed installer and Intelligent Security Graph (ISG) logging events
@ -17,7 +16,7 @@ Refer to [Understanding Application Control Events](event-id-explanations.md#dia
## Using fsutil to query extended attributes for Managed Installer (MI)
Customers using Windows Defender Application Control (WDAC) with Managed Installer (MI) enabled can use fsutil.exe to determine whether a file was created by a managed installer process. This verification is done by querying the Extended Attributes (EAs) on a file using fsutil.exe and looking for the KERNEL.SMARTLOCKER.ORIGINCLAIM EA. Then, you can use the data from the first row of output to identify if the file was created by a managed installer. For example, let's look at the fsutil.exe output for a file called application.exe:
Customers using App Control for Business with Managed Installer (MI) enabled can use fsutil.exe to determine whether a file was created by a managed installer process. This verification is done by querying the Extended Attributes (EAs) on a file using fsutil.exe and looking for the KERNEL.SMARTLOCKER.ORIGINCLAIM EA. Then, you can use the data from the first row of output to identify if the file was created by a managed installer. For example, let's look at the fsutil.exe output for a file called application.exe:
**Example:**
@ -47,7 +46,7 @@ If there is "00" in the fifth position of the output (the start of the second UL
0000: 01 00 00 00 **`00` 00 00 00** 00 00 00 00 01 00 00 00
Finally, the two-character set in the ninth position of the output (the start of the third ULONG) indicates whether the file was created by a process running as managed installer. A value of "00" means the file was directly written by a managed installer process and will run if your WDAC policy trusts managed installers.
Finally, the two-character set in the ninth position of the output (the start of the third ULONG) indicates whether the file was created by a process running as managed installer. A value of "00" means the file was directly written by a managed installer process and will run if your App Control policy trusts managed installers.
0000: 01 00 00 00 00 00 00 00 **`00` 00 00 00** 01 00 00 00
@ -98,4 +97,4 @@ Both managed installer and the ISG depend on AppLocker to provide some functiona
Get-AppLockerPolicy -Effective -XML > $env:USERPROFILE\Desktop\AppLocker.xml
```
Then open the XML file created and confirm it contains the rules you expect. In particular, the policy should include at least one rule for each of the EXE, DLL, and MANAGEDINSTALLER RuleCollections. The RuleCollections can either be set to AuditOnly or Enabled. Additionally, the EXE and DLL RuleCollections must include the RuleCollectionExtensions configuration as shown in [Automatically allow apps deployed by a managed installer with Windows Defender Application Control](/windows/security/threat-protection/windows-defender-application-control/configure-authorized-apps-deployed-with-a-managed-installer#create-and-deploy-an-applocker-policy-that-defines-your-managed-installer-rules-and-enables-services-enforcement-for-executables-and-dlls).
Then open the XML file created and confirm it contains the rules you expect. In particular, the policy should include at least one rule for each of the EXE, DLL, and MANAGEDINSTALLER RuleCollections. The RuleCollections can either be set to AuditOnly or Enabled. Additionally, the EXE and DLL RuleCollections must include the RuleCollectionExtensions configuration as shown in [Automatically allow apps deployed by a managed installer with App Control for Business](../design/configure-authorized-apps-deployed-with-a-managed-installer.md#create-and-deploy-an-applocker-policy-that-defines-your-managed-installer-rules-and-enables-services-enforcement-for-executables-and-dlls).

View File

@ -1,6 +1,6 @@
---
title: Understanding Application Control event IDs
description: Learn what different Windows Defender Application Control event IDs signify.
description: Learn what different App Control for Business event IDs signify.
ms.localizationpriority: medium
ms.date: 03/24/2023
ms.topic: reference
@ -8,50 +8,50 @@ ms.topic: reference
# Understanding Application Control events
## WDAC Events Overview
## App Control Events Overview
WDAC logs events when a policy is loaded, when a file is blocked, or when a file would be blocked if in audit mode. These block events include information that identifies the policy and gives more details about the block. WDAC doesn't generate events when a binary is allowed. However, you can turn on allow audit events for files authorized by a managed installer or the Intelligent Security Graph (ISG) as described later in this article.
App Control logs events when a policy is loaded, when a file is blocked, or when a file would be blocked if in audit mode. These block events include information that identifies the policy and gives more details about the block. App Control doesn't generate events when a binary is allowed. However, you can turn on allow audit events for files authorized by a managed installer or the Intelligent Security Graph (ISG) as described later in this article.
### Core WDAC event logs
### Core App Control event logs
WDAC events are generated under two locations in the Windows Event Viewer:
App Control events are generated under two locations in the Windows Event Viewer:
- **Applications and Services logs - Microsoft - Windows - CodeIntegrity - Operational** includes events about Application Control policy activation and the control of executables, dlls, and drivers.
- **Applications and Services logs - Microsoft - Windows - AppLocker - MSI and Script** includes events about the control of MSI installers, scripts, and COM objects.
Most app and script failures that occur when WDAC is active can be diagnosed using these two event logs. This article describes in greater detail the events that exist in these logs. To understand the meaning of different data elements, or tags, found in the details of these events, see [Understanding Application Control event tags](event-tag-explanations.md).
Most app and script failures that occur when App Control is active can be diagnosed using these two event logs. This article describes in greater detail the events that exist in these logs. To understand the meaning of different data elements, or tags, found in the details of these events, see [Understanding Application Control event tags](event-tag-explanations.md).
> [!NOTE]
> **Applications and Services logs - Microsoft - Windows - AppLocker - MSI and Script** events are not included on Windows Server Core edition.
## WDAC block events for executables, dlls, and drivers
## App Control block events for executables, dlls, and drivers
These events are found in the **CodeIntegrity - Operational** event log.
| Event ID | Explanation |
|--------|-----------|
| 3004 | This event isn't common and may occur with or without an Application Control policy present. It typically indicates a kernel driver tried to load with an invalid signature. For example, the file may not be WHQL-signed on a system where WHQL is required. <br><br> This event is also seen for kernel- or user-mode code that the developer opted-in to [/INTEGRITYCHECK](/cpp/build/reference/integritycheck-require-signature-check) but isn't signed correctly. |
| 3033 | This event may occur with or without an Application Control policy present and should occur alongside a 3077 event if caused by WDAC policy. It often means the file's signature is revoked or a signature with the Lifetime Signing EKU has expired. Presence of the Lifetime Signing EKU is the only case where WDAC blocks files due to an expired signature. Try using option `20 Enabled:Revoked Expired As Unsigned` in your policy along with a rule (for example, hash) that doesn't rely on the revoked or expired cert. <br><br> This event also occurs if code compiled with [Code Integrity Guard (CIG)](/microsoft-365/security/defender-endpoint/exploit-protection-reference#code-integrity-guard) tries to load other code that doesn't meet the CIG requirements. |
| 3033 | This event may occur with or without an Application Control policy present and should occur alongside a 3077 event if caused by App Control policy. It often means the file's signature is revoked or a signature with the Lifetime Signing EKU has expired. Presence of the Lifetime Signing EKU is the only case where App Control blocks files due to an expired signature. Try using option `20 Enabled:Revoked Expired As Unsigned` in your policy along with a rule (for example, hash) that doesn't rely on the revoked or expired cert. <br><br> This event also occurs if code compiled with [Code Integrity Guard (CIG)](/microsoft-365/security/defender-endpoint/exploit-protection-reference#code-integrity-guard) tries to load other code that doesn't meet the CIG requirements. |
| 3034 | This event isn't common. It's the audit mode equivalent of event 3033. |
| 3076 | This event is the main Application Control block event for audit mode policies. It indicates that the file would have been blocked if the policy was enforced. |
| 3077 | This event is the main Application Control block event for enforced policies. It indicates that the file didn't pass your policy and was blocked. |
| 3089 | This event contains signature information for files that were blocked or audit blocked by Application Control. One of these events is created for each signature of a file. Each event shows the total number of signatures found and an index value to identify the current signature. Unsigned files generate a single one of these events with TotalSignatureCount of 0. These events are correlated with 3004, 3033, 3034, 3076 and 3077 events. You can match the events using the `Correlation ActivityID` found in the **System** portion of the event. |
## WDAC block events for packaged apps, MSI installers, scripts, and COM objects
## App Control block events for packaged apps, MSI installers, scripts, and COM objects
These events are found in the **AppLocker - MSI and Script** event log.
| Event ID | Explanation |
|--------|-----------|
| 8028 | This event indicates that a script host, such as PowerShell, queried Application Control about a file the script host was about to run. Since the policy was in audit mode, the script or MSI file should have run, but wouldn't have passed the WDAC policy if it was enforced. Some script hosts may have additional information in their logs. Note: Most third-party script hosts don't integrate with Application Control. Consider the risks from unverified scripts when choosing which script hosts you allow to run. |
| 8029 | This event is the enforcement mode equivalent of event 8028. Note: While this event says that a script was blocked, the script hosts control the actual script enforcement behavior. The script host may allow the file to run with restrictions and not block the file outright. For example, PowerShell runs script not allowed by your WDAC policy in [Constrained Language Mode](/powershell/module/microsoft.powershell.core/about/about_language_modes). |
| 8036| COM object was blocked. To learn more about COM object authorization, see [Allow COM object registration in a Windows Defender Application Control policy](../design/allow-com-object-registration-in-appcontrol-policy.md). |
| 8037 | This event indicates that a script host checked whether to allow a script to run, and the file passed the WDAC policy. |
| 8028 | This event indicates that a script host, such as PowerShell, queried Application Control about a file the script host was about to run. Since the policy was in audit mode, the script or MSI file should have run, but wouldn't have passed the App Control policy if it was enforced. Some script hosts may have additional information in their logs. Note: Most third-party script hosts don't integrate with Application Control. Consider the risks from unverified scripts when choosing which script hosts you allow to run. |
| 8029 | This event is the enforcement mode equivalent of event 8028. Note: While this event says that a script was blocked, the script hosts control the actual script enforcement behavior. The script host may allow the file to run with restrictions and not block the file outright. For example, PowerShell runs script not allowed by your App Control policy in [Constrained Language Mode](/powershell/module/microsoft.powershell.core/about/about_language_modes). |
| 8036| COM object was blocked. To learn more about COM object authorization, see [Allow COM object registration in a App Control for Business policy](../design/allow-com-object-registration-in-appcontrol-policy.md). |
| 8037 | This event indicates that a script host checked whether to allow a script to run, and the file passed the App Control policy. |
| 8038 | Signing information event correlated with either an 8028 or 8029 event. One 8038 event is generated for each signature of a script file. Contains the total number of signatures on a script file and an index as to which signature it is. Unsigned script files generate a single 8038 event with TotalSignatureCount 0. These events are correlated with 8028 and 8029 events and can be matched using the `Correlation ActivityID` found in the **System** portion of the event. |
| 8039 | This event indicates that a packaged app (MSIX/AppX) was allowed to install or run because the WDAC policy is in audit mode. But, it would have been blocked if the policy was enforced. |
| 8040 | This event indicates that a packaged app was prevented from installing or running due to the WDAC policy. |
| 8039 | This event indicates that a packaged app (MSIX/AppX) was allowed to install or run because the App Control policy is in audit mode. But, it would have been blocked if the policy was enforced. |
| 8040 | This event indicates that a packaged app was prevented from installing or running due to the App Control policy. |
## WDAC policy activation events
## App Control policy activation events
These events are found in the **CodeIntegrity - Operational** event log.
@ -72,7 +72,7 @@ These events are found in the **CodeIntegrity - Operational** event log.
> [!NOTE]
> When Managed Installer is enabled, customers using LogAnalytics should be aware that Managed Installer may fire many 3091 events. Customers may need to filter out these events to avoid high LogAnalytics costs.
The following events provide helpful diagnostic information when a WDAC policy includes the ISG or MI option. These events can help you debug why something was allowed/denied based on managed installer or ISG. Events 3090, 3091, and 3092 don't necessarily indicate a problem but should be reviewed in context with other events like 3076 or 3077.
The following events provide helpful diagnostic information when a App Control policy includes the ISG or MI option. These events can help you debug why something was allowed/denied based on managed installer or ISG. Events 3090, 3091, and 3092 don't necessarily indicate a problem but should be reviewed in context with other events like 3076 or 3077.
Unless otherwise noted, these events are found in either the **CodeIntegrity - Operational** event log or the **CodeIntegrity - Verbose** event log depending on your version of Windows.
@ -81,7 +81,7 @@ Unless otherwise noted, these events are found in either the **CodeIntegrity - O
| 3090 | *Optional* This event indicates that a file was allowed to run based purely on ISG or managed installer. |
| 3091 | This event indicates that a file didn't have ISG or managed installer authorization and the Application Control policy is in audit mode. |
| 3092 | This event is the enforcement mode equivalent of 3091. |
| 8002 | This event is found in the **AppLocker - EXE and DLL** event log. When a process launches that matches a managed installer rule, this event is raised with PolicyName = MANAGEDINSTALLER found in the event Details. Events with PolicyName = EXE or DLL aren't related to WDAC. |
| 8002 | This event is found in the **AppLocker - EXE and DLL** event log. When a process launches that matches a managed installer rule, this event is raised with PolicyName = MANAGEDINSTALLER found in the event Details. Events with PolicyName = EXE or DLL aren't related to App Control. |
Events 3090, 3091, and 3092 are reported per active policy on the system, so you may see multiple events for the same file.

View File

@ -1,6 +1,6 @@
---
title: Understanding Application Control event tags
description: Learn what different Windows Defender Application Control event tags signify.
description: Learn what different App Control for Business event tags signify.
ms.localizationpriority: medium
ms.date: 05/09/2023
ms.topic: conceptual
@ -8,7 +8,7 @@ ms.topic: conceptual
# Understanding Application Control event tags
Windows Defender Application Control (WDAC) events include many fields, which provide helpful troubleshooting information to figure out exactly what an event means. This article describes the values and meanings for a few useful event tags.
App Control for Business events include many fields, which provide helpful troubleshooting information to figure out exactly what an event means. This article describes the values and meanings for a few useful event tags.
## SignatureType
@ -33,7 +33,7 @@ Represents the signature level at which the code was verified.
|---|----------|
| 0 | Signing level hasn't yet been checked |
| 1 | File is unsigned or has no signature that passes the active policies |
| 2 | Trusted by Windows Defender Application Control policy |
| 2 | Trusted by App Control for Business policy |
| 3 | Developer signed code |
| 4 | Authenticode signed |
| 5 | Microsoft Store signed app PPL (Protected Process Light) |
@ -71,7 +71,7 @@ Represents why verification failed, or if it succeeded.
| 18 | Custom signing level not met; returned if signature fails to match `CISigners` in UMCI. |
| 19 | Binary is revoked based on its file hash. |
| 20 | SHA1 cert hash's timestamp is missing or after valid cutoff as defined by Weak Crypto Policy. |
| 21 | Failed to pass Windows Defender Application Control policy. |
| 21 | Failed to pass App Control for Business policy. |
| 22 | Not Isolated User Mode (IUM)) signed; indicates an attempt to load a standard Windows binary into a virtualization-based security (VBS) trustlet. |
| 23 | Invalid image hash. This error can indicate file corruption or a problem with the file's signature. Signatures using elliptic curve cryptography (ECC), such as ECDSA, return this VerificationError. |
| 24 | Flight root not allowed; indicates trying to run flight-signed code on production OS. |
@ -82,7 +82,7 @@ Represents why verification failed, or if it succeeded.
## Policy activation event Options
The Application Control policy rule option values can be derived from the "Options" field in the Details section for successful [policy activation events](event-id-explanations.md#wdac-policy-activation-events). To parse the values, first convert the hex value to binary. To derive and parse these values, follow the below workflow.
The Application Control policy rule option values can be derived from the "Options" field in the Details section for successful [policy activation events](event-id-explanations.md#app-control-policy-activation-events). To parse the values, first convert the hex value to binary. To derive and parse these values, follow the below workflow.
- Access Event Viewer.
- Access the Code integrity 3099 event.
@ -105,7 +105,7 @@ For a simple solution for converting hex to binary, follow these steps:
This view provides the hex code in binary form, with each bit address shown separately. The bit addresses start at 0 in the bottom right. Each bit address correlates to a specific event policy-rule option. If the bit address holds a value of 1, the setting is in the policy.
Next, use the bit addresses and their values from the following table to determine the state of each [policy rule-option](../design/select-types-of-rules-to-create.md#table-1-windows-defender-application-control-policy---policy-rule-options). For example, if the bit address of 16 holds a value of 1, then the **Enabled: Audit Mode (Default)** option is in the policy. This setting means that the policy is in audit mode.
Next, use the bit addresses and their values from the following table to determine the state of each [policy rule-option](../design/select-types-of-rules-to-create.md#table-1-app-control-for-business-policy---policy-rule-options). For example, if the bit address of 16 holds a value of 1, then the **Enabled: Audit Mode (Default)** option is in the policy. This setting means that the policy is in audit mode.
| Bit Address | Policy Rule Option |
|-------|------|
@ -157,7 +157,7 @@ The rule means trust anything signed by a certificate that chains to this root C
| 18 | Microsoft ECC Product Root CA 2018 |
| 19 | Microsoft ECC Devices Root CA 2017 |
For well-known roots, the TBS hashes for the certificates are baked into the code for Windows Defender Application Control. For example, they don't need to be listed as TBS hashes in the policy file.
For well-known roots, the TBS hashes for the certificates are baked into the code for App Control for Business. For example, they don't need to be listed as TBS hashes in the policy file.
## Status values

View File

@ -1,24 +1,23 @@
---
title: Inbox WDAC policies
description: This article describes the inbox WDAC policies that may be active on a device.
title: Inbox App Control policies
description: This article describes the inbox App Control policies that may be active on a device.
ms.manager: jsuther
ms.date: 03/10/2023
ms.topic: conceptual
ms.localizationpriority: medium
---
# Inbox WDAC policies
# Inbox App Control policies
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
This article describes the Windows Defender Application Control (WDAC) policies that ship inbox with Windows and may be active on your devices. To see which policies are active on your device, use [citool.exe](/windows/security/threat-protection/windows-defender-application-control/operations/citool-commands) or check the *CodeIntegrity - Operational* event log for 3099 policy activation events.
This article describes the App Control for Business policies that ship inbox with Windows and may be active on your devices. To see which policies are active on your device, use [citool.exe](citool-commands.md) or check the *CodeIntegrity - Operational* event log for 3099 policy activation events.
## Inbox WDAC Policies
## Inbox App Control Policies
| **Policy Name** | **Policy ID** | **Policy Type** | **Description** |
|-----------|-----------|-----------|-----------|
| **Microsoft Windows Driver Policy** | {d2bda982-ccf6-4344-ac5b-0b44427b6816} | Kernel-only Base policy | This policy blocks known [vulnerable or malicious kernel drivers](/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-driver-block-rules). It's active by default on Windows 11 22H2, [Windows in S mode](https://support.microsoft.com/windows/windows-10-and-windows-11-in-s-mode-faq-851057d6-1ee9-b9e5-c30b-93baebeebc85), [Windows 11 SE](/education/windows/windows-11-se-overview), and anywhere [memory integrity](https://support.microsoft.com/windows/core-isolation-e30ed737-17d8-42f3-a2a9-87521df09b78) (also known as hypervisor-protected code integrity (HVCI)) is on. Its policy binary file is found at `%windir%\System32\CodeIntegrity\driversipolicy.p7b` and in the EFI system partition at `<EFI System Partition>\Microsoft\Boot\driversipolicy.p7b`. |
| **Microsoft Windows Driver Policy** | {d2bda982-ccf6-4344-ac5b-0b44427b6816} | Kernel-only Base policy | This policy blocks known [vulnerable or malicious kernel drivers](../design/microsoft-recommended-driver-block-rules.md). It's active by default on Windows 11 22H2, [Windows in S mode](https://support.microsoft.com/windows/windows-10-and-windows-11-in-s-mode-faq-851057d6-1ee9-b9e5-c30b-93baebeebc85), [Windows 11 SE](/education/windows/windows-11-se-overview), and anywhere [memory integrity](https://support.microsoft.com/windows/core-isolation-e30ed737-17d8-42f3-a2a9-87521df09b78) (also known as hypervisor-protected code integrity (HVCI)) is on. Its policy binary file is found at `%windir%\System32\CodeIntegrity\driversipolicy.p7b` and in the EFI system partition at `<EFI System Partition>\Microsoft\Boot\driversipolicy.p7b`. |
| **Windows10S_Lockdown_Policy_Supplementable** | {5951a96a-e0b5-4d3d-8fb8-3e5b61030784} | Base policy | This policy is active on devices running [Windows in S mode](https://support.microsoft.com/windows/windows-10-and-windows-11-in-s-mode-faq-851057d6-1ee9-b9e5-c30b-93baebeebc85). Its policy binary file is found in the EFI system partition at `<EFI System Partition>\Microsoft\Boot\winsipolicy.p7b`. |
| **WindowsE_Lockdown_Policy** | {82443e1e-8a39-4b4a-96a8-f40ddc00b9f3} | Base policy | This policy is active on devices running [Windows 11 SE](/education/windows/windows-11-se-overview). Its policy binary file is found in the EFI system partition at `<EFI System Partition>\Microsoft\Boot\CIPolicies\Active\{82443e1e-8a39-4b4a-96a8-f40ddc00b9f3}.cip`. |
| **WindowsE_Lockdown_Flight_Policy_Supplemental** | {5dac656c-21ad-4a02-ab49-649917162e70} | Supplemental policy | This policy is active on devices running [Windows 11 SE](/education/windows/windows-11-se-overview) that are enrolled in the [Windows Insider](https://insider.windows.com) program. Its policy binary file is found in the EFI system partition at `<EFI System Partition>\Microsoft\Boot\CIPolicies\Active\{5dac656c-21ad-4a02-ab49-649917162e70}.cip`. |

View File

@ -1,47 +1,46 @@
---
title: WDAC Admin Tips & Known Issues
description: WDAC Known Issues
title: App Control Admin Tips & Known Issues
description: App Control Known Issues
ms.manager: jsuther
ms.date: 04/15/2024
ms.topic: troubleshooting
ms.localizationpriority: medium
---
# WDAC Admin Tips & Known Issues
# App Control Admin Tips & Known Issues
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
[!INCLUDE [Feature availability note](../includes/feature-availability-note.md)]
This article covers tips and tricks for admins and known issues with Windows Defender Application Control (WDAC). Test this configuration in your lab before enabling it in production.
This article covers tips and tricks for admins and known issues with App Control for Business. Test this configuration in your lab before enabling it in production.
## WDAC policy file locations
## App Control policy file locations
**Multiple policy format WDAC policies** are found in the following locations depending on whether the policy is signed or not, and the method of policy deployment that was used.
**Multiple policy format App Control policies** are found in the following locations depending on whether the policy is signed or not, and the method of policy deployment that was used.
- &lt;OS Volume&gt;\\Windows\\System32\\CodeIntegrity\\CiPolicies\Active\\*\{PolicyId GUID\}*.cip
- &lt;EFI System Partition&gt;\\Microsoft\\Boot\\CiPolicies\Active\\*\{PolicyId GUID\}*.cip
The *\{PolicyId GUID\}* value is unique by policy and defined in the policy XML with the &lt;PolicyId&gt; element.
For **single policy format WDAC policies**, in addition to the two preceding locations, also look for a file called SiPolicy.p7b in the following locations:
For **single policy format App Control policies**, in addition to the two preceding locations, also look for a file called SiPolicy.p7b in the following locations:
- &lt;EFI System Partition&gt;\\Microsoft\\Boot\\SiPolicy.p7b
- &lt;OS Volume&gt;\\Windows\\System32\\CodeIntegrity\\SiPolicy.p7b
> [!NOTE]
> A multiple policy format WDAC policy using the single policy format GUID `{A244370E-44C9-4C06-B551-F6016E563076}` may exist under any of the policy file locations.
> A multiple policy format App Control policy using the single policy format GUID `{A244370E-44C9-4C06-B551-F6016E563076}` may exist under any of the policy file locations.
## File Rule Precedence Order
When the WDAC engine evaluates files against the active set of policies on the device, rules are applied in the following order. Once a file encounters a match, WDAC stops further processing.
When the App Control engine evaluates files against the active set of policies on the device, rules are applied in the following order. Once a file encounters a match, App Control stops further processing.
1. Explicit deny rules - a file is blocked if any explicit deny rule exists for it, even if other rules are created to try to allow it. Deny rules can use any [rule level](/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create#windows-defender-application-control-file-rule-levels). Use the most specific rule level practical when creating deny rules to avoid blocking more than you intend.
1. Explicit deny rules - a file is blocked if any explicit deny rule exists for it, even if other rules are created to try to allow it. Deny rules can use any [rule level](../design/select-types-of-rules-to-create.md#app-control-for-business-file-rule-levels). Use the most specific rule level practical when creating deny rules to avoid blocking more than you intend.
2. Explicit allow rules - if any explicit allow rule exists for the file, the file runs.
3. WDAC then checks for the [Managed Installer extended attribute (EA)](/windows/security/threat-protection/windows-defender-application-control/configure-authorized-apps-deployed-with-a-managed-installer) or the [Intelligent Security Graph (ISG) EA](/windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-intelligent-security-graph) on the file. If either EA exists and the policy enables the corresponding option, then the file is allowed.
3. App Control then checks for the [Managed Installer extended attribute (EA)](../design/configure-authorized-apps-deployed-with-a-managed-installer.md) or the [Intelligent Security Graph (ISG) EA](../design/use-appcontrol-with-intelligent-security-graph.md) on the file. If either EA exists and the policy enables the corresponding option, then the file is allowed.
4. Lastly, WDAC makes a cloud call to the ISG to get reputation about the file, if the policy enables the ISG option.
4. Lastly, App Control makes a cloud call to the ISG to get reputation about the file, if the policy enables the ISG option.
5. Any file not allowed by an explicit rule or based on ISG or MI is blocked implicitly.
@ -49,32 +48,32 @@ When the WDAC engine evaluates files against the active set of policies on the d
### Boot stop failure (blue screen) occurs if more than 32 policies are active
Until you apply the Windows security update released on or after April 9, 2024, your device is limited to 32 active policies. If the maximum number of policies is exceeded, the device bluescreens referencing ci.dll with a bug check value of 0x0000003b. Consider this maximum policy count limit when planning your WDAC policies. Any [Windows inbox policies](/windows/security/threat-protection/windows-defender-application-control/operations/inbox-wdac-policies) that are active on the device also count towards this limit. To remove the maximum policy limit, install the Windows security update released on, or after, April 9, 2024 and then restart the device. Otherwise, reduce the number of policies on the device to remain below 32 policies.
Until you apply the Windows security update released on or after April 9, 2024, your device is limited to 32 active policies. If the maximum number of policies is exceeded, the device bluescreens referencing ci.dll with a bug check value of 0x0000003b. Consider this maximum policy count limit when planning your App Control policies. Any [Windows inbox policies](inbox-appcontrol-policies.md) that are active on the device also count towards this limit. To remove the maximum policy limit, install the Windows security update released on, or after, April 9, 2024 and then restart the device. Otherwise, reduce the number of policies on the device to remain below 32 policies.
**Note:** The policy limit was not removed on Windows 11 21H2, and will remain limited to 32 policies.
### Audit mode policies can change the behavior for some apps or cause app crashes
Although WDAC audit mode is designed to avoid impact to apps, some features are always on/always enforced with any WDAC policy that turns on user mode code integrity (UMCI) with the option **0 Enabled:UMCI**. Here's a list of known system changes in audit mode:
Although App Control audit mode is designed to avoid impact to apps, some features are always on/always enforced with any App Control policy that turns on user mode code integrity (UMCI) with the option **0 Enabled:UMCI**. Here's a list of known system changes in audit mode:
- Some script hosts might block code or run code with fewer privileges even in audit mode. See [Script enforcement with WDAC](/windows/security/application-security/application-control/windows-defender-application-control/design/script-enforcement) for information about individual script host behaviors.
- Option **19 Enabled:Dynamic Code Security** is always enforced if any UMCI policy includes that option. See [WDAC and .NET](/windows/security/application-security/application-control/windows-defender-application-control/design/wdac-and-dotnet#wdac-and-net-hardening).
- Some script hosts might block code or run code with fewer privileges even in audit mode. See [Script enforcement with App Control](../design/script-enforcement.md) for information about individual script host behaviors.
- Option **19 Enabled:Dynamic Code Security** is always enforced if any UMCI policy includes that option. See [App Control and .NET](../design/appcontrol-and-dotnet.md#app-control-and-net-hardening).
### .NET native images may generate false positive block events
In some cases, the code integrity logs where Windows Defender Application Control errors and warnings are written include error events for native images generated for .NET assemblies. Typically, native image blocks are functionally benign as a blocked native image falls back to its corresponding assembly and .NET regenerates the native image at its next scheduled maintenance window.
In some cases, the code integrity logs where App Control for Business errors and warnings are written include error events for native images generated for .NET assemblies. Typically, native image blocks are functionally benign as a blocked native image falls back to its corresponding assembly and .NET regenerates the native image at its next scheduled maintenance window.
### Signatures using elliptical curve cryptography (ECC) aren't supported
WDAC signer-based rules only work with RSA cryptography. ECC algorithms, such as ECDSA, aren't supported. If WDAC blocks a file based on ECC signatures, the corresponding 3089 signature information events show VerificationError = 23. You can authorize the files instead by hash or file attribute rules, or using other signer rules if the file is also signed with signatures using RSA.
App Control signer-based rules only work with RSA cryptography. ECC algorithms, such as ECDSA, aren't supported. If App Control blocks a file based on ECC signatures, the corresponding 3089 signature information events show VerificationError = 23. You can authorize the files instead by hash or file attribute rules, or using other signer rules if the file is also signed with signatures using RSA.
### MSI installers are treated as user writeable on Windows 10 when allowed by FilePath rule
MSI installer files are always detected as user writeable on Windows 10, and on Windows Server 2022 and earlier. If you need to allow MSI files using FilePath rules, you must set option **18 Disabled:Runtime FilePath Rule Protection** in your WDAC policy.
MSI installer files are always detected as user writeable on Windows 10, and on Windows Server 2022 and earlier. If you need to allow MSI files using FilePath rules, you must set option **18 Disabled:Runtime FilePath Rule Protection** in your App Control policy.
### MSI Installations launched directly from the internet are blocked by WDAC
### MSI Installations launched directly from the internet are blocked by App Control
Installing .msi files directly from the internet to a computer protected by WDAC fails.
Installing .msi files directly from the internet to a computer protected by App Control fails.
For example, this command fails:
```console
@ -89,13 +88,13 @@ msiexec -i c:\temp\Windows10_Version_1511_ADMX.msi
### Slow boot and performance with custom policies
WDAC evaluates all processes that run, including inbox Windows processes. You can cause slower boot times, degraded performance, and possibly boot issues if your policies don't build upon the WDAC templates or don't trust the Windows signers. For these reasons, you should use the [WDAC base templates](../design/example-appcontrol-base-policies.md) whenever possible to create your policies.
App Control evaluates all processes that run, including inbox Windows processes. You can cause slower boot times, degraded performance, and possibly boot issues if your policies don't build upon the App Control templates or don't trust the Windows signers. For these reasons, you should use the [App Control base templates](../design/example-appcontrol-base-policies.md) whenever possible to create your policies.
#### AppId Tagging policy considerations
AppId Tagging policies that aren't built upon the WDAC base templates or don't allow the Windows in-box signers might cause a significant increase in boot times (~2 minutes).
AppId Tagging policies that aren't built upon the App Control base templates or don't allow the Windows in-box signers might cause a significant increase in boot times (~2 minutes).
If you can't allowlist the Windows signers or build off the WDAC base templates, add the following rule to your policies to improve the performance:
If you can't allowlist the Windows signers or build off the App Control base templates, add the following rule to your policies to improve the performance:
:::image type="content" source="../images/known-issue-appid-dll-rule.png" alt-text="Allow all dlls in the policy.":::

View File

@ -1,6 +1,6 @@
---
title: Query Application Control events with Advanced Hunting
description: Learn how to query Windows Defender Application Control events across your entire organization by using Advanced Hunting.
description: Learn how to query App Control for Business events across your entire organization by using Advanced Hunting.
ms.localizationpriority: medium
ms.date: 03/01/2022
ms.topic: troubleshooting
@ -8,12 +8,12 @@ ms.topic: troubleshooting
# Querying Application Control events centrally using Advanced hunting
A Windows Defender Application Control (WDAC) policy logs events locally in Windows Event Viewer in either enforced or audit mode.
A App Control for Business policy logs events locally in Windows Event Viewer in either enforced or audit mode.
While Event Viewer helps to see the impact on a single system, IT Pros want to gauge it across many systems.
In November 2018, we added functionality in Microsoft Defender for Endpoint that makes it easy to view WDAC events centrally from all connected systems.
In November 2018, we added functionality in Microsoft Defender for Endpoint that makes it easy to view App Control events centrally from all connected systems.
Advanced hunting in Microsoft Defender for Endpoint allows customers to query data using a rich set of capabilities. WDAC events can be queried with using an ActionType that starts with "AppControl".
Advanced hunting in Microsoft Defender for Endpoint allows customers to query data using a rich set of capabilities. App Control events can be queried with using an ActionType that starts with "AppControl".
This capability is supported beginning with Windows version 1607.
## Action Types
@ -22,8 +22,8 @@ This capability is supported beginning with Windows version 1607.
| - | - | - |
| AppControlCodeIntegrityDriverRevoked | 3023 | The driver file under validation didn't meet the requirements to pass the application control policy. |
| AppControlCodeIntegrityImageRevoked | 3036 | The signed file under validation is signed by a code signing certificate that has been revoked by Microsoft or the certificate issuing authority. |
| AppControlCodeIntegrityPolicyAudited | 3076 | This event is the main Windows Defender Application Control block event for audit mode policies. It indicates the file would have been blocked if the WDAC policy was enforced. |
| AppControlCodeIntegrityPolicyBlocked | 3077 | This event is the main Windows Defender Application Control block event for enforced policies. It indicates the file didn't pass your WDAC policy and was blocked. |
| AppControlCodeIntegrityPolicyAudited | 3076 | This event is the main App Control for Business block event for audit mode policies. It indicates the file would have been blocked if the App Control policy was enforced. |
| AppControlCodeIntegrityPolicyBlocked | 3077 | This event is the main App Control for Business block event for enforced policies. It indicates the file didn't pass your App Control policy and was blocked. |
| AppControlExecutableAudited | 8003 | Applied only when the Audit only enforcement mode is enabled. Specifies the .exe or .dll file would be blocked if the Enforce rules enforcement mode were enabled. |
| AppControlExecutableBlocked | 8004 | The .exe or .dll file can't run. |
| AppControlPackagedAppAudited | 8021 | Applied only when the Audit only enforcement mode is enabled. Specifies the packaged app would be blocked if the Enforce rules enforcement mode were enabled. |
@ -45,7 +45,7 @@ Learn more about the [Understanding Application Control event IDs (Windows)](eve
Query Example 1: Query the application control action types summarized by type for past seven days
Here's a simple example query that shows all the Windows Defender Application Control events generated in the last seven days from machines being monitored by Microsoft Defender for Endpoint:
Here's a simple example query that shows all the App Control for Business events generated in the last seven days from machines being monitored by Microsoft Defender for Endpoint:
```
DeviceEvents
@ -55,7 +55,7 @@ ActionType startswith "AppControl"
| order by Machines desc
```
The query results can be used for several important functions related to managing Windows Defender Application Control including:
The query results can be used for several important functions related to managing App Control for Business including:
- Assessing the impact of deploying policies in audit mode
Since applications still run in audit mode, it's an ideal way to see the impact and correctness of the rules included in the policy. Integrating the generated events with Advanced Hunting makes it much easier to have broad deployments of audit mode policies and see how the included rules would influence those systems in real world usage. This audit mode data will help streamline the transition to using policies in enforced mode.