mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-16 10:53:43 +00:00
Merge branch 'main' into patch-8
This commit is contained in:
Stephanie Savell
GitHub
@ -52,8 +52,11 @@ Available naming macros:
|
||||
|
||||
|Macro|Description|Example|Generated Name|
|
||||
|:---|:---|:---|:---|
|
||||
|%RAND:<# of digits>|Generates the specified number of random digits.|Test%RAND:6%|Test123456|
|
||||
|%SERIAL%|Generates the serial number derived from the device. If the serial number causes the new name to exceed the 15 character limit, the serial number will be truncated from the beginning of the sequence.|Test-Device-%SERIAL%|Test-Device-456|
|
||||
|`%RAND:#%`|Generates the specified number (`#`) of random digits.|`Test%RAND:6%`|`Test123456`|
|
||||
|`%SERIAL%`|Generates the serial number derived from the device. If the serial number causes the new name to exceed the 15 character limit, the serial number will be truncated from the beginning of the sequence.|`Test-Device-%SERIAL%`|`Test-Device-456`|
|
||||
|
||||
> [!NOTE]
|
||||
> If you use these naming macros, a unique name isn't guaranteed. The generated name may still be duplicated. To reduce the likelihood of a duplicated device name, use `%RAND:#%` with a large number. With the understanding that the maximum device name is 15 characters.
|
||||
|
||||
Supported operation is Add.
|
||||
|
||||
|
||||
@ -1,21 +1,16 @@
|
||||
---
|
||||
title: Deploy WDAC policies using Mobile Device Management (MDM) (Windows)
|
||||
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
|
||||
ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
|
||||
ms.prod: m365-security
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
ms.prod: windows-client
|
||||
ms.technology: itpro-security
|
||||
ms.localizationpriority: medium
|
||||
audience: ITPro
|
||||
ms.collection: M365-security-compliance
|
||||
author: jsuther1974
|
||||
ms.reviewer: isbrahm
|
||||
ms.author: dansimp
|
||||
manager: dansimp
|
||||
ms.author: vinpa
|
||||
manager: aaroncz
|
||||
ms.date: 06/27/2022
|
||||
ms.technology: windows-sec
|
||||
ms.topic: how-to
|
||||
---
|
||||
|
||||
# Deploy WDAC policies using Mobile Device Management (MDM)
|
||||
@ -61,13 +56,13 @@ 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>`
|
||||
|
||||
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](/powershell/module/configci/convertfrom-cipolicy) cmdlet in order to be deployed. The binary policy may be signed or unsigned.
|
||||
|
||||
3. Open the Microsoft Intune portal and [create a profile with custom settings](/mem/intune/configuration/custom-settings-windows-10).
|
||||
|
||||
4. Specify a **Name** and **Description** and use the following values for the remaining custom OMA-URI settings:
|
||||
- **OMA-URI**: ./Vendor/MSFT/ApplicationControl/Policies/_Policy GUID_/Policy
|
||||
- **Data type**: Base64
|
||||
- **OMA-URI**: `./Vendor/MSFT/ApplicationControl/Policies/_Policy GUID_/Policy`
|
||||
- **Data type**: Base64 (file)
|
||||
- **Certificate file**: upload your binary format policy file. You don't need to upload a Base64 file, as Intune will convert the uploaded .bin file to Base64 on your behalf.
|
||||
|
||||
> [!div class="mx-imgBorder"]
|
||||
@ -86,13 +81,13 @@ Upon deletion, policies deployed through Intune via the ApplicationControl CSP a
|
||||
|
||||
The steps to use Intune's Custom OMA-URI functionality to apply 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](/powershell/module/configci/convertfrom-cipolicy) cmdlet in order to be deployed. The binary policy may be signed or unsigned.
|
||||
|
||||
2. Open the Microsoft Intune portal and [create a profile with custom settings](/mem/intune/configuration/custom-settings-windows-10).
|
||||
|
||||
3. Specify a **Name** and **Description** and use the following values for the remaining custom OMA-URI settings:
|
||||
- **OMA-URI**: ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/_Grouping_/CodeIntegrity/Policy)
|
||||
- **Data type**: Base64
|
||||
- **OMA-URI**: `./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/_Grouping_/CodeIntegrity/Policy`
|
||||
- **Data type**: Base64 (file)
|
||||
- **Certificate file**: upload your binary format policy file
|
||||
|
||||
> [!NOTE]
|
||||
|
||||
@ -1,21 +1,16 @@
|
||||
---
|
||||
title: Microsoft recommended block rules (Windows)
|
||||
title: Microsoft recommended block rules
|
||||
description: View a list of recommended block rules, based on knowledge shared between Microsoft and the wider security community.
|
||||
keywords: security, malware
|
||||
ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
|
||||
ms.prod: m365-security
|
||||
ms.technology: windows-sec
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
ms.prod: windows-client
|
||||
ms.technology: itpro-security
|
||||
ms.localizationpriority: medium
|
||||
audience: ITPro
|
||||
ms.collection: M365-security-compliance
|
||||
author: jsuther1974
|
||||
ms.reviewer: isbrahm
|
||||
ms.author: dansimp
|
||||
manager: dansimp
|
||||
ms.author: vinpa
|
||||
manager: aaroncz
|
||||
ms.date: 09/29/2021
|
||||
ms.topic: reference
|
||||
---
|
||||
|
||||
# Microsoft recommended block rules
|
||||
@ -75,7 +70,7 @@ Unless your use scenarios explicitly require them, Microsoft recommends that you
|
||||
- wslconfig.exe
|
||||
- wslhost.exe
|
||||
|
||||
<sup>1</sup> A vulnerability in bginfo.exe has been fixed in the latest version 4.22. If you use BGInfo, for security, make sure to download and run the latest version here [BGInfo 4.22](/sysinternals/downloads/bginfo). BGInfo versions earlier than 4.22 are still vulnerable and should be blocked.
|
||||
<sup>1</sup> A vulnerability in bginfo.exe was fixed in version 4.22. If you use BGInfo, for security, make sure to download and run the latest version of [BGInfo](/sysinternals/downloads/bginfo). BGInfo versions earlier than 4.22 are still vulnerable and should be blocked.
|
||||
|
||||
<sup>2</sup> If you're using your reference system in a development context and use msbuild.exe to build managed applications, we recommend that you allow msbuild.exe in your code integrity policies. However, if your reference system is an end-user device that isn't being used in a development context, we recommend that you block msbuild.exe.
|
||||
|
||||
@ -107,11 +102,11 @@ Unless your use scenarios explicitly require them, Microsoft recommends that you
|
||||
|
||||
Certain software applications may allow other code to run by design. Such applications should be blocked by your Windows Defender Application Control policy. In addition, when an application version is upgraded to fix a security vulnerability or potential Windows Defender Application Control bypass, you should add *deny* rules to your application control policies for that application’s previous, less secure versions.
|
||||
|
||||
Microsoft recommends that you install the latest security updates. The June 2017 Windows updates resolve several issues in PowerShell modules that allowed an attacker to bypass Windows Defender Application Control. These modules can't be blocked by name or version, and therefore must be blocked by their corresponding hashes.
|
||||
Microsoft recommends that you install the latest security updates. For example, updates help resolve several issues in PowerShell modules that allowed an attacker to bypass Windows Defender Application Control. These modules can't be blocked by name or version, and therefore must be blocked by their corresponding hashes.
|
||||
|
||||
For October 2017, we're announcing an update to system.management.automation.dll in which we're revoking older versions by hash values, instead of version rules.
|
||||
As of October 2017, system.management.automation.dll is updated to revoke earlier versions by hash values, instead of version rules.
|
||||
|
||||
Microsoft recommends that you block the following Microsoft-signed applications and PowerShell files by merging the following policy into your existing policy to add these deny rules using the Merge-CIPolicy cmdlet. Beginning with the March 2019 quality update, each version of Windows requires blocking a specific version of the following files:
|
||||
Microsoft recommends that you block the following Microsoft-signed applications and PowerShell files by merging the following policy into your existing policy to add these deny rules using the Merge-CIPolicy cmdlet. As of March 2019, each version of Windows requires blocking a specific version of the following files:
|
||||
|
||||
- msxml3.dll
|
||||
- msxml6.dll
|
||||
|
||||
Reference in New Issue
Block a user