deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-05-12 21:37:22 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Merge branch 'master' into nimishasatapathy-4852875-phase6

Browse Source
This commit is contained in:
Asha Iyengar 2021-04-23 17:33:27 +05:30 committed by GitHub
commit 8eef3ab234
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
25 changed files with 534 additions and 819 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
.openpublishing.redirection.json
View File

@ -18769,6 +18769,16 @@
"source_path": "windows/security/threat-protection/microsoft-defender-antivirus/manage-updates-baselines-microsoft-defender-antivirus.md", "source_path": "windows/security/threat-protection/microsoft-defender-antivirus/manage-updates-baselines-microsoft-defender-antivirus.md",
"redirect_url": "/microsoft-365/security/defender-endpoint/manage-updates-baselines-microsoft-defender-antivirus", "redirect_url": "/microsoft-365/security/defender-endpoint/manage-updates-baselines-microsoft-defender-antivirus",
"redirect_document_id": false "redirect_document_id": false
},
{
"source_path": "windows/security/threat-protection/device-control/control-usb-devices-using-intune.md",
"redirect_url": "/microsoft-365/security/defender-endpoint/control-usb-devices-using-intune",
"redirect_document_id": false
},
{
"source_path": "windows/security/threat-protection/device-control/device-control-report.md",
"redirect_url": "/microsoft-365/security/defender-endpoint/device-control-report",
"redirect_document_id": false
} }
] ]
} }

26
windows/client-management/mdm/enroll-a-windows-10-device-automatically-using-group-policy.md
View File

