diff --git a/windows/device-security/device-guard/deploy-code-integrity-policies-steps.md b/windows/device-security/device-guard/deploy-code-integrity-policies-steps.md index ca63dd6b20..a27db98ffe 100644 --- a/windows/device-security/device-guard/deploy-code-integrity-policies-steps.md +++ b/windows/device-security/device-guard/deploy-code-integrity-policies-steps.md @@ -16,19 +16,25 @@ author: brianlic-msft For an overview of the process described in the following procedures, see [Deploy code integrity policies: policy rules and file rules](deploy-code-integrity-policies-policy-rules-and-file-rules.md). To understand how the deployment of code integrity policies fits with other steps in the Windows Defender Device Guard deployment process, see [Planning and getting started on the Windows Defender Device Guard deployment process](planning-and-getting-started-on-the-device-guard-deployment-process.md). -## Create a code integrity policy from a golden computer +## Create a code integrity policy from a reference computer -The process for creating a golden code integrity policy from a reference system is straightforward. This section outlines the process that is required to successfully create a code integrity policy with Windows PowerShell. First, for this example, you must initiate variables to be used during the creation process. Rather than using variables, you can simply use the full file paths in the command. Next, you create the code integrity policy by scanning the system for installed applications. When created, the policy file is converted to binary format so that Windows can consume its contents. +This section outlines the process to create a code integrity policy with Windows PowerShell. +For this example, you must initiate variables to be used during the creation process or use the full file paths in the command. +Then create the code integrity policy by scanning the system for installed applications. +The policy file is converted to binary format when it gets created so that Windows can interpret it. > [!Note] -> Before you begin this procedure, make sure that the reference PC is virus and malware-free,and that any software you want to be scanned is installed on the system before creating the code integrity policy. +> Make sure the reference computer is virus and malware-free, and install any software you want to be scanned before creating the code integrity policy. ### Scripting and applications -Each installed software application should be validated as trustworthy before you create a policy. We recommend that you review the reference PC for software that can load arbitrary DLLs and run code or scripts that could render the PC more vulnerable. Examples include software aimed at development or scripting such as msbuild.exe (part of Visual Studio and the .NET Framework) which can be removed if you do not want it to run scripts. -You can remove or disable such software on reference PCs used to create code integrity policies. You can also fine-tune your control by using Windows Defender Device Guard in combination with AppLocker, as described in [Windows Defender Device Guard with AppLocker](https://technet.microsoft.com/itpro/windows/keep-secure/introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies#device-guard-with-applocker). +Each installed software application should be validated as trustworthy before you create a policy. +We recommend that you review the reference computer for software that can load arbitrary DLLs and run code or scripts that could render the PC more vulnerable. +Examples include software aimed at development or scripting such as msbuild.exe (part of Visual Studio and the .NET Framework) which can be removed if you do not want it to run scripts. +You can remove or disable such software on the reference computer. +You can also fine-tune your control by [using Windows Defender Device Guard in combination with AppLocker](https://technet.microsoft.com/itpro/windows/keep-secure/introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies#device-guard-with-applocker). -Members of the security community\* continuously collaborate with Microsoft® to help protect customers. With the help of their valuable reports, Microsoft has identified a list of valid applications that an attacker could also potentially use to bypass Windows Defender Device Guard code integrity policies. +Members of the security community\* continuously collaborate with Microsoft to help protect customers. With the help of their valuable reports, Microsoft has identified a list of valid applications that an attacker could also potentially use to bypass Windows Defender Device Guard code integrity policies. Unless your use scenarios explicitly require them, Microsoft recommends that you block the following applications. These applications or files can be used by an attacker to circumvent Application Whitelisting policies, including Windows Defender Device Guard: @@ -70,11 +76,15 @@ Unless your use scenarios explicitly require them, Microsoft recommends that you
>[!Note] ->This application list is fluid and will be updated with the latest vendor information as application vulnerabilities are resolved and new issues are discovered. +>This application list will be updated with the latest vendor information as application vulnerabilities are resolved and new issues are discovered. -Certain software applications may allow additional code to run by design. These types of applications should be blocked by your Windows Defender Device Guard policy. In addition, when an application version is upgraded to fix a security vulnerability or potential Windows Defender Device Guard bypass, you should add deny rules to your code integrity policies for that application’s previous, less secure versions. +Certain software applications may allow additional code to run by design. +These types of applications should be blocked by your Windows Defender Device Guard policy. +In addition, when an application version is upgraded to fix a security vulnerability or potential Windows Defender Device Guard bypass, you should add deny rules to your code integrity 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 in-box PowerShell modules that allowed an attacker to bypass Windows Defender Device Guard code integrity policies. These modules cannot be blocked by name or version, and therefore must be blocked by their corresponding hashes. +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 Device Guard code integrity policies. +These modules cannot be blocked by name or version, and therefore must be blocked by their corresponding hashes. For October 2017, we are announcing an update to system.management.automation.dll in which we are revoking older versions by hash values, instead of version rules. @@ -681,7 +691,7 @@ To create a code integrity policy, copy each of the following commands into an e ` New-CIPolicy -Level PcaCertificate -FilePath $InitialCIPolicy –UserPEs 3> CIPolicyLog.txt ` - > [!Notes] + > [!Note] > - When you specify the **-UserPEs** parameter (to include user mode executables in the scan), rule option **0 Enabled:UMCI** is automatically added to the code integrity policy. In contrast, if you do not specify **-UserPEs**, the policy will be empty of user mode executables and will only have rules for kernel mode binaries like drivers, in other words, the whitelist will not include applications. If you create such a policy and later add rule option **0 Enabled:UMCI**, all attempts to start applications will cause a response from Windows Defender Device Guard. In audit mode, the response is logging an event, and in enforced mode, the response is blocking the application. @@ -725,7 +735,7 @@ When code integrity policies are run in audit mode, it allows administrators to > [!Note] - > - The illustration shows the example file name *DeviceGuardPolicy.bin* because this name was used earlier in this topic, in [Create a code integrity policy from a golden computer](#create-a-code-integrity-policy-from-a-golden-computer). Also, this policy file does not need to be copied to every system. You can instead copy the code integrity policies to a file share to which all computer accounts have access. + > - The illustration shows the example file name *DeviceGuardPolicy.bin* because this name was used earlier in this topic, in [Create a code integrity policy from a reference computer](#create-a-code-integrity-policy-from-a-golden-computer). Also, this policy file does not need to be copied to every system. You can instead copy the code integrity policies to a file share to which all computer accounts have access. > - Any policy you select here is converted to SIPolicy.p7b when it is deployed to the individual computers. @@ -892,15 +902,17 @@ Now that this policy is in enforced mode, you can deploy it to your test compute ## Signing code integrity policies with SignTool.exe -Signed code integrity policies give organizations the highest level of malware protection available in Windows 10. In addition to their enforced policy rules, signed policies cannot be modified or deleted by a user or administrator on the computer. These policies are designed to prevent administrative tampering and kernel mode exploit access. With this in mind, it is much more difficult to remove signed code integrity policies than unsigned ones. Before you sign and deploy a signed code integrity policy, we recommend that you audit the policy to discover any blocked applications that should be allowed to run. For more information about how to audit code integrity policies, see the [Audit code integrity policies](#audit-code-integrity-policies) section. +Signed code integrity policies give organizations the highest level of malware protection available in Windows 10. +In addition to their enforced policy rules, signed policies cannot be modified or deleted by a user or administrator on the computer. +These policies are designed to prevent administrative tampering and kernel mode exploit access. +With this in mind, it is much more difficult to remove signed code integrity policies. +Before you sign and deploy a signed code integrity policy, we recommend that you [audit the policy](#audit-code-integrity-policies) to discover any blocked applications that should be allowed to run. -Signing code integrity policies by using an on-premises CA-generated certificate or a purchased code signing certificate is straightforward. If you do not currently have a code signing certificate exported in .pfx format (containing private keys, extensions, and root certificates), see [Optional: Create a code signing certificate for code integrity policies](optional-create-a-code-signing-certificate-for-code-integrity-policies.md) to create one with your on-premises CA. +Signing code integrity policies by using an on-premises CA-generated certificate or a purchased code signing certificate is straightforward. +If you do not currently have a code signing certificate exported in .pfx format (containing private keys, extensions, and root certificates), see [Optional: Create a code signing certificate for code integrity policies](optional-create-a-code-signing-certificate-for-code-integrity-policies.md) to create one with your on-premises CA. Before signing code integrity policies for the first time, be sure to enable rule options 9 (“Advanced Boot Options Menu”) and 10 (“Boot Audit on Failure”) to leave troubleshooting options available to administrators. To ensure that a rule option is enabled, you can run a command such as `Set-RuleOption -FilePath -Option 9` even if you're not sure whether the option is already enabled—if so, the command has no effect. When validated and ready for enterprise deployment, you can remove these options. For more information about rule options, see [Code integrity policy rules](deploy-code-integrity-policies-policy-rules-and-file-rules.md#code-integrity-policy-rules) in "Deploy code integrity policies: policy rules and file rules." -> [!Note] -> Signing code integrity policies is the last step in a code integrity deployment. It is much more difficult to remove a signed code integrity policy than an unsigned one. Before you deploy a signed code integrity policy to deployed client computers, be sure to test its effect on a subset of computers. - To sign a code integrity policy with SignTool.exe, you need the following components: - SignTool.exe, found in the Windows SDK (Windows 7 or later) diff --git a/windows/device-security/device-guard/optional-create-a-code-signing-certificate-for-code-integrity-policies.md b/windows/device-security/device-guard/optional-create-a-code-signing-certificate-for-code-integrity-policies.md index dbd9304e45..de08418e65 100644 --- a/windows/device-security/device-guard/optional-create-a-code-signing-certificate-for-code-integrity-policies.md +++ b/windows/device-security/device-guard/optional-create-a-code-signing-certificate-for-code-integrity-policies.md @@ -16,7 +16,9 @@ author: brianlic-msft As you deploy code integrity policies (part of Windows Defender Device Guard), you might need to sign catalog files or code integrity policies internally. To do this, you will either need a publicly issued code signing certificate or an internal CA. If you have purchased a code signing certificate, you can skip this topic and instead follow other topics listed in [Deploy Windows Defender Device Guard: deploy code integrity policies](deploy-device-guard-deploy-code-integrity-policies.md). -If you have not purchased a certificate but have an internal CA, complete these steps to create a code signing certificate: +If you have an internal CA, complete these steps to create a code signing certificate. +Only RSA algorithm is supported for the code signing certificate, and signatures must be PKCS 1.5 padded. +ECDSA is not supported. 1. Open the Certification Authority Microsoft Management Console (MMC) snap-in, and then select your issuing CA. diff --git a/windows/threat-protection/windows-information-protection/create-wip-policy-using-intune-azure.md b/windows/threat-protection/windows-information-protection/create-wip-policy-using-intune-azure.md index 48b2f0abd2..7ce9d2ae5d 100644 --- a/windows/threat-protection/windows-information-protection/create-wip-policy-using-intune-azure.md +++ b/windows/threat-protection/windows-information-protection/create-wip-policy-using-intune-azure.md @@ -50,7 +50,7 @@ After you’ve set up Intune for your organization, you must create a WIP-specif >[!NOTE] >Optionally, you can also add your apps and set your settings from the **Add a policy** blade, but for the purposes of this documentation, we recommend instead that you create the policy first, and then use the subsequent menus that become available. -### Add apps to your Allowed apps list +## Add apps to your Allowed apps list During the policy-creation process in Intune, you can choose the apps you want to give access to your enterprise data through WIP. Apps included in this list can protect data on behalf of the enterprise and are restricted from copying or moving enterprise data to unprotected apps. The steps to add your apps are based on the type of template being applied. You can add a recommended app, a store app (also known as a Universal Windows Platform (UWP) app), or a signed Windows desktop app. @@ -58,7 +58,7 @@ The steps to add your apps are based on the type of template being applied. You >[!Important] >Enlightened apps are expected to prevent enterprise data from going to unprotected network locations and to avoid encrypting personal data. On the other hand, WIP-unaware apps might not respect the corporate network boundary, and WIP-unaware apps will encrypt all files they create or modify. This means that they could encrypt personal data and cause data loss during the revocation process.

Care must be taken to get a support statement from the software provider that their app is safe with WIP before adding it to your **Allowed apps** list. If you don’t get this statement, it’s possible that you could experience app compat issues due to an app losing the ability to access a necessary file after revocation. -#### Add a Recommended app to your Allowed apps list +### Add a Recommended app to your Allowed apps list For this example, we’re going to add Microsoft Edge, a recommended app, to the **Allowed apps** list. **To add a recommended app** @@ -80,7 +80,7 @@ For this example, we’re going to add Microsoft Edge, a recommended app, to the ![Microsoft Intune management console: Allowed apps blade with recommended apps](images/wip-azure-allowed-apps-with-apps.png) -#### Add a Store app to your Allowed apps list +### Add a Store app to your Allowed apps list For this example, we’re going to add Microsoft Power BI, a store app, to the **Allowed apps** list. **To add a Store app** @@ -150,7 +150,7 @@ If you don't know the publisher or product name, you can find them for both desk >The JSON file might also return a `windowsPhoneLegacyId` value for both the **Publisher Name** and **Product Name** boxes. This means that you have an app that’s using a XAP package and that you must set the **Product Name** as `windowsPhoneLegacyId`, and set the **Publisher Name** as `CN=` followed by the `windowsPhoneLegacyId`.

For example:
{
"windowsPhoneLegacyId": "ca05b3ab-f157-450c-8c49-a1f127f5e71d",
} -#### Add a Desktop app to your Allowed apps list +### Add a Desktop app to your Allowed apps list For this example, we’re going to add WordPad, a desktop app, to the **Allowed apps** list. **To add a Desktop app** @@ -223,7 +223,7 @@ For this example, we’re going to add WordPad, a desktop app, to the **Allowed ``` Where the text, `O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US` is the publisher name to enter into the **Publisher** box and `WORDPAD.EXE` is the text to enter into the **File** box. -#### Import a list of apps to your Allowed apps list +### Import a list of apps to your Allowed apps list For this example, we’re going to add an AppLocker XML file to the **Allowed apps** list. You’ll use this option if you want to add multiple apps at the same time. For more info about AppLocker, see the [AppLocker](https://technet.microsoft.com/itpro/windows/keep-secure/applocker-overview) content. **To create a list of Allowed apps using the AppLocker tool** @@ -311,7 +311,7 @@ For this example, we’re going to add an AppLocker XML file to the **Allowed ap The file imports and the apps are added to your **Allowed app** list. -#### Add exempt apps to your policy +### Add exempt apps to your policy If you're running into compatibility issues where your app is incompatible with WIP, but still needs to be used with enterprise data, you can exempt the app from the WIP restrictions. This means that your apps won't include auto-encryption or tagging and won't honor your network restrictions. It also means that your exempted apps might leak. **To exempt a Store app, a Desktop app, or an AppLocker policy file from the Allowed apps list** @@ -336,7 +336,7 @@ If you're running into compatibility issues where your app is incompatible with 4. Click **OK**. -### Manage the WIP protection mode for your enterprise data +## Manage the WIP protection mode for your enterprise data After you've added the apps you want to protect with WIP, you'll need to apply a management and protection mode. We recommend that you start with **Silent** or **Allow Overrides** while verifying with a small group that you have the right apps on your allowed apps list. After you're done, you can change to your final enforcement policy, **Hide Overrides**. @@ -361,7 +361,7 @@ We recommend that you start with **Silent** or **Allow Overrides** while verifyi 2. Click **Save**. -### Define your enterprise-managed corporate identity +## Define your enterprise-managed corporate identity Corporate identity, usually expressed as your primary Internet domain (for example, contoso.com), helps to identify and tag your corporate data from apps you’ve marked as protected by WIP. For example, emails using contoso.com are identified as being corporate and are restricted by your Windows Information Protection policies. Starting with Windows 10, version 1703, Intune automatically determines your corporate identity and adds it to the **Corporate identity** field. @@ -376,7 +376,7 @@ Starting with Windows 10, version 1703, Intune automatically determines your cor ![Microsoft Intune, Set your corporate identity for your organization](images/wip-azure-required-settings-corp-identity.png) -### Choose where apps can access enterprise data +## Choose where apps can access enterprise data After you've added a protection mode to your apps, you'll need to decide where those apps can access enterprise data on your network. There are no default locations included with WIP, you must add each of your network locations. This area applies to any network endpoint device that gets an IP address in your enterprise’s range and is also bound to one of your enterprise domains, including SMB shares. Local file system locations should just maintain encryption (for example, on local NTFS, FAT, ExFAT). @@ -453,7 +453,7 @@ There are no default locations included with WIP, you must add each of your netw - **Enterprise IP Ranges list is authoritative (do not auto-detect).** Click this box if you want Windows to treat the IP ranges you specified in the network boundary definition as the complete list of IP ranges available on your network. If you clear this box, Windows will search for additional IP ranges on any domain-joined devices connected to your network. -### Upload your Data Recovery Agent (DRA) certificate +## Upload your Data Recovery Agent (DRA) certificate After you create and deploy your WIP policy to your employees, Windows begins to encrypt your corporate data on the employees’ local device drive. If somehow the employees’ local encryption keys get lost or revoked, the encrypted data can become unrecoverable. To help avoid this possibility, the Data Recovery Agent (DRA) certificate lets Windows use an included public key to encrypt the local data while you maintain the private key that can unencrypt the data. >[!Important] @@ -468,7 +468,7 @@ After you create and deploy your WIP policy to your employees, Windows begins to ![Microsoft Intune, Upload your Data Recovery Agent (DRA) certificate](images/wip-azure-advanced-settings-efsdra.png) -### Choose your optional WIP-related settings +## Choose your optional WIP-related settings After you've decided where your protected apps can access enterprise data on your network, you’ll be asked to decide if you want to add any optional WIP settings. **To set your optional settings** @@ -501,7 +501,7 @@ After you've decided where your protected apps can access enterprise data on you - **Off, or not configured.** Stops using Azure Rights Management encryption with WIP. -### Choose to set up Azure Rights Management with WIP +## Choose to set up Azure Rights Management with WIP WIP can integrate with Microsoft Azure Rights Management to enable secure sharing of files by using removable drives such as USB drives. For more info about Azure Rights Management, see [Microsoft Azure Rights Management](https://products.office.com/en-us/business/microsoft-azure-rights-management). To integrate Azure Rights Management with WIP, you must already have Azure Rights Management set up. To configure WIP to use Azure Rights Management, you must set the **AllowAzureRMSForEDP** MDM setting to **1** in Microsoft Intune. This setting tells WIP to encrypt files copied to removable drives with Azure Rights Management, so they can be shared amongst your employees on computers running at least Windows 10, version 1703. diff --git a/windows/threat-protection/windows-information-protection/create-wip-policy-using-intune.md b/windows/threat-protection/windows-information-protection/create-wip-policy-using-intune.md index b40ee0a441..b21ecd9232 100644 --- a/windows/threat-protection/windows-information-protection/create-wip-policy-using-intune.md +++ b/windows/threat-protection/windows-information-protection/create-wip-policy-using-intune.md @@ -33,7 +33,7 @@ After you’ve set up Intune for your organization, you must create a WIP-specif ![Microsoft Intune: Fill out the required Name and optional Description fields](images/intune-generalinfo.png) -### Add app rules to your policy +## Add app rules to your policy During the policy-creation process in Intune, you can choose the apps you want to give access to your enterprise data through WIP. Apps included in this list can protect data on behalf of the enterprise and are restricted from copying or moving enterprise data to unprotected apps. The steps to add your app rules are based on the type of rule template being applied. You can add a store app (also known as a Universal Windows Platform (UWP) app), a signed Windows desktop app, or an AppLocker policy file. @@ -41,7 +41,7 @@ The steps to add your app rules are based on the type of rule template being app >[!Important] >Enlightened apps are expected to prevent enterprise data from going to unprotected network locations and to avoid encrypting personal data. On the other hand, WIP-unaware apps might not respect the corporate network boundary, and WIP-unaware apps will encrypt all files they create or modify. This means that they could encrypt personal data and cause data loss during the revocation process.

Care must be taken to get a support statement from the software provider that their app is safe with WIP before adding it to your **App Rules** list. If you don’t get this statement, it’s possible that you could experience app compat issues due to an app losing the ability to access a necessary file after revocation. -#### Add a store app rule to your policy +### Add a store app rule to your policy For this example, we’re going to add Microsoft OneNote, a store app, to the **App Rules** list. **To add a store app** @@ -118,7 +118,7 @@ If you don't know the publisher or product name, you can find them for both desk } ``` -#### Add a desktop app rule to your policy +### Add a desktop app rule to your policy For this example, we’re going to add Internet Explorer, a desktop app, to the **App Rules** list. **To add a desktop app** @@ -191,7 +191,7 @@ In this example, you'd get the following info: ``` Where the text, `O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US` is the publisher name to enter in the **Publisher Name** box. -#### Add an AppLocker policy file +### Add an AppLocker policy file For this example, we’re going to add an AppLocker XML file to the **App Rules** list. You’ll use this option if you want to add multiple apps at the same time. For more info about AppLocker, see the [AppLocker](https://technet.microsoft.com/itpro/windows/keep-secure/applocker-overview) content. **To create an app rule and xml file using the AppLocker tool** @@ -282,7 +282,7 @@ For this example, we’re going to add an AppLocker XML file to the **App Rules* The file is imported and the apps are added to your **App Rules** list. -#### Exempt apps from WIP restrictions +### Exempt apps from WIP restrictions If you're running into compatibility issues where your app is incompatible with WIP, but still needs to be used with enterprise data, you can exempt the app from the WIP restrictions. This means that your apps won't include auto-encryption or tagging and won't honor your network restrictions. It also means that your exempted apps might leak. **To exempt a store app, a desktop app, or an AppLocker policy file app rule** @@ -306,7 +306,7 @@ If you're running into compatibility issues where your app is incompatible with 5. Click **OK**. -### Manage the WIP protection mode for your enterprise data +## Manage the WIP protection mode for your enterprise data After you've added the apps you want to protect with WIP, you'll need to apply a management and protection mode. We recommend that you start with **Silent** or **Allow Overrides** while verifying with a small group that you have the right apps on your protected apps list. After you're done, you can change to your final enforcement policy, either **Allow Overrides** or **Hide Overrides**. @@ -320,7 +320,7 @@ We recommend that you start with **Silent** or **Allow Overrides** while verifyi ![Microsoft Intune, Set the protection mode for your data](images/intune-protection-mode.png) -### Define your enterprise-managed corporate identity +## Define your enterprise-managed corporate identity Corporate identity, usually expressed as your primary Internet domain (for example, contoso.com), helps to identify and tag your corporate data from apps you’ve marked as protected by WIP. For example, emails using contoso.com are identified as being corporate and are restricted by your Windows Information Protection policies. You can specify multiple domains owned by your enterprise by separating them with the "|" character. For example, (`contoso.com|newcontoso.com`). With multiple domains, the first one is designated as your corporate identity and all of the additional ones as being owned by the first one. We strongly recommend that you include all of your email address domains in this list. @@ -330,7 +330,7 @@ You can specify multiple domains owned by your enterprise by separating them wit ![Microsoft Intune, Set your primary Internet domains](images/intune-corporate-identity.png) -### Choose where apps can access enterprise data +## Choose where apps can access enterprise data After you've added a protection mode to your apps, you'll need to decide where those apps can access enterprise data on your network. There are no default locations included with WIP, you must add each of your network locations. This area applies to any network endpoint device that gets an IP address in your enterprise’s range and is also bound to one of your enterprise domains, including SMB shares. Local file system locations should just maintain encryption (for example, on local NTFS, FAT, ExFAT). @@ -412,7 +412,7 @@ There are no default locations included with WIP, you must add each of your netw For more info about how to find and export your data recovery certificate, see the [Data Recovery and Encrypting File System (EFS)](https://go.microsoft.com/fwlink/p/?LinkId=761462) topic. For more info about creating and verifying your EFS DRA certificate, see the [Create and verify an Encrypting File System (EFS) Data Recovery Agent (DRA) certificate](create-and-verify-an-efs-dra-certificate.md). -### Choose to set up Azure Rights Management with WIP +## Choose to set up Azure Rights Management with WIP WIP can integrate with Microsoft Azure Rights Management to enable secure sharing of files via removable drives such as USB drives. For more info about Azure Rights Management, see [Microsoft Azure Rights Management](https://products.office.com/en-us/business/microsoft-azure-rights-management). To integrate Azure Rights Management with WIP, you must already have Azure Rights Management set up. To configure WIP to use Azure Rights Management, you must set the **AllowAzureRMSForEDP** MDM setting to **1** in Microsoft Intune. This setting tells WIP to encrypt files copied to removable drives with Azure Rights Management, so they can be shared amongst your employees on computers running at least Windows 10, version 1703. @@ -422,7 +422,7 @@ Optionally, if you don’t want everyone in your organization to be able to shar >[!NOTE] >For more info about setting the **AllowAzureRMSForEDP** and the **RMSTemplateIDForEDP** MDM settings, see the [EnterpriseDataProtection CSP](https://msdn.microsoft.com/windows/hardware/commercialize/customize/mdm/enterprisedataprotection-csp) topic. For more info about setting up and using a custom template, see [Configuring custom templates for the Azure Rights Management service](https://docs.microsoft.com/en-us/information-protection/deploy-use/configure-custom-templates) topic. -### Choose your optional WIP-related settings +## Choose your optional WIP-related settings After you've decided where your protected apps can access enterprise data on your network, you’ll be asked to decide if you want to add any optional WIP settings. ![Microsoft Intune, Choose any additional, optional settings](images/intune-optional-settings.png)