@ -84,9 +84,13 @@ The following steps demonstrate required settings using the Intune service:
You may contact your domain administrators to verify if the group policy has been deployed successfully. You may contact your domain administrators to verify if the group policy has been deployed successfully.
8. Verify that the device is not enrolled with the old Intune client used on the Intune Silverlight Portal (this is the Intune portal used before the Azure portal). 8. Verify that the device is not enrolled with the old Intune client used on the Intune Silverlight Portal (this is the Intune portal used before the Azure portal).
9. Verify that Azure AD allows the logon user to enroll devices. 9. Verify that Azure AD allows the logon user to enroll devices.
![Azure AD device settings](images/auto-enrollment-azure-ad-device-settings.png) ![Azure AD device settings](images/auto-enrollment-azure-ad-device-settings.png)
10. Verify that Microsoft Intune should allow enrollment of Windows devices. 10. Verify that Microsoft Intune should allow enrollment of Windows devices.
![Enrollment of Windows devices](images/auto-enrollment-enrollment-of-windows-devices.png) ![Enrollment of Windows devices](images/auto-enrollment-enrollment-of-windows-devices.png)
## Configure the auto-enrollment Group Policy for a single PC ## Configure the auto-enrollment Group Policy for a single PC
@ -108,18 +112,21 @@ Requirements:
3. In **Local Computer Policy**, click **Administrative Templates** > **Windows Components** > **MDM**. 3. In **Local Computer Policy**, click **Administrative Templates** > **Windows Components** > **MDM**.
![MDM policies](images/autoenrollment-mdm-policies.png) > [!div class="mx-imgBorder"]
> ![MDM policies](images/autoenrollment-mdm-policies.png)
4. Double-click **Enable automatic MDM enrollment using default Azure AD credentials** (previously called **Auto MDM Enrollment with AAD Token** in Windows 10, version 1709). For ADMX files in Windows 10, version 1903 and later, select **User Credential** as the Selected Credential Type to use. 4. Double-click **Enable automatic MDM enrollment using default Azure AD credentials** (previously called **Auto MDM Enrollment with AAD Token** in Windows 10, version 1709). For ADMX files in Windows 10, version 1903 and later, select **User Credential** as the Selected Credential Type to use.
> [!NOTE] > [!NOTE]
> **Device Credential** Credential Type may work, however, it is not yet supported by Intune. We don't recommend using this option until it's supported. > **Device Credential** Credential Type may work, however, it is not yet supported by Intune. We don't recommend using this option until it's supported.
![MDM autoenrollment policy](images/autoenrollment-policy.png) ![MDM autoenrollment policy](images/autoenrollment-policy.png)
5. Click **Enable**, and select **User Credential** from the dropdown **Select Credential Type to Use**, then click **OK**. 5. Click **Enable**, and select **User Credential** from the dropdown **Select Credential Type to Use**, then click **OK**.
> [!NOTE] > [!NOTE]
> In Windows 10, version 1903, the MDM.admx file was updated to include an option to select which credential is used to enroll the device. **Device Credential** is a new option that will only have an effect on clients that have installed Windows 10, version 1903 or later. > In Windows 10, version 1903, the MDM.admx file was updated to include an option to select which credential is used to enroll the device. **Device Credential** is a new option that will only have an effect on clients that have installed Windows 10, version 1903 or later.
>
> The default behavior for older releases is to revert to **User Credential**. > The default behavior for older releases is to revert to **User Credential**.
> **Device Credential** is not supported for enrollment type when you have a ConfigMgr Agent on your device. > **Device Credential** is not supported for enrollment type when you have a ConfigMgr Agent on your device.
@ -158,7 +165,10 @@ Requirements:
To see the result of the task, move the scroll bar to the right to see the **Last Run Result**. Note that **0x80180026** is a failure message (MENROLL\_E_DEVICE\_MANAGEMENT_BLOCKED). You can see the logs in the **History** tab. To see the result of the task, move the scroll bar to the right to see the **Last Run Result**. Note that **0x80180026** is a failure message (MENROLL\_E_DEVICE\_MANAGEMENT_BLOCKED). You can see the logs in the **History** tab.
If the device enrollment is blocked, your IT admin may have enabled the **Disable MDM Enrollment** policy. Note that the GPEdit console does not reflect the status of policies set by your IT admin on your device. It is only used by the user to set policies. If the device enrollment is blocked, your IT admin may have enabled the **Disable MDM Enrollment** policy.
> [!NOTE]
> The GPEdit console does not reflect the status of policies set by your IT admin on your device. It is only used by the user to set policies.
## Configure the auto-enrollment for a group of devices ## Configure the auto-enrollment for a group of devices
@ -203,11 +213,11 @@ Requirements:
4. Rename the extracted Policy Definitions folder to **PolicyDefinitions**. 4. Rename the extracted Policy Definitions folder to **PolicyDefinitions**.
5. Copy PolicyDefinitions folder to **C:\Windows\SYSVOL\domain\Policies**. 5. Copy PolicyDefinitions folder to **\\contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions**.
If this folder does not exist, then be aware that you will be switching to a [central policy store](https://support.microsoft.com/help/3087759/how-to-create-and-manage-the-central-store-for-group-policy-administra) for your entire domain. If this folder does not exist, then be aware that you will be switching to a [central policy store](https://support.microsoft.com/help/3087759/how-to-create-and-manage-the-central-store-for-group-policy-administra) for your entire domain.
6. Restart the Domain Controller for the policy to be available. 6. Wait for the SYSVOL DFSR replication to be completed and then restart the Domain Controller for the policy to be available.
This procedure will work for any future version as well. This procedure will work for any future version as well.
@ -231,15 +241,21 @@ To collect Event Viewer logs:
> For guidance on how to collect event logs for Intune, see [Collect MDM Event Viewer Log YouTube video](https://www.youtube.com/watch?v=U_oCe2RmQEc). > For guidance on how to collect event logs for Intune, see [Collect MDM Event Viewer Log YouTube video](https://www.youtube.com/watch?v=U_oCe2RmQEc).
3. Search for event ID 75, which represents a successful auto-enrollment. Here is an example screenshot that shows the auto-enrollment completed successfully: 3. Search for event ID 75, which represents a successful auto-enrollment. Here is an example screenshot that shows the auto-enrollment completed successfully:
![Event ID 75](images/auto-enrollment-troubleshooting-event-id-75.png) ![Event ID 75](images/auto-enrollment-troubleshooting-event-id-75.png)
If you cannot find event ID 75 in the logs, it indicates that the auto-enrollment failed. This can happen because of the following reasons: If you cannot find event ID 75 in the logs, it indicates that the auto-enrollment failed. This can happen because of the following reasons:
- The enrollment failed with error. In this case, search for event ID 76, which represents failed auto-enrollment. Here is an example screenshot that shows that the auto-enrollment failed: - The enrollment failed with error. In this case, search for event ID 76, which represents failed auto-enrollment. Here is an example screenshot that shows that the auto-enrollment failed:
![Event ID 76](images/auto-enrollment-troubleshooting-event-id-76.png) ![Event ID 76](images/auto-enrollment-troubleshooting-event-id-76.png)
To troubleshoot, check the error code that appears in the event. See [Troubleshooting Windows device enrollment problems in Microsoft Intune](https://support.microsoft.com/en-ph/help/4469913/troubleshooting-windows-device-enrollment-problems-in-microsoft-intune) for more information. To troubleshoot, check the error code that appears in the event. See [Troubleshooting Windows device enrollment problems in Microsoft Intune](https://support.microsoft.com/en-ph/help/4469913/troubleshooting-windows-device-enrollment-problems-in-microsoft-intune) for more information.
- The auto-enrollment did not trigger at all. In this case, you will not find either event ID 75 or event ID 76. To know the reason, you must understand the internal mechanisms happening on the device as described in the following section. - The auto-enrollment did not trigger at all. In this case, you will not find either event ID 75 or event ID 76. To know the reason, you must understand the internal mechanisms happening on the device as described in the following section.
The auto-enrollment process is triggered by a task (**Microsoft > Windows > EnterpriseMgmt**) within the task-scheduler. This task appears if the *Enable automatic MDM enrollment using default Azure AD credentials* group policy (**Computer Configuration > Policies > Administrative Templates > Windows Components > MDM**) is successfully deployed to the target machine as shown in the following screenshot: The auto-enrollment process is triggered by a task (**Microsoft > Windows > EnterpriseMgmt**) within the task-scheduler. This task appears if the *Enable automatic MDM enrollment using default Azure AD credentials* group policy (**Computer Configuration > Policies > Administrative Templates > Windows Components > MDM**) is successfully deployed to the target machine as shown in the following screenshot:
![Task scheduler](images/auto-enrollment-task-scheduler.png) ![Task scheduler](images/auto-enrollment-task-scheduler.png)
> [!Note] > [!Note]
@ -252,6 +268,7 @@ To collect Event Viewer logs:
![Event ID 107](images/auto-enrollment-event-id-107.png) ![Event ID 107](images/auto-enrollment-event-id-107.png)
When the task is completed, a new event ID 102 is logged. When the task is completed, a new event ID 102 is logged.
![Event ID 102](images/auto-enrollment-event-id-102.png) ![Event ID 102](images/auto-enrollment-event-id-102.png)
Note that the task scheduler log displays event ID 102 (task completed) regardless of the auto-enrollment success or failure. This means that the task scheduler log is only useful to confirm if the auto-enrollment task is triggered or not. It does not indicate the success or failure of auto-enrollment. Note that the task scheduler log displays event ID 102 (task completed) regardless of the auto-enrollment success or failure. This means that the task scheduler log is only useful to confirm if the auto-enrollment task is triggered or not. It does not indicate the success or failure of auto-enrollment.
@ -262,6 +279,7 @@ To collect Event Viewer logs:
![Outdated enrollment entries](images/auto-enrollment-outdated-enrollment-entries.png) ![Outdated enrollment entries](images/auto-enrollment-outdated-enrollment-entries.png)
By default, these entries are removed when the device is un-enrolled, but occasionally the registry key remains even after un-enrollment. In this case, `gpupdate /force` fails to initiate the auto-enrollment task and error code 2149056522 is displayed in the **Applications and Services Logs > Microsoft > Windows > Task Scheduler > Operational** event log file under event ID 7016. By default, these entries are removed when the device is un-enrolled, but occasionally the registry key remains even after un-enrollment. In this case, `gpupdate /force` fails to initiate the auto-enrollment task and error code 2149056522 is displayed in the **Applications and Services Logs > Microsoft > Windows > Task Scheduler > Operational** event log file under event ID 7016.
A resolution to this issue is to remove the registry key manually. If you do not know which registry key to remove, go for the key which displays most entries as the screenshot above. All other keys will display fewer entries as shown in the following screenshot: A resolution to this issue is to remove the registry key manually. If you do not know which registry key to remove, go for the key which displays most entries as the screenshot above. All other keys will display fewer entries as shown in the following screenshot:
![Manually deleted entries](images/auto-enrollment-activation-verification-less-entries.png) ![Manually deleted entries](images/auto-enrollment-activation-verification-less-entries.png)

20
windows/client-management/mdm/policy-configuration-service-provider.md
View File

@ -57,12 +57,12 @@ The following diagram shows the Policy configuration service provider in tree fo
<p style="margin-left: 20px">Supported operation is Get. <p style="margin-left: 20px">Supported operation is Get.
<a href="" id="policy-config-areaname"></a>**Policy/Config/**<strong>*AreaName*</strong> <a href="" id="policy-config-areaname"></a>**Policy/Config/_AreaName_**
<p style="margin-left: 20px">The area group that can be configured by a single technology for a single provider. Once added, you cannot change the value. <p style="margin-left: 20px">The area group that can be configured by a single technology for a single provider. Once added, you cannot change the value.
<p style="margin-left: 20px">Supported operations are Add, Get, and Delete. <p style="margin-left: 20px">Supported operations are Add, Get, and Delete.
<a href="" id="policy-config-areaname-policyname"></a>**Policy/Config/**<strong>*AreaName/PolicyName*</strong> <a href="" id="policy-config-areaname-policyname"></a>**Policy/Config/_AreaName/PolicyName_**
<p style="margin-left: 20px">Specifies the name/value pair used in the policy. <p style="margin-left: 20px">Specifies the name/value pair used in the policy.
<p style="margin-left: 20px">The following list shows some tips to help you when configuring policies: <p style="margin-left: 20px">The following list shows some tips to help you when configuring policies:
@ -81,12 +81,12 @@ The following diagram shows the Policy configuration service provider in tree fo
<p style="margin-left: 20px">Supported operation is Get. <p style="margin-left: 20px">Supported operation is Get.
<a href="" id="policy-result-areaname"></a>**Policy/Result/**<strong>*AreaName*</strong> <a href="" id="policy-result-areaname"></a>**Policy/Result/_AreaName_**
<p style="margin-left: 20px">The area group that can be configured by a single technology independent of the providers. <p style="margin-left: 20px">The area group that can be configured by a single technology independent of the providers.
<p style="margin-left: 20px">Supported operation is Get. <p style="margin-left: 20px">Supported operation is Get.
<a href="" id="policy-result-areaname-policyname"></a>**Policy/Result/**<strong>*AreaName/PolicyName*</strong> <a href="" id="policy-result-areaname-policyname"></a>**Policy/Result/_AreaName/PolicyName_**
<p style="margin-left: 20px">Specifies the name/value pair used in the policy. <p style="margin-left: 20px">Specifies the name/value pair used in the policy.
<p style="margin-left: 20px">Supported operation is Get. <p style="margin-left: 20px">Supported operation is Get.
@ -102,31 +102,31 @@ The following diagram shows the Policy configuration service provider in tree fo
> [!NOTE] > [!NOTE]
> The OPAX settings that are managed by the Microsoft Office Customization Tool are not supported by MDM. For more information about this tool, see [Office Customization Tool](/previous-versions/office/office-2013-resource-kit/cc179097(v=office.15)). > The OPAX settings that are managed by the Microsoft Office Customization Tool are not supported by MDM. For more information about this tool, see [Office Customization Tool](/previous-versions/office/office-2013-resource-kit/cc179097(v=office.15)).
<p style="margin-left: 20px">ADMX files that have been installed by using <strong>ConfigOperations/ADMXInstall</strong> can later be deleted by using the URI delete operation. Deleting an ADMX file will delete the ADMX file from disk, remove the metadata from the ADMXdefault registry hive, and delete all the policies that were set from the file. The MDM server can also delete all ADMX policies that are tied to a particular app by calling delete on the URI, <code>./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/{AppName}</code>. <p style="margin-left: 20px">ADMX files that have been installed by using **ConfigOperations/ADMXInstall** can later be deleted by using the URI delete operation. Deleting an ADMX file will delete the ADMX file from disk, remove the metadata from the ADMXdefault registry hive, and delete all the policies that were set from the file. The MDM server can also delete all ADMX policies that are tied to a particular app by calling delete on the URI, <code>./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/{AppName}</code>.
<p style="margin-left: 20px">Supported operations are Add, Get, and Delete. <p style="margin-left: 20px">Supported operations are Add, Get, and Delete.
<a href="" id="policy-configoperations-admxinstall-appname"></a>**Policy/ConfigOperations/ADMXInstall/**<strong>*AppName*</strong> <a href="" id="policy-configoperations-admxinstall-appname"></a>**Policy/ConfigOperations/ADMXInstall/_AppName_**
<p style="margin-left: 20px">Added in Windows 10, version 1703. Specifies the name of the Win32 or Desktop Bridge app associated with the ADMX file. <p style="margin-left: 20px">Added in Windows 10, version 1703. Specifies the name of the Win32 or Desktop Bridge app associated with the ADMX file.
<p style="margin-left: 20px">Supported operations are Add, Get, and Delete. <p style="margin-left: 20px">Supported operations are Add, Get, and Delete.
<a href="" id="policy-configoperations-admxinstall-appname-policy"></a>**Policy/ConfigOperations/ADMXInstall/**<strong>*AppName*/Policy</strong> <a href="" id="policy-configoperations-admxinstall-appname-policy"></a>**Policy/ConfigOperations/ADMXInstall/_AppName_/Policy**
<p style="margin-left: 20px">Added in Windows 10, version 1703. Specifies that a Win32 or Desktop Bridge app policy is to be imported. <p style="margin-left: 20px">Added in Windows 10, version 1703. Specifies that a Win32 or Desktop Bridge app policy is to be imported.
<p style="margin-left: 20px">Supported operations are Add, Get, and Delete. <p style="margin-left: 20px">Supported operations are Add, Get, and Delete.
<a href="" id="policy-configoperations-admxinstall-appname-policy-uniqueid"></a>**Policy/ConfigOperations/ADMXInstall/**<strong>*AppName*/Policy/*UniqueID*</strong> <a href="" id="policy-configoperations-admxinstall-appname-policy-uniqueid"></a>**Policy/ConfigOperations/ADMXInstall/_AppName_/Policy/_UniqueID_**
<p style="margin-left: 20px">Added in Windows 10, version 1703. Specifies the unique ID of the app ADMX file that contains the policy to import. <p style="margin-left: 20px">Added in Windows 10, version 1703. Specifies the unique ID of the app ADMX file that contains the policy to import.
<p style="margin-left: 20px">Supported operations are Add and Get. Does not support Delete. <p style="margin-left: 20px">Supported operations are Add and Get. Does not support Delete.
<a href="" id="policy-configoperations-admxinstall-appname-preference"></a>**Policy/ConfigOperations/ADMXInstall/**<strong>*AppName*/Preference</strong> <a href="" id="policy-configoperations-admxinstall-appname-preference"></a>**Policy/ConfigOperations/ADMXInstall/_AppName_/Preference**
<p style="margin-left: 20px">Added in Windows 10, version 1703. Specifies that a Win32 or Desktop Bridge app preference is to be imported. <p style="margin-left: 20px">Added in Windows 10, version 1703. Specifies that a Win32 or Desktop Bridge app preference is to be imported.
<p style="margin-left: 20px">Supported operations are Add, Get, and Delete. <p style="margin-left: 20px">Supported operations are Add, Get, and Delete.
<a href="" id="policy-configoperations-admxinstall-appname-preference-uniqueid"></a>**Policy/ConfigOperations/ADMXInstall/**<strong>*AppName*/Preference/*UniqueID*</strong> <a href="" id="policy-configoperations-admxinstall-appname-preference-uniqueid"></a>**Policy/ConfigOperations/ADMXInstall/_AppName_/Preference/_UniqueID_**
<p style="margin-left: 20px">Added in Windows 10, version 1703. Specifies the unique ID of the app ADMX file that contains the preference to import. <p style="margin-left: 20px">Added in Windows 10, version 1703. Specifies the unique ID of the app ADMX file that contains the preference to import.
<p style="margin-left: 20px">Supported operations are Add and Get. Does not support Delete. <p style="margin-left: 20px">Supported operations are Add and Get. Does not support Delete.

62
windows/client-management/mdm/policy-csp-experience.md
View File

@ -37,6 +37,9 @@ manager: dansimp
<dd> <dd>
<a href="#experience-allowmanualmdmunenrollment">Experience/AllowManualMDMUnenrollment</a> <a href="#experience-allowmanualmdmunenrollment">Experience/AllowManualMDMUnenrollment</a>
</dd> </dd>
<dd>
<a href="#experience-allownewsandinterestsonthetaskbar">Experience/AllowNewsAndInterestsOnTheTaskbar</a>
</dd>
<dd> <dd>
<a href="#experience-allowsaveasofofficefiles">Experience/AllowSaveAsOfOfficeFiles</a> <a href="#experience-allowsaveasofofficefiles">Experience/AllowSaveAsOfOfficeFiles</a>
</dd> </dd>
@ -436,6 +439,65 @@ The following list shows the supported values:
<hr/> <hr/>
<!--Policy-->
<a href="" id="experience-allownewsandinterestsonthetaskbar"></a>**Experience/AllowNewsAndInterestsOnTheTaskbar**
<!--SupportedSKUs-->
<table>
<tr>
<th>Windows Edition</th>
<th>Supported?</th>
</tr>
<tr>
<td>Home</td>
<td><img src="images/crossmark.png" alt="cross mark" /></td>
</tr>
<tr>
<td>Pro</td>
<td><img src="images/checkmark.png" alt="check mark" /></td>
</tr>
<tr>
<td>Business</td>
<td><img src="images/checkmark.png" alt="check mark" /></td>
</tr>
<tr>
<td>Enterprise</td>
<td><img src="images/checkmark.png" alt="check mark" /></td>
</tr>
<tr>
<td>Education</td>
<td><img src="images/checkmark.png" alt="check mark" /></td>
</tr>
</table>
<!--/SupportedSKUs-->
<hr/>
<!--Scope-->
[Scope](./policy-configuration-service-provider.md#policy-scope):
> [!div class = "checklist"]
> * Machine
<hr/>
<!--/Scope-->
<!--Description-->
Specifies whether to allow "News and interests" on the Taskbar.
<!--/Description-->
<!--SupportedValues-->
The values for this policy are 1 and 0. This policy defaults to 1.
- 1 - Default - News and interests feature will be allowed on the taskbar. The settings UI will be present in Taskbar context menu, and users will be able to turn off or switch mode.
- 0 - News and interests feature will be turned off completely, and the settings UI in Taskbar context menu will be removed.
<!--/SupportedValues-->
<!--/Policy-->
<hr/>
<!--Policy--> <!--Policy-->
<a href="" id="experience-allowsaveasofofficefiles"></a>**Experience/AllowSaveAsOfOfficeFiles** <a href="" id="experience-allowsaveasofofficefiles"></a>**Experience/AllowSaveAsOfOfficeFiles**

36
windows/deployment/update/waas-delivery-optimization-reference.md
View File

@ -21,7 +21,7 @@ ms.custom: seo-marvel-apr2020
- Windows 10 - Windows 10
> **Looking for consumer information?** See [Windows Update: FAQ](https://support.microsoft.com/help/12373/windows-update-faq) > **Looking for more Group Policy settings?** See the master spreadsheet available at the [Download Center](https://www.microsoft.com/download/details.aspx?id=102158).
There are a great many details you can set in Delivery Optimization to customize it to do just what you need it to. This topic summarizes them for your reference. If you just need an overview of Delivery Optimization, see [Delivery Optimization for Windows 10 updates](waas-delivery-optimization.md). If you need information about setting up Delivery Optimization, including tips for the best settings in different scenarios, see [Set up Delivery Optimization for Windows 10 updates](waas-delivery-optimization-setup.md). There are a great many details you can set in Delivery Optimization to customize it to do just what you need it to. This topic summarizes them for your reference. If you just need an overview of Delivery Optimization, see [Delivery Optimization for Windows 10 updates](waas-delivery-optimization.md). If you need information about setting up Delivery Optimization, including tips for the best settings in different scenarios, see [Set up Delivery Optimization for Windows 10 updates](waas-delivery-optimization-setup.md).
@ -87,7 +87,7 @@ Additional options available that control the impact Delivery Optimization has o
- [Maximum Download Bandwidth](#maximum-download-bandwidth) and [Percentage of Maximum Download Bandwidth](#percentage-of-maximum-download-bandwidth) control the download bandwidth used by Delivery Optimization. - [Maximum Download Bandwidth](#maximum-download-bandwidth) and [Percentage of Maximum Download Bandwidth](#percentage-of-maximum-download-bandwidth) control the download bandwidth used by Delivery Optimization.
- [Max Upload Bandwidth](#max-upload-bandwidth) controls the Delivery Optimization upload bandwidth usage. - [Max Upload Bandwidth](#max-upload-bandwidth) controls the Delivery Optimization upload bandwidth usage.
- [Monthly Upload Data Cap](#monthly-upload-data-cap) controls the amount of data a client can upload to peers each month. - [Monthly Upload Data Cap](#monthly-upload-data-cap) controls the amount of data a client can upload to peers each month.
- [Minimum Background QoS](#minimum-background-qos) lets administrators guarantee a minimum download speed for Windows updates. This is achieved by adjusting the amount of data downloaded directly from Windows Update or WSUS servers, rather than other peers in the network. - [Minimum Background QoS](#minimum-background-qos) lets administrators guarantee a minimum download speed for Windows updates. This setting adjusts the amount of data downloaded directly from Windows Update or WSUS servers, rather than other peers in the network.
- [Maximum Foreground Download Bandwidth](#maximum-foreground-download-bandwidth) specifies the **maximum foreground download bandwidth** that Delivery Optimization uses, across all concurrent download activities, as a percentage of available download bandwidth. - [Maximum Foreground Download Bandwidth](#maximum-foreground-download-bandwidth) specifies the **maximum foreground download bandwidth** that Delivery Optimization uses, across all concurrent download activities, as a percentage of available download bandwidth.
- [Maximum Background Download Bandwidth](#maximum-background-download-bandwidth) specifies the **maximum background download bandwidth** that Delivery Optimization uses, across all concurrent download activities, as a percentage of available download bandwidth. - [Maximum Background Download Bandwidth](#maximum-background-download-bandwidth) specifies the **maximum background download bandwidth** that Delivery Optimization uses, across all concurrent download activities, as a percentage of available download bandwidth.
- [Set Business Hours to Limit Background Download Bandwidth](#set-business-hours-to-limit-background-download-bandwidth) specifies the maximum background download bandwidth that Delivery Optimization uses during and outside business hours across all concurrent download activities as a percentage of available download bandwidth. - [Set Business Hours to Limit Background Download Bandwidth](#set-business-hours-to-limit-background-download-bandwidth) specifies the maximum background download bandwidth that Delivery Optimization uses during and outside business hours across all concurrent download activities as a percentage of available download bandwidth.
@ -110,7 +110,7 @@ Download mode dictates which download sources clients are allowed to use when do
| Download mode option | Functionality when set | | Download mode option | Functionality when set |
| --- | --- | | --- | --- |
| HTTP Only (0) | This setting disables peer-to-peer caching but still allows Delivery Optimization to download content over HTTP from the download's original source. This mode uses additional metadata provided by the Delivery Optimization cloud services for a peerless reliable and efficient download experience. | | HTTP Only (0) | This setting disables peer-to-peer caching but still allows Delivery Optimization to download content over HTTP from the download's original source. This mode uses additional metadata provided by the Delivery Optimization cloud services for a peerless reliable and efficient download experience. |
| LAN (1 – Default) | This default operating mode for Delivery Optimization enables peer sharing on the same network. The Delivery Optimization cloud service finds other clients that connect to the Internet using the same public IP as the target client. These clients then attempts to connect to other peers on the same network by using their private subnet IP.| | LAN (1 – Default) | This default operating mode for Delivery Optimization enables peer sharing on the same network. The Delivery Optimization cloud service finds other clients that connect to the Internet using the same public IP as the target client. These clients then try to connect to other peers on the same network by using their private subnet IP.|
| Group (2) | When group mode is set, the group is automatically selected based on the device's Active Directory Domain Services (AD DS) site (Windows 10, version 1607) or the domain the device is authenticated to (Windows 10, version 1511). In group mode, peering occurs across internal subnets, between devices that belong to the same group, including devices in remote offices. You can use GroupID option to create your own custom group independently of domains and AD DS sites. Starting with Windows 10, version 1803, you can use the GroupIDSource parameter to take advantage of other method to create groups dynamically. Group download mode is the recommended option for most organizations looking to achieve the best bandwidth optimization with Delivery Optimization. | | Group (2) | When group mode is set, the group is automatically selected based on the device's Active Directory Domain Services (AD DS) site (Windows 10, version 1607) or the domain the device is authenticated to (Windows 10, version 1511). In group mode, peering occurs across internal subnets, between devices that belong to the same group, including devices in remote offices. You can use GroupID option to create your own custom group independently of domains and AD DS sites. Starting with Windows 10, version 1803, you can use the GroupIDSource parameter to take advantage of other method to create groups dynamically. Group download mode is the recommended option for most organizations looking to achieve the best bandwidth optimization with Delivery Optimization. |
| Internet (3) | Enable Internet peer sources for Delivery Optimization. | | Internet (3) | Enable Internet peer sources for Delivery Optimization. |
| Simple (99) | Simple mode disables the use of Delivery Optimization cloud services completely (for offline environments). Delivery Optimization switches to this mode automatically when the Delivery Optimization cloud services are unavailable, unreachable or when the content file size is less than 10 MB. In this mode, Delivery Optimization provides a reliable download experience, with no peer-to-peer caching. | | Simple (99) | Simple mode disables the use of Delivery Optimization cloud services completely (for offline environments). Delivery Optimization switches to this mode automatically when the Delivery Optimization cloud services are unavailable, unreachable or when the content file size is less than 10 MB. In this mode, Delivery Optimization provides a reliable download experience, with no peer-to-peer caching. |
@ -121,7 +121,7 @@ Download mode dictates which download sources clients are allowed to use when do
### Group ID ### Group ID
By default, peer sharing on clients using the group download mode is limited to the same domain in Windows 10, version 1511, and the same domain and Active Directory Domain Services site in Windows 10, version 1607. By using the Group ID setting, you can optionally create a custom group that contains devices that should participate in Delivery Optimization but do not fall within those domain or Active Directory Domain Services site boundaries, including devices in another domain. Using Group ID, you can further restrict the default group (for example, you could create a sub-group representing an office building), or extend the group beyond the domain, allowing devices in multiple domains in your organization to be peers. This setting requires the custom group to be specified as a GUID on each device that participates in the custom group. By default, peer sharing on clients using the group download mode is limited to the same domain in Windows 10, version 1511, and the same domain and Active Directory Domain Services site in Windows 10, version 1607. By using the Group ID setting, you can optionally create a custom group that contains devices that should participate in Delivery Optimization but do not fall within those domain or Active Directory Domain Services site boundaries, including devices in another domain. Using Group ID, you can further restrict the default group (for example, you could create a subgroup representing an office building), or extend the group beyond the domain, allowing devices in multiple domains in your organization to be peers. This setting requires the custom group to be specified as a GUID on each device that participates in the custom group.
[//]: # (Configuration Manager boundary group option; GroupID Source policy) [//]: # (Configuration Manager boundary group option; GroupID Source policy)
@ -144,11 +144,11 @@ When set, the Group ID is assigned automatically from the selected source. If yo
### Minimum RAM (inclusive) allowed to use Peer Caching ### Minimum RAM (inclusive) allowed to use Peer Caching
This setting specifies the minimum RAM size in GB required to use Peer Caching. For example if the minimum set is 1 GB, then devices with 1 GB or higher available RAM will be allowed to use Peer caching. The recommended values are 1 to 4 GB, and the default value is 4 GB. This setting specifies the minimum RAM size in GB required to use Peer Caching. For example if the minimum set is 1 GB, then devices with 1 GB or higher available RAM will be allowed to use Peer caching. The recommended values are 1 to 4, and the default value is 4 GB.
### Minimum disk size allowed to use Peer Caching ### Minimum disk size allowed to use Peer Caching
This setting specifies the required minimum disk size (capacity in GB) for the device to use Peer Caching. The recommended values are 64 to 256 GB, and the default value is 32 GB. This setting specifies the required minimum disk size (capacity in GB) for the device to use Peer Caching. The recommended values are 64 to 256, and the default value is 32 GB.
>[!NOTE] >[!NOTE]
>If the [Modify Cache Drive](#modify-cache-drive) policy is set, the disk size check will apply to the new working directory specified by this policy. >If the [Modify Cache Drive](#modify-cache-drive) policy is set, the disk size check will apply to the new working directory specified by this policy.
@ -156,7 +156,7 @@ This setting specifies the required minimum disk size (capacity in GB) for the d
### Max Cache Age ### Max Cache Age
In environments configured for Delivery Optimization, you might want to set an expiration on cached updates and Windows application installation files. If so, this setting defines the maximum number of seconds each file can be held in the Delivery Optimization cache on each Windows 10 client device. The default Max Cache Age value is 259,200 seconds (3 days). Alternatively, organizations might choose to set this value to "0" which means "unlimited" to avoid peers re-downloading content. When "Unlimited" value is set, Delivery Optimization will hold the files in the cache longer and will clean up the cache as needed (for example when the cache size exceeded the maximum space allowed). In environments configured for Delivery Optimization, you might want to set an expiration on cached updates and Windows application installation files. If so, this setting defines the maximum number of seconds each file can be held in the Delivery Optimization cache on each Windows 10 client device. The default Max Cache Age value is 259,200 seconds (three days). Alternatively, organizations might choose to set this value to "0" which means "unlimited" to avoid peers re-downloading content. When "Unlimited" value is set, Delivery Optimization will hold the files in the cache longer and will clean up the cache as needed (for example when the cache size exceeded the maximum space allowed).
### Max Cache Size ### Max Cache Size
@ -168,19 +168,19 @@ This setting specifies the maximum number of gigabytes the Delivery Optimization
### Minimum Peer Caching Content File Size ### Minimum Peer Caching Content File Size
This setting specifies the minimum content file size in MB enabled to use Peer Caching. The recommended values are from 1 to 100000 MB. This setting specifies the minimum content file size in MB enabled to use Peer Caching. The recommended values are from 1 to 100000.
### Maximum Download Bandwidth ### Maximum Download Bandwidth
This setting specifies the maximum download bandwidth that can be used across all concurrent Delivery Optimization downloads in kilobytes per second (KB/s). A default value of 0 means that Delivery Optimization will dynamically adjust and optimize the maximum bandwidth used. This setting specifies the maximum download bandwidth that can be used across all concurrent Delivery Optimization downloads in kilobytes per second (KB/s). A default value of "0" means that Delivery Optimization will dynamically adjust and optimize the maximum bandwidth used.
### Maximum Foreground Download Bandwidth ### Maximum Foreground Download Bandwidth
Starting in Windows 10, version 1803, specifies the maximum foreground download bandwidth that Delivery Optimization uses across all concurrent download activities as a percentage of available download bandwidth. The default value of 0 means that Delivery Optimization dynamically adjusts to use the available bandwidth for foreground downloads. However, downloads from LAN peers are not throttled even when this policy is set. Starting in Windows 10, version 1803, specifies the maximum foreground download bandwidth that Delivery Optimization uses across all concurrent download activities as a percentage of available download bandwidth. The default value of "0" means that Delivery Optimization dynamically adjusts to use the available bandwidth for foreground downloads. However, downloads from LAN peers are not throttled even when this policy is set.
### Maximum Background Download Bandwidth ### Maximum Background Download Bandwidth
Starting in Windows 10, version 1803, specifies the maximum background download bandwidth that Delivery Optimization uses across all concurrent download activities as a percentage of available download bandwidth. The default value of 0 means that Delivery Optimization dynamically adjusts to use the available bandwidth for foreground downloads. However, downloads from LAN peers are not throttled even when this policy is set. Starting in Windows 10, version 1803, specifies the maximum background download bandwidth that Delivery Optimization uses across all concurrent download activities as a percentage of available download bandwidth. The default value of "0" means that Delivery Optimization dynamically adjusts to use the available bandwidth for foreground downloads. However, downloads from LAN peers are not throttled even when this policy is set.
### Percentage of Maximum Download Bandwidth ### Percentage of Maximum Download Bandwidth
@ -188,7 +188,7 @@ This setting specifies the maximum download bandwidth that Delivery Optimization
### Max Upload Bandwidth ### Max Upload Bandwidth
This setting allows you to limit the amount of upload bandwidth individual clients can use for Delivery Optimization. Consider this setting when clients are providing content to requesting peers on the network. This option is set in kilobytes per second (KB/s). The default setting is 0, or "unlimited" which means Delivery Optimization dynamically optimizes for minimal usage of upload bandwidth; however it does not cap the upload bandwidth rate at a set rate. This setting allows you to limit the number of upload bandwidth individual clients can use for Delivery Optimization. Consider this setting when clients are providing content to requesting peers on the network. This option is set in kilobytes per second (KB/s). The default setting is "0", or "unlimited" which means Delivery Optimization dynamically optimizes for minimal usage of upload bandwidth; however it does not cap the upload bandwidth rate at a set rate.
### Set Business Hours to Limit Background Download Bandwidth ### Set Business Hours to Limit Background Download Bandwidth
Starting in Windows 10, version 1803, specifies the maximum background download bandwidth that Delivery Optimization uses during and outside business hours across all concurrent download activities as a percentage of available download bandwidth. Starting in Windows 10, version 1803, specifies the maximum background download bandwidth that Delivery Optimization uses during and outside business hours across all concurrent download activities as a percentage of available download bandwidth.
@ -198,7 +198,7 @@ Starting in Windows 10, version 1803, specifies the maximum foreground download
### Select a method to restrict peer selection ### Select a method to restrict peer selection
Starting in Windows 10, version 1803, set this policy to restrict peer selection via selected option. Starting in Windows 10, version 1803, set this policy to restrict peer selection via selected option.
Currently the only available option is **1 = Subnet mask** This option (Subnet mask) applies to both Download Modes LAN (1) and Group (2). Currently the only available option is **1 = Subnet mask**. The subnet mask option applies to both Download Modes LAN (1) and Group (2).
### Delay background download from http (in secs) ### Delay background download from http (in secs)
Starting in Windows 10, version 1803, this allows you to delay the use of an HTTP source in a background download that is allowed to use peer-to-peer. Starting in Windows 10, version 1803, this allows you to delay the use of an HTTP source in a background download that is allowed to use peer-to-peer.
@ -214,19 +214,19 @@ Starting in Windows 10, version 1903, set this policy to delay the fallback from
### Minimum Background QoS ### Minimum Background QoS
This value specifies the minimum download speed guarantee that a client attempts to achieve and will fulfill by downloading more kilobytes from Windows Update servers or WSUS. Simply put, the lower this value is, the more content will be sourced using peers on the network rather than Windows Update. The higher this value, the more content is received from Windows Update servers or WSUS, versus peers on the local network. This value specifies the minimum download speed guarantee that a client attempts to achieve and will fulfill by downloading more kilobytes from Windows Update servers or WSUS. The lower this value is, the more content will be sourced using peers on the network rather than Windows Update. The higher this value, the more content is received from Windows Update servers or WSUS, versus peers on the local network.
### Modify Cache Drive ### Modify Cache Drive
This setting allows for an alternate Delivery Optimization cache location on the clients. By default, the cache is stored on the operating system drive through the %SYSTEMDRIVE% environment variable. You can set the value to an environment variable (e.g., %SYSTEMDRIVE%), a drive letter (e.g., D:), or a folder path (e.g., D:\DOCache). This setting allows for an alternate Delivery Optimization cache location on the clients. By default, the cache is stored on the operating system drive through the %SYSTEMDRIVE% environment variable. You can set the value to an environment variable (for example, %SYSTEMDRIVE%), a drive letter (for example, D:), or a folder path (for example, D:\DOCache).
### Monthly Upload Data Cap ### Monthly Upload Data Cap
This setting specifies the total amount of data in gigabytes that a Delivery Optimization client can upload to Internet peers per month. A value of 0 means that an unlimited amount of data can be uploaded. The default value for this setting is 20 GB. This setting specifies the total amount of data in gigabytes that a Delivery Optimization client can upload to Internet peers per month. A value of "0" means that an unlimited amount of data can be uploaded. The default value for this setting is 20 GB.
### Enable Peer Caching while the device connects via VPN ### Enable Peer Caching while the device connects via VPN
This setting determines whether a device will be allowed to participate in Peer Caching while connected to VPN. Specify "true" to allow the device to participate in Peer Caching while connected via VPN to the domain network. This means the device can download from or upload to other domain network devices, either on VPN or on the corporate domain network. This setting determines whether a device will be allowed to participate in Peer Caching while connected to VPN. Specify "true" to allow the device to participate in Peer Caching while connected via VPN to the domain network. The device can download from or upload to other domain network devices, either on VPN or on the corporate domain network.
### Allow uploads while the device is on battery while under set Battery level ### Allow uploads while the device is on battery while under set Battery level
@ -238,7 +238,7 @@ The device can download from peers while on battery regardless of this policy.
### Cache Server Hostname ### Cache Server Hostname
Set this policy to to designate one or more Microsoft Connected Cache servers to be used by Delivery Optimization. You can set one or more FQDNs or IP Addresses that are comma separated, for example: myhost.somerandomhost.com,myhost2.somrandomhost.com,10.10.1.7. Set this policy to designate one or more Microsoft Connected Cache servers to be used by Delivery Optimization. You can set one or more FQDNs or IP Addresses that are comma separated, for example: myhost.somerandomhost.com,myhost2.somrandomhost.com,10.10.1.7.
### Cache Server Hostname Source ### Cache Server Hostname Source

26
windows/deployment/update/waas-delivery-optimization.md
View File

@ -23,9 +23,9 @@ ms.custom: seo-marvel-apr2020
- Windows 10 - Windows 10
> **Looking for consumer information?** See [Windows Update: FAQ](https://support.microsoft.com/help/12373/windows-update-faq) > **Looking for Group Policy objects?** See [Delivery Optimization reference](waas-delivery-optimization-reference.md) or the master spreadsheet available at the [Download Center](https://www.microsoft.com/download/details.aspx?id=102158).
Windows updates, upgrades, and applications can contain packages with very large files. Downloading and distributing updates can consume quite a bit of network resources on the devices receiving them. You can use Delivery Optimization to reduce bandwidth consumption by sharing the work of downloading these packages among multiple devices in your deployment. Delivery Optimization can accomplish this because it is a self-organizing distributed cache that allows clients to download those packages from alternate sources (such as other peers on the network) in addition to the traditional Internet-based servers. You can use Delivery Optimization in conjunction with Windows Update, Windows Server Update Services (WSUS), Windows Update for Business, or Microsoft Endpoint Manager (when installation of Express Updates is enabled). Windows updates, upgrades, and applications can contain packages with very large files. Downloading and distributing updates can consume quite a bit of network resources on the devices receiving them. You can use Delivery Optimization to reduce bandwidth consumption by sharing the work of downloading these packages among multiple devices in your deployment. Delivery Optimization is a self-organizing distributed cache that allows clients to download those packages from alternate sources (such as other peers on the network) in addition to the traditional Internet-based servers. You can use Delivery Optimization with Windows Update, Windows Server Update Services (WSUS), Windows Update for Business, or Microsoft Endpoint Manager (when installation of Express Updates is enabled).
Delivery Optimization is a cloud-managed solution. Access to the Delivery Optimization cloud services is a requirement. This means that in order to use the peer-to-peer functionality of Delivery Optimization, devices must have access to the internet. Delivery Optimization is a cloud-managed solution. Access to the Delivery Optimization cloud services is a requirement. This means that in order to use the peer-to-peer functionality of Delivery Optimization, devices must have access to the internet.
@ -65,7 +65,7 @@ For information about setting up Delivery Optimization, including tips for the b
- Office installs and updates - Office installs and updates
- Xbox game pass games - Xbox game pass games
- MSIX apps (HTTP downloads only) - MSIX apps (HTTP downloads only)
- Edge browser installs and updates - Microsoft Edge browser installations and updates
- [Dynamic updates](https://techcommunity.microsoft.com/t5/windows-it-pro-blog/the-benefits-of-windows-10-dynamic-update/ba-p/467847) - [Dynamic updates](https://techcommunity.microsoft.com/t5/windows-it-pro-blog/the-benefits-of-windows-10-dynamic-update/ba-p/467847)
## Requirements ## Requirements
@ -159,14 +159,14 @@ For the payloads (optional):
**Does Delivery Optimization use multicast?**: No. It relies on the cloud service for peer discovery, resulting in a list of peers and their IP addresses. Client devices then connect to their peers to obtain download files over TCP/IP. **Does Delivery Optimization use multicast?**: No. It relies on the cloud service for peer discovery, resulting in a list of peers and their IP addresses. Client devices then connect to their peers to obtain download files over TCP/IP.
**How does Delivery Optimization deal with congestion on the router from peer-to-peer activity on the LAN?**: Starting in Windows 10, version 1903, Delivery Optimization uses LEDBAT to relieve such congestion. For more details see this post on the [Networking Blog](https://techcommunity.microsoft.com/t5/Networking-Blog/Windows-Transport-converges-on-two-Congestion-Providers-Cubic/ba-p/339819). **How does Delivery Optimization deal with congestion on the router from peer-to-peer activity on the LAN?**: Starting in Windows 10, version 1903, Delivery Optimization uses LEDBAT to relieve such congestion. For more details, see this post on the [Networking Blog](https://techcommunity.microsoft.com/t5/Networking-Blog/Windows-Transport-converges-on-two-Congestion-Providers-Cubic/ba-p/339819).
**How does Delivery Optimization handle VPNs?** **How does Delivery Optimization handle VPNs?**
Delivery Optimization attempts to identify VPNs by checking the network adapter type and details and will treat the connection as a VPN if the adapter description contains certain keywords, such as "VPN" or "secure." Delivery Optimization attempts to identify VPNs by checking the network adapter type and details and will treat the connection as a VPN if the adapter description contains certain keywords, such as "VPN" or "secure."
If the connection is identified as a VPN, Delivery Optimization will suspend uploads to other peers. However, you can allow uploads over a VPN by using the [Enable Peer Caching while the device connects via VPN](waas-delivery-optimization-reference.md#enable-peer-caching-while-the-device-connects-via-vpn) policy. If the connection is identified as a VPN, Delivery Optimization will suspend uploads to other peers. However, you can allow uploads over a VPN by using the [Enable Peer Caching while the device connects via VPN](waas-delivery-optimization-reference.md#enable-peer-caching-while-the-device-connects-via-vpn) policy.
If you have defined a boundary group in Configuration Manager for VPN IP ranges, you can set the DownloadMode policy to 0 for that boundary group to ensure that there will be no peer-to-peer activity over the VPN. When the device is not connected via VPN, it can still leverage peer-to-peer with the default of LAN. If you have defined a boundary group in Configuration Manager for VPN IP ranges, you can set the DownloadMode policy to 0 for that boundary group to ensure that there will be no peer-to-peer activity over the VPN. When the device is not connected using a VPN, it can still use peer-to-peer with the default of LAN.
With split tunneling, make sure to allow direct access to these endpoints: With split tunneling, make sure to allow direct access to these endpoints:
@ -202,34 +202,34 @@ If you don't see any bytes coming from peers the cause might be one of the follo
### Clients aren't able to reach the Delivery Optimization cloud services. ### Clients aren't able to reach the Delivery Optimization cloud services.
If you suspect this is the problem, try these steps: Try these steps:
1. Start a download of an app that is larger than 50 MB from the Store (for example "Candy Crush Saga"). 1. Start a download of an app that is larger than 50 MB from the Store (for example "Candy Crush Saga").
2. Run `Get-DeliveryOptimizationStatus` from an elevated PowerShell window and observe the DownloadMode setting. For peering to work, DownloadMode should be 1, 2, or 3. 2. Run `Get-DeliveryOptimizationStatus` from an elevated PowerShell window and observe the DownloadMode setting. For peering to work, DownloadMode should be 1, 2, or 3.
3. If **DownloadMode** is 99 it could indicate your device is unable to reach the Delivery Optimization cloud services. Ensure that the Delivery Optimization hostnames are allowed access: most importantly **\*.do.dsp.mp.microsoft.com**. 3. If **DownloadMode** is 99, it could indicate your device is unable to reach the Delivery Optimization cloud services. Ensure that the Delivery Optimization host names are allowed access: most importantly **\*.do.dsp.mp.microsoft.com**.
### The cloud service doesn't see other peers on the network. ### The cloud service doesn't see other peers on the network.
If you suspect this is the problem, try these steps: Try these steps:
1. Download the same app on two different devices on the same network, waiting 10 – 15 minutes between downloads. 1. Download the same app on two different devices on the same network, waiting 10 – 15 minutes between downloads.
2. Run `Get-DeliveryOptimizationStatus` from an elevated PowerShell window and ensure that **DownloadMode** is 1 or 2 on both devices. 2. Run `Get-DeliveryOptimizationStatus` from an elevated PowerShell window and ensure that **DownloadMode** is 1 or 2 on both devices.
3. Run `Get-DeliveryOptimizationPerfSnap` from an elevated PowerShell window on the second device. The **NumberOfPeers** field should be non-zero. 3. Run `Get-DeliveryOptimizationPerfSnap` from an elevated PowerShell window on the second device. The **NumberOfPeers** field should be non-zero.
4. If the number of peers is zero and you have **DownloadMode** = 1, ensure that both devices are using the same public IP address to reach the internet. To do this, open a browser Windows and search for “what is my IP”. You can **DownloadMode 2** (Group) and a custom GroupID (Guid) to fix this if the devices aren’t reporting the same public IP address. 4. If the number of peers is zero and you have **DownloadMode** = 1, ensure that both devices are using the same public IP address to reach the internet. Open a browser Windows and search for “what is my IP”. You can **DownloadMode 2** (Group) and a custom GroupID (Guid) to fix this if the devices aren’t reporting the same public IP address.
### Clients aren't able to connect to peers offered by the cloud service ### Clients aren't able to connect to peers offered by the cloud service
If you suspect this is the problem, try a Telnet test between two devices on the network to ensure they can connect using port 7680. To do this, follow these steps: Try a Telnet test between two devices on the network to ensure they can connect using port 7680. Follow these steps:
1. Install Telnet by running **dism /online /Enable-Feature /FeatureName:TelnetClient** from an elevated command prompt. 1. Install Telnet by running `dism /online /Enable-Feature /FeatureName:TelnetClient` from an elevated command prompt.
2. Run the test. For example, if you are on device with IP 192.168.8.12 and you are trying to test the connection to 192.168.9.17 run **telnet 192.168.9.17 7680** (the syntax is *telnet [destination IP] [port]*. You will either see a connection error or a blinking cursor like this /_. The blinking cursor means success. 2. Run the test. For example, if you are on device with IP 192.168.8.12 and you are trying to test the connection to 192.168.9.17 run `telnet 192.168.9.17 7680` (the syntax is *telnet [destination IP] [port]*. You will either see a connection error or a blinking cursor like this /_. The blinking cursor means success.
### None of the computers on the network are getting updates from peers ### None of the computers on the network are getting updates from peers
If you suspect this is the problem, check Delivery Optimization settings that could limit participation in peer caching. Check whether the following settings in assigned group policies, local group policies, are MDM policies are too restrictive: Check Delivery Optimization settings that could limit participation in peer caching. Check whether the following settings in assigned group policies, local group policies, or MDM policies are too restrictive:
- Minimum RAM (inclusive) allowed to use peer caching - Minimum RAM (inclusive) allowed to use peer caching
- Minimum disk size allowed to use peer caching - Minimum disk size allowed to use peer caching

5
windows/security/threat-protection/TOC.md
View File

@ -105,10 +105,7 @@
### [System integrity](windows-defender-system-guard/system-guard-how-hardware-based-root-of-trust-helps-protect-windows.md) ### [System integrity](windows-defender-system-guard/system-guard-how-hardware-based-root-of-trust-helps-protect-windows.md)
## [Device control]() ## [Code integrity](device-guard/enable-virtualization-based-protection-of-code-integrity.md)
### [Code integrity](device-guard/enable-virtualization-based-protection-of-code-integrity.md)
### [Control USB devices](device-control/control-usb-devices-using-intune.md)
### [Device control report](device-control/device-control-report.md)
## [Network firewall]() ## [Network firewall]()
### [Network firewall overview](windows-firewall/windows-firewall-with-advanced-security.md) ### [Network firewall overview](windows-firewall/windows-firewall-with-advanced-security.md)
### [Network firewall evaluation](windows-firewall/evaluating-windows-firewall-with-advanced-security-design-examples.md) ### [Network firewall evaluation](windows-firewall/evaluating-windows-firewall-with-advanced-security-design-examples.md)

331
windows/security/threat-protection/device-control/control-usb-devices-using-intune.md
View File

@ -1,331 +0,0 @@
---
title: How to control USB devices and other removable media using Intune (Windows 10)
description: You can configure Intune settings to reduce threats from removable storage such as USB devices.
ms.prod: m365-security
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
ms.localizationpriority: medium
ms.author: dansimp
author: dansimp
ms.reviewer: dansimp
manager: dansimp
audience: ITPro
ms.technology: mde
---
# How to control USB devices and other removable media using Microsoft Defender for Endpoint
**Applies to:** [Microsoft Defender for Endpoint](https://go.microsoft.com/fwlink/p/?linkid=2069559)
Microsoft recommends [a layered approach to securing removable media](https://aka.ms/devicecontrolblog), and Microsoft Defender for Endpoint provides multiple monitoring and control features to help prevent threats in unauthorized peripherals from compromising your devices:
1. [Discover plug and play connected events for peripherals in Microsoft Defender for Endpoint advanced hunting](#discover-plug-and-play-connected-events). Identify or investigate suspicious usage activity.
2. Configure to allow or block only certain removable devices and prevent threats.
1. [Allow or block removable devices](#allow-or-block-removable-devices) based on granular configuration to deny write access to removable disks and approve or deny devices by using USB device IDs. Flexible policy assignment of device installation settings based on an individual or group of Azure Active Directory (Azure AD) users and devices.
2. [Prevent threats from removable storage](#prevent-threats-from-removable-storage) introduced by removable storage devices by enabling:
- Microsoft Defender Antivirus real-time protection (RTP) to scan removable storage for malware.
- The Attack Surface Reduction (ASR) USB rule to block untrusted and unsigned processes that run from USB.
- Direct Memory Access (DMA) protection settings to mitigate DMA attacks, including Kernel DMA Protection for Thunderbolt and blocking DMA until a user signs in.
3. [Create customized alerts and response actions](#create-customized-alerts-and-response-actions) to monitor usage of removable devices based on these plug and play events or any other Microsoft Defender for Endpoint events with [custom detection rules](/windows/security/threat-protection/microsoft-defender-atp/custom-detection-rules).
4. [Respond to threats](#respond-to-threats) from peripherals in real-time based on properties reported by each peripheral.
>[!Note]
>These threat reduction measures help prevent malware from coming into your environment. To protect enterprise data from leaving your environment, you can also configure data loss prevention measures. For example, on Windows 10 devices you can configure [BitLocker](../../information-protection/bitlocker/bitlocker-overview.md) and [Windows Information Protection](../../information-protection/windows-information-protection/create-wip-policy-using-intune-azure.md), which will encrypt company data even if it is stored on a personal device, or use the [Storage/RemovableDiskDenyWriteAccess CSP](/windows/client-management/mdm/policy-csp-storage#storage-removablediskdenywriteaccess) to deny write access to removable disks. Additionally, you can [classify and protect files on Windows devices](/windows/security/threat-protection/windows-defender-atp/information-protection-in-windows-overview) (including their mounted USB devices) by using Microsoft Defender for Endpoint and Azure Information Protection.
## Discover plug and play connected events
You can view plug and play connected events in Microsoft Defender for Endpoint advanced hunting to identify suspicious usage activity or perform internal investigations.
For examples of Defender for Endpoint advanced hunting queries, see the [Microsoft Defender for Endpoint hunting queries GitHub repo](https://github.com/Microsoft/WindowsDefenderATP-Hunting-Queries).
Sample Power BI report templates are available for Microsoft Defender for Endpoint that you can use for Advanced hunting queries. With these sample templates, including one for device control, you can integrate the power of Advanced hunting into Power BI. See the [GitHub repository for PowerBI templates](https://github.com/microsoft/MDATP-PowerBI-Templates) for more information. See [Create custom reports using Power BI](/windows/security/threat-protection/microsoft-defender-atp/api-power-bi) to learn more about Power BI integration.
## Allow or block removable devices
The following table describes the ways Microsoft Defender for Endpoint can allow or block removable devices based on granular configuration.
| Control | Description |
|----------|-------------|
| [Restrict USB drives and other peripherals](#restrict-usb-drives-and-other-peripherals) | You can allow/prevent users to install only the USB drives and other peripherals included on a list of authorized/unauthorized devices or device types. |
| [Block installation and usage of removable storage](#block-installation-and-usage-of-removable-storage) | You can't install or use removable storage. |
| [Allow installation and usage of specifically approved peripherals](#allow-installation-and-usage-of-specifically-approved-peripherals) | You can only install and use approved peripherals that report specific properties in their firmware. |
| [Prevent installation of specifically prohibited peripherals](#prevent-installation-of-specifically-prohibited-peripherals) | You can't install or use prohibited peripherals that report specific properties in their firmware. |
| [Allow installation and usage of specifically approved peripherals with matching device instance IDs](#allow-installation-and-usage-of-specifically-approved-peripherals-with-matching-device-instance-ids) | You can only install and use approved peripherals that match any of these device instance IDs. |
| [Prevent installation and usage of specifically prohibited peripherals with matching device instance IDs](#prevent-installation-and-usage-of-specifically-prohibited-peripherals-with-matching-device-instance-ids) | You can't install or use prohibited peripherals that match any of these device instance IDs. |
| [Limit services that use Bluetooth](#limit-services-that-use-bluetooth) | You can limit the services that can use Bluetooth. |
| [Use Microsoft Defender for Endpoint baseline settings](#use-microsoft-defender-for-endpoint-baseline-settings) | You can set the recommended configuration for ATP by using the Defender for Endpoint security baseline. |
### Restrict USB drives and other peripherals
To prevent malware infections or data loss, an organization may restrict USB drives and other peripherals. The following table describes the ways Microsoft Defender for Endpoint can help prevent installation and usage of USB drives and other peripherals.
| Control | Description
|----------|-------------|
| [Allow installation and usage of USB drives and other peripherals](#allow-installation-and-usage-of-usb-drives-and-other-peripherals) | Allow users to install only the USB drives and other peripherals included on a list of authorized devices or device types |
| [Prevent installation and usage of USB drives and other peripherals](#prevent-installation-and-usage-of-usb-drives-and-other-peripherals) | Prevent users from installing USB drives and other peripherals included on a list of unauthorized devices and device types |
All of the above controls can be set through the Intune [Administrative Templates](/intune/administrative-templates-windows). The relevant policies are located here in the Intune Administrator Templates:
![screenshot of list of Admin Templates](images/admintemplates.png)
>[!Note]
>Using Intune, you can apply device configuration policies to Azure AD user and/or device groups.
The above policies can also be set through the [Device Installation CSP settings](/windows/client-management/mdm/policy-csp-deviceinstallation) and the [Device Installation GPOs](/previous-versions/dotnet/articles/bb530324(v=msdn.10)).
> [!Note]
> Always test and refine these settings with a pilot group of users and devices first before applying them in production.
For more information about controlling USB devices, see the [Microsoft Defender for Endpoint blog](https://www.microsoft.com/security/blog/2018/12/19/windows-defender-atp-has-protections-for-usb-and-removable-devices/).
#### Allow installation and usage of USB drives and other peripherals
One way to approach allowing installation and usage of USB drives and other peripherals is to start by allowing everything. Afterwards, you can start reducing the allowable USB drivers and other peripherals.
>[!Note]
>Because an unauthorized USB peripheral can have firmware that spoofs its USB properties, we recommend only allowing specifically approved USB peripherals and limiting the users who can access them.
1. Enable **Prevent installation of devices not described by other policy settings** to all users.
2. Enable **Allow installation of devices using drivers that match these device setup classes** for all [device setup classes](/windows-hardware/drivers/install/system-defined-device-setup-classes-available-to-vendors).
To enforce the policy for already installed devices, apply the prevent policies that have this setting.
When configuring the allow device installation policy, you must allow all parent attributes as well. You can view the parents of a device by opening Device Manager and view by connection.
![Devices by connection](images/devicesbyconnection.png)
In this example, the following classes needed to be added: HID, Keyboard, and {36fc9e60-c465-11cf-8056-444553540000}. See [Microsoft-provided USB drivers](/windows-hardware/drivers/usbcon/supported-usb-classes) for more information.
![Device host controller](images/devicehostcontroller.jpg)
If you want to restrict to certain devices, remove the device setup class of the peripheral that you want to limit. Then add the device ID that you want to add. Device ID is based on the vendor ID and product ID values for a device. For information on device ID formats, see [Standard USB Identifiers](/windows-hardware/drivers/install/standard-usb-identifiers).
To find the device IDs, see [Look up device ID](#look-up-device-id).
For example:
1. Remove class USBDevice from the **Allow installation of devices using drivers that match these device setup**.
2. Add the device ID to allow in the **Allow installation of device that match any of these device IDs**.
#### Prevent installation and usage of USB drives and other peripherals
If you want to prevent the installation of a device class or certain devices, you can use the prevent device installation policies:
1. Enable **Prevent installation of devices that match any of these device IDs** and add these devices to the list.
2. Enable **Prevent installation of devices using drivers that match these device setup classes**.
> [!Note]
> The prevent device installation policies take precedence over the allow device installation policies.
The **Prevent installation of devices that match any of these device IDs** policy allows you to specify a list of devices that Windows is prevented from installing.
To prevent installation of devices that match any of these device IDs:
1. [Look up device ID](#look-up-device-id) for devices that you want Windows to prevent from installing.
![Look up vendor or product ID](images/lookup-vendor-product-id.png)
2. Enable **Prevent installation of devices that match any of these device IDs** and add the vendor or product IDs to the list.
![Add vendor ID to prevent list](images/add-vendor-id-to-prevent-list.png)
#### Look up device ID
You can use Device Manager to look up a device ID.
1. Open Device Manager.
2. Click **View** and select **Devices by connection**.
3. From the tree, right-click the device and select **Properties**.
4. In the dialog box for the selected device, click the **Details** tab.
5. Click the **Property** drop-down list and select **Hardware Ids**.
6. Right-click the top ID value and select **Copy**.
For information about Device ID formats, see [Standard USB Identifiers](/windows-hardware/drivers/install/standard-usb-identifiers).
For information on vendor IDs, see [USB members](https://www.usb.org/members).
The following is an example for looking up a device vendor ID or product ID (which is part of the device ID) using PowerShell:
``` PowerShell
Get-WMIObject -Class Win32_DiskDrive |
Select-Object -Property *
```
The **Prevent installation of devices using drivers that match these device setup classes** policy allows you to specify device setup classes that Windows is prevented from installing.
To prevent installation of particular classes of devices:
1. Find the GUID of the device setup class from [System-Defined Device Setup Classes Available to Vendors](/windows-hardware/drivers/install/system-defined-device-setup-classes-available-to-vendors).
2. Enable **Prevent installation of devices using drivers that match these device setup classes** and add the class GUID to the list.
![Add device setup class to prevent list](images/Add-device-setup-class-to-prevent-list.png)
### Block installation and usage of removable storage
1. Sign in to the [Microsoft Azure portal](https://portal.azure.com/).
2. Click **Intune** > **Device configuration** > **Profiles** > **Create profile**.
![Create device configuration profile](images/create-device-configuration-profile.png)
3. Use the following settings:
- Name: Type a name for the profile
- Description: Type a description
- Platform: Windows 10 and later
- Profile type: Device restrictions
![Create profile](images/create-profile.png)
4. Click **Configure** > **General**.
5. For **Removable storage** and **USB connection (mobile only)**, choose **Block**. **Removable storage** includes USB drives, whereas **USB connection (mobile only)** excludes USB charging but includes other USB connections on mobile devices only.
![General settings](images/general-settings.png)
6. Click **OK** to close **General** settings and **Device restrictions**.
7. Click **Create** to save the profile.
### Allow installation and usage of specifically approved peripherals
Peripherals that are allowed to be installed can be specified by their [hardware identity](/windows-hardware/drivers/install/device-identification-strings). For a list of common identifier structures, see [Device Identifier Formats](/windows-hardware/drivers/install/device-identifier-formats). Test the configuration prior to rolling it out to ensure it blocks and allows the devices expected. Ideally test various instances of the hardware. For example, test multiple USB keys rather than only one.
For a SyncML example that allows installation of specific device IDs, see [DeviceInstallation/AllowInstallationOfMatchingDeviceIDs CSP](/windows/client-management/mdm/policy-csp-deviceinstallation#deviceinstallation-allowinstallationofmatchingdeviceids). To allow specific device classes, see [DeviceInstallation/AllowInstallationOfMatchingDeviceSetupClasses CSP](/windows/client-management/mdm/policy-csp-deviceinstallation#deviceinstallation-allowinstallationofmatchingdevicesetupclasses).
Allowing installation of specific devices requires also enabling [DeviceInstallation/PreventInstallationOfDevicesNotDescribedByOtherPolicySettings](/windows/client-management/mdm/policy-csp-deviceinstallation#deviceinstallation-preventinstallationofdevicesnotdescribedbyotherpolicysettings).
### Prevent installation of specifically prohibited peripherals
Microsoft Defender for Endpoint blocks installation and usage of prohibited peripherals by using either of these options:
- [Administrative Templates](/intune/administrative-templates-windows) can block any device with a matching hardware ID or setup class.
- [Device Installation CSP settings](/windows/client-management/mdm/policy-csp-deviceinstallation) with a custom profile in Intune. You can [prevent installation of specific device IDs](/windows/client-management/mdm/policy-csp-deviceinstallation#deviceinstallation-preventinstallationofmatchingdeviceids) or [prevent specific device classes](/windows/client-management/mdm/policy-csp-deviceinstallation#deviceinstallation-preventinstallationofmatchingdevicesetupclasses).
### Allow installation and usage of specifically approved peripherals with matching device instance IDs
Peripherals that are allowed to be installed can be specified by their [device instance IDs](/windows-hardware/drivers/install/device-instance-ids). Test the configuration prior to rolling it out to ensure it allows the devices expected. Ideally test various instances of the hardware. For example, test multiple USB keys rather than only one.
You can allow installation and usage of approved peripherals with matching device instance IDs by configuring [DeviceInstallation/AllowInstallationOfMatchingDeviceInstanceIDs](/windows/client-management/mdm/policy-csp-deviceinstallation#deviceinstallation-allowinstallationofmatchingdeviceinstanceids) policy setting.
### Prevent installation and usage of specifically prohibited peripherals with matching device instance IDs
Peripherals that are prohibited to be installed can be specified by their [device instance IDs](/windows-hardware/drivers/install/device-instance-ids). Test the configuration prior to rolling it out to ensure it allows the devices expected. Ideally test various instances of the hardware. For example, test multiple USB keys rather than only one.
You can prevent installation of the prohibited peripherals with matching device instance IDs by configuring [DeviceInstallation/PreventInstallationOfMatchingDeviceInstanceIDs](/windows/client-management/mdm/policy-csp-deviceinstallation#deviceinstallation-preventinstallationofmatchingdeviceinstanceids) policy setting.
### Limit services that use Bluetooth
Using Intune, you can limit the services that can use Bluetooth through the ["Bluetooth allowed services"](/windows/client-management/mdm/policy-csp-bluetooth#servicesallowedlist-usage-guide). The default state of "Bluetooth allowed services" settings means everything is allowed. As soon as a service is added, that becomes the allowed list. If the customer adds the Keyboards and Mice values, and doesn’t add the file transfer GUIDs, file transfer should be blocked.
![screenshot of Bluetooth settings page](images/bluetooth.png)
### Use Microsoft Defender for Endpoint baseline settings
The Microsoft Defender for Endpoint baseline settings represent the recommended configuration for threat protection. Configuration settings for baseline are located in the edit profile page of the configuration settings.
![Baselines in MEM](images/baselines.png)
## Prevent threats from removable storage
Removable storage devices can introduce additional security risk to your organization. Microsoft Defender for Endpoint can help identify and block malicious files on removable storage devices.
Microsoft Defender for Endpoint can also prevent USB peripherals from being used on devices to help prevent external threats. It does this by using the properties reported by USB peripherals to determine whether or not they can be installed and used on the device.
Note that if you block USB devices or any other device classes using the device installation policies, connected devices, such as phones, can still charge.
>[!NOTE]
>Always test and refine these settings with a pilot group of users and devices first before widely distributing to your organization.
The following table describes the ways Microsoft Defender for Endpoint can help prevent threats from removable storage.
For more information about controlling USB devices, see the [Microsoft Defender for Endpoint blog](https://aka.ms/devicecontrolblog).
| Control | Description |
|----------|-------------|
| [Enable Microsoft Defender Antivirus Scanning](#enable-microsoft-defender-antivirus-scanning) | Enable Microsoft Defender Antivirus scanning for real-time protection or scheduled scans.|
| [Block untrusted and unsigned processes on USB peripherals](#block-untrusted-and-unsigned-processes-on-usb-peripherals) | Block USB files that are unsigned or untrusted. |
| [Protect against Direct Memory Access (DMA) attacks](#protect-against-direct-memory-access-dma-attacks) | Configure settings to protect against DMA attacks. |
>[!NOTE]
>Because an unauthorized USB peripheral can have firmware that spoofs its USB properties, we recommend only allowing specifically approved USB peripherals and limiting the users who can access them.
### Enable Microsoft Defender Antivirus Scanning
Protecting authorized removable storage with Microsoft Defender Antivirus requires [enabling real-time protection](/microsoft-365/security/defender-endpoint/configure-real-time-protection-microsoft-defender-antivirus) or scheduling scans and configuring removable drives for scans.
- If real-time protection is enabled, files are scanned before they are accessed and executed. The scanning scope includes all files, including those on mounted removable devices such as USB drives. You can optionally [run a PowerShell script to perform a custom scan](/samples/browse/?redirectedfrom=TechNet-Gallery) of a USB drive after it is mounted, so that Microsoft Defender Antivirus starts scanning all files on a removable device once the removable device is attached. However, we recommend enabling real-time protection for improved scanning performance, especially for large storage devices.
- If scheduled scans are used, then you need to disable the DisableRemovableDriveScanning setting (enabled by default) to scan the removable device during a full scan. Removable devices are scanned during a quick or custom scan regardless of the DisableRemovableDriveScanning setting.
>[!NOTE]
>We recommend enabling real-time monitoring for scanning. In Intune, you can enable real-time monitoring for Windows 10 in **Device Restrictions** > **Configure** > **Microsoft Defender Antivirus** > **Real-time monitoring**.
<!-- Need to build out point in the preceding note.
-->
### Block untrusted and unsigned processes on USB peripherals
End-users might plug in removable devices that are infected with malware.
To prevent infections, a company can block USB files that are unsigned or untrusted.
Alternatively, companies can leverage the audit feature of [attack surface reduction rules](/microsoft-365/security/defender-endpoint/attack-surface-reduction) to monitor the activity of untrusted and unsigned processes that execute on a USB peripheral.
This can be done by setting **Untrusted and unsigned processes that run from USB** to either **Block** or **Audit only**, respectively.
With this rule, admins can prevent or audit unsigned or untrusted executable files from running from USB removable drives, including SD cards.
Affected file types include executable files (such as .exe, .dll, or .scr) and script files such as a PowerShell (.ps), VisualBasic (.vbs), or JavaScript (.js) files.
These settings require [enabling real-time protection](/microsoft-365/security/defender-endpoint/configure-real-time-protection-microsoft-defender-antivirus).
1. Sign in to the [Microsoft Endpoint Manager](https://endpoint.microsoft.com/).
2. Click **Devices** > **Windows** > **Configuration Policies** > **Create profile**.
![Create device configuration profile](images/create-device-configuration-profile.png)
3. Use the following settings:
- Platform: Windows 10 and later
- Profile type: Device restrictions
![Create endpoint protection profile](images/create-endpoint-protection-profile.png)
4. Click **Create**.
5. For **Unsigned and untrusted processes that run from USB**, choose **Block**.
![Block untrusted processes](images/block-untrusted-processes.png)
6. Click **OK** to close settings and **Device restrictions**.
### Protect against Direct Memory Access (DMA) attacks
DMA attacks can lead to disclosure of sensitive information residing on a PC, or even injection of malware that allows attackers to bypass the lock screen or control PCs remotely. The following settings help to prevent DMA attacks:
1. Beginning with Windows 10 version 1803, Microsoft introduced [Kernel DMA Protection for Thunderbolt](../../information-protection/kernel-dma-protection-for-thunderbolt.md) to provide native protection against DMA attacks via Thunderbolt ports. Kernel DMA Protection for Thunderbolt is enabled by system manufacturers and cannot be turned on or off by users.
Beginning with Windows 10 version 1809, you can adjust the level of Kernel DMA Protection by configuring the [DMA Guard CSP](/windows/client-management/mdm/policy-csp-dmaguard#dmaguard-deviceenumerationpolicy). This is an additional control for peripherals that don't support device memory isolation (also known as DMA-remapping). Memory isolation allows the OS to leverage the I/O Memory Management Unit (IOMMU) of a device to block unallowed I/O, or memory access, by the peripheral (memory sandboxing). In other words, the OS assigns a certain memory range to the peripheral. If the peripheral attempts to read/write to memory outside of the assigned range, the OS blocks it.
Peripherals that support device memory isolation can always connect. Peripherals that don't can be blocked, allowed, or allowed only after the user signs in (default).
2. On Windows 10 systems that do not support Kernel DMA Protection, you can:
- [Block DMA until a user signs in](/windows/client-management/mdm/policy-csp-dataprotection#dataprotection-allowdirectmemoryaccess)
- [Block all connections via the Thunderbolt ports (including USB devices)](https://support.microsoft.com/help/2516445/blocking-the-sbp-2-driver-and-thunderbolt-controllers-to-reduce-1394-d)
## Create customized alerts and response actions
You can create custom alerts and response actions with the WDATP Connector and the custom detection rules:
**Wdatp Connector response Actions:**
**Investigate:** Initiate investigations, collect investigation package, and isolate a machine.
**Threat Scanning** on USB devices.
**Restrict execution of all applications** on the machine except a predefined set
MDATP connector is one of over 200 pre-defined connectors including Outlook, Teams, Slack, etc. Custom connectors can be built.
- [More information on WDATP Connector Response Actions](/connectors/wdatp/)
**Custom Detection Rules Response Action:**
Both machine and file level actions can be applied.
- [More information on Custom Detection Rules Response Actions](/windows/security/threat-protection/microsoft-defender-atp/custom-detection-rules)
For information on device control related advance hunting events and examples on how to create custom alerts, see [Advanced hunting updates: USB events, machine-level actions, and schema changes](https://techcommunity.microsoft.com/t5/Microsoft-Defender-ATP/Advanced-hunting-updates-USB-events-machine-level-actions-and/ba-p/824152).
## Respond to threats
You can create custom alerts and automatic response actions with the [Microsoft Defender for Endpoint Custom Detection Rules](/windows/security/threat-protection/microsoft-defender-atp/custom-detection-rules). Response actions within the custom detection cover both machine and file level actions. You can also create alerts and automatic response actions using [PowerApps](https://powerapps.microsoft.com/) and [Flow](https://flow.microsoft.com/) with the [Microsoft Defender for Endpoint connector](/connectors/wdatp/). The connector supports actions for investigation, threat scanning, and restricting running applications. It is one of over 200 pre-defined connectors including Outlook, Teams, Slack, and more. Custom connectors can also be built. See [Connectors](/connectors/) to learn more about connectors.
For example, using either approach, you can automatically have the Microsoft Defender Antivirus run when a USB device is mounted onto a machine.
## Related topics
- [Configure real-time protection for Microsoft Defender Antivirus](/microsoft-365/security/defender-endpoint/configure-real-time-protection-microsoft-defender-antivirus)
- [Defender/AllowFullScanRemovableDriveScanning](/windows/client-management/mdm/policy-csp-defender#defender-allowfullscanremovabledrivescanning)
- [Policy/DeviceInstallation CSP](/windows/client-management/mdm/policy-csp-deviceinstallation)
- [Perform a custom scan of a removable device](/samples/browse/?redirectedfrom=TechNet-Gallery)
- [Device Control PowerBI Template for custom reporting](https://github.com/microsoft/MDATP-PowerBI-Templates)
- [BitLocker](../../information-protection/bitlocker/bitlocker-overview.md)
- [Windows Information Protection](../../information-protection/windows-information-protection/create-wip-policy-using-intune-azure.md)

74
windows/security/threat-protection/device-control/device-control-report.md
View File

@ -1,74 +0,0 @@
---
title: Protect your organization’s data with device control
description: Monitor your organization's data security through device control reports.
ms.prod: m365-security
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
ms.localizationpriority: medium
ms.author: v-ajupudi
author: alluthewriter
ms.reviewer: dansimp
manager: dansimp
audience: ITPro
ms.technology: mde
---
# Protect your organization’s data with device control
**Applies to:** [Microsoft Defender for Endpoint](https://go.microsoft.com/fwlink/p/?linkid=2069559)
Microsoft Defender for Endpoint device control protects against data loss, by monitoring and controlling media use by devices in your organization, such as the use of removable storage devices and USB drives.
With the device control report, you can view events that relate to media usage, such as:
- **Audit events:** Shows the number of audit events that occur when external media is connected.
- **Policy events:** Shows the number of policy events that occur when a device control policy is triggered.
> [!NOTE]
> The audit event to track media usage is enabled by default for devices onboarded to Microsoft Defender for Endpoint.
## Understanding the audit events
The audit events include:
- **USB drive mount and unmount:** Audit events that are generated when a USB drive is mounted or unmounted.
- **PnP:** Plug and Play audit events are generated when removable storage, a printer, or Bluetooth media is connected.
## Monitor device control security
Device control in Microsoft Defender for Endpoint empowers security administrators with tools that enable them to track their organization’s device control security through reports. You can find the device control report in the Microsoft 365 security center by going to **Reports > Device protection**.
The Device protection card on the **Reports** dashboard shows the number of audit events generated by media type, over the last 180 days.
> [!div class="mx-imgBorder"]
> ![DeviceControlReportCard](images/devicecontrolcard.png)
The **View details** button shows more media usage data in the **device control report** page.
The page provides a dashboard with aggregated number of events per type and a list of events. Administrators can filter on time range, media class name, and device ID.
> [!div class="mx-imgBorder"]
> ![DeviceControlReportDetails](images/Detaileddevicecontrolreport.png)
When you select an event, a flyout appears that shows you more information:
- **General details:** Date, Action mode, and the policy of this event.
- **Media information:** Media information includes Media name, Class name, Class GUID, Device ID, Vendor ID, Volume, Serial number, and Bus type.
- **Location details:** Device name and MDATP device ID.
> [!div class="mx-imgBorder"]
> ![FilterOnDeviceControlReport](images/devicecontrolreportfilter.png)
To see real-time activity for this media across the organization, select the **Open Advanced hunting** button. This includes an embedded, pre-defined query.
> [!div class="mx-imgBorder"]
> ![QueryOnDeviceControlReport](images/Devicecontrolreportquery.png)
To see the security of the device, select the **Open device page** button on the flyout. This button opens the device entity page.
> [!div class="mx-imgBorder"]
> ![DeviceEntityPage](images/Devicesecuritypage.png)
## Reporting delays
The device control report can have a 12-hour delay from the time a media connection occurs to the time the event is reflected in the card or in the domain list.

36
windows/security/threat-protection/device-guard/introduction-to-device-guard-virtualization-based-security-and-windows-defender-application-control.md
View File

@ -16,35 +16,33 @@ ms.technology: mde
# Windows Defender Application Control and virtualization-based protection of code integrity # Windows Defender Application Control and virtualization-based protection of code integrity
**Applies to** **Applies to**
- Windows 10 - Windows 10
- Windows Server 2016 - Windows Server 2016
Windows 10 includes a set of hardware and OS technologies that, when configured together, allow enterprises to "lock down" Windows 10 systems so they operate with many of the properties of mobile devices. In this configuration, specific technologies work together to restrict devices to only run authorized apps by using a feature called configurable code integrity, while simultaneously hardening the OS against kernel memory attacks by using virtualization-based protection of code integrity (more specifically, HVCI). Windows 10 includes a set of hardware and OS technologies that, when configured together, allow enterprises to "lock down" Windows 10 systems so they behave more like mobile devices. In this configuration, Windows Defender Application Control (WDAC) is used to restrict devices to run only approved apps, while the OS is hardened against kernel memory attacks using hypervisor-protected code integrity (HVCI).
Configurable code integrity policies and HVCI are powerful protections that can be used separately. However, when these two technologies are configured to work together, they present a strong protection capability for Windows 10 devices. WDAC policies and HVCI are powerful protections that can be used separately. However, when these two technologies are configured to work together, they present a strong protection capability for Windows 10 devices.
Using configurable code integrity to restrict devices to only authorized apps has these advantages over other solutions: Using WDAC to restrict devices to only authorized apps has these advantages over other solutions:
1. Configurable code integrity policy is enforced by the Windows kernel itself. As such, the policy takes effect early in the boot sequence before nearly all other OS code and before traditional antivirus solutions run. 1. WDAC policy is enforced by the Windows kernel itself, and the policy takes effect early in the boot sequence before nearly all other OS code and before traditional antivirus solutions run.
2. Configurable code integrity allows customers to set application control policy not only over code running in user mode, but also kernel mode hardware and software drivers and even code that runs as part of Windows. 2. WDAC lets you set application control policy for code that runs in user mode, kernel mode hardware and software drivers, and even code that runs as part of Windows.
3. Customers can protect the configurable code integrity policy even from local administrator tampering by digitally signing the policy. This would mean that changing the policy would require both administrative privilege and access to the organization’s digital signing process, making it difficult for an attacker with administrative privilege, or malicious software that managed to gain administrative privilege, to alter the application control policy. 3. Customers can protect the WDAC policy even from local administrator tampering by digitally signing the policy. To change signed policy requires both administrative privilege and access to the organization’s digital signing process. This makes it difficult for an attacker, including one who has managed to gain administrative privilege, to tamper with WDAC policy.
4. The entire configurable code integrity enforcement mechanism can be protected by HVCI, where even if a vulnerability exists in kernel mode code, the likelihood that an attacker could successfully exploit it is diminished. Why is this relevant? That’s because an attacker that compromises the kernel would otherwise have enough privilege to disable most system defenses and override the application control policies enforced by configurable code integrity or any other application control solution. 4. You can protect the entire WDAC enforcement mechanism with HVCI. Even if a vulnerability exists in kernel mode code, HVCI greatly reduces the likelihood that an attacker could successfully exploit it. This is important because an attacker that compromises the kernel could normally disable most system defenses, including those enforced by WDAC or any other application control solution.
## Windows Defender Application Control ## Why we no longer use the Device Guard brand
When we originally designed this configuration state, we did so with a specific security promise in mind. Although there were no direct dependencies between configurable code integrity and HVCI, we intentionally focused our discussion around the lockdown state you achieve when deploying them together. However, given that HVCI relies on Windows virtualization-based security, it comes with more hardware, firmware, and kernel driver compatibility requirements that some older systems can’t meet. As a result, many IT Professionals assumed that because some systems couldn't use HVCI, they couldn’t use configurable code integrity either. When we originally promoted Device Guard, we did so with a specific security promise in mind. Although there were no direct dependencies between WDAC and HVCI, we intentionally focused our discussion around the lockdown state achieved when using them together. However, since HVCI relies on Windows virtualization-based security, it has hardware, firmware, and kernel driver compatibility requirements that some older systems can’t meet. This misled many people to assume that if systems couldn't use HVCI, they couldn’t use WDAC either.
Configurable code integrity carries no specific hardware or software requirements other than running Windows 10, which means many IT professionals were wrongly denied the benefits of this powerful application control capability. WDAC has no specific hardware or software requirements other than running Windows 10, which means customers were denied the benefits of this powerful application control capability due to Device Guard confusion.
Since the initial release of Windows 10, the world has witnessed numerous hacking and malware attacks where application control alone could have prevented the attack altogether. With this in mind, we are discussing and documenting configurable code integrity as an independent technology within our security stack and giving it a name of its own: [Windows Defender Application Control](../windows-defender-application-control/windows-defender-application-control.md). Since the initial release of Windows 10, the world has witnessed numerous hacking and malware attacks where application control alone could have prevented the attack altogether. With this in mind, we now discuss and document WDAC as an independent technology within our security stack and gave it a name of its own: [Windows Defender Application Control](../windows-defender-application-control/windows-defender-application-control.md).
We hope this change will help us better communicate options for adopting application control within an organization. We hope this change will help us better communicate options for adopting application control within your organizations.
## Related articles ## Related articles
[Windows Defender Application Control](../windows-defender-application-control/windows-defender-application-control.md) - [Windows Defender Application Control](../windows-defender-application-control/windows-defender-application-control.md)
- [Dropping the Hammer Down on Malware Threats with Windows 10’s Windows Defender](https://channel9.msdn.com/Events/Ignite/2015/BRK2336)
[Dropping the Hammer Down on Malware Threats with Windows 10’s Windows Defender](https://channel9.msdn.com/Events/Ignite/2015/BRK2336) - [Driver compatibility with Windows Defender in Windows 10](https://blogs.msdn.microsoft.com/windows_hardware_certification/2015/05/22/driver-compatibility-with-device-guard-in-windows-10)
- [Code integrity](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd348642(v=ws.10))
[Driver compatibility with Windows Defender in Windows 10](https://blogs.msdn.microsoft.com/windows_hardware_certification/2015/05/22/driver-compatibility-with-device-guard-in-windows-10)
[Code integrity](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd348642(v=ws.10))

38
windows/security/threat-protection/windows-defender-application-control/TOC.md
View File

@ -1,44 +1,44 @@
# [Application Control for Windows](windows-defender-application-control.md) # [Application Control for Windows](windows-defender-application-control.md)
## [WDAC and AppLocker Overview](wdac-and-applocker-overview.md) ## [WDAC and AppLocker Overview](wdac-and-applocker-overview.md)
### [WDAC and AppLocker Feature Availability](feature-availability.md) ### [WDAC and AppLocker Feature Availability](feature-availability.md)
### [Virtualization-based code integrity](../device-guard/introduction-to-device-guard-virtualization-based-security-and-windows-defender-application-control.md) ### [Virtualization-based protection of code integrity](../device-guard/introduction-to-device-guard-virtualization-based-security-and-windows-defender-application-control.md)
## [WDAC design guide](windows-defender-application-control-design-guide.md) ## [WDAC design guide](windows-defender-application-control-design-guide.md)
### [Plan for WDAC policy lifecycle management](plan-windows-defender-application-control-management.md) ### [Plan for WDAC policy lifecycle management](plan-windows-defender-application-control-management.md)
### Design your initial WDAC policy ### Design your WDAC policy
#### [Understand WDAC policy design decisions](understand-windows-defender-application-control-policy-design-decisions.md) #### [Understand WDAC policy design decisions](understand-windows-defender-application-control-policy-design-decisions.md)
#### [Understand WDAC policy rules and file rules](select-types-of-rules-to-create.md) #### [Understand WDAC policy rules and file rules](select-types-of-rules-to-create.md)
#### [Authorize apps deployed with a WDAC managed installer](use-windows-defender-application-control-with-managed-installer.md) ##### [Allow apps installed by a managed installer](use-windows-defender-application-control-with-managed-installer.md)
##### [Configure a WDAC managed installer](configure-wdac-managed-installer.md) ##### [Configure managed installer rules](configure-wdac-managed-installer.md)
#### [Authorize reputable apps with Intelligent Security Graph (ISG)](use-windows-defender-application-control-with-intelligent-security-graph.md) ##### [Allow reputable apps with Intelligent Security Graph (ISG)](use-windows-defender-application-control-with-intelligent-security-graph.md)
##### [Allow COM object registration](allow-com-object-registration-in-windows-defender-application-control-policy.md)
##### [Use WDAC with .NET hardening](use-windows-defender-application-control-with-dynamic-code-security.md)
##### [Manage packaged apps with WDAC](manage-packaged-apps-with-windows-defender-application-control.md)
##### [Use WDAC to control specific plug-ins, add-ins, and modules](use-windows-defender-application-control-policy-to-control-specific-plug-ins-add-ins-and-modules.md)
#### [Use multiple WDAC policies](deploy-multiple-windows-defender-application-control-policies.md) #### [Use multiple WDAC policies](deploy-multiple-windows-defender-application-control-policies.md)
#### [Microsoft recommended block rules](microsoft-recommended-block-rules.md) ### Create your WDAC policy
#### [Microsoft recommended driver block rules](microsoft-recommended-driver-block-rules.md)
### Create your initial WDAC policy
#### [Example WDAC base policies](example-wdac-base-policies.md) #### [Example WDAC base policies](example-wdac-base-policies.md)
#### [Policy creation for common WDAC usage scenarios](types-of-devices.md) #### [Policy creation for common WDAC usage scenarios](types-of-devices.md)
##### [Create a WDAC policy for lightly-managed devices](create-wdac-policy-for-lightly-managed-devices.md) ##### [Create a WDAC policy for lightly-managed devices](create-wdac-policy-for-lightly-managed-devices.md)
##### [Create a WDAC policy for fully-managed devices](create-wdac-policy-for-fully-managed-devices.md) ##### [Create a WDAC policy for fully-managed devices](create-wdac-policy-for-fully-managed-devices.md)
##### [Create a WDAC policy for fixed-workload devices](create-initial-default-policy.md) ##### [Create a WDAC policy for fixed-workload devices](create-initial-default-policy.md)
##### [Microsoft recommended block rules](microsoft-recommended-block-rules.md) ##### [Microsoft recommended block rules](microsoft-recommended-block-rules.md)
#### [Using the WDAC Wizard tool](wdac-wizard.md) ##### [Microsoft recommended driver block rules](microsoft-recommended-driver-block-rules.md)
#### [Use the WDAC Wizard tool](wdac-wizard.md)
##### [Create a base WDAC policy with the Wizard](wdac-wizard-create-base-policy.md) ##### [Create a base WDAC policy with the Wizard](wdac-wizard-create-base-policy.md)
##### [Create a supplemental WDAC policy with the Wizard](wdac-wizard-create-supplemental-policy.md) ##### [Create a supplemental WDAC policy with the Wizard](wdac-wizard-create-supplemental-policy.md)
##### [Editing a WDAC policy with the Wizard](wdac-wizard-editing-policy.md) ##### [Editing a WDAC policy with the Wizard](wdac-wizard-editing-policy.md)
##### [Merging multiple WDAC policies with the Wizard](wdac-wizard-merging-policies.md) ##### [Merging multiple WDAC policies with the Wizard](wdac-wizard-merging-policies.md)
## [WDAC deployment guide](windows-defender-application-control-deployment-guide.md)
## [Windows Defender Application Control deployment guide](windows-defender-application-control-deployment-guide.md) ### [Deploy WDAC policies with MDM](deploy-windows-defender-application-control-policies-using-intune.md)
### [Deploy WDAC policies with MEMCM](deployment/deploy-wdac-policies-with-memcm.md)
### [Deploy WDAC policies with script](deployment/deploy-wdac-policies-with-script.md)
### [Deploy WDAC policies with Group Policy](deploy-windows-defender-application-control-policies-using-group-policy.md)
### [Audit WDAC policies](audit-windows-defender-application-control-policies.md) ### [Audit WDAC policies](audit-windows-defender-application-control-policies.md)
### [Merge WDAC policies](merge-windows-defender-application-control-policies.md) ### [Merge WDAC policies](merge-windows-defender-application-control-policies.md)
### [Enforce WDAC policies](enforce-windows-defender-application-control-policies.md) ### [Enforce WDAC policies](enforce-windows-defender-application-control-policies.md)
### [Deploy WDAC policies using Group Policy](deploy-windows-defender-application-control-policies-using-group-policy.md)
### [Deploy WDAC policies using Intune](deploy-windows-defender-application-control-policies-using-intune.md)
### [Allow COM object registration](allow-com-object-registration-in-windows-defender-application-control-policy.md)
### [Use WDAC with .NET hardening](use-windows-defender-application-control-with-dynamic-code-security.md)
### [Manage packaged apps with WDAC](manage-packaged-apps-with-windows-defender-application-control.md)
### [Use a Windows Defender Application Control policy to control specific plug-ins, add-ins, and modules](use-windows-defender-application-control-policy-to-control-specific-plug-ins-add-ins-and-modules.md)
### [Use code signing to simplify application control for classic Windows applications](use-code-signing-to-simplify-application-control-for-classic-windows-applications.md) ### [Use code signing to simplify application control for classic Windows applications](use-code-signing-to-simplify-application-control-for-classic-windows-applications.md)
#### [Optional: Use the WDAC Signing Portal in the Microsoft Store for Business](use-device-guard-signing-portal-in-microsoft-store-for-business.md) #### [Optional: Use the WDAC Signing Portal in the Microsoft Store for Business](use-device-guard-signing-portal-in-microsoft-store-for-business.md)
#### [Optional: Create a code signing cert for WDAC](create-code-signing-cert-for-windows-defender-application-control.md) #### [Optional: Create a code signing cert for WDAC](create-code-signing-cert-for-windows-defender-application-control.md)
@ -47,11 +47,11 @@
### [Disable WDAC policies](disable-windows-defender-application-control-policies.md) ### [Disable WDAC policies](disable-windows-defender-application-control-policies.md)
### [LOB Win32 Apps on S Mode](LOB-win32-apps-on-s.md) ### [LOB Win32 Apps on S Mode](LOB-win32-apps-on-s.md)
## [Windows Defender Application Control operational guide](windows-defender-application-control-operational-guide.md) ## [Windows Defender Application Control operational guide](windows-defender-application-control-operational-guide.md)
### [Understanding Application Control event IDs](event-id-explanations.md) ### [Understanding Application Control event IDs](event-id-explanations.md)
### [Understanding Application Control event tags](event-tag-explanations.md) ### [Understanding Application Control event tags](event-tag-explanations.md)
### [Query WDAC events with Advanced hunting](querying-application-control-events-centrally-using-advanced-hunting.md) ### [Query WDAC events with Advanced hunting](querying-application-control-events-centrally-using-advanced-hunting.md)
### [Known Issues](operations/known-issues.md)
## [AppLocker](applocker\applocker-overview.md) ## [AppLocker](applocker\applocker-overview.md)
### [Administer AppLocker](applocker\administer-applocker.md) ### [Administer AppLocker](applocker\administer-applocker.md)
@ -138,5 +138,3 @@
#### [Tools to Use with AppLocker](applocker\tools-to-use-with-applocker.md) #### [Tools to Use with AppLocker](applocker\tools-to-use-with-applocker.md)
##### [Using Event Viewer with AppLocker](applocker\using-event-viewer-with-applocker.md) ##### [Using Event Viewer with AppLocker](applocker\using-event-viewer-with-applocker.md)
#### [AppLocker Settings](applocker\applocker-settings.md) #### [AppLocker Settings](applocker\applocker-settings.md)

95
windows/security/threat-protection/windows-defender-application-control/audit-windows-defender-application-control-policies.md
View File

@ -1,6 +1,6 @@
--- ---
title: Audit Windows Defender Application Control policies (Windows 10) title: Use audit events to create WDAC policy rules (Windows 10)
description: Audits allow admins to discover apps that were missed during an initial policy scan and to identify new apps that were installed since the policy was created. description: Audits allow admins to discover apps, binaries, and scripts that should be added to the WDAC policy.
keywords: security, malware keywords: security, malware
ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
ms.prod: m365-security ms.prod: m365-security
@ -11,94 +11,65 @@ ms.localizationpriority: medium
audience: ITPro audience: ITPro
ms.collection: M365-security-compliance ms.collection: M365-security-compliance
author: jsuther1974 author: jsuther1974
ms.reviewer: isbrahm ms.reviewer: jogeurte
ms.author: dansimp ms.author: dansimp
manager: dansimp manager: dansimp
ms.date: 05/03/2018 ms.date: 05/03/2018
ms.technology: mde ms.technology: mde
--- ---
# Audit Windows Defender Application Control policies # Use audit events to create WDAC policy rules
**Applies to:** **Applies to:**
- Windows 10 - Windows 10
- Windows Server 2016 - Windows Server 2016 and above
Running **Application Control** in audit mode allows administrators to discover any applications that were missed during an initial policy scan and to identify any new applications that have been installed and run since the original policy was created. While a WDAC policy is running in audit mode, any binary that runs and would have been denied had the policy been enforced is logged in the **Applications and Services Logs\\Microsoft\\Windows\\CodeIntegrity\\Operational** event log. When these logged binaries have been validated, they can easily be added to a new WDAC policy. When the new exception policy is created, you can merge it with your existing WDAC policies. Running Application Control in audit mode lets you discover applications, binaries, and scripts that are missing from your WDAC policy but should be included.
Before you begin this process, you need to create a WDAC policy binary file. If you have not already done so, see [Create an initial Windows Defender Application Control policy from a reference computer](create-initial-default-policy.md). While a WDAC policy is running in audit mode, any binary that runs but would have been denied is logged in the **Applications and Services Logs\\Microsoft\\Windows\\CodeIntegrity\\Operational** event log. Script and MSI are logged in the **Applications and Services Logs\\Microsoft\\Windows\\AppLocker\\MSI and Script** event log. These events can be used to generate a new WDAC policy that can be merged with the original Base policy or deployed as a separate Supplemental policy, if allowed.
**To audit a Windows Defender Application Control policy with local policy:** ## Overview of the process to create WDAC policy to allow apps using audit events
1. Before you begin, find the *.bin policy file , for example, the DeviceGuardPolicy.bin. Copy the file to C:\\Windows\\System32\\CodeIntegrity.
2. On the computer you want to run in audit mode, open the Local Group Policy Editor by running **GPEdit.msc**.
> [!Note] > [!Note]
> > You must have already deployed a WDAC audit mode policy to use this process. If you have not already done so, see [Deploying Windows Defender Application Control policies](windows-defender-application-control-deployment-guide.md).
> - The computer that you will run in audit mode must be clean of viruses or malware. Otherwise, in the process that you follow after auditing the system, you might unintentionally merge in a policy that allows viruses or malware to run.
>
> - An alternative method to test a policy is to rename the test file to SIPolicy.p7b and drop it into C:\\Windows\\System32\\CodeIntegrity, rather than deploy it by using the Local Group Policy Editor.
3. Navigate to **Computer Configuration\\Administrative Templates\\System\\Device Guard**, and then select **Deploy Windows Defender Application Control**. Enable this setting by using the appropriate file path, for example, C:\\Windows\\System32\\CodeIntegrity\\DeviceGuardPolicy.bin, as shown in Figure 1. To familiarize yourself with creating WDAC rules from audit events, follow these steps on a device with a WDAC audit mode policy.
> [!Note] 1. Install and run an application not allowed by the WDAC policy but that you want to allow.
>
> - You can copy the WDAC policies to a file share to which all computer accounts have access rather than copy them to every system.
>
> - You might have noticed that the GPO setting references a .p7b file and this policy uses a .bin file. Regardless of the type of policy you deploy (.bin, .p7b, or .p7), they are all converted to SIPolicy.p7b when dropped onto the computers running Windows 10. We recommend that you make your WDAC policy names friendly and allow the system to convert the policy names for you. By doing this, it ensures that the policies are easily distinguishable when viewed in a share or any other central repository.
![Group Policy called Deploy Windows Defender Application Control](images/dg-fig22-deploycode.png) 2. Review the **CodeIntegrity - Operational** and **AppLocker - MSI and Script** event logs to confirm events, like those shown in Figure 1, are generated related to the application. For information about the types of events you should see, refer to [Understanding Application Control events](event-id-explanations.md).
Figure 1. Deploy your Windows Defender Application Control policy
4. Restart the reference system for the WDAC policy to take effect.
5. Use the system as you normally would, and monitor code integrity events in the event log. While in audit mode, any exception to the deployed WDAC policy will be logged in the **Applications and Services Logs\\Microsoft\\Windows\\CodeIntegrity\\Operational** event log, as shown in Figure 2.
**Figure 1. Exceptions to the deployed WDAC policy**
![Event showing exception to WDAC policy](images/dg-fig23-exceptionstocode.png) ![Event showing exception to WDAC policy](images/dg-fig23-exceptionstocode.png)
Figure 2. Exceptions to the deployed WDAC policy 3. In an elevated PowerShell session, run the following commands to initialize variables used by this procedure. This procedure builds upon the **Lamna_FullyManagedClients_Audit.xml** policy introduced in [Create a WDAC policy for fully managed devices](create-wdac-policy-for-fully-managed-devices.md) and will produce a new policy called **EventsPolicy.xml**.
You will be reviewing the exceptions that appear in the event log, and making a list of any applications that should be allowed to run in your environment. ```powershell
$PolicyName= "Lamna_FullyManagedClients_Audit"
$LamnaPolicy=$env:userprofile+"\Desktop\"+$PolicyName+".xml"
$EventsPolicy=$env:userprofile+"\Desktop\EventsPolicy.xml"
$EventsPolicyWarnings=$env:userprofile+"\Desktop\EventsPolicyWarnings.txt"
```
6. If you want to create a catalog file to simplify the process of including unsigned LOB applications in your WDAC policy, this is a good time to create it. For information, see [Deploy catalog files to support Windows Defender Application Control](deploy-catalog-files-to-support-windows-defender-application-control.md). 4. Use [New-CIPolicy](/powershell/module/configci/new-cipolicy) to generate a new WDAC policy from logged audit events. This example uses a **FilePublisher** file rule level and a **Hash** fallback level. Warning messages are redirected to a text file **EventsPolicyWarnings.txt**.
Now that you have a WDAC policy deployed in audit mode, you can capture any audit information that appears in the event log. This is described in the next section. ```powershell
New-CIPolicy -FilePath $EventsPolicy -Audit -Level FilePublisher -Fallback Hash –UserPEs -MultiplePolicyFormat 3> $EventsPolicyWarnings
## Create a Windows Defender Application Control policy that captures audit information from the event log ```
Use the following procedure after you have been running a computer with a WDAC policy in audit mode for a period of time. When you are ready to capture the needed policy information from the event log (so that you can later merge that information into the original WDAC policy), complete the following steps.
<!-- Watch the phrase "later step in this procedure" in step 1, in case the organization of the procedures changes. -->
1. Review the audit information in the event log. From the WDAC policy exceptions that you see, make a list of any applications that should be allowed to run in your environment, and decide on the file rule level that should be used to trust these applications.
Although the Hash file rule level will catch all of these exceptions, it may not be the best way to trust all of them. For information about file rule levels, see [Windows Defender Application Control file rule levels](select-types-of-rules-to-create.md) in "Deploy Windows Defender Application Control: policy rules and file rules."
Your event log might also contain exceptions for applications that you eventually want your WDAC policy to block. If these appear, make a list of these also, for a later step in this procedure.
2. In an elevated Windows PowerShell session, initialize the variables that will be used. The example filename shown here is **DeviceGuardAuditPolicy.xml**:
`$CIPolicyPath=$env:userprofile+"\Desktop\"`
`$CIAuditPolicy=$CIPolicyPath+"DeviceGuardAuditPolicy.xml"`
3. Use [New-CIPolicy](/powershell/module/configci/new-cipolicy) to generate a new WDAC policy from logged audit events. This example uses a file rule level of **Hash** and includes `3> CIPolicylog.txt`, which redirects warning messages to a text file, **CIPolicylog.txt**.
`New-CIPolicy -Audit -Level Hash -FilePath $CIAuditPolicy –UserPEs 3> CIPolicylog.txt`
> [!NOTE] > [!NOTE]
> When you create policies from audit events, you should carefully consider the file rule level that you select to trust. The preceding example uses the **Hash** rule level, which is the most specific. Any change to the file (such as replacing the file with a newer version of the same file) will change the Hash value, and require an update to the policy. > When you create policies from audit events, you should carefully consider the file rule level that you select to trust. The preceding example uses the **FilePublisher** rule level with a fallback level of **Hash**, which may be more specific than desired. You can re-run the above command using different **-Level** and **-Fallback** options to meet your needs. For more information about WDAC rule levels, see [Understand WDAC policy rules and file rules](select-types-of-rules-to-create.md).
4. Find and review the WDAC audit policy .xml file that you created. If you used the example variables as shown, the filename will be **DeviceGuardAuditPolicy.xml**, and it will be on your desktop. Look for the following: 5. Find and review the WDAC policy file **EventsPolicy.xml** that should be found on your desktop. Ensure that it only includes file and signer rules for applications, binaries, and scripts you wish to allow. You can remove rules by manually editing the policy XML or use the WDAC Policy Wizard tool (see [Editing existing base and supplemental WDAC policies with the Wizard](wdac-wizard-editing-policy.md)).
- Any applications that were caught as exceptions, but should be allowed to run in your environment. These are applications that should be in the .xml file. Leave these as-is in the file. 6. Find and review the text file **EventsPolicyWarnings.txt** that should be found on your desktop. This file will include a warning for any files that WDAC couldn't create a rule for at either the specified rule level or fallback rule level.
- Any applications that actually should not be allowed to run in your environment. Edit these out of the .xml file. If they remain in the .xml file, and the information in the file is merged into your existing WDAC policy, the policy will treat the applications as trusted, and allow them to run. > [!NOTE]
> New-CIPolicy only creates rules for files that can still be found on disk. Files which are no longer present on the system will not have a rule created to allow them. However, the event log should have sufficient information to allow these files by manually editing the policy XML to add rules. You can use an existing rule as a template and verify your results against the WDAC policy schema definition found at **%windir%\schemas\CodeIntegrity\cipolicy.xsd**.
You can now use this file to update the existing WDAC policy that you ran in audit mode by merging the two policies. For instructions on how to merge this audit policy with the existing WDAC policy, see the next section, [Merge Windows Defender Application Control policies](merge-windows-defender-application-control-policies.md). 7. Merge **EventsPolicy.xml** with the Base policy **Lamna_FullyManagedClients_Audit.xml** or convert it to a supplemental policy.
> [!Note] For information on merging policies, refer to [Merge Windows Defender Application Control policies](merge-windows-defender-application-control-policies.md) and for information on supplemental policies see [Use multiple Windows Defender Application Control Policies](deploy-multiple-windows-defender-application-control-policies.md).
> You may have noticed that you did not generate a binary version of this policy as you did in [Create a Windows Defender Application Control policy from a reference computer](./create-initial-default-policy.md). This is because WDAC policies created from an audit log are not intended to run as stand-alone policies but rather to update existing WDAC policies.
8. Convert the Base or Supplemental policy to binary and deploy using your preferred method.

10
windows/security/threat-protection/windows-defender-application-control/deploy-multiple-windows-defender-application-control-policies.md
View File

@ -11,7 +11,7 @@ ms.localizationpriority: medium
audience: ITPro audience: ITPro
ms.collection: M365-security-compliance ms.collection: M365-security-compliance
author: jsuther1974 author: jsuther1974
ms.reviewer: isbrahm ms.reviewer: jogeurte
ms.author: dansimp ms.author: dansimp
manager: dansimp manager: dansimp
ms.date: 11/13/2020 ms.date: 11/13/2020
@ -22,10 +22,10 @@ ms.technology: mde
**Applies to:** **Applies to:**
- Windows 10 - Windows 10 version 1903 and above
- Windows Server 2016 - Windows Server 2022 and above
The restriction of only having a single code integrity policy active on a system at any given time has felt limiting for customers in situations where multiple policies with different intents would be useful. Beginning with Windows 10 version 1903, WDAC supports up to 32 active policies on a device at once in order to enable the following scenarios: Prior to Windows 10 1903, WDAC only supported a single active on a system at any given time. This significantly limited customers in situations where multiple policies with different intents would be useful. Beginning with Windows 10 version 1903, WDAC supports up to 32 active policies on a device at once in order to enable the following scenarios:
1. Enforce and Audit Side-by-Side 1. Enforce and Audit Side-by-Side
- To validate policy changes before deploying in enforcement mode, users can now deploy an audit-mode base policy side by side with an existing enforcement-mode base policy - To validate policy changes before deploying in enforcement mode, users can now deploy an audit-mode base policy side by side with an existing enforcement-mode base policy
@ -49,7 +49,7 @@ The restriction of only having a single code integrity policy active on a system
## Creating WDAC policies in Multiple Policy Format ## Creating WDAC policies in Multiple Policy Format
In order to allow multiple policies to exist and take effect on a single system, policies must be created using the new Multiple Policy Format. The "MultiplePolicyFormat" switch in [New-CIPolicy](/powershell/module/configci/new-cipolicy?preserve-view=true&view=win10-ps) results in 1) random GUIDs being generated for the policy ID and 2) the policy type being specified as base. The below is an example of creating a new policy in the multiple policy format. In order to allow multiple policies to exist and take effect on a single system, policies must be created using the new Multiple Policy Format. The "MultiplePolicyFormat" switch in [New-CIPolicy](/powershell/module/configci/new-cipolicy?preserve-view=true&view=win10-ps) results in 1) unique GUIDs being generated for the policy ID and 2) the policy type being specified as base. The below is an example of creating a new policy in the multiple policy format.
```powershell ```powershell
New-CIPolicy -MultiplePolicyFormat -ScanPath "<path>" -UserPEs -FilePath ".\policy.xml" -Level Publisher -Fallback Hash New-CIPolicy -MultiplePolicyFormat -ScanPath "<path>" -UserPEs -FilePath ".\policy.xml" -Level Publisher -Fallback Hash

19
windows/security/threat-protection/windows-defender-application-control/deploy-windows-defender-application-control-policies-using-group-policy.md
View File

@ -11,7 +11,7 @@ ms.localizationpriority: medium
audience: ITPro audience: ITPro
ms.collection: M365-security-compliance ms.collection: M365-security-compliance
author: jsuther1974 author: jsuther1974
ms.reviewer: isbrahm ms.reviewer: jogeurte
ms.author: dansimp ms.author: dansimp
manager: dansimp manager: dansimp
ms.date: 02/28/2018 ms.date: 02/28/2018
@ -23,15 +23,12 @@ ms.technology: mde
**Applies to:** **Applies to:**
- Windows 10 - Windows 10
- Windows Server 2016 - Windows Server 2016 and above
WDAC policies can easily be deployed and managed with Group Policy. Windows Defender allows you to simplify deployment Windows Defender hardware-based security features and Windows Defender Application Control policies. The following procedure walks you through how to deploy a WDAC policy called **DeviceGuardPolicy.bin** to a test OU called *DG Enabled PCs* by using a GPO called **Contoso GPO Test**.
> [!NOTE] > [!NOTE]
> This walkthrough requires that you have previously created a WDAC policy and have a computer running Windows 10 on which to test a Group Policy deployment. For more information about how to create a WDAC policy, see [Create a Windows Defender Application Control policy from a reference computer](create-initial-default-policy.md), earlier in this topic. > Group Policy-based deployment of WDAC policies only supports single-policy format WDAC policies. To use WDAC on devices running Windows 10 1903 and greater, we recommend using an alternative method for policy deployment.
> [!NOTE] Single-policy format WDAC policies (pre-1903 policy schema) can be easily deployed and managed with Group Policy. The following procedure walks you through how to deploy a WDAC policy called **ContosoPolicy.bin** to a test OU called *WDAC Enabled PCs* by using a GPO called **Contoso GPO Test**.
> Signed WDAC policies can cause boot failures when deployed. We recommend that signed WDAC policies be thoroughly tested on each hardware platform before enterprise deployment.
To deploy and manage a WDAC policy with Group Policy: To deploy and manage a WDAC policy with Group Policy:
@ -52,9 +49,9 @@ To deploy and manage a WDAC policy with Group Policy:
![Edit the Group Policy for Windows Defender Application Control](images/wdac-edit-gp.png) ![Edit the Group Policy for Windows Defender Application Control](images/wdac-edit-gp.png)
6. In the **Deploy Windows Defender Application Control** dialog box, select the **Enabled** option, and then specify the code integrity policy deployment path. 6. In the **Deploy Windows Defender Application Control** dialog box, select the **Enabled** option, and then specify the WDAC policy deployment path.
In this policy setting, you specify either the local path in which the policy will exist on the client computer or a Universal Naming Convention (UNC) path that the client computers will look to retrieve the latest version of the policy. For example, with DeviceGuardPolicy.bin on the test computer, the example file path would be C:\\Windows\\System32\\CodeIntegrity\\DeviceGuardPolicy.bin. In this policy setting, you specify either the local path in which the policy will exist on the client computer or a Universal Naming Convention (UNC) path that the client computers will look to retrieve the latest version of the policy. For example, with ContosoPolicy.bin on the test computer, the example file path would be C:\\Windows\\System32\\CodeIntegrity\\ContosoPolicy.bin.
> [!NOTE] > [!NOTE]
> This policy file does not need to be copied to every computer. You can instead copy the WDAC policies to a file share to which all computer accounts have access. Any policy selected here is converted to SIPolicy.p7b when it is deployed to the individual client computers. > This policy file does not need to be copied to every computer. You can instead copy the WDAC policies to a file share to which all computer accounts have access. Any policy selected here is converted to SIPolicy.p7b when it is deployed to the individual client computers.
@ -62,6 +59,6 @@ To deploy and manage a WDAC policy with Group Policy:
![Group Policy called Deploy Windows Defender Application Control](images/dg-fig26-enablecode.png) ![Group Policy called Deploy Windows Defender Application Control](images/dg-fig26-enablecode.png)
> [!NOTE] > [!NOTE]
> You may have noticed that the GPO setting references a .p7b file and this example uses a .bin file for the policy. Regardless of the type of policy you deploy (.bin, .p7b, or .p7), they are all converted to SIPolicy.p7b when dropped on the client computer running Windows 10. Make your WDAC policies friendly and allow the system to convert the policy names for you to ensure that the policies are easily distinguishable when viewed in a share or any other central repository. > You may have noticed that the GPO setting references a .p7b file and this example uses a .bin file for the policy. Regardless of the type of policy you deploy (.bin, .p7b, or .p7), they are all converted to SIPolicy.p7b when dropped on the client computer running Windows 10. Give your WDAC policies friendly names and allow the system to convert the policy names for you to ensure that the policies are easily distinguishable when viewed in a share or any other central repository.
7. Close the Group Policy Management Editor, and then restart the Windows 10 test computer. Restarting the computer updates the WDAC policy. For information about how to audit WDAC policies, see [Audit Windows Defender Application Control policies](audit-windows-defender-application-control-policies.md). 7. Close the Group Policy Management Editor, and then restart the Windows 10 test computer. Restarting the computer updates the WDAC policy.

70
windows/security/threat-protection/windows-defender-application-control/deploy-windows-defender-application-control-policies-using-intune.md
View File

@ -1,6 +1,6 @@
--- ---
title: Deploy Windows Defender Application Control (WDAC) policies by using Microsoft Intune (Windows 10) title: Deploy WDAC policies using Mobile Device Management (MDM) (Windows 10)
description: You can use Microsoft Intune to configure Windows Defender Application Control (WDAC). Learn how with this step-by-step guide. description: You can use an MDM like Microsoft Intune to configure Windows Defender Application Control (WDAC). Learn how with this step-by-step guide.
keywords: security, malware keywords: security, malware
ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
ms.prod: m365-security ms.prod: m365-security
@ -18,54 +18,49 @@ ms.date: 04/29/2020
ms.technology: mde ms.technology: mde
--- ---
# Deploy Windows Defender Application Control policies by using Microsoft Intune # Deploy WDAC policies using Mobile Device Management (MDM)
**Applies to:** **Applies to:**
- Windows 10 - Windows 10
You can use Microsoft Endpoint Manager (MEM) Intune to configure Windows Defender Application Control (WDAC) on client machines. Intune includes native support for WDAC, which allows you to configure Windows 10 client computers to only run Windows components and Microsoft Store apps, or to also allow reputable apps as defined by the Intelligent Security Graph (ISG). Using the built-in policies can be a helpful starting point, but many customers may find the available circle-of-trust options to be too limited. In order to deploy a custom policy through Intune and define your own circle of trust, you can configure a profile using Custom OMA-URI. You can use a Mobile Device Management (MDM) solution, like Microsoft Endpoint Manager (MEM) Intune, to configure Windows Defender Application Control (WDAC) on client machines. Intune includes native support for WDAC which can be a helpful starting point, but customers may find the available circle-of-trust options too limiting. To deploy a custom policy through Intune and define your own circle of trust, you can configure a profile using Custom OMA-URI. If your organization uses another MDM solution, check with your solution provider for WDAC policy deployment steps.
## Using Intune's Built-In Policies ## Use Intune's built-in policies
Intune's built-in WDAC support enables you to deploy a policy which only allows Windows components and Microsoft Store apps to run. This policy is the non-Multiple Policy Format version of the DefaultWindows policy; the Multiple Policy Format version can be found at C:\Windows\schemas\CodeIntegrity\ExamplePolicies. Intune's built-in WDAC support allows you to configure Windows 10 client computers to only run:
Setting "Trust apps with good reputation" to enabled is equivalent to adding [Option 14 (Enabled: Intelligent Security Graph Authorization)](./select-types-of-rules-to-create.md#windows-defender-application-control-policy-rules) to the DefaultWindows policy. - Windows components
- 3rd party hardware and software kernel drivers
1. Open the Microsoft Intune portal and click **Device configuration** > **Profiles** > **Create profile**. - Microsoft Store-signed apps
- [Optional] Reputable apps as defined by the Intelligent Security Graph (ISG)
2. Type a name for the new profile, select **Windows 10 and later** as the **Platform** and **Endpoint protection** as the **Profile type**.
![Configure profile](images/wdac-intune-create-profile-name.png)
3. Click **Configure** > **Windows Defender Application Control**, choose from the following settings and then click **OK**:
- **Application control code integrity policies**: Select **Audit only** to log events but not block any apps from running or select **Enforce** to allow only Windows components and Store apps to run.
- **Trust apps with good reputation**: Select **Enable** to allow reputable apps as defined by the Intelligent Security Graph to run in addition to Windows components and Store apps.
![Configure built-in WDAC](images/wdac-intune-wdac-settings.png)
## Using a Custom OMA-URI Profile
> [!NOTE] > [!NOTE]
> Policies deployed through Intune Custom OMA-URI are subject to a 350,000 byte limit. Customers whose devices are running 1903+ builds of Windows are encouraged to use [multiple policies](deploy-multiple-windows-defender-application-control-policies.md) which are more streamlined and less than 350K bytes in size. > Intune's built-in policies use the pre-1903 single-policy format version of the DefaultWindows policy. You can use Intune's custom OMA-URI feature to deploy your own multiple-policy format WDAC policies and leverage features available on Windows 10 1903+ as described later in this topic.
### For 1903+ systems > [!NOTE]
> Intune currently uses the AppLocker CSP to deploy its built-in policies. The AppLocker CSP will always request a reboot when applying WDAC policies. You can use Intune's custom OMA-URI feature with the ApplicationControl CSP to deploy your own WDAC policies rebootlessly.
Beginning in 1903, Custom OMA-URI policy deployment leverages the [ApplicationControl CSP](/windows/client-management/mdm/applicationcontrol-csp), which has support for multiple policies and rebootless policies. To use Intune's built-in WDAC policies, configure [Endpoint Protection for Windows 10 (and later)](https://docs.microsoft.com/mem/intune/protect/endpoint-protection-windows-10?toc=/intune/configuration/toc.json&bc=/intune/configuration/breadcrumb/toc.json).
#### Deploying policies ## Deploy WDAC policies with custom OMA-URI
The steps to use Intune's Custom OMA-URI functionality are:
> [!NOTE]
> Policies deployed through Intune custom OMA-URI are subject to a 350,000 byte limit. Customers should create WDAC policies that use signature-based rules, the Intelligent Security Graph, and managed installers where practical. Customers whose devices are running 1903+ builds of Windows are also encouraged to use [multiple policies](deploy-multiple-windows-defender-application-control-policies.md) which allow more granular policy.
### Deploy custom WDAC policies on Windows 10 1903+
Beginning with Windows 10 1903, custom OMA-URI policy deployment can use the [ApplicationControl CSP](/windows/client-management/mdm/applicationcontrol-csp), which has support for multiple policies and rebootless policies.
The steps to use Intune's custom OMA-URI functionality are:
1. Know a generated policy's GUID, which can be found in the policy xml as `<PolicyID>` 1. Know a generated policy's GUID, which can be found in the policy xml as `<PolicyID>`
2. Convert the policy XML to binary format using the ConvertFrom-CIPolicy cmdlet in order to be deployed. The binary policy may be signed or unsigned. 2. Convert the policy XML to binary format using the ConvertFrom-CIPolicy cmdlet in order to be deployed. The binary policy may be signed or unsigned.
3. Open the Microsoft Intune portal and click **Device configuration** > **Profiles** > **Create profile**. 3. Open the Microsoft Intune portal and [create a profile with custom settings](/mem/intune/configuration/custom-settings-windows-10).
4. Type a name for the new profile, select **Windows 10 and later** as the **Platform** and **Custom** as the **Profile type**. 4. Specify a **Name** and **Description** and use the following values for the remaining custom OMA-URI settings:
5. Add a row, then give your policy a name and use the following settings:
- **OMA-URI**: ./Vendor/MSFT/ApplicationControl/Policies/_Policy GUID_/Policy - **OMA-URI**: ./Vendor/MSFT/ApplicationControl/Policies/_Policy GUID_/Policy
- **Data type**: Base64 - **Data type**: Base64
- **Certificate file**: upload your binary format policy file. You do not need to upload a Base64 file, as Intune will convert the uploaded .bin file to Base64 on your behalf. - **Certificate file**: upload your binary format policy file. You do not need to upload a Base64 file, as Intune will convert the uploaded .bin file to Base64 on your behalf.
@ -73,22 +68,21 @@ The steps to use Intune's Custom OMA-URI functionality are:
> [!div class="mx-imgBorder"] > [!div class="mx-imgBorder"]
> ![Configure custom WDAC](images/wdac-intune-custom-oma-uri.png) > ![Configure custom WDAC](images/wdac-intune-custom-oma-uri.png)
#### Removing policies ### Remove WDAC policies on Windows 10 1903+
Upon deletion, policies deployed through Intune via the ApplicationControl CSP are removed from the system but stay in effect until the next reboot. In order to functionally do a rebootless delete, first replace the existing policy with an Allow All policy (found at C:\Windows\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml) and then delete the updated policy. This will immediately prevent anything from being blocked and fully deactive the policy on the next reboot. Upon deletion, policies deployed through Intune via the ApplicationControl CSP are removed from the system but stay in effect until the next reboot. In order to disable WDAC enforcement, first replace the existing policy with a new version of the policy that will "Allow *", like the rules in the example policy at %windir%\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml. Once the updated policy is deployed, you can then delete the policy from the Intune portal. This will prevent anything from being blocked and fully remove the WDAC policy on the next reboot.
### For pre-1903 systems ### For pre-1903 systems
#### Deploying policies #### Deploying policies
The steps to use Intune's Custom OMA-URI functionality to leverage the [AppLocker CSP](/windows/client-management/mdm/applocker-csp) and deploy a custom WDAC policy to pre-1903 systems are: The steps to use Intune's Custom OMA-URI functionality to leverage the [AppLocker CSP](/windows/client-management/mdm/applocker-csp) and deploy a custom WDAC policy to pre-1903 systems are:
1. Convert the policy XML to binary format using the ConvertFrom-CIPolicy cmdlet in order to be deployed. The binary policy may be signed or unsigned. 1. Convert the policy XML to binary format using the ConvertFrom-CIPolicy cmdlet in order to be deployed. The binary policy may be signed or unsigned.
2. Open the Microsoft Intune portal and click **Device configuration** > **Profiles** > **Create profile**. 2. Open the Microsoft Intune portal and [create a profile with custom settings](/mem/intune/configuration/custom-settings-windows-10).
3. Type a name for the new profile, select **Windows 10 and later** as the **Platform** and **Custom** as the **Profile type**. 3. Specify a **Name** and **Description** and use the following values for the remaining custom OMA-URI settings:
4. Add a row, then give your policy a name and use the following settings:
- **OMA-URI**: ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/_Grouping_/CodeIntegrity/Policy) - **OMA-URI**: ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/_Grouping_/CodeIntegrity/Policy)
- **Data type**: Base64 - **Data type**: Base64
- **Certificate file**: upload your binary format policy file - **Certificate file**: upload your binary format policy file
@ -98,4 +92,4 @@ The steps to use Intune's Custom OMA-URI functionality to leverage the [AppLocke
#### Removing policies #### Removing policies
Policies deployed through Intune via the AppLocker CSP cannot be deleted through the Intune console. In order to disable WDAC policy enforcement, either deploy an audit-mode policy and/or use a script to delete the existing policy. Policies deployed through Intune via the AppLocker CSP cannot be deleted through the Intune console. In order to disable WDAC policy enforcement, either deploy an audit-mode policy or use a script to delete the existing policy.

42
windows/security/threat-protection/windows-defender-application-control/deployment/deploy-wdac-policies-with-memcm.md Normal file
View File

@ -0,0 +1,42 @@
---
title: Deploy Windows Defender Application Control (WDAC) policies by using Microsoft Endpoint Configuration Manager (MEMCM) (Windows 10)
description: You can use Microsoft Endpoint Configuration Manager (MEMCM) to configure Windows Defender Application Control (WDAC). Learn how with this step-by-step guide.
keywords: security, malware
ms.prod: m365-security
audience: ITPro
ms.collection: M365-security-compliance
author: jsuther1974
ms.reviewer: jogeurte
ms.author: jogeurte
ms.manager: jsuther
manager: dansimp
ms.date: 04/14/2021
ms.technology: mde
ms.topic: article
ms.localizationpriority: medium
---
# Deploy WDAC policies by using Microsoft Endpoint Configuration Manager (MEMCM)
**Applies to:**
- Windows 10
- Windows Server 2016 and above
You can use Microsoft Endpoint Configuration Manager (MEMCM) to configure Windows Defender Application Control (WDAC) on client machines.
## Use MEMCM's built-in policies
MEMCM includes native support for WDAC, which allows you to configure Windows 10 client computers with a policy that will only allow:
- Windows components
- Microsoft Store apps
- Apps installed by MEMCM (MEMCM self-configured as a managed installer)
- [Optional] Reputable apps as defined by the Intelligent Security Graph (ISG)
- [Optional] Apps and executables already installed in admin-definable folder locations that MEMCM will allow through a one-time scan during policy creation on managed endpoints.
For more information on using MEMCM's native WDAC policies, see [Windows Defender Application Control management with Configuration Manager](/mem/configmgr/protect/deploy-use/use-device-guard-with-configuration-manager)
## Deploy custom WDAC policies using Packages/Programs or Task Sequences
Using MEMCM's built-in policies can be a helpful starting point, but customers may find the available circle-of-trust options available in MEMCM too limiting. To define your own circle-of-trust, you can use MEMCM to deploy custom WDAC policies using [script-based deployment](deploy-wdac-policies-with-script.md) via Software Distribution Packages and Programs or Operating System Deployment Task Sequences.

56
windows/security/threat-protection/windows-defender-application-control/deployment/deploy-wdac-policies-with-script.md Normal file
View File

@ -0,0 +1,56 @@
---
title: Deploy Windows Defender Application Control (WDAC) policies using script (Windows 10)
description: Use scripts to deploy Windows Defender Application Control (WDAC) policies. Learn how with this step-by-step guide.
keywords: security, malware
ms.prod: m365-security
audience: ITPro
ms.collection: M365-security-compliance
author: jsuther1974
ms.reviewer: jogeurte
ms.author: jogeurte
ms.manager: jsuther
manager: dansimp
ms.date: 04/14/2021
ms.technology: mde
ms.topic: article
ms.localizationpriority: medium
---
# Deploy WDAC policies using script
**Applies to:**
- Windows 10
- Windows Server 2016 and above
This topic describes how to deploy Windows Defender Application Control (WDAC) policies using script. The instructions below use PowerShell but can work with any scripting host.
> [!NOTE]
> To use this procedure, download and distribute the [WDAC policy refresh tool](https://aka.ms/refreshpolicy) to all managed endpoints. Ensure your WDAC policies allow the WDAC policy refresh tool or use a managed installer to distribute the tool.
## Script-based deployment process for WDAC policy
1. Initialize the variables to be used by the script.
```powershell
# Policy binary files should be named as {GUID}.cip for multiple policy format files (where {GUID} = <PolicyId> from the Policy XML)
# Single policy format binaries should be named as SiPolicy.p7b.
$PolicyBinary = "<Path to policy binary file to deploy>"
$DestinationFolder = $env:windir+"\System32\CodeIntegrity\CIPolicies\Active\"
$RefreshPolicyTool = "<Path where RefreshPolicy.exe can be found from managed endpoints>"
```
2. Copy WDAC policy binary to the destination folder.
```powershell
cp $PolicyBinary $DestinationFolder
```
3. Repeat steps 1-2 as appropriate to deploy additional WDAC policies.
4. Run RefreshPolicy.exe to activate and refresh all WDAC policies on the managed endpoint.
```powershell
& $RefreshPolicyTool
```
5. If successful, you should see the message **Rebootless ConfigCI Policy Refreshing Succeeded!**

18
windows/security/threat-protection/windows-defender-application-control/example-wdac-base-policies.md
View File

@ -1,5 +1,5 @@
--- ---
title: Example WDAC base policies (Windows 10) title: Example Windows Defender Application Control (WDAC) base policies (Windows 10)
description: When creating a WDAC policy for an organization, start from one of the many available example base policies. description: When creating a WDAC policy for an organization, start from one of the many available example base policies.
keywords: security, malware keywords: security, malware
ms.topic: article ms.topic: article
@ -12,30 +12,30 @@ ms.localizationpriority: medium
audience: ITPro audience: ITPro
ms.collection: M365-security-compliance ms.collection: M365-security-compliance
author: jsuther1974 author: jsuther1974
ms.reviewer: isbrahm ms.reviewer: jogeurte
ms.author: dansimp ms.author: dansimp
manager: dansimp manager: dansimp
ms.date: 11/15/2019 ms.date: 11/15/2019
ms.technology: mde ms.technology: mde
--- ---
# Windows Defender Application Control example base policies # Windows Defender Application Control (WDAC) example base policies
**Applies to:** **Applies to:**
- Windows 10 - Windows 10
- Windows Server 2016 and above - Windows Server 2016 and above
When creating policies for use with Windows Defender Application Control (WDAC), it is recommended to start from an existing base policy and then add or remove rules to build your own custom policy XML files. Windows includes several example policies which can be used, or organizations which use the Device Guard Signing Service can download a starter policy from that service. When creating policies for use with Windows Defender Application Control (WDAC), start from an existing base policy and then add or remove rules to build your own custom policy. Windows includes several example policies that can be used, or organizations that use the Device Guard Signing Service can download a starter policy from that service.
## Example Base Policies ## Example Base Policies
| **Example Base Policy** | **Description** | **Where it can be found** | | **Example Base Policy** | **Description** | **Where it can be found** |
|----------------------------|---------------------------------------------------------------|--------| |----------------------------|---------------------------------------------------------------|--------|
| **DefaultWindows.xml** | This example policy is available in either audit or enforce mode. It includes the rules necessary to ensure that Windows, 3rd party hardware and software kernel drivers, and Windows Store apps will run. Used as the basis for all [Microsoft Endpoint Manager(MEM)](https://www.microsoft.com/microsoft-365/microsoft-endpoint-manager) policies. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies | | **DefaultWindows.xml** | This example policy is available in both audit and enforced mode. It includes rules to allow Windows, third-party hardware and software kernel drivers, and Windows Store apps. Used as the basis for all [Microsoft Endpoint Manager(MEM)](https://www.microsoft.com/microsoft-365/microsoft-endpoint-manager) policies. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies |
| **AllowMicrosoft.xml** | This example policy is available in audit mode. It includes the rules from DefaultWindows and adds rules to trust apps signed by the Microsoft product root certificate. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies | | **AllowMicrosoft.xml** | This example policy is available in audit mode. It includes the rules from DefaultWindows and adds rules to trust apps signed by the Microsoft product root certificate. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies |
| **AllowAll.xml** | This example policy is useful when creating a block list policy. All block policies should include rules allowing all other code to run and then add the DENY rules for your organization's needs. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies | | **AllowAll.xml** | This example policy is useful when creating a blocklist. All block policies should include rules allowing all other code to run and then add the DENY rules for your organization's needs. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies |
| **AllowAll_EnableHVCI.xml** | This example policy can be used to enable [memory integrity](/windows/security/threat-protection/device-guard/memory-integrity) (also known as hypervisor-protected code integrity) using WDAC. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies | | **AllowAll_EnableHVCI.xml** | This example policy can be used to enable [memory integrity](/windows/security/threat-protection/device-guard/memory-integrity) (also known as hypervisor-protected code integrity) using WDAC. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies |
| **DenyAllAudit.xml** | This example policy should only be deployed in audit mode and can be used to audit all binaries running on critical systems or to comply with regulatory requirements. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies | | **DenyAllAudit.xml** | Only deploy this example policy in audit mode to track all binaries running on critical systems or to meet regulatory requirements. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies |
| **Device Guard Signing Service (DGSS) DefaultPolicy.xml** | This example policy is available in audit mode. It includes the rules from DefaultWindows and adds rules to trust apps signed with your organization-specific certificates issued by the DGSS. | [DGSS in the Microsoft Store for Business](https://businessstore.microsoft.com/manage/settings/devices) | | **Device Guard Signing Service (DGSS) DefaultPolicy.xml** | This example policy is available in audit mode. It includes the rules from DefaultWindows and adds rules to trust apps signed with your organization-specific certificates issued by the DGSS. | [Device Guard Signing Service NuGet Package](https://www.nuget.org/packages/Microsoft.Acs.Dgss.Client) |
| **MEM Configuration Manager** | Customers who use MEM Configuration Manager (MEMCM), formerly known as System Center Configuration Manager, can deploy a policy to a device using MEMCM's built-in integration with WDAC and then copy the resulting policy XML to use as a custom base policy. | %OSDrive%\Windows\CCM\DeviceGuard on a managed endpoint | | **MEM Configuration Manager** | Customers who use MEM Configuration Manager (MEMCM) can deploy a policy with MEMCM's built-in WDAC integration, and then use the generated policy XML as an example base policy. | %OSDrive%\Windows\CCM\DeviceGuard on a managed endpoint |

BIN
windows/security/threat-protection/windows-defender-application-control/images/policyflow.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 70 KiB

46
windows/security/threat-protection/windows-defender-application-control/operations/known-issues.md Normal file
View File

@ -0,0 +1,46 @@
---
title: WDAC Admin Tips & Known Issues
description: WDAC Known Issues
keywords: security, malware
ms.prod: m365-security
audience: ITPro
ms.collection: M365-security-compliance
author: jsuther1974
ms.reviewer: jogeurte
ms.author: jogeurte
ms.manager: jsuther
manager: dansimp
ms.date: 04/14/2021
ms.technology: mde
ms.topic: article
ms.localizationpriority: medium
---
# WDAC Admin Tips & Known Issues
**Applies to:**
- Windows 10
- Windows Server 2016 and above
This topic covers tips and tricks for admins as well as known issues with WDAC.
Test this configuration in your lab before enabling it in production.
## .NET native images may generate false positive block events
In some cases, the code integrity logs where WDAC errors and warnings are written will contain error events for native images generated for .NET assemblies. Typically, native image blocks are functionally benign as a blocked native image will fallback to its corresponding assembly and .NET will regenerate the native image at its next scheduled maintenance window.
## MSI Installations launched directly from the internet are blocked by WDAC
Installing .msi files directly from the internet to a computer protected by WDAC will fail.
For example, this command will not work:
```code
msiexec –i https://download.microsoft.com/download/2/E/3/2E3A1E42-8F50-4396-9E7E-76209EA4F429/Windows10_Version_1511_ADMX.msi
```
As a workaround, download the MSI file and run it locally:
```code
msiexec –i c:\temp\Windows10_Version_1511_ADMX.msi
```

3
windows/security/threat-protection/windows-defender-application-control/plan-windows-defender-application-control-management.md
View File

@ -31,7 +31,6 @@ This topic describes the decisions you need to make to establish the processes f
The first step in implementing application control is to consider how your policies will be managed and maintained over time. Developing a process for managing WDAC policies helps assure that WDAC continues to effectively control how applications are allowed to run in your organization. The first step in implementing application control is to consider how your policies will be managed and maintained over time. Developing a process for managing WDAC policies helps assure that WDAC continues to effectively control how applications are allowed to run in your organization.
<!-- We should insert a diagram to show this visually -->
Most WDAC policies will evolve over time and proceed through a set of identifiable phases during their lifetime. Typically, these phases include: Most WDAC policies will evolve over time and proceed through a set of identifiable phases during their lifetime. Typically, these phases include:
1. [Define (or refine) the "circle-of-trust"](understand-windows-defender-application-control-policy-design-decisions.md) for the policy and build an audit mode version of the policy XML. In audit mode, block events are generated but files are not prevented from executing. 1. [Define (or refine) the "circle-of-trust"](understand-windows-defender-application-control-policy-design-decisions.md) for the policy and build an audit mode version of the policy XML. In audit mode, block events are generated but files are not prevented from executing.
@ -42,6 +41,8 @@ Most WDAC policies will evolve over time and proceed through a set of identifiab
6. Deploy the enforced mode policy to intended devices. We recommend using staged rollouts for enforced policies to detect and respond to issues before deploying the policy broadly. 6. Deploy the enforced mode policy to intended devices. We recommend using staged rollouts for enforced policies to detect and respond to issues before deploying the policy broadly.
7. Repeat steps 1-6 anytime the desired "circle-of-trust" changes. 7. Repeat steps 1-6 anytime the desired "circle-of-trust" changes.
![Recommended WDAC policy deployment process](images/policyflow.png)
### Keep WDAC policies in a source control or document management solution ### Keep WDAC policies in a source control or document management solution
To effectively manage WDAC policies, you should store and maintain your policy XML documents in a central repository that is accessible to everyone responsible for WDAC policy management. We recommend a source control solution such as [GitHub](https://github.com/) or a document management solution such as [Office 365 SharePoint](https://products.office.com/sharepoint/collaboration), which provide version control and allow you to specify metadata about the XML documents. To effectively manage WDAC policies, you should store and maintain your policy XML documents in a central repository that is accessible to everyone responsible for WDAC policy management. We recommend a source control solution such as [GitHub](https://github.com/) or a document management solution such as [Office 365 SharePoint](https://products.office.com/sharepoint/collaboration), which provide version control and allow you to specify metadata about the XML documents.

82
windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md
View File

@ -1,6 +1,6 @@
--- ---
title: Understand WDAC policy rules and file rules (Windows 10) title: Understand Windows Defender Application Control (WDAC) policy rules and file rules (Windows 10)
description: Learn how Windows Defender Application Control provides control over a computer running Windows 10 by using policies that include policy rules and file rules. description: Learn how WDAC policy rules and file rules can control your Windows 10 computers.
keywords: security, malware keywords: security, malware
ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
ms.prod: m365-security ms.prod: m365-security
@ -18,14 +18,14 @@ ms.date: 03/04/2020
ms.technology: mde ms.technology: mde
--- ---
# Understand WDAC policy rules and file rules # Understand Windows Defender Application Control (WDAC) policy rules and file rules
**Applies to:** **Applies to:**
- Windows 10 - Windows 10
- Windows Server 2016 and above - Windows Server 2016 and above
Windows Defender Application Control (WDAC) provides control over a computer running Windows 10 by using policies that specify whether a driver or application is trusted and can be run. A policy includes *policy rules* that control options such as audit mode or whether user mode code integrity (UMCI) is enabled in a WDAC policy, and *file rules* (or *file rule levels*) that specify the level at which applications will be identified and trusted. Windows Defender Application Control (WDAC) can control what runs on Windows 10 by setting policies that specify whether a driver or application is trusted. A policy includes *policy rules* that control options such as audit mode, and *file rules* (or *file rule levels*) that specify how applications are identified and trusted.
## Windows Defender Application Control policy rules ## Windows Defender Application Control policy rules
@ -35,7 +35,7 @@ To modify the policy rule options of an existing WDAC policy XML, use [Set-RuleO
`Set-RuleOption -FilePath <Path to policy XML> -Option 0` `Set-RuleOption -FilePath <Path to policy XML> -Option 0`
Note that a policy that was created without the `-UserPEs` option is empty of user mode executables, that is, applications. If you enable UMCI (Option 0) for such a policy and then attempt to run an application, Windows Defender Application Control will see that the application is not on its list (which is empty of applications), and respond. In audit mode, the response is logging an event, and in enforced mode, the response is blocking the application. To create a policy that includes user mode executables (applications), when you run `New-CIPolicy`, include the `-UserPEs` option. A policy created without the `-UserPEs` option has no rules for user mode code. If you enable UMCI (Option 0) for such a policy, WDAC will block all applications and even critical Windows user session code. In audit mode, WDAC simply logs an event, but when enforced, all user mode code will be blocked. To create a policy that includes user mode executables (applications), run `New-CIPolicy` with the `-UserPEs` option.
- To disable UMCI on an existing WDAC policy, delete rule option 0 by running the following command: - To disable UMCI on an existing WDAC policy, delete rule option 0 by running the following command:
@ -52,28 +52,28 @@ You can set several rule options within a WDAC policy. Table 1 describes each ru
|------------ | ----------- | |------------ | ----------- |
| **0 Enabled:UMCI** | WDAC policies restrict both kernel-mode and user-mode binaries. By default, only kernel-mode binaries are restricted. Enabling this rule option validates user mode executables and scripts. | | **0 Enabled:UMCI** | WDAC policies restrict both kernel-mode and user-mode binaries. By default, only kernel-mode binaries are restricted. Enabling this rule option validates user mode executables and scripts. |
| **1 Enabled:Boot Menu Protection** | This option is not currently supported. | | **1 Enabled:Boot Menu Protection** | This option is not currently supported. |
| **2 Required:WHQL** | By default, legacy drivers that are not Windows Hardware Quality Labs (WHQL) signed are allowed to execute. Enabling this rule requires that every executed driver is WHQL signed and removes legacy driver support. Going forward, every new Windows 10–compatible driver must be WHQL certified. | | **2 Required:WHQL** | By default, legacy drivers that are not Windows Hardware Quality Labs (WHQL) signed are allowed to execute. Enabling this rule requires that every executed driver is WHQL signed and removes legacy driver support. Kernel drivers built for Windows 10 should be WHQL certified. |
| **3 Enabled:Audit Mode (Default)** | Enables the execution of binaries outside of the WDAC policy but logs each occurrence in the CodeIntegrity event log, which can be used to update the existing policy before enforcement. To begin enforcing a WDAC policy, delete this option. | | **3 Enabled:Audit Mode (Default)** | Instructs WDAC to log information about applications, binaries, and scripts that would have been blocked if the policy was enforced. You can use this option to identify the potential impact of your WDAC policy, and use the audit events to refine the policy before enforcement. To enforce a WDAC policy, delete this option. |
| **4 Disabled:Flight Signing** | If enabled, WDAC policies will not trust flightroot-signed binaries. This would be used in the scenario in which organizations only want to run released binaries, not flighted builds. | | **4 Disabled:Flight Signing** | If enabled, WDAC policies will not trust flightroot-signed binaries. This option would be used by organizations that only want to run released binaries, not pre-release Windows builds. |
| **5 Enabled:Inherit Default Policy** | This option is reserved for future use and currently has no effect. | | **5 Enabled:Inherit Default Policy** | This option is reserved for future use and currently has no effect. |
| **6 Enabled:Unsigned System Integrity Policy (Default)** | Allows the policy to remain unsigned. When this option is removed, the policy must be signed and have UpdatePolicySigners added to the policy to enable future policy modifications. | | **6 Enabled:Unsigned System Integrity Policy (Default)** | Allows the policy to remain unsigned. When this option is removed, the policy must be signed and the certificates that are trusted for future policy updates must be identified in the UpdatePolicySigners section. |
| **7 Allowed:Debug Policy Augmented** | This option is not currently supported. | | **7 Allowed:Debug Policy Augmented** | This option is not currently supported. |
| **8 Required:EV Signers** | In addition to being WHQL signed, this rule requires that drivers must have been submitted by a partner that has an Extended Verification (EV) certificate. All future Windows 10 and later drivers will meet this requirement. | | **8 Required:EV Signers** | This rule requires that drivers must be WHQL signed and have been submitted by a partner with an Extended Verification (EV) certificate. All Windows 10 and later drivers will meet this requirement. |
| **9 Enabled:Advanced Boot Options Menu** | The F8 preboot menu is disabled by default for all WDAC policies. Setting this rule option allows the F8 menu to appear to physically present users. | | **9 Enabled:Advanced Boot Options Menu** | The F8 preboot menu is disabled by default for all WDAC policies. Setting this rule option allows the F8 menu to appear to physically present users. |
| **10 Enabled:Boot Audit on Failure** | Used when the WDAC policy is in enforcement mode. When a driver fails during startup, the WDAC policy will be placed in audit mode so that Windows will load. Administrators can validate the reason for the failure in the CodeIntegrity event log. | | **10 Enabled:Boot Audit on Failure** | Used when the WDAC policy is in enforcement mode. When a driver fails during startup, the WDAC policy will be placed in audit mode so that Windows will load. Administrators can validate the reason for the failure in the CodeIntegrity event log. |
| **11 Disabled:Script Enforcement** | This option disables script enforcement options. Unsigned PowerShell scripts and interactive PowerShell are no longer restricted to [Constrained Language Mode](/powershell/module/microsoft.powershell.core/about/about_language_modes). NOTE: This option is supported on 1709, 1803, and 1809 builds with the 2019 10C LCU or higher, as well as on devices with the Windows 10 May 2019 Update (1903) and higher. Using it on pre-1903 versions of Windows 10 without the 10C or later LCU is not supported and may have unintended results. | | **11 Disabled:Script Enforcement** | This option disables script enforcement options. Unsigned PowerShell scripts and interactive PowerShell are no longer restricted to [Constrained Language Mode](/powershell/module/microsoft.powershell.core/about/about_language_modes). NOTE: This option is supported on 1709, 1803, and 1809 builds with the 2019 10C LCU or higher, and on devices with the Windows 10 May 2019 Update (1903) and higher. Using it on versions of Windows 10 without the proper update may have unintended results. |
| **12 Required:Enforce Store Applications** | If this rule option is enabled, WDAC policies will also apply to Universal Windows applications. | | **12 Required:Enforce Store Applications** | If this rule option is enabled, WDAC policies will also apply to Universal Windows applications. |
| **13 Enabled:Managed Installer** | Use this option to automatically allow applications installed by a software distribution solution, such as Microsoft Endpoint Configuration Manager, that has been defined as a managed installer. | | **13 Enabled:Managed Installer** | Use this option to automatically allow applications installed by a managed installer. For more information, see [Authorize apps deployed with a WDAC managed installer](use-windows-defender-application-control-with-managed-installer.md) |
| **14 Enabled:Intelligent Security Graph Authorization** | Use this option to automatically allow applications with "known good" reputation as defined by Microsoft’s Intelligent Security Graph (ISG). | | **14 Enabled:Intelligent Security Graph Authorization** | Use this option to automatically allow applications with "known good" reputation as defined by Microsoft’s Intelligent Security Graph (ISG). |
| **15 Enabled:Invalidate EAs on Reboot** | When the Intelligent Security Graph option (14) is used, WDAC sets an extended file attribute that indicates that the file was authorized to run. This option will cause WDAC to periodically re-validate the reputation for files that were authorized by the ISG.| | **15 Enabled:Invalidate EAs on Reboot** | When the Intelligent Security Graph option (14) is used, WDAC sets an extended file attribute that indicates that the file was authorized to run. This option will cause WDAC to periodically revalidate the reputation for files that were authorized by the ISG.|
| **16 Enabled:Update Policy No Reboot** | Use this option to allow future WDAC policy updates to apply without requiring a system reboot. NOTE: This option is only supported on Windows 10, version 1709, and above.| | **16 Enabled:Update Policy No Reboot** | Use this option to allow future WDAC policy updates to apply without requiring a system reboot. NOTE: This option is only supported on Windows 10, version 1709, and above.|
| **17 Enabled:Allow Supplemental Policies** | Use this option on a base policy to allow supplemental policies to expand it. NOTE: This option is only supported on Windows 10, version 1903, and above. | | **17 Enabled:Allow Supplemental Policies** | Use this option on a base policy to allow supplemental policies to expand it. NOTE: This option is only supported on Windows 10, version 1903, and above. |
| **18 Disabled:Runtime FilePath Rule Protection** | Disable default FilePath rule protection (apps and executables allowed based on file path rules must come from a file path that’s only writable by an administrator) for any FileRule that allows a file based on FilePath. NOTE: This option is only supported on Windows 10, version 1903, and above. | | **18 Disabled:Runtime FilePath Rule Protection** | This option disables the default runtime check that only allows FilePath rules for paths that are only writable by an administrator. NOTE: This option is only supported on Windows 10, version 1903, and above. |
| **19 Enabled:Dynamic Code Security** | Enables policy enforcement for .NET applications and dynamically-loaded libraries. NOTE: This option is only supported on Windows 10, version 1803, and above. | | **19 Enabled:Dynamic Code Security** | Enables policy enforcement for .NET applications and dynamically loaded libraries. NOTE: This option is only supported on Windows 10, version 1803, and above. |
## Windows Defender Application Control file rule levels ## Windows Defender Application Control file rule levels
File rule levels allow administrators to specify the level at which they want to trust their applications. This level of trust could be as fine-tuned as the hash of each binary or as general as a CA certificate. You specify file rule levels both when you create a new WDAC policy from a scan and when you create a policy from audit events. In addition, to combine rule levels found in multiple policies, you can merge the policies. When merged, WDAC policies combine their file rules, so that any application that would be allowed by either of the original policies will be allowed by the combined policy. File rule levels allow administrators to specify the level at which they want to trust their applications. This level of trust could be as granular as the hash of each binary or as general as a CA certificate. You specify file rule levels when using WDAC PowerShell cmdlets to create and modify policies.
Each file rule level has its benefit and disadvantage. Use Table 2 to select the appropriate protection level for your available administrative resources and Windows Defender Application Control deployment scenario. Each file rule level has its benefit and disadvantage. Use Table 2 to select the appropriate protection level for your available administrative resources and Windows Defender Application Control deployment scenario.
@ -81,18 +81,18 @@ Each file rule level has its benefit and disadvantage. Use Table 2 to select the
| Rule level | Description | | Rule level | Description |
|----------- | ----------- | |----------- | ----------- |
| **Hash** | Specifies individual hash values for each discovered binary. Although this level is specific, it can cause additional administrative overhead to maintain the current product versions’ hash values. Each time a binary is updated, the hash value changes, therefore requiring a policy update. | | **Hash** | Specifies individual hash values for each discovered binary. This is the most specific level and requires additional effort to maintain the current product versions’ hash values. Each time a binary is updated, the hash value changes, therefore requiring a policy update. |
| **FileName** | Specifies individual binary file names. Although the hash values for an application are modified when updated, the file names are typically not. This offers less specific security than the hash level but does not typically require a policy update when any binary is modified. | | **FileName** | Specifies the original filename for each binary. Although the hash values for an application are modified when updated, the file names are typically not. This level offers less specific security than the hash level but does not typically require a policy update when any binary is modified. |
| **FilePath** | Beginning with Windows 10 version 1903, this specifies rules that allow execution of binaries contained under specific file path locations. Additional information about FilePath level rules can be found below. | | **FilePath** | Beginning with Windows 10 version 1903, this level allows binaries to run from specific file path locations. Additional information about FilePath level rules can be found below. |
| **SignedVersion** | This combines the publisher rule with a version number. This option allows anything from the specified publisher, with a version at or above the specified version number, to run. | | **SignedVersion** | This level combines the publisher rule with a version number and allows anything to run from the specified publisher with a version at or above the specified version number. |
| **Publisher** | This is a combination of the PcaCertificate level (typically one certificate below the root) and the common name (CN) of the leaf certificate. This rule level allows organizations to trust a certificate from a major CA (such as Symantec), but only if the leaf certificate is from a specific company (such as Intel, for device drivers). | | **Publisher** | This level combines the PcaCertificate level (typically one certificate below the root) and the common name (CN) of the leaf certificate. You can use this rule level to trust a certificate issued by a particular CA and issued to a specific company you trust (such as Intel, for device drivers). |
| **FilePublisher** | This is a combination of the “FileName” attribute of the signed file, plus “Publisher” (PCA certificate with CN of leaf), plus a minimum version number. This option trusts specific files from the specified publisher, with a version at or above the specified version number. | | **FilePublisher** | This level combines the “FileName” attribute of the signed file, plus “Publisher” (PCA certificate with CN of leaf), plus a minimum version number. This option trusts specific files from the specified publisher, with a version at or above the specified version number. |
| **LeafCertificate** | Adds trusted signers at the individual signing certificate level. The benefit of using this level versus the individual hash level is that new versions of the product will have different hash values but typically the same signing certificate. Using this level, no policy update would be needed to run the new version of the application. However, leaf certificates have much shorter validity periods than CA certificates, so additional administrative overhead is associated with updating the WDAC policy when these certificates expire. | | **LeafCertificate** | Adds trusted signers at the individual signing certificate level. The benefit of using this level versus the individual hash level is that new versions of the product will have different hash values but typically the same signing certificate. Using this level, no policy update would be needed to run the new version of the application. However, leaf certificates have much shorter validity periods than other certificate levels, so the WDAC policy must be updated whenever these certificates change. |
| **PcaCertificate** | Adds the highest available certificate in the provided certificate chain to signers. This is typically one certificate below the root certificate, because the scan does not validate anything beyond the certificates included in the provided signature (it does not go online or check local root stores). | | **PcaCertificate** | Adds the highest available certificate in the provided certificate chain to signers. This level is typically one certificate below the root certificate, because the scan does not validate anything beyond the certificates included in the provided signature (it does not go online or check local root stores). |
| **RootCertificate** | Currently unsupported. | | **RootCertificate** | Currently unsupported. |
| **WHQL** | Trusts binaries if they have been validated and signed by WHQL. This is primarily for kernel binaries. | | **WHQL** | Trusts binaries if they have been validated and signed by WHQL. This level is primarily for kernel binaries. |
| **WHQLPublisher** | This is a combination of the WHQL and the CN on the leaf certificate and is primarily for kernel binaries. | | **WHQLPublisher** | This level combines the WHQL level and the CN on the leaf certificate and is primarily for kernel binaries. |
| **WHQLFilePublisher** | Specifies that the binaries are validated and signed by WHQL, with a specific publisher (WHQLPublisher), and that the binary is the specified version or newer. This is primarily for kernel binaries. | | **WHQLFilePublisher** | Specifies that the binaries are validated and signed by WHQL, with a specific publisher (WHQLPublisher), and that the binary is the specified version or newer. This level is primarily for kernel binaries. |
> [!NOTE] > [!NOTE]
> When you create WDAC policies with [New-CIPolicy](/powershell/module/configci/new-cipolicy), you can specify a primary file rule level by including the **-Level** parameter. For discovered binaries that cannot be trusted based on the primary file rule criteria, use the **-Fallback** parameter. For example, if the primary file rule level is PCACertificate but you would like to trust the unsigned applications as well, using the Hash rule level as a fallback adds the hash values of binaries that did not have a signing certificate. > When you create WDAC policies with [New-CIPolicy](/powershell/module/configci/new-cipolicy), you can specify a primary file rule level by including the **-Level** parameter. For discovered binaries that cannot be trusted based on the primary file rule criteria, use the **-Fallback** parameter. For example, if the primary file rule level is PCACertificate but you would like to trust the unsigned applications as well, using the Hash rule level as a fallback adds the hash values of binaries that did not have a signing certificate.
@ -102,37 +102,35 @@ Each file rule level has its benefit and disadvantage. Use Table 2 to select the
## Example of file rule levels in use ## Example of file rule levels in use
For example, consider some IT professionals in a department that runs many servers. They decide they want their servers to run only software signed by the providers of their software and drivers, that is, the companies that provide their hardware, operating system, antivirus, and other important software. They know that their servers also run an internally written application that is unsigned but is rarely updated. They want to allow this application to run. For example, consider an IT professional in a department that runs many servers. They only want to run software signed by the companies that provide their hardware, operating system, antivirus, and other important software. They know that their servers also run an internally written application that is unsigned but is rarely updated. They want to allow this application to run.
To create the WDAC policy, they build a reference server on their standard hardware, and install all of the software that their servers are known to run. Then they run [New-CIPolicy](/powershell/module/configci/new-cipolicy) with **-Level Publisher** (to allow software from their software providers, the "Publishers") and **-Fallback Hash** (to allow the internal, unsigned application). They enable the policy in auditing mode and gather information about any necessary software that was not included on the reference server. They merge WDAC policies into the original policy to allow that additional software to run. Then they enable the WDAC policy in enforced mode for their servers. To create the WDAC policy, they build a reference server on their standard hardware, and install all of the software that their servers are known to run. Then they run [New-CIPolicy](/powershell/module/configci/new-cipolicy) with **-Level Publisher** (to allow software from their software providers, the "Publishers") and **-Fallback Hash** (to allow the internal, unsigned application). They deploy the policy in auditing mode to determine the potential impact from enforcing the policy. Using the audit data, they update their WDAC policies to include any additional software they want to run. Then they enable the WDAC policy in enforced mode for their servers.
As part of normal operations, they will eventually install software updates, or perhaps add software from the same software providers. Because the "Publisher" remains the same on those updates and software, they will not need to update their WDAC policy. If they come to a time when the internally-written, unsigned application must be updated, they must also update the WDAC policy so that the hash in the policy matches the hash of the updated internal application. As part of normal operations, they will eventually install software updates, or perhaps add software from the same software providers. Because the "Publisher" remains the same on those updates and software, they will not need to update their WDAC policy. If the unsigned, internal application is updated, they must also update the WDAC policy to allow the new version.
They could also choose to create a catalog that captures information about the unsigned internal application, then sign and distribute the catalog. Then the internal application could be handled by WDAC policies in the same way as any other signed application. An update to the internal application would only require that the catalog be regenerated, signed, and distributed (no restarts would be required).
## More information about filepath rules ## More information about filepath rules
Filepath rules do not provide the same security guarantees that explicit signer rules do, as they are based on mutable access permissions. Filepath rules are best suited for environments where most users are running as standard rather than admin. IT Pros should take care while crafting path rules to allow paths that they know are likely to remain to be admin-writeable only and deny execution from sub-directories where standard users can modify ACLs on the folder. Filepath rules do not provide the same security guarantees that explicit signer rules do, as they are based on mutable access permissions. Filepath rules are best suited for environments where most users are running as standard rather than admin. Path rules are best suited to allow paths that you expect will remain admin-writeable only. You may want to avoid path rules for directories where standard users can modify ACLs on the folder.
By default, WDAC performs a user-writeability check at runtime which ensures that the current permissions on the specified filepath and its parent directories (recursively) do not allow standard users write access. By default, WDAC performs a user-writeability check at runtime that ensures that the current permissions on the specified filepath and its parent directories (recursively) do not allow standard users write access.
There is a defined list of SIDs which WDAC recognizes as admins. If a filepath allows write permissions for any SID not in this list, the filepath is considered to be user-writeable even if the additional SID is associated to a custom admin user. To handle these special cases, you can override WDAC's runtime admin-writeable check with the **Disabled:Runtime FilePath Rule Protection** option described above. There is a defined list of SIDs which WDAC recognizes as admins. If a filepath allows write permissions for any SID not in this list, the filepath is considered to be user-writeable even if the SID is associated to a custom admin user. To handle these special cases, you can override WDAC's runtime admin-writeable check with the **Disabled:Runtime FilePath Rule Protection** option described above.
WDAC's list of well-known admin SIDs are:
WDAC's list of well-known admin SIDs are: <br>
S-1-3-0; S-1-5-18; S-1-5-19; S-1-5-20; S-1-5-32-544; S-1-5-32-549; S-1-5-32-550; S-1-5-32-551; S-1-5-32-577; S-1-5-32-559; S-1-5-32-568; S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394; S-1-15-2-95739096-486727260-2033287795-3853587803-1685597119-444378811-2746676523. S-1-3-0; S-1-5-18; S-1-5-19; S-1-5-20; S-1-5-32-544; S-1-5-32-549; S-1-5-32-550; S-1-5-32-551; S-1-5-32-577; S-1-5-32-559; S-1-5-32-568; S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394; S-1-15-2-95739096-486727260-2033287795-3853587803-1685597119-444378811-2746676523.
When generating filepath rules using [New-CIPolicy](/powershell/module/configci/new-cipolicy), a unique, fully-qualified path rule is generated for every file discovered in the scanned path(s). To create rules that instead allow all files under a specified folder path, use [New-CIPolicyRule](/powershell/module/configci/new-cipolicyrule) to define rules containing wildcards using the [-FilePathRules](/powershell/module/configci/new-cipolicyrule#parameters) switch. When generating filepath rules using [New-CIPolicy](/powershell/module/configci/new-cipolicy), a unique, fully qualified path rule is generated for every file discovered in the scanned path(s). To create rules that instead allow all files under a specified folder path, use [New-CIPolicyRule](/powershell/module/configci/new-cipolicyrule) to define rules containing wildcards using the [-FilePathRules](/powershell/module/configci/new-cipolicyrule#parameters) switch.
Wildcards can be used at the beginning or end of a path rule; only one wildcard is allowed per path rule. Wildcards placed at the end of a path authorize all files in that path and its subdirectories recursively (ex. `C:\\*` would include `C:\foo\\*` ). Wildcards placed at the beginning of a path will allow the exact specified filename under any path (ex. `*\bar.exe` would allow `C:\bar.exe` and `C:\foo\bar.exe`). Wildcards in the middle of a path are not supported (ex. `C:\\*\foo.exe`). Without a wildcard, the rule will allow only a specific file (ex. `C:\foo\bar.exe`). <br/> The use of macros is also supported and useful in scenarios where the system drive is different from the `C:\` drive. Supported macros: `%OSDRIVE%`, `%WINDIR%`, `%SYSTEM32%`. Wildcards can be used at the beginning or end of a path rule; only one wildcard is allowed per path rule. Wildcards placed at the end of a path authorize all files in that path and its subdirectories recursively (ex. `C:\*` would include `C:\foo\*` ). Wildcards placed at the beginning of a path will allow the exact specified filename under any path (ex. `*\bar.exe` would allow `C:\bar.exe` and `C:\foo\bar.exe`). Wildcards in the middle of a path are not supported (ex. `C:\*\foo.exe`). Without a wildcard, the rule will allow only a specific file (ex. `C:\foo\bar.exe`).
> [!NOTE] You can also use the following macros when the exact volume may vary: `%OSDRIVE%`, `%WINDIR%`, `%SYSTEM32%`.
> Due to an existing bug, you can not combine Path-based ALLOW rules with any DENY rules in a single policy. Instead, either separate DENY rules into a separate Base policy or move the Path-based ALLOW rules into a supplemental policy as described in [Deploy multiple WDAC policies.](deploy-multiple-windows-defender-application-control-policies.md)
## Windows Defender Application Control filename rules ## Windows Defender Application Control filename rules
File name rule levels provide administrators to specify the file attributes off which to base a file name rule. File name rules provide the same security guarantees that explicit signer rules do, as they are based on non-mutable file attributes. Specification of the file name level occurs when creating new policy rules. In addition, to combine file name levels found in multiple policies, you can merge multiple policies. File name rule levels let you specify file attributes to base a rule on. File name rules provide the same security guarantees that explicit signer rules do, as they are based on non-mutable file attributes. Specification of the file name level occurs when creating new policy rules.
Use Table 3 to select the appropriate file name level for your available administrative resources and Windows Defender Application Control deployment scenario. For instance, an LOB or production application and its binaries (eg. DLLs) may all share the same product name. This allows users to easily create targeted policies based on the Product Name filename rule level. Use Table 3 to select the appropriate file name level for your use cases. For instance, an LOB or production application and its binaries may all share the same product name. This option lets you easily create targeted policies based on the Product Name filename rule level.
**Table 3. Windows Defender Application Control policy - filename levels** **Table 3. Windows Defender Application Control policy - filename levels**

32
windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-intelligent-security-graph.md
View File

@ -25,33 +25,31 @@ ms.technology: mde
- Windows 10 - Windows 10
- Windows Server 2016 and above - Windows Server 2016 and above
Application execution control can be difficult to implement in enterprises that do not have processes to effectively control the deployment of applications centrally through an IT managed system. In such environments, users are empowered to acquire the applications they need for work, making accounting for all the applications that would need to be authorized for execution control a daunting task. Application control can be difficult to implement in organizations that don't deploy and manage applications through an IT-managed system. In such environments, users can acquire the applications they want to use for work, making it hard to build an effective application control policy.
Windows 10, version 1709 (also known as the Windows 10 Fall Creators Update) provides a new option, known as the Microsoft Intelligent Security Graph authorization, that allows IT administrators to automatically authorize applications that the Microsoft Intelligent Security Graph recognizes as having known good reputation. The Microsoft Intelligent Security Graph option helps IT organizations take a significant first step towards going from having no application control at all to a simple means of preventing the execution of unknown and known bad software. To learn more about the Microsoft Intelligent Security Graph, see the Security section in [Major services and features in Microsoft Graph](/graph/overview-major-services). Beginning with Windows 10, version 1709, you can set an option to automatically allow applications that the Microsoft Intelligent Security Graph recognizes as having known good reputation. The ISG option helps organizations begin to implement application control even when the organization has limited control over their app ecosystem. To learn more about the Microsoft Intelligent Security Graph, see the Security section in [Major services and features in Microsoft Graph](/graph/overview-major-services).
## How does the integration between WDAC and the Intelligent Security Graph work? ## How does the integration between WDAC and the Intelligent Security Graph work?
The Microsoft Intelligent Security Graph relies on the same vast security intelligence and machine learning analytics which power Microsoft Defender SmartScreen and Microsoft Defender Antivirus to help classify applications as having known good, known bad, or unknown reputation. When an unevaluated file is run on a system with WDAC enabled with the Microsoft Intelligent Security Graph authorization option specified, WDAC queries the file's reputation by sending its hash and signing information to the cloud. If the Microsoft Intelligent Security Graph determines that the file has a known good reputation, the $KERNEL.SMARTLOCKER.ORIGINCLAIM kernel Extended Attribute (EA) is written to the file. Every time the file tries to execute, if there are no explicit deny rules present for the file, it will be allowed to run based on its positive reputation. Conversely, a file that has unknown or known bad reputation will still be allowed to run in the presence of a rule that explicitly allows the file. The ISG uses the same vast security intelligence and machine learning analytics that power Microsoft Defender SmartScreen and Microsoft Defender Antivirus to help classify applications as having known good, known bad, or unknown reputation. When a binary runs on a system with WDAC enabled with the ISG option, WDAC checks the file's reputation by sending its hash and signing information to the cloud. If the ISG reports that the file has a known good reputation, the $KERNEL.SMARTLOCKER.ORIGINCLAIM kernel Extended Attribute (EA) is written to the file. Every time the binary runs, it is allowed based on its positive reputation unless there is an explicit deny rule set in the WDAC policy. Conversely, a file that has unknown or known bad reputation will be allowed if your WDAC policy explicitly allows it.
Additionally, an application installer which is determined to have known good reputation will pass along that positive reputation to any files that it writes. This way, all the files needed to install and run an app are granted positive reputation data. If the file with good reputation is an application installer, its reputation will pass along to any files that it writes to disk. This way, all the files needed to install and run an app inherit the positive reputation data from the installer.
WDAC periodically re-queries the reputation data on a file. Additionally, enterprises can specify that any cached reputation results are flushed on reboot by using the **Enabled:Invalidate EAs on Reboot** option. WDAC periodically re-queries the reputation data on a file. Additionally, enterprises can specify that any cached reputation results are flushed on reboot by using the **Enabled:Invalidate EAs on Reboot** option.
>[!NOTE] >[!NOTE]
>Admins should make sure there is a WDAC policy in place to allow the system to boot and run any other authorized applications that may not be classified as being known good by the Intelligent Security Graph, such as custom line-of-business (LOB) apps. Since the Intelligent Security Graph is powered by global prevalence data, internal LOB apps may not be recognized as being known good. Other mechanisms like managed installer and explicit rules will help cover internal applications. Both Microsoft Endpoint Manager Configuration Manager (MEMCM) and Microsoft Endpoint Manager Intune (MEM Intune) can be used to create and push a WDAC policy to your client machines. >Admins should make sure there is a WDAC policy in place to allow the system to boot and run any other authorized applications that may not be classified as being known good by the Intelligent Security Graph, such as custom line-of-business (LOB) apps. Since the Intelligent Security Graph is powered by global prevalence data, internal LOB apps may not be recognized as being known good. Other mechanisms like managed installer and explicit rules will help cover internal applications. Both Microsoft Endpoint Manager Configuration Manager (MEMCM) and Microsoft Endpoint Manager Intune (MEM Intune) can be used to create and push a WDAC policy to your client machines.
Other examples of WDAC policies are available in `C:\Windows\schemas\CodeIntegrity\ExamplePolicies` and can help authorize Windows OS components, WHQL signed drivers and all Store apps. Admins can reference and customize them as needed for their Windows Defender Application Control deployment or [create a custom WDAC policy](./create-initial-default-policy.md).
## Configuring Intelligent Security Graph authorization for Windows Defender Application Control ## Configuring Intelligent Security Graph authorization for Windows Defender Application Control
Setting up the Microsoft Intelligent Security Graph authorization is easy regardless of what management solution you use. Configuring the Microsoft Intelligent Security Graph option involves these basic steps: Setting up the ISG is easy using any management solution you wish. Configuring the Microsoft Intelligent Security Graph option involves these basic steps:
- [Ensure that the Microsoft Intelligent Security Graph option is enabled in the WDAC policy XML](#ensure-that-the-intelligent-security-graph-option-is-enabled-in-the-wdac-policy-xml) - [Ensure that the Microsoft Intelligent Security Graph option is enabled in the WDAC policy XML](#ensure-that-the-intelligent-security-graph-option-is-enabled-in-the-wdac-policy-xml)
- [Enable the necessary services to allow WDAC to use the Microsoft Intelligent Security Graph correctly on the client](#enable-the-necessary-services-to-allow-wdac-to-use-the-isg-correctly-on-the-client) - [Enable the necessary services to allow WDAC to use the Microsoft Intelligent Security Graph correctly on the client](#enable-the-necessary-services-to-allow-wdac-to-use-the-isg-correctly-on-the-client)
### Ensure that the Intelligent Security Graph option is enabled in the WDAC policy XML ### Ensure that the Intelligent Security Graph option is enabled in the WDAC policy XML
In order to enable trust for executables based on classifications in the Microsoft Intelligent Security Graph, the **Enabled:Intelligent Security Graph authorization** option must be specified in the WDAC policy. This can be done with the Set-RuleOption cmdlet. In addition, it is recommended from a security perspective to also enable the **Enabled:Invalidate EAs on Reboot** option to invalidate the cached Intelligent Security Graph results on reboot to force rechecking of applications against the Microsoft Intelligent Security Graph. Caution is advised if devices will regularly transition to and from environments that may not be able to access the Microsoft Intelligent Security Graph. The following example shows both options being set. To allow apps and binaries based on the Microsoft Intelligent Security Graph, the **Enabled:Intelligent Security Graph authorization** option must be specified in the WDAC policy. This step can be done with the Set-RuleOption cmdlet. You should also enable the **Enabled:Invalidate EAs on Reboot** option so that ISG results are verified again after each reboot. The ISG option is not recommended for devices that don't have regular access to the internet. The following example shows both options being set.
```code ```code
<Rules> <Rules>
@ -81,29 +79,27 @@ In order to enable trust for executables based on classifications in the Microso
### Enable the necessary services to allow WDAC to use the ISG correctly on the client ### Enable the necessary services to allow WDAC to use the ISG correctly on the client
In order for the heuristics used by the Microsoft Intelligent Security Graph to function properly, a number of component in Windows must be enabled. The easiest way to do this is to run the appidtel executable in `c:\windows\system32`. In order for the heuristics used by the ISG to function properly, a number of components in Windows must be enabled. You can configure these components by running the appidtel executable in `c:\windows\system32`.
``` ```
appidtel start appidtel start
``` ```
This step is not required for WDAC policies deployed over MDM using the AppLocker CSP, as the CSP will enable the necessary components. This step is also not required when enabling the Microsoft Intelligent Security Graph through the MEMCM WDAC UX. However, if custom policies are being deployed outside of the WDAC UX through MEMCM, then this step is required. This step isn't required for WDAC policies deployed over MDM, as the CSP will enable the necessary components. This step is also not required when the ISG is configured using MEMCM's WDAC integration.
## Security considerations with the Intelligent Security Graph ## Security considerations with the Intelligent Security Graph
Since the Microsoft Intelligent Security Graph is a heuristic-based mechanism, it does not provide the same security guarantees that explicit allow or deny rules do. It is best suited for deployment to systems where each user is configured as a standard user and there are other monitoring systems in place like Microsoft Defender for Endpoint to help provide optics into what users are doing. Since the Microsoft Intelligent Security Graph is a heuristic-based mechanism, it doesn't provide the same security guarantees that explicit allow or deny rules do. It's best suited where users operate with standard user rights and where a security monitoring solution like Microsoft Defender for Endpoint is used.
Users with administrator privileges or malware running as an administrator user on the system may be able to circumvent the intent of WDAC when the Microsoft Intelligent Security Graph option is allowed by circumventing or corrupting the heuristics used to assign reputation to application executables. The Microsoft Intelligent Security Graph option uses the same heuristic tracking as managed installer and so for application installers that include an option to automatically run the application at the end of the installation process the heuristic may over-authorize. Processes running with kernel privileges can circumvent WDAC by setting the ISG extended file attribute to make a binary appear to have known good reputation. Also, since the ISG option passes along reputation from application installers to the binaries they write to disk, it can over-authorize files in some cases where the installer launches the application upon completion.
## Known limitations with using the Intelligent Security Graph ## Known limitations with using the Intelligent Security Graph
Since the Microsoft Intelligent Security Graph relies on identifying executables as being known good, there are cases where it may classify legitimate executables as unknown, leading to blocks that need to be resolved either with a rule in the WDAC policy, a catalog signed by a certificate trusted in the WDAC policy or by deployment through a WDAC managed installer. Typically, this is due to an installer or application using a dynamic file as part of execution. These files do not tend to build up known good reputation. Auto-updating applications have also been observed using this mechanism and may be flagged by the ISG. Since the ISG only allows binaries that are known good, there are cases where legitimate software may be unknown to the ISG and will be blocked by WDAC. In this case, you need to allow the software with a rule in your WDAC policy, deploy a catalog signed by a certificate trusted in the WDAC policy, or install the software from a WDAC managed installer. Installers or applications that dynamically create binaries at runtime, as well as self-updating applications, may exhibit this symptom.
Modern apps are not supported with the Microsoft Intelligent Security Graph heuristics and will need to be separately authorized in your WDAC policy. As modern apps are signed by the Microsoft Store and Microsoft Store for Business, it is straightforward to authorize modern apps with signer rules in the WDAC policy. Packaged apps are not supported with the Microsoft Intelligent Security Graph heuristics and will need to be separately authorized in your WDAC policy. Since packaged apps have a strong app identity and must be signed, it is straightforward to authorize these apps with your WDAC policy.
The Microsoft Intelligent Security Graph heuristics do not authorize kernel mode drivers. The WDAC policy must have rules that allow the necessary drivers to run. The ISG doesn't authorize kernel mode drivers. The WDAC policy must have rules that allow the necessary drivers to run.
In some cases, the code integrity logs where WDAC errors and warnings are written will contain error events for native images generated for .NET assemblies. Typically, the error is functionally benign as a blocked native image will result in the corresponding assembly being re-interpreted. Review for functionality and performance for the related applications using the native images maybe necessary in some cases.
>[!NOTE] >[!NOTE]
> A rule that explicitly denies or allows a file will take precedence over that file's reputation data. MEM Intune's built-in WDAC support includes the option to trust apps with good reputation via the Microsoft Intelligent Security Graph, but it has no option to add explicit allow or deny rules. In most circumstances, customers enforcing application control need to deploy a custom WDAC policy (which can include the Microsoft Intelligent Security Graph option if desired) using [Intune's OMA-URI functionality](./deploy-windows-defender-application-control-policies-using-intune.md#using-a-custom-oma-uri-profile). > A rule that explicitly denies or allows a file will take precedence over that file's reputation data. MEM Intune's built-in WDAC support includes the option to trust apps with good reputation via the Microsoft Intelligent Security Graph, but it has no option to add explicit allow or deny rules. In most circumstances, customers enforcing application control need to deploy a custom WDAC policy (which can include the Microsoft Intelligent Security Graph option if desired) using [Intune's OMA-URI functionality](deploy-windows-defender-application-control-policies-using-intune.md#deploy-wdac-policies-with-custom-oma-uri).

54
windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-managed-installer.md
View File

@ -1,6 +1,6 @@
--- ---
title: Authorize apps deployed with a WDAC managed installer (Windows 10) title: Authorize apps installed by a managed installer (Windows 10)
description: Explains how you can use a managed installer to automatically authorize applications deployed and installed by a designated software distribution solution, such as Microsoft Endpoint Configuration Manager. description: Explains how to automatically allow applications deployed and installed by a managed installer.
keywords: security, malware keywords: security, malware
ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
ms.prod: m365-security ms.prod: m365-security
@ -11,63 +11,49 @@ ms.localizationpriority: medium
audience: ITPro audience: ITPro
ms.collection: M365-security-compliance ms.collection: M365-security-compliance
author: jsuther1974 author: jsuther1974
ms.reviewer: isbrahm ms.reviewer: jogeurte
ms.author: dansimp ms.author: dansimp
manager: dansimp manager: dansimp
ms.date: 08/14/2020 ms.date: 04/20/2021
ms.technology: mde ms.technology: mde
--- ---
# Authorize apps deployed with a WDAC managed installer # Authorize apps deployed by a managed installer
**Applies to:** **Applies to:**
- Windows 10 - Windows 10
- Windows Server 2019 - Windows Server 2019
Windows 10, version 1703 (also known as the Windows 10 Creators Update) provides a new option, known as a managed installer, that allows IT administrators to automatically authorize applications deployed and installed by a designated software distribution solution such as Microsoft Endpoint Configuration Manager. Windows 10, version 1703 introduced a new option for Windows Defender Application Control (WDAC), called managed installer, that helps balance security and manageability when enforcing application control policies. This option lets you automatically allow applications installed by a designated software distribution solution such as Microsoft Endpoint Configuration Manager.
A managed installer helps an IT admin balance security and manageability requirements when employing application execution control policies by providing an option that does not require specifying explicit rules for software that is being managed through a software distribution solution.
## How does a managed installer work? ## How does a managed installer work?
A managed installer uses a new rule collection in AppLocker to specify one or more executables that are trusted by the organization as an authorized source for application deployment. A new rule collection in AppLocker specifies binaries that are trusted by the organization as an authorized source for application deployment. When one of these binaries runs, Windows will monitor the binary's process (and processes it launches) and tag all files it writes as having originated from a managed installer. The managed installer rule collection is configured using Group Policy and can be applied with the Set-AppLockerPolicy PowerShell cmdlet. You can't currently set managed installers with the AppLocker CSP through MDM.
Specifying an executable as a managed installer will cause Windows to tag files that are written from the executable's process (or processes it launches) as having originated from a trusted installation authority. The Managed Installer rule collection is currently supported for AppLocker rules in Group Policy and in Configuration Manager, but not in the AppLocker CSP for OMA-URI policies. Having defined your managed installers using AppLocker, you can then configure WDAC to trust files installed by a managed installer by adding the Enabled:Managed Installer option to your WDAC policy. Once 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 present for the file, WDAC will allow a file to run based on its managed installer origin.
Once the IT administrator adds the Allow: Managed Installer option to a WDAC policy, the WDAC component will subsequently check for the presence of the origin information when evaluating other application execution control rules specified in the policy. If there are no deny rules present for the file, it will be authorized based on the managed installer origin information. You should ensure that the WDAC policy allows the system to boot and any other authorized applications that can't be deployed through a managed installer.
Admins needs to ensure that there is a WDAC policy in place to allow the system to boot and run any other authorized applications that may not be deployed through a managed installer. For an example of a managed installer use case, see [Creating a WDAC policy for fully managed devices](create-wdac-policy-for-fully-managed-devices.md).
An example managed installer use-case can be seen in the guidance for [creating a WDAC policy for fully-managed devices](create-wdac-policy-for-fully-managed-devices.md).
Note that a WDAC policy with managed installer configured will begin to tag files which originated from that managed installer, regardless of whether the policy is in audit or enforced mode.
## Security considerations with managed installer ## Security considerations with managed installer
Since managed installer is a heuristic-based mechanism, it does not provide the same security guarantees that explicit allow or deny rules do. Since managed installer is a heuristic-based mechanism, it doesn't provide the same security guarantees that explicit allow or deny rules do.
It is best suited for deployment to systems where each user is configured as a standard user and where all software is deployed and installed by a software distribution solution, such as Microsoft Endpoint Configuration Manager. It is best suited for use where each user operates as a standard user and where all software is deployed and installed by a software distribution solution, such as Microsoft Endpoint Configuration Manager.
Users with administrator privileges or malware running as an administrator user on the system may be able to circumvent the intent of Windows Defender Application Control when the managed installer option is allowed. Users with administrator privileges or malware running as an administrator user on the system may be able to circumvent the intent of Windows Defender Application Control when the managed installer option is allowed.
If the authorized managed installer process performs installations in the context of a user with standard privileges, then it is 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 include an option to 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 may continue to apply to all files created during the first run of the application. This could result in over-authorization for executables that were not intended. If a managed installer process runs in the context of a user with standard privileges, then it is possible that standard users or malware running as standard user may be able to circumvent the intent of Windows Defender Application Control.
To avoid this, ensure that the application deployment solution being 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 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 created during the first run of the application. This could result in over-authorization for executables that were not intended. To avoid that outcome, ensure that the application deployment solution used as a managed installer limits running applications as part of installation.
## Known limitations with managed installer ## Known limitations with managed installer
- Application execution control based on managed installer does not support applications that self-update/auto-update. - Application control based on managed installer does not support applications that self-update. If an application deployed by a managed installer later updates itself, the updated application files won't include the managed installer origin information and may not be able to run. When you rely on managed installers, you must deploy and install all application updates using a managed installer or include rules to authorize the app in the WDAC policy. In some cases, it may be possible to also designate an application binary that performs self-updates as a managed installer. Proper review for functionality and security should be performed for the application before using this method.
If an application deployed by a managed installer subsequently updates itself, the updated application files will no longer include the managed installer origin information and will not be authorized to run.
Enterprises should deploy and install all application updates using the managed installer.
In some cases, it may be possible to also designate an application binary that performs the self-updates as a managed installer.
Proper review for functionality and security should be performed for the application before using this method.
- Modern apps deployed through a managed installer will not be tracked by the managed installer heuristic and will need to be separately authorized in your WDAC policy. - [Packaged apps (MSIX)](/windows/msix/) deployed through a managed installer aren't tracked by the managed installer heuristic and will need to be separately authorized in your WDAC policy. See [Manage packaged apps with WDAC](manage-packaged-apps-with-windows-defender-application-control.md).
- Executables that extract files and then attempt to execute may not be allowed by the managed installer heuristic. - Some applications or installers may extract, download, or generate binaries and immediately attempt to run them. Files run by such a process may not be allowed by the managed installer heuristic. In some cases, it may be possible to also designate an application binary that performs such an operation as a managed installer. Proper review for functionality and security should be performed for the application before using this method.
In some cases, it may be possible to also designate an application binary that performs such an operation as a managed installer.
Proper review for functionality and security should be performed for the application before using this method.
- The managed installer heuristic does not authorize drivers. - The managed installer heuristic doesn't authorize kernel drivers. The WDAC policy must have rules that allow the necessary drivers to run.
The WDAC policy must have rules that allow the necessary drivers to run.
- In some cases, the code integrity logs where WDAC errors and warnings are written will contain error events for native images generated for .NET assemblies.
Typically, the error is functionally benign as a blocked native image will result in the corresponding assembly being re-interpreted.
Review for functionality and performance for the related applications using the native images maybe necessary in some cases.

82
windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-deployment-guide.md
View File

@ -1,6 +1,6 @@
--- ---
title: Planning and getting started on the Windows Defender Application Control deployment process (Windows 10) title: Deploying Windows Defender Application Control (WDAC) policies (Windows 10)
description: Learn how to gather information, create a plan, and begin to test initial code integrity policies for a Windows Defender Application Control deployment. description: Learn how to plan and implement a WDAC deployment.
keywords: security, malware keywords: security, malware
ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
ms.prod: m365-security ms.prod: m365-security
@ -11,83 +11,33 @@ ms.localizationpriority: medium
audience: ITPro audience: ITPro
ms.collection: M365-security-compliance ms.collection: M365-security-compliance
author: jsuther1974 author: jsuther1974
ms.reviewer: isbrahm ms.reviewer: jogeurte
ms.author: dansimp ms.author: dansimp
manager: dansimp manager: dansimp
ms.date: 05/16/2018 ms.date: 05/16/2018
ms.technology: mde ms.technology: mde
--- ---
# Planning and getting started on the Windows Defender Application Control deployment process # Deploying Windows Defender Application Control (WDAC) policies
**Applies to** **Applies to**
- Windows 10 - Windows 10
- Windows Server 2016 - Windows Server 2016 and above
This topic provides a roadmap for planning and getting started on the Windows Defender Application Control (WDAC) deployment process, with links to topics that provide additional detail. Planning for WDAC deployment involves looking at both the end-user and the IT pro impact of your choices. You should now have one or more WDAC policies ready to deploy. If you haven't yet completed the steps described in the [WDAC Design Guide](windows-defender-application-control-design-guide.md), do so now before proceeding.
## Planning ## Plan your deployment
1. Review requirements, especially hardware requirements for VBS. As with any significant change to your environment, implementing application control can have unintended consequences. To ensure the best chance for success, you should follow safe deployment practices and plan your deployment carefully. Decide what devices you will manage with WDAC and split them into deployment rings so you can control the scale of the deployment and respond if anything goes wrong. Define the success criteria that will determine when it's safe to continue from one ring to the next.
2. Group devices by degree of control needed. Do most devices fit neatly into a few categories, or are they scattered across all categories? Are users allowed to install any application or must they choose from a list? Are users allowed to use their own peripheral devices?<br>Deployment is simpler if everything is locked down in the same way, but meeting individual departments' needs, and working with a wide variety of devices, may require a more complicated and flexible deployment. All WDAC policy changes should be deployed in audit mode before proceeding to enforcement. Carefully monitor events from devices where the policy has been deployed to ensure the block events you observe match your expectation before broadening the deployment to other deployment rings. If your organization uses Microsoft Defender for Endpoint, you can use the Advanced Hunting feature to centrally monitor WDAC-related events. Otherwise, we recommend using an event log forwarding solution to collect relevant events from your managed endpoints.
3. Review how much variety in software and hardware is needed by roles or departments. The following questions can help you clarify how many WDAC policies to create: ## Choose how to deploy WDAC policies
- How standardized is the hardware?<br>This can be relevant because of drivers. You could create a WDAC policy on hardware that uses a particular set of drivers, and if other drivers in your environment use the same signature, they would also be allowed to run. However, you might need to create several WDAC policies on different "reference" hardware, then merge the policies together, to ensure that the resulting policy recognizes all the drivers in your environment.
- What software does each department or role need? Should they be able to install and run other departments' software?<br>If multiple departments are allowed to run the same list of software, you might be able to merge several WDAC policies to simplify management.
- Are there departments or roles where unique, restricted software is used?<br>If one department needs to run an application that no other department is allowed, it might require a separate WDAC policy. Similarly, if only one department must run an old version of an application (while other departments allow only the newer version), it might require a separate WDAC policy.
- Is there already a list of accepted applications?<br>A list of accepted applications can be used to help create a baseline WDAC policy.<br>As of Windows 10, version 1703, it might also be useful to have a list of plug-ins, add-ins, or modules that you want to allow only in a specific app (such as a line-of-business app). Similarly, it might be useful to have a list of plug-ins, add-ins, or modules that you want to block in a specific app (such as a browser).
- As part of a threat review process, have you reviewed systems for software that can load arbitrary DLLs or run code or scripts?
In day-to-day operations, your organization's security policy may allow certain applications, code, or scripts to run on your systems depending on their role and the context. However, if your security policy requires that you run only trusted applications, code, and scripts on your systems, you may decide to lock these systems down securely with Windows Defender Application Control policies.
Legitimate applications from trusted vendors provide valid functionality. However, an attacker could also potentially use that same functionality to run malicious executable code that could bypass WDAC.
For operational scenarios that require elevated security, certain applications with known Code Integrity bypasses may represent a security risk if you allow them in your WDAC policies. Other applications, where older versions of the application had vulnerabilities, also represent a risk. Therefore, you may want to deny or block such applications from your WDAC policies. For applications with vulnerabilities, once the vulnerabilities are fixed you can create a rule that only allows the fixed or newer versions of that application. The decision to allow or block applications depends on the context and on how the reference system is being used.
Security professionals collaborate with Microsoft continuously to help protect customers. With the help of their valuable reports, Microsoft has identified a list of known applications that an attacker could potentially use to bypass Windows Defender Application Control. Depending on the context, you may want to block these applications. To view this list of applications and for use case examples, such as disabling msbuild.exe, see [Microsoft recommended block rules](microsoft-recommended-block-rules.md).
4. Identify LOB applications that are currently unsigned. Although requiring signed code (through WDAC) protects against many threats, your organization might use unsigned LOB applications, for which the process of signing might be difficult. You might also have applications that are signed, but you want to add a secondary signature to them. If so, identify these applications, because you will need to create a catalog file for them.
## Getting started on the deployment process
1. Optionally, create a signing certificate for Windows Defender Application Control. As you deploy WDAC, you might need to sign catalog files or WDAC policies internally. To do this, you will either need a publicly issued code signing certificate (that you purchase) or an internal CA. If you choose to use an internal CA, you will need to [create a code signing certificate](create-code-signing-cert-for-windows-defender-application-control.md).
2. Create WDAC policies from reference computers. In this respect, creating and managing WDAC policies to align with the needs of roles or departments can be similar to managing corporate images. From each reference computer, you can create a WDAC policy, and decide how to manage that policy. You can [merge](merge-windows-defender-application-control-policies.md) WDAC policies to create a broader policy or a master policy, or you can manage and deploy each policy individually.
3. Audit the WDAC policy and capture information about applications that are outside the policy. We recommend that you use [audit mode](audit-windows-defender-application-control-policies.md) to carefully test each WDAC policy before you enforce it. With audit mode, no application is blocked—the policy just logs an event whenever an application outside the policy is started. Later, you can expand the policy to allow these applications, as needed.
4. Create a [catalog file](deploy-catalog-files-to-support-windows-defender-application-control.md) for unsigned LOB applications. Use the Package Inspector tool to create and sign a catalog file for your unsigned LOB applications. In later steps, you can merge the catalog file's signature into your WDAC policy, so that applications in the catalog will be allowed by the policy.
6. Capture needed policy information from the event log, and merge information into the existing policy as needed. After a WDAC policy has been running for a time in audit mode, the event log will contain information about applications that are outside the policy. To expand the policy so that it allows for these applications, use Windows PowerShell commands to capture the needed policy information from the event log, and then merge that information into the existing policy. You can merge WDAC policies from other sources also, for flexibility in how you create your final WDAC policies.
7. Deploy WDAC policies and catalog files. After you confirm that you have completed all the preceding steps, you can begin deploying catalog files and taking WDAC policies out of auditing mode. We strongly recommend that you begin this process with a test group of users. This provides a final quality-control validation before you deploy the catalog files and WDAC policies more broadly.
8. Enable desired virtualization-based security (VBS) features. Hardware-based security features—also called virtualization-based security (VBS) features—strengthen the protections offered by Windows Defender Application Control.
## Known issues
This section covers known issues with WDAC. Virtualization-based protection of code integrity may be incompatible with some devices and applications, which might cause unexpected failures, data loss, or a blue screen error (also called a stop error).
Test this configuration in your lab before enabling it in production.
### MSI Installations are blocked by WDAC
Installing .msi files directly from the internet to a computer protected by WDAC will fail.
For example, this command will not work:
```code
msiexec –i https://download.microsoft.com/download/2/E/3/2E3A1E42-8F50-4396-9E7E-76209EA4F429/Windows10_Version_1511_ADMX.msi
```
As a workaround, download the MSI file and run it locally:
```code
msiexec –i c:\temp\Windows10_Version_1511_ADMX.msi
```
There are several options to deploy WDAC policies to managed endpoints, including:
1. [Deploy using a Mobile Device Management (MDM) solution](deploy-windows-defender-application-control-policies-using-intune.md), such as Microsoft Intune
2. [Deploy using Microsoft Endpoint Configuration Manager (MEMCM)](deployment/deploy-wdac-policies-with-memcm.md)
3. [Deploy via script](deployment/deploy-wdac-policies-with-script.md)
4. [Deploy via Group Policy](deploy-windows-defender-application-control-policies-using-group-policy.md)