mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-05-14 14:27:22 +00:00
Merge remote-tracking branch 'refs/remotes/origin/master' into atp-fixes
This commit is contained in:
Joey Caparas
commit
9269f74f78
@ -1,6 +1,11 @@
|
||||
{
|
||||
"redirections": [
|
||||
{
|
||||
"source_path": "windows/keep-secure/add-apps-to-protected-list-using-custom-uri.md",
|
||||
"redirect_url": "/itpro/windows/keep-secure/create-wip-policy-using-intune",
|
||||
"redirect_document_id": false
|
||||
},
|
||||
{
|
||||
"source_path": "windows/keep-secure/configure-windows-defender-in-windows-10.md",
|
||||
"redirect_url": "/itpro/windows/keep-secure/deploy-manage-report-windows-defender-antivirus",
|
||||
"redirect_document_id": true
|
||||
|
||||
@ -113,7 +113,21 @@ Use one of these methods to set this policy.
|
||||
|
||||
|
||||
### Group Policy
|
||||
**SetEduPolicies** is not natively supported in Group Policy. Instead, use the [MDM Bridge WMI Provider](https://msdn.microsoft.com/en-us/library/windows/desktop/dn905224(v=vs.85).aspx) to set the policy in [MDM SharedPC](https://msdn.microsoft.com/en-us/library/windows/desktop/mt779129(v=vs.85).aspx).
|
||||
**SetEduPolicies** is not natively supported in Group Policy. Instead, use the [MDM Bridge WMI Provider](https://msdn.microsoft.com/en-us/library/windows/desktop/dn905224(v=vs.85).aspx) to set the policy in [MDM SharedPC](https://msdn.microsoft.com/en-us/library/windows/desktop/mt779129(v=vs.85).aspx).
|
||||
|
||||
For example:
|
||||
|
||||
- Open PowerShell as an administrator and enter the following:
|
||||
|
||||
```
|
||||
$sharedPC = Get-CimInstance -Namespace "root\cimv2\mdm\dmmap" -ClassName "MDM_SharedPC"
|
||||
|
||||
$sharedPC.SetEduPolicies = $True
|
||||
|
||||
Set-CimInstance -CimInstance $sharedPC
|
||||
|
||||
Get-CimInstance -Namespace $namespaceName -ClassName $MDM_SharedPCClass
|
||||
```
|
||||
|
||||
### Provisioning tools
|
||||
- [Set up School PCs](use-set-up-school-pcs-app.md) always sets this policy in provisioning packages it creates.
|
||||
|
||||
@ -18,6 +18,7 @@ This topic lists new and updated topics in the [Deploy Windows 10](index.md) doc
|
||||
| [Deploy Windows 10 in a test lab using System Center Configuration Manager](windows-10-poc-sc-config-mgr.md) | Updated: The "refresh" and "replace" procedures were swapped in order so that it would not be necessary to save and restore VMs. Also a missing step was added to include the State migration point role. |
|
||||
| [Step by step guide: Configure a test lab to deploy Windows 10](windows-10-poc.md)| Updated with minor fixes. |
|
||||
| [Manage Windows upgrades with Upgrade Readiness](manage-windows-upgrades-with-upgrade-readiness.md)| Updated child topics under this node to include new feature and user interface changes. |
|
||||
| [Get started with Upgrade Readiness](upgrade-readiness-get-started.md)| Added a table summarizing connection scenarios under the Enable data sharing topic. |
|
||||
|
||||
## RELEASE: Windows 10, version 1703
|
||||
The topics in this library have been updated for Windows 10, version 1703 (also known as the Creators Update). The provisioning topics have been moved to [Configure Windows 10](../configure/index.md).
|
||||
|
||||
55
windows/deploy/upgrade-readiness-data-sharing.md
Normal file
55
windows/deploy/upgrade-readiness-data-sharing.md
Normal file
@ -0,0 +1,55 @@
|
||||
---
|
||||
title: Upgrade Readiness data sharing
|
||||
description: Connectivity scenarios for data sharing with Upgrade Readiness
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: deploy
|
||||
author: greg-lindsay
|
||||
---
|
||||
|
||||
# Upgrade Readiness data sharing
|
||||
|
||||
To enable data sharing with the Upgrade Readiness solution, the following endpoints must be accessible:
|
||||
|
||||
|
||||
| **Endpoint** | **Function** |
|
||||
|---------------------------------------------------------|-----------|
|
||||
| `https://v10.vortex-win.data.microsoft.com/collect/v1`<br>`https://Vortex-win.data.microsoft.com/health/keepalive` | Connected User Experience and Telemetry component endpoint. User computers send data to Microsoft through this endpoint. |
|
||||
| `https://settings.data.microsoft.com/qos` | Enables the compatibility update KB to send data to Microsoft. |
|
||||
| `https://go.microsoft.com/fwlink/?LinkID=544713`<br>`https://compatexchange1.trafficmanager.net/CompatibilityExchangeService.svc` | This service provides driver information about whether there will be a driver available post-upgrade for the hardware on the system. |
|
||||
|
||||
Whitelist these endpoints on your network. This might require working with your organizations's network security group.
|
||||
|
||||
## Connectivity to the Internet
|
||||
|
||||
There are several different methods your organization can use to connect to the Internet, and these methods can affect how authentication is performed by the deployment script.
|
||||
|
||||
### Direct connection to the Internet
|
||||
|
||||
This scenario is very simple since there is no proxy involved. If you are using a network firewall which is blocking outgoing traffic, please keep in mind that even though we provide DNS names for the endpoints needed to communicate to the Microsoft telemetry backend, We therefore do not recommend to attempt to whitelist endpoints on your firewall based on IP-addresses.
|
||||
|
||||
In order to use the direct connection scenario, set the parameter **ClientProxy=Direct** in **runconfig.bat**.
|
||||
|
||||
### Connection through the WinHTTP proxy
|
||||
|
||||
This is the first and most simple proxy scenario. The WinHTTP stack was designed for use in services and does not support proxy autodetection, PAC scripts or authentication.
|
||||
|
||||
In order to set the WinHTTP proxy system-wide on your computers, you need to
|
||||
•Use the command netsh winhttp set proxy \<server\>:\<port\>
|
||||
•Set ClientProxy=System in runconfig.bat
|
||||
|
||||
The WinHTTP scenario is most appropriate for customers who use a single proxy or f. If you have more advanced proxy requirements, refer to Scenario 3.
|
||||
|
||||
If you want to learn more about Proxy considerations on Windows, please take a look at this post in the ieinternals blog
|
||||
|
||||
### Logged-in user’s Internet connection
|
||||
|
||||
In order to accommodate complex proxy scenarios, we also support using the currently logged-in user’s internet connection. This scenario supports PAC scripts, proxy autodetection and authentication. Essentially, if the logged in user can reach the Windows Telemetry endpoints, the telemetry client can send data. If runconfig.bat runs while no user is logged in, telemetry events get written into a buffer which gets flushed when a user logs in.
|
||||
|
||||
In order to enable this scenario, you need:
|
||||
- A current quality update Rollup for Windows 7, 8.1 or Windows 10 Version 1511. Updates shipped after October 2016 have the needed code
|
||||
- Set the reg key HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DataCollection\DisableEnterpriseAuthProxy to 0. If the value does not exist, create a new DWORD, name it DisableEnterpriseAuthProxy and set the value to 0. The deployment script will check this is configured correctly.
|
||||
- Set ClientProxy=User in bat.
|
||||
|
||||
|
||||
@ -264,6 +264,26 @@ or <div style='font-size:7.0pt'>**HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersio
|
||||
<TD>Function **EndImpersonatingLoggedOnUser** failed with an unexpected exception.
|
||||
<TD>Check the logs for the exception message and HResult.
|
||||
|
||||
<TR><TD>44</TD>
|
||||
<TD>Function **Diagtrack.dll** version is old and so Auth Proxy will not work.
|
||||
<TD>Update the computer using Windows Update or WSUS.
|
||||
|
||||
<TR><TD>45</TD>
|
||||
<TD>**Diagtrack.dll** not found.
|
||||
<TD>Update the computer using Windows Update or WSUS.
|
||||
|
||||
<TR><TD>46</TD>
|
||||
<TD>**DisableEnterpriseAuthProxy** property should be set to 1 for ClientProxy=Telemetry to work.
|
||||
<TD>The ClientProxy=Telemetry scenario requires the **DisableEnterpriseAuthProxy** registry key to be set to 1 at registry path: **HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection**.
|
||||
|
||||
<TR><TD>47</TD>
|
||||
<TD>**TelemetryProxyServer** property is not present in the Windows registry at **HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection**.
|
||||
<TD>ClientProxy selected is Telemetry. The **TelemetryProxyServer** key is not present at Windows registry path: **HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection**.
|
||||
|
||||
<TR><TD>48</TD>
|
||||
<TD>The **CommercialID** referenced in RunConfig.bat must be a GUID.
|
||||
<TD>The **CommercialID** that is entered in RunConfig.bat must be a GUID. Copy the commercial ID from your workspace. To find the commercialID on the OMS portal, view Upgrade Readiness > Settings. You will find the commercial ID on the settings page.
|
||||
|
||||
</TABLE>
|
||||
|
||||
</div>
|
||||
|
||||
@ -79,14 +79,23 @@ For Upgrade Readiness to receive and display upgrade readiness data from Microso
|
||||
|
||||
To enable data sharing, whitelist the following endpoints. Note that you may need to get approval from your security group to do this.
|
||||
|
||||
Note: The compatibility update KB runs under the computer’s system account. If you are using user authenticated proxies, read [this blog post](https://blogs.technet.microsoft.com/upgradeanalytics/2017/03/10/understanding-connectivity-scenarios-and-the-deployment-script/) to learn what you need to do to run it under the logged on user account.
|
||||
|
||||
| **Endpoint** | **Function** |
|
||||
|---------------------------------------------------------|-----------|
|
||||
| `https://v10.vortex-win.data.microsoft.com/collect/v1`<br>`https://Vortex-win.data.microsoft.com/health/keepalive` | Connected User Experience and Telemetry component endpoint. User computers send data to Microsoft through this endpoint. |
|
||||
| `https://settings.data.microsoft.com/qos` | Enables the compatibility update KB to send data to Microsoft. |
|
||||
| `https://go.microsoft.com/fwlink/?LinkID=544713`<br>`https://compatexchange1.trafficmanager.net/CompatibilityExchangeService.svc` | This service provides driver information about whether there will be a driver available post-upgrade for the hardware on the system. |
|
||||
|
||||
Note: The compatibility update KB runs under the computer’s system account.
|
||||
|
||||
### Connection settings
|
||||
|
||||
The settings that are used to enable client computers to connect to Windows Telemetry depend on the type of connection scenario you use. These scenarios are discussed in [this blog post](https://blogs.technet.microsoft.com/upgradeanalytics/2017/03/10/understanding-connectivity-scenarios-and-the-deployment-script/) and are summarized below.
|
||||
|
||||
| **Connection scenario** | **ClientProxy setting** <BR>in **runconfig.bat** | **Local computer configuration** |
|
||||
|---------------------------------------------------------|-----------|-----------|
|
||||
| Direct connection to the Internet (no proxy) | **ClientProxy=Direct** | No additional configuration necessary |
|
||||
| WinHTTP proxy | **ClientProxy=System** | Specify `netsh winhttp set proxy <server>:<port>` on client computers |
|
||||
| Other proxy | **ClientProxy=User** | Configure the Windows Registry value: <p style="font-size: 12px"> **HKLM\SOFTWARE\Policies\Microsoft\Windows\DataCollection\DisableEnterpriseAuthProxy** </p> to 0 on client computers |
|
||||
|
||||
## Deploy the compatibility update and related KBs
|
||||
|
||||
|
||||
@ -20,6 +20,7 @@
|
||||
#### [Deploy code integrity policies: policy rules and file rules](deploy-code-integrity-policies-policy-rules-and-file-rules.md)
|
||||
#### [Deploy code integrity policies: steps](deploy-code-integrity-policies-steps.md)
|
||||
#### [Deploy catalog files to support code integrity policies](deploy-catalog-files-to-support-code-integrity-policies.md)
|
||||
#### [Deploy Managed Installer for Device Guard](deploy-managed-installer-for-device-guard.md)
|
||||
### [Deploy Device Guard: enable virtualization-based security](deploy-device-guard-enable-virtualization-based-security.md)
|
||||
## [Mitigate threats by using Windows 10 security features](overview-of-threat-mitigations-in-windows-10.md)
|
||||
## [Protect derived domain credentials with Credential Guard](credential-guard.md)
|
||||
@ -33,7 +34,6 @@
|
||||
## [Protect your enterprise data using Windows Information Protection (WIP)](protect-enterprise-data-using-wip.md)
|
||||
### [Create a Windows Information Protection (WIP) policy](overview-create-wip-policy.md)
|
||||
#### [Create a Windows Information Protection (WIP) policy using Microsoft Intune](create-wip-policy-using-intune.md)
|
||||
##### [Add apps to your Windows Information Protection (WIP) policy by using the Microsoft Intune custom URI functionality](add-apps-to-protected-list-using-custom-uri.md)
|
||||
##### [Deploy your Windows Information Protection (WIP) policy](deploy-wip-policy-using-intune.md)
|
||||
##### [Create and deploy a VPN policy for Windows Information Protection (WIP) using Microsoft Intune](create-vpn-and-wip-policy-using-intune.md)
|
||||
#### [Create and deploy a Windows Information Protection (WIP) policy using System Center Configuration Manager](create-wip-policy-using-sccm.md)
|
||||
@ -42,6 +42,7 @@
|
||||
### [Mandatory tasks and settings required to turn on Windows Information Protection (WIP)](mandatory-settings-for-wip.md)
|
||||
### [Testing scenarios for Windows Information Protection (WIP)](testing-scenarios-for-wip.md)
|
||||
### [Limitations while using Windows Information Protection (WIP)](limitations-with-wip.md)
|
||||
### [How to collect Windows Information Protection (WIP) audit event logs](collect-wip-audit-event-logs.md)
|
||||
### [General guidance and best practices for Windows Information Protection (WIP)](guidance-and-best-practices-wip.md)
|
||||
#### [Enlightened apps for use with Windows Information Protection (WIP)](enlightened-microsoft-apps-and-wip.md)
|
||||
#### [Unenlightened and enlightened app behavior while using Windows Information Protection (WIP)](app-behavior-with-wip.md)
|
||||
|
||||
@ -1,134 +0,0 @@
|
||||
---
|
||||
title: Add apps to your Windows Information Protection (WIP) policy by using Microsoft Intune custom URI functionality (Windows 10)
|
||||
description: Add apps to your Windows Information Protection (WIP) allowed app list, by using the Microsoft Intune custom URI functionality and AppLocker.
|
||||
ms.assetid: b50db35d-a2a9-4b78-a95d-a1b066e66880
|
||||
keywords: WIP, Enterprise Data Protection, protected apps, protected app list
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: explore
|
||||
ms.pagetype: security
|
||||
ms.sitesec: library
|
||||
author: eross-msft
|
||||
localizationpriority: high
|
||||
---
|
||||
|
||||
# Add apps to your Windows Information Protection (WIP) policy by using the Microsoft Intune custom URI functionality
|
||||
**Applies to:**
|
||||
|
||||
- Windows 10, version 1607 and later
|
||||
- Windows 10 Mobile
|
||||
|
||||
You can add apps to your Windows Information Protection (WIP) protected app list using the Microsoft Intune custom URI functionality and AppLocker. For more info about how to create a custom URI using Intune, [Windows 10 custom policy settings in Microsoft Intune](https://go.microsoft.com/fwlink/p/?LinkID=691330).
|
||||
|
||||
>[!IMPORTANT]
|
||||
>Results can be unpredictable if you configure your policy using both the UI and the Custom URI method together. We recommend using a single method for each policy.
|
||||
|
||||
## Add Store apps
|
||||
1. Go to the AppLocker UI by opening a command line window and running secpol.msc. The local security policy MMC snap-in opens showing the **Security Settings**.
|
||||
|
||||
2. In the left pane, expand **Application Control Policies**, expand **AppLocker**, right-click **Packaged app Rules**, and then click **Automatically Generate Rules**.
|
||||
|
||||
The **Automatically Generate Packaged app Rules** wizard opens, letting you create WIP-protected app polices for all of the installed apps on the device or for packaged apps within a specific folder.
|
||||
|
||||
3. In the **Folder and Permissions** screen, keep the default value of **Everyone** in the **User or security group that the rules will apply to** box.
|
||||
|
||||
You want to keep this value because your WIP policy needs to apply to the device being managed, not a single user or group of users.
|
||||
|
||||
4. Type the name you’ll use to tag the rules into the **Name to identify this set of rules** box, and then click **Next**.
|
||||
|
||||
This name should be easily recognizable, such as *WIP_StoreApps_Rules*.
|
||||
|
||||
5. In the **Rules Preferences** screen, keep the default settings, and then click **Next** to start generating the rules.
|
||||
|
||||
>[!Note]
|
||||
>We recommend that you use **Publisher** rules because they only work with apps you've specifically defined and they can be configured to not require updating simply because a new version came out.<br><br>If you can't use **Publisher** rules, we then recommend that you use **File hash** rules. **File hash** rules are a secure alternative that can be used on unsigned code. The primary disadvantage to **File hash** is that every time a binary changes (such as, through servicing updates or upgrades), you'll need to create a new rule.
|
||||
|
||||
6. In the **Review Rules** screen, look over your rules to make sure they’re right, and then click **Create** to add them to your collection of rules.
|
||||
|
||||
7. In the left pane, right-click **AppLocker**, click **Export Policies**, go to where you want to save the XML file and type a file name, click **Save**, and then clear your AppLocker rules.
|
||||
|
||||
>[!Important]
|
||||
>Be aware that what you're saving are the actual AppLocker rules using your local policy. You don't want to apply these rules to your employee devices, you just want to use them to create and export the XML content. You must delete the AppLocker rules before you apply your policy.
|
||||
|
||||
8. Open the Intune administration console, and go to the **Policy** node, click **Add Policy** from the **Tasks** area, go to **Windows**, click the **Custom Configuration (Windows 10 Desktop and Mobile and later)** policy, click **Create and Deploy a Custom Policy**, and then click **Create Policy**.
|
||||
|
||||
9. Type a name (required) and an optional description for your policy into the **Name** and **Description** boxes.
|
||||
|
||||
10. In the **Add one or more OMA-URI settings that control functionality on Windows devices** box, click **Add**.
|
||||
|
||||
11. Type your new **Setting Name** and **Description** into the associated boxes, keeping the default **Data Type** of **String**.
|
||||
|
||||
12. In the **OMA-URI** box, type `./Vendor/MSFT/AppLocker/EnterpriseDataProtection/<your_enterprise_name>/StoreApp EXE`
|
||||
|
||||
13. Open File Explorer, go to the location where you saved your new XML file, and open it using an XML editor, such as Notepad.
|
||||
|
||||
14. Copy the text that has a **Type** of `Appx`, within the **RuleCollection** tags, and then go back to Intune and paste the text into the **Value** box of the **Add or edit OMA-URI Setting** box. For example:
|
||||
|
||||
```
|
||||
<RuleCollection Type="Appx" EnforcementMode="Enabled"><your_xml_rules_here></RuleCollection>
|
||||
```
|
||||
|
||||
15. Click **OK** to close the **Add or edit OMA-URI Setting** box, and then click **Save Policy**.
|
||||
|
||||
After saving the policy, you’ll need to deploy it to your employee’s devices. For more info, see the [Deploy your Windows Information Protection (WIP) policy](deploy-wip-policy-using-intune.md) topic.
|
||||
|
||||
## Add Desktop apps
|
||||
1. Open the Local Security Policy snap-in (SecPol.msc).
|
||||
|
||||
2. In the left pane, expand **Application Control Policies**, expand **AppLocker**, right-click **Executable Rules**, and then click **Automatically Generate Rules**.
|
||||
|
||||
The **Automatically Generate Executable Rules** wizard opens, letting you create WIP-protected app polices by analyzing the files within a specific folder.
|
||||
|
||||
3. In the **Folder and Permissions** screen, keep the default value of **Everyone** in the **User or security group that the rules will apply to** box.
|
||||
|
||||
You want to keep this value because your WIP policy needs to apply to the device being managed, not a single user or group of users.
|
||||
|
||||
4. Type the name you’ll use to tag the rules into the **Name to identify this set of rules** box, and then click **Next**.
|
||||
|
||||
This name should be easily recognizable, such as *WIP_DesktopApps_Rules*.
|
||||
|
||||
5. In the **Rules Preferences** screen, keep the default settings, and then click **Next** to start generating the rules.
|
||||
|
||||
>[!Important]
|
||||
>You can also use **Path** rules instead of the **File hash** if you have concerns about unsigned files potentially changing the hash value if they're updated in the future.
|
||||
|
||||
>[!Note]
|
||||
>We recommend that you use **Publisher** rules because they only work with apps you've specifically defined and they can be configured to not require updating simply because a new version came out.<br><br>If you can't use **Publisher** rules, we then recommend that you use **File hash** rules. **File hash** rules are a secure alternative that can be used on unsigned code. The primary disadvantage to **File hash** is that every time a binary changes (such as, through servicing updates or upgrades), you'll need to create a new rule.<br><br>Finally, there's **Path** rules. **Path** rules are easier to set up and maintain, but can let apps bypass Windows Information Protection (WIP) by simply renaming and moving an unallowed file to match one of the apps on the **Protected App** list. For example, if your **Path** rule says to allow `%PROGRAMFILES%/NOTEPAD.EXE`, it becomes possible to rename DisallowedApp.exe to Notepad.exe, move it into the specified path above, and have it suddenly be allowed.
|
||||
|
||||
6. In the **Review Rules** screen, look over your rules to make sure they’re right, and then click **Create** to add them to your collection of rules.
|
||||
|
||||
7. In the left pane, right-click **AppLocker**, click **Export Policies**, go to where you want to save the XML file and type a file name, click **Save**, and then clear your AppLocker rules.
|
||||
|
||||
>[!Important]
|
||||
>Be aware that what you're saving are the actual AppLocker rules using your local policy. You don't want to apply these rules to your employee devices, you just want to use them to create and export the XML content. You must delete the AppLocker rules before you apply your policy.
|
||||
|
||||
8. Open the Intune administration console, and go to the **Policy** node, click **Add Policy** from the **Tasks** area, go to **Windows**, click the **Custom Configuration (Windows 10 Desktop and Mobile and later)** policy, click **Create and Deploy a Custom Policy**, and then click **Create Policy**.
|
||||
|
||||
9. Type a name (required) and an optional description for your policy into the **Name** and **Description** boxes.
|
||||
|
||||
10. In the **Add one or more OMA-URI settings that control functionality on Windows devices** box, click **Add**.
|
||||
|
||||
11. Type your new **Setting Name** and **Description** into the associated boxes, keeping the default **Data Type** of **String**.
|
||||
|
||||
12. In the **OMA-URI** box, type `./Vendor/MSFT/AppLocker/EnterpriseDataProtection/<your_enterprise_name>/EXE`
|
||||
|
||||
13. Open File Explorer, go to the location where you saved your new XML file, and open it using an XML editor, such as Notepad.
|
||||
|
||||
14. Copy the text that has a **Type** of `EXE`, within in the **RuleCollection** tags, and then go back to Intune and paste the text into the **Value** box of the **Add or edit OMA-URI Setting** box. For example:
|
||||
|
||||
```
|
||||
<RuleCollection Type="Exe" EnforcementMode="Enabled"><your_xml_rules_here></RuleCollection>
|
||||
```
|
||||
|
||||
15. Click **OK** to close the **Add or edit OMA-URI Setting** box, and then click **Save Policy**.
|
||||
|
||||
After saving the policy, you’ll need to deploy it to your employee’s devices. For more info, see the [Deploy your Windows Information Protection (WIP) policy](deploy-wip-policy-using-intune.md) topic.
|
||||
|
||||
>[!NOTE]
|
||||
>Help to make this topic better by providing us with edits, additions, and feedback. For info about how to contribute to this topic, see [Contributing to TechNet content](https://github.com/Microsoft/windows-itpro-docs/blob/master/CONTRIBUTING.md).
|
||||
|
||||
## Related topics
|
||||
- [Create a Windows Information Protection (WIP) policy using Microsoft Intune](create-wip-policy-using-intune.md)
|
||||
|
||||
- [Deploy your Windows Information Protection (WIP) policy](deploy-wip-policy-using-intune.md)
|
||||
|
||||
- [Create and deploy a VPN policy for Windows Information Protection (WIP) using Microsoft Intune](create-vpn-and-wip-policy-using-intune.md)
|
||||
@ -16,6 +16,7 @@ This topic lists new and updated topics in the [Keep Windows 10 secure](index.md
|
||||
## March 2017
|
||||
|New or changed topic |Description |
|
||||
|---------------------|------------|
|
||||
|[How to collect Windows Information Protection (WIP) audit event logs](collect-wip-audit-event-logs.md) |New |
|
||||
|[Mandatory tasks and settings required to turn on Windows Information Protection (WIP)](mandatory-settings-for-wip.md) |Updated based on Windows 10, version 1703. |
|
||||
|[Create a Windows Information Protection (WIP) policy using Microsoft Intune](create-wip-policy-using-intune.md) |Updated based on Windows 10, version 1703. |
|
||||
|[Deploy your Windows Information Protection (WIP) policy using Microsoft Intune](deploy-wip-policy-using-intune.md) |Updated based on Windows 10, version 1703.
|
||||
|
||||
172
windows/keep-secure/collect-wip-audit-event-logs.md
Normal file
172
windows/keep-secure/collect-wip-audit-event-logs.md
Normal file
@ -0,0 +1,172 @@
|
||||
---
|
||||
title: How to collect Windows Information Protection (WIP) audit event logs (Windows 10)
|
||||
description: How to collect and understand your Windows Information Protection audit event logs by using the Reporting configuration service provider (CSP) or the Windows Event Forwarding (for Windows desktop domain-joined devices only).
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: explore
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
author: eross-msft
|
||||
localizationpriority: high
|
||||
---
|
||||
|
||||
# How to collect Windows Information Protection (WIP) audit event logs
|
||||
|
||||
**Applies to:**
|
||||
|
||||
- Windows 10 and later
|
||||
- Windows 10 Mobile and later
|
||||
|
||||
Windows Information Protection (WIP) creates audit events in the following situations:
|
||||
|
||||
- If an employee changes the File ownership for a file from **Work** to **Personal**.
|
||||
|
||||
- If data is marked as **Work**, but shared to a personal app or webpage. For example, through copying and pasting, dragging and dropping, sharing a contact, uploading to a personal webpage, or if the user grants a personal app provides temporary access to a work file.
|
||||
|
||||
- If an app has custom audit events.
|
||||
|
||||
## Collect WIP audit logs by using the Reporting configuration service provider (CSP)
|
||||
Collect the WIP audit logs from your employee’s devices by following the guidance provided by the [Reporting configuration service provider (CSP)](https://msdn.microsoft.com/windows/hardware/commercialize/customize/mdm/reporting-csp) documentation. This topic provides info about the actual audit events.
|
||||
|
||||
>[!Note]
|
||||
>The **Data** element in the response includes the requested audit logs in an XML-encoded format.
|
||||
|
||||
### User element and attributes
|
||||
This table includes all available attributes for the **User** element.
|
||||
|
||||
|Attribute |Value type |Description |
|
||||
|----------|-----------|------------|
|
||||
|UserID |String |The security identifier (SID) of the user corresponding to this audit report. |
|
||||
|EnterpriseID |String |The enterprise ID corresponding to this audit report. |
|
||||
|
||||
### Log element and attributes
|
||||
This table includes all available attributes/elements for the **Log** element. The response can contain zero (0) or more **Log** elements.
|
||||
|
||||
|Attribute/Element |Value type |Description |
|
||||
|----------|-----------|------------|
|
||||
|ProviderType |String |This is always **EDPAudit**. |
|
||||
|LogType |String |Includes:<ul><li>**DataCopied.** Work data is copied or shared to a personal location.</li><li>**ProtectionRemoved.** WIP protection is removed from a Work-defined file.</li><li>**ApplicationGenerated.** A custom audit log provided by an app.</li></ul>|
|
||||
|TimeStamp |Int |Uses the [FILETIME structure](https://msdn.microsoft.com/library/windows/desktop/ms724284(v=vs.85).aspx) to represent the time that the event happened. |
|
||||
|Policy |String |How the work data was shared to the personal location:<ul><li>**CopyPaste.** Work data was pasted into a personal location or app.</li><li>**ProtectionRemoved.** Work data was changed to be unprotected.</li><li>**DragDrop.** Work data was dropped into a personal location or app.</li><li>**Share.** Work data was shared with a personal location or app.</li><li>**NULL.** Any other way work data could be made personal beyond the options above. For example, when a work file is opened using a personal application (also known as, temporary access).</li></ul> |
|
||||
|Justification |String |Not implemented. This will always be either blank or NULL.<br><br>**Note**<br>Reserved for future use to collect the user justification for changing from **Work** to **Personal**. |
|
||||
|Object |String |A description of the shared work data. For example, if an employee opens a work file by using a personal app, this would be the file path. |
|
||||
|DataInfo |String |Any additional info about how the work file changed:<ul><li>**A file path.** If an employee uploads a work file to a personal website by using Microsoft Edge or Internet Explorer, the file path is included here.</li><li>**Clipboard data types.** If an employee pastes work data into a personal app, the list of clipboard data types provided by the work app are included here. For more info, see the [Examples](#examples) section of this topic.</li></ul> |
|
||||
|Action |Int |Provides info about what happened when the work data was shared to personal, including:<ul><li>**1.** File decrypt.</li><li>**2.** Copy to location.</li><li>**3.** Send to recipient.</li><li>**4.** Other.</li></ul> |
|
||||
|FilePath |String |The file path to the file specified in the audit event. For example, the location of a file that’s been decrypted by an employee or uploaded to a personal website. |
|
||||
|SourceApplicationName |String |The source app or website. For the source app, this is the AppLocker identity. For the source website, this is the hostname. |
|
||||
|SourceName |String |A string provided by the app that’s logging the event. It’s intended to describe the source of the work data. |
|
||||
|DestinationEnterpriseID |String |The enterprise ID value for the app or website where the employee is sharing the data.<br><br>**NULL**, **Personal**, or **blank** means there’s no enterprise ID because the work data was shared to a personal location. Because we don’t currently support multiple enrollments, you’ll always see one of these values. |
|
||||
|DestinationApplicationName |String |The destination app or website. For the destination app, this is the AppLocker identity. For the destination website, this is the hostname. |
|
||||
|DestinationName |String |A string provided by the app that’s logging the event. It’s intended to describe the destination of the work data. |
|
||||
|Application |String |The AppLocker identity for the app where the audit event happened. |
|
||||
|
||||
### Examples
|
||||
Here are a few examples of responses from the Reporting CSP.
|
||||
|
||||
#### File ownership on a file is changed from work to personal
|
||||
```
|
||||
<SyncML><SyncHdr/><SyncBody><Status><CmdID>1</CmdID><MsgRef>1</MsgRef><CmdRef>0</CmdRef><Cmd>SyncHdr</Cmd><Data>200</Data></Status><Status><CmdID>2</CmdID><MsgRef>1</MsgRef><CmdRef>2</CmdRef><Cmd>Replace</Cmd><Data>200</Data></Status><Status><CmdID>3</CmdID><MsgRef>1</MsgRef><CmdRef>4</CmdRef><Cmd>Get</Cmd><Data>200</Data></Status><Results><CmdID>4</CmdID><MsgRef>1</MsgRef><CmdRef>4</CmdRef><Item><Source><LocURI>./Vendor/MSFT/Reporting/EnterpriseDataProtection/RetrieveByTimeRange/Logs</LocURI></Source><Meta><Format xmlns="syncml:metinf">xml</Format></Meta><Data><?xml version="1.0" encoding="utf-8"?>
|
||||
<Reporting Version="com.contoso/2.0/MDM/Reporting">
|
||||
<User UserID="S-1-12-1-1111111111-1111111111-1111111111-1111111111" EnterpriseID="corp.contoso.com">
|
||||
<Log ProviderType="EDPAudit" LogType="ProtectionRemoved" TimeStamp="131357166318347527">
|
||||
<Policy>Protection removed</Policy>
|
||||
<Justification>NULL</Justification>
|
||||
<FilePath>C:\Users\TestUser\Desktop\tmp\demo\Work document.docx</FilePath>
|
||||
</Log>
|
||||
</User>
|
||||
</Reporting></Data></Item></Results><Final/></SyncBody></SyncML>
|
||||
```
|
||||
|
||||
#### A work file is uploaded to a personal webpage in Edge
|
||||
```
|
||||
<SyncML><SyncHdr/><SyncBody><Status><CmdID>1</CmdID><MsgRef>1</MsgRef><CmdRef>0</CmdRef><Cmd>SyncHdr</Cmd><Data>200</Data></Status><Status><CmdID>2</CmdID><MsgRef>1</MsgRef><CmdRef>2</CmdRef><Cmd>Replace</Cmd><Data>200</Data></Status><Status><CmdID>3</CmdID><MsgRef>1</MsgRef><CmdRef>4</CmdRef><Cmd>Get</Cmd><Data>200</Data></Status><Results><CmdID>4</CmdID><MsgRef>1</MsgRef><CmdRef>4</CmdRef><Item><Source><LocURI>./Vendor/MSFT/Reporting/EnterpriseDataProtection/RetrieveByTimeRange/Logs</LocURI></Source><Meta><Format xmlns="syncml:metinf">xml</Format></Meta><Data><?xml version="1.0" encoding="utf-8"?>
|
||||
<Reporting Version="com.contoso/2.0/MDM/Reporting">
|
||||
<User UserID="S-1-12-1-1111111111-1111111111-1111111111-1111111111" EnterpriseID="corp.contoso.com">
|
||||
<Log ProviderType="EDPAudit" LogType="DataCopied" TimeStamp="131357192409318534">
|
||||
<Policy>CopyPaste</Policy>
|
||||
<Justification>NULL</Justification>
|
||||
<SourceApplicationName>NULL</SourceApplicationName>
|
||||
<DestinationEnterpriseID>NULL</DestinationEnterpriseID>
|
||||
<DestinationApplicationName>mail.contoso.com</DestinationApplicationName>
|
||||
<DataInfo>C:\Users\TestUser\Desktop\tmp\demo\Work document.docx</DataInfo>
|
||||
</Log>
|
||||
</User>
|
||||
</Reporting></Data></Item></Results><Final/></SyncBody></SyncML>
|
||||
```
|
||||
|
||||
#### Work data is pasted into a personal webpage
|
||||
```
|
||||
<SyncML><SyncHdr/><SyncBody><Status><CmdID>1</CmdID><MsgRef>1</MsgRef><CmdRef>0</CmdRef><Cmd>SyncHdr</Cmd><Data>200</Data></Status><Status><CmdID>2</CmdID><MsgRef>1</MsgRef><CmdRef>2</CmdRef><Cmd>Replace</Cmd><Data>200</Data></Status><Status><CmdID>3</CmdID><MsgRef>1</MsgRef><CmdRef>4</CmdRef><Cmd>Get</Cmd><Data>200</Data></Status><Results><CmdID>4</CmdID><MsgRef>1</MsgRef><CmdRef>4</CmdRef><Item><Source><LocURI>./Vendor/MSFT/Reporting/EnterpriseDataProtection/RetrieveByTimeRange/Logs</LocURI></Source><Meta><Format xmlns="syncml:metinf">xml</Format></Meta><Data><?xml version="1.0" encoding="utf-8"?>
|
||||
<Reporting Version="com.contoso/2.0/MDM/Reporting">
|
||||
<User UserID="S-1-12-1-1111111111-1111111111-1111111111-1111111111" EnterpriseID="corp.contoso.com">
|
||||
<Log ProviderType="EDPAudit" LogType="DataCopied" TimeStamp="131357193734179782">
|
||||
<Policy>CopyPaste</Policy>
|
||||
<Justification>NULL</Justification>
|
||||
<SourceApplicationName>O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US\MICROSOFT OFFICE 2016\WINWORD.EXE\16.0.8027.1000</SourceApplicationName>
|
||||
<DestinationEnterpriseID>NULL</DestinationEnterpriseID>
|
||||
<DestinationApplicationName>mail.contoso.com</DestinationApplicationName>
|
||||
<DataInfo>EnterpriseDataProtectionId|Object Descriptor|Rich Text Format|HTML Format|AnsiText|Text|EnhancedMetafile|Embed Source|Link Source|Link Source Descriptor|ObjectLink|Hyperlink</DataInfo>
|
||||
</Log>
|
||||
</User>
|
||||
</Reporting></Data></Item></Results><Final/></SyncBody></SyncML>
|
||||
```
|
||||
|
||||
#### A work file is opened with a personal application
|
||||
```
|
||||
<SyncML><SyncHdr/><SyncBody><Status><CmdID>1</CmdID><MsgRef>1</MsgRef><CmdRef>0</CmdRef><Cmd>SyncHdr</Cmd><Data>200</Data></Status><Status><CmdID>2</CmdID><MsgRef>1</MsgRef><CmdRef>2</CmdRef><Cmd>Replace</Cmd><Data>200</Data></Status><Status><CmdID>3</CmdID><MsgRef>1</MsgRef><CmdRef>4</CmdRef><Cmd>Get</Cmd><Data>200</Data></Status><Results><CmdID>4</CmdID><MsgRef>1</MsgRef><CmdRef>4</CmdRef><Item><Source><LocURI>./Vendor/MSFT/Reporting/EnterpriseDataProtection/RetrieveByTimeRange/Logs</LocURI></Source><Meta><Format xmlns="syncml:metinf">xml</Format></Meta><Data><?xml version="1.0" encoding="utf-8"?>
|
||||
<Reporting Version="com.contoso/2.0/MDM/Reporting">
|
||||
<User UserID="S-1-12-1-1111111111-1111111111-1111111111-1111111111" EnterpriseID="corp.contoso.com">
|
||||
<Log ProviderType="EDPAudit" LogType="ApplicationGenerated" TimeStamp="131357194991209469">
|
||||
<Policy>NULL</Policy>
|
||||
<Justification></Justification>
|
||||
<Object>C:\Users\TestUser\Desktop\tmp\demo\Work document.docx</Object>
|
||||
<Action>1</Action>
|
||||
<SourceName>O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US\MICROSOFT® WINDOWS® OPERATING SYSTEM\WORDPAD.EXE\10.0.15063.2</SourceName>
|
||||
<DestinationEnterpriseID>Personal</DestinationEnterpriseID>
|
||||
<DestinationName>O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US\MICROSOFT® WINDOWS® OPERATING SYSTEM\WORDPAD.EXE\10.0.15063.2</DestinationName>
|
||||
<Application>O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US\MICROSOFT® WINDOWS® OPERATING SYSTEM\WORDPAD.EXE\10.0.15063.2</Application>
|
||||
</Log>
|
||||
</User>
|
||||
</Reporting></Data></Item></Results><Final/></SyncBody></SyncML>
|
||||
```
|
||||
|
||||
#### Work data is pasted into a personal application
|
||||
```
|
||||
<SyncML><SyncHdr/><SyncBody><Status><CmdID>1</CmdID><MsgRef>1</MsgRef><CmdRef>0</CmdRef><Cmd>SyncHdr</Cmd><Data>200</Data></Status><Status><CmdID>2</CmdID><MsgRef>1</MsgRef><CmdRef>2</CmdRef><Cmd>Replace</Cmd><Data>200</Data></Status><Status><CmdID>3</CmdID><MsgRef>1</MsgRef><CmdRef>4</CmdRef><Cmd>Get</Cmd><Data>200</Data></Status><Results><CmdID>4</CmdID><MsgRef>1</MsgRef><CmdRef>4</CmdRef><Item><Source><LocURI>./Vendor/MSFT/Reporting/EnterpriseDataProtection/RetrieveByTimeRange/Logs</LocURI></Source><Meta><Format xmlns="syncml:metinf">xml</Format></Meta><Data><?xml version="1.0" encoding="utf-8"?>
|
||||
<Reporting Version="com.contoso/2.0/MDM/Reporting">
|
||||
<User UserID="S-1-12-1-1111111111-1111111111-1111111111-1111111111" EnterpriseID="corp.contoso.com">
|
||||
<Log ProviderType="EDPAudit" LogType="DataCopied" TimeStamp="131357196076537270">
|
||||
<Policy>CopyPaste</Policy>
|
||||
<Justification>NULL</Justification>
|
||||
<SourceApplicationName>O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US\MICROSOFT OFFICE 2016\WINWORD.EXE\16.0.8027.1000</SourceApplicationName>
|
||||
<DestinationEnterpriseID>NULL</DestinationEnterpriseID>
|
||||
<DestinationApplicationName></DestinationApplicationName>
|
||||
<DataInfo>EnterpriseDataProtectionId|Object Descriptor|Rich Text Format|HTML Format|AnsiText|Text|EnhancedMetafile|Embed Source|Link Source|Link Source Descriptor|ObjectLink|Hyperlink</DataInfo>
|
||||
</Log>
|
||||
</User>
|
||||
</Reporting></Data></Item></Results><Final/></SyncBody></SyncML>
|
||||
```
|
||||
|
||||
## Collect WIP audit logs by using Windows Event Forwarding (for Windows desktop domain-joined devices only)
|
||||
Use Windows Event Forwarding to collect and aggregate your WIP audit events. You can view your audit events in the Event Viewer.
|
||||
|
||||
>[!NOTE]
|
||||
>Windows 10 Mobile requires you to use the [Reporting CSP process](#collect-wip-audit-logs-by-using-the-reporting-configuration-service-provider-csp) instead.
|
||||
|
||||
**To view the WIP events in the Event Viewer**
|
||||
1. Open Event Viewer.
|
||||
|
||||
2. In the console tree under **Application and Services Logs\Microsoft\Windows**, click **EDP-Audit-Regular** and **EDP-Audit-TCB**.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -417,12 +417,12 @@ There are no default locations included with WIP, you must add each of your netw
|
||||
<tr>
|
||||
<td>Proxy servers</td>
|
||||
<td>proxy.contoso.com:80;proxy2.contoso.com:443</td>
|
||||
<td>Specify the proxy servers your devices will go through to reach your cloud resources. Using this server type indicates that the cloud resources you’re connecting to are enterprise resources.<br><br>This list shouldn’t include any servers listed in the Proxy servers list, which are used for non-WIP-protected traffic.<br><br>If you have multiple resources, you must separate them using the ";" delimiter.</td>
|
||||
<td>Specify the proxy servers your devices will go through to reach your cloud resources. Using this server type indicates that the cloud resources you’re connecting to are enterprise resources.<br><br>This list shouldn’t include any servers listed in the Internal proxy servers list, which are used for non-WIP-protected traffic.<br><br>If you have multiple resources, you must separate them using the ";" delimiter.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Internal proxy servers</td>
|
||||
<td>contoso.internalproxy1.com;contoso.internalproxy2.com</td>
|
||||
<td>Specify the proxy servers your devices will go through to reach your cloud resources.<br><br>Using this server type indicates that the cloud resources you’re connecting to are enterprise resources.<br><br>This list shouldn’t include any servers listed in the Enterprise Proxy Servers list, which are used for non-WIP-protected traffic.<br><br>If you have multiple resources, you must separate them using the ";" delimiter.</td>
|
||||
<td>Specify the proxy servers your devices will go through to reach your cloud resources. Using this server type indicates that the cloud resources you’re connecting to are enterprise resources.<br><br>This list shouldn’t include any servers listed in the Proxy servers list, which are used for WIP-protected traffic.<br><br>If you have multiple resources, you must separate them using the ";" delimiter.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>IPv4 ranges</td>
|
||||
|
||||
182
windows/keep-secure/deploy-managed-installer-for-device-guard.md
Normal file
182
windows/keep-secure/deploy-managed-installer-for-device-guard.md
Normal file
@ -0,0 +1,182 @@
|
||||
---
|
||||
title: Deploy Managed Installer for Device Guard (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 System Center Configuration Manager.
|
||||
keywords: virtualization, security, malware
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
localizationpriority: high
|
||||
author: mdsakibMSFT
|
||||
---
|
||||
|
||||
# Deploy Managed Installer for Device Guard
|
||||
|
||||
Creating and maintaining application execution control policies has always been challenging and options for addressing this has been a frequently cited request for customers of AppLocker and Device Guard’s [configurable code integrity (CI)](device-guard-deployment-guide.md).
|
||||
This is especially true for enterprises with large, ever changing software catalogs.
|
||||
|
||||
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 System Center 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?
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
Once the IT administrator adds the Allow: Managed Installer option to a configurable CI policy for Device Guard, the configurable CI 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.
|
||||
|
||||
> [!NOTE]
|
||||
> Admins needs to ensure that there is a CI policy in place to allow the system to boot and run any other authorized applications that may not be deployed through a managed installer.
|
||||
>
|
||||
> Examples of CI policies available in C:\Windows\schemas\CodeIntegrity\ExamplePolicies help authorize Windows OS components, WHQL signed drivers and all Store apps.
|
||||
> Admins can reference and customize them as needed for their Device Guard deployment.
|
||||
|
||||
## Configuring a managed installer with AppLocker and configurable code integrity policy
|
||||
|
||||
Setting up managed installer tracking and application execution enforcement requires applying both an AppLocker and configurable CI policy with specific rules and options enabled.
|
||||
There are three primary steps to keep in mind:
|
||||
|
||||
- Specify managed installers using the Managed Installer rule collection in AppLocker policy
|
||||
- Enable service enforcement in AppLocker policy
|
||||
- Enable the managed installer option in a configurable CI policy
|
||||
|
||||
### Specify managed installers using the Managed Installer rule collection in AppLocker policy
|
||||
|
||||
The identity of the managed installer executable(s) is specified in an AppLocker policy in a Managed Installer rule collection.
|
||||
Currently the AppLocker policy creation UI and cmdlets do not allow for directly specifying rules for the Managed Installer rule collection, however a text editor can be used to make the simple changes needed to an EXE or DLL rule collection policy to specify Type="ManagedInstaller".
|
||||
|
||||
An example of a valid Managed Installer rule collection is shown below.
|
||||
|
||||
```code
|
||||
<RuleCollection Type="ManagedInstaller" EnforcementMode="AuditOnly">
|
||||
<FilePublisherRule Id="6cc9a840-b0fd-4f86-aca7-8424a22b4b93" Name="CMM - CCMEXEC.EXE, 5.0.0.0+, Microsoft signed" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
|
||||
<Conditions>
|
||||
<FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="SYSTEM CENTER CONFIGURATION MANAGER" BinaryName="CCMEXEC.EXE">
|
||||
<BinaryVersionRange LowSection="5.0.0.0" HighSection="*" />
|
||||
</FilePublisherCondition>
|
||||
</Conditions>
|
||||
</FilePublisherRule>
|
||||
<FilePublisherRule Id="780ae2d3-5047-4240-8a57-767c251cbb12" Name="CCM - CCMSETUP.EXE, 5.0.0.0+, Microsoft signed" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
|
||||
<Conditions>
|
||||
<FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="SYSTEM CENTER CONFIGURATION MANAGER" BinaryName="CCMSETUP.EXE">
|
||||
<BinaryVersionRange LowSection="5.0.0.0" HighSection="*" />
|
||||
</FilePublisherCondition>
|
||||
</Conditions>
|
||||
</FilePublisherRule>
|
||||
</RuleCollection>
|
||||
```
|
||||
|
||||
## Enable service enforcement in AppLocker policy
|
||||
|
||||
Since many installation processes rely on services, it is typically necessary to enable tracking of services.
|
||||
Correct tracking of services requires the presence of at least one rule in the rule collection – a simple audit only rule will suffice.
|
||||
For example:
|
||||
|
||||
```code
|
||||
<RuleCollection Type="Dll" EnforcementMode="AuditOnly" >
|
||||
<FilePathRule Id="86f235ad-3f7b-4121-bc95-ea8bde3a5db5" Name="Dummy Rule" Description="" UserOrGroupSid="S-1-1-0" Action="Deny">
|
||||
<Conditions>
|
||||
<FilePathCondition Path="%OSDRIVE%\ThisWillBeBlocked.dll" />
|
||||
</Conditions>
|
||||
</FilePathRule>
|
||||
<RuleCollectionExtensions>
|
||||
<ThresholdExtensions>
|
||||
<Services EnforcementMode="Enabled" />
|
||||
</ThresholdExtensions>
|
||||
<RedstoneExtensions>
|
||||
<SystemApps Allow="Enabled"/>
|
||||
</RedstoneExtensions>
|
||||
</RuleCollectionExtensions>
|
||||
</RuleCollection>
|
||||
<RuleCollection Type="Exe" EnforcementMode="AuditOnly">
|
||||
<FilePathRule Id="9420c496-046d-45ab-bd0e-455b2649e41e" Name="Dummy Rule" Description="" UserOrGroupSid="S-1-1-0" Action="Deny">
|
||||
<Conditions>
|
||||
<FilePathCondition Path="%OSDRIVE%\ThisWillBeBlocked.exe" />
|
||||
</Conditions>
|
||||
</FilePathRule>
|
||||
<RuleCollectionExtensions>
|
||||
<ThresholdExtensions>
|
||||
<Services EnforcementMode="Enabled" />
|
||||
</ThresholdExtensions>
|
||||
<RedstoneExtensions>
|
||||
<SystemApps Allow="Enabled"/>
|
||||
</RedstoneExtensions>
|
||||
</RuleCollectionExtensions>
|
||||
</RuleCollection>
|
||||
```
|
||||
|
||||
### Enable the managed installer option in CI policy
|
||||
|
||||
In order to enable trust for the binaries laid down by managed installers, the Allow: Managed Installer option must be specified in your configurable CI policy. .
|
||||
This can be done by using the [Set-RuleOption cmdlet](https://technet.microsoft.com/itpro/powershell/windows/configci/set-ruleoption).
|
||||
An example of the managed installer option being set in policy is shown below.
|
||||
|
||||
```code
|
||||
<Rules>
|
||||
|
||||
<Rule>
|
||||
|
||||
<Option>Enabled:Unsigned System Integrity Policy</Option>
|
||||
|
||||
</Rule>
|
||||
|
||||
<Rule>
|
||||
|
||||
<Option>Enabled:Advanced Boot Options Menu</Option>
|
||||
|
||||
</Rule>
|
||||
|
||||
<Rule>
|
||||
|
||||
<Option>Enabled:UMCI</Option>
|
||||
|
||||
</Rule>
|
||||
|
||||
<Rule>
|
||||
|
||||
<Option>Enabled:Inherit Default Policy</Option>
|
||||
|
||||
</Rule>
|
||||
|
||||
<Rule>
|
||||
|
||||
<Option>Enabled:Managed Installer </Option>
|
||||
|
||||
</Rule>
|
||||
|
||||
</Rules>
|
||||
```
|
||||
|
||||
## 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.
|
||||
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 System Center Configuration Manager.
|
||||
|
||||
Users with administrator privileges on the system may be able to circumvent the intent of Device Guard configurable CI 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 may be able to circumvent the intent of Device Guard configurable CI policy.
|
||||
In some cases, the heuristic tracking and authorizing applications may be active on the first execution of an application that is laid down from a designated managed installer.
|
||||
Typically, this would occur if the managed installer executes the application directly as part of the installation process.
|
||||
To avoid this, ensure that the application deployment solution being used as a managed installer limits running applications as part of installation.
|
||||
|
||||
## Known limitations with managed installer
|
||||
|
||||
- Application execution control based on managed installer does not support applications that self-update.
|
||||
If an application deployed by a managed installer subsequently updates itself, the updated application files will no longer include the managed installer origin EA 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.
|
||||
|
||||
- Although configurable CI policies can be deployed in both audit and enforced mode, the managed installer option is currently only recommended for use with policies set to enforced except in lab environments.
|
||||
Using the managed installer option with configurable CI policies set to audit only may result in unexpected behavior if the policy is subsequently changed to enforced mode.
|
||||
|
||||
- Modern apps deployed through a managed installer will not be tracked by the heuristic and will need to be appropriately authorized in policy.
|
||||
|
||||
- Executables that extract files and then attempt to execute may fail the 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.
|
||||
|
||||
- The managed installer heuristic does not authorize drivers.
|
||||
The configurable code integrity policy being used must have rules that allow the necessary drivers to run.
|
||||
|
||||
- In some cases, the code integrity logs 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.
|
||||
@ -21,6 +21,8 @@ localizationpriority: high
|
||||
|
||||
The Windows 10 operating system introduces a new way to build, deploy, and service Windows: Windows as a service. Microsoft has reimagined each part of the process, to simplify the lives of IT pros and maintain a consistent Windows 10 experience for its customers. These improvements focus on maximizing customer involvement in Windows development, simplifying the deployment and servicing of Windows client computers, and leveling out the resources needed to deploy and maintain Windows over time.
|
||||
|
||||
<iframe width="560" height="315" align="center" src="https://www.youtube.com/embed/MLc4-Suv0LU" frameborder="0" allowfullscreen></iframe>
|
||||
|
||||
## Building
|
||||
|
||||
Prior to Windows 10, Microsoft released new versions of Windows every few years. This traditional deployment schedule imposed a training burden on users because the feature revisions were often significant. That schedule also meant waiting long periods without new features — a scenario that doesn’t work in today’s rapidly changing world, a world in which new security, management, and deployment capabilities are necessary to address challenges. Windows as a service will deliver smaller feature updates two to three times per year to help address these issues.
|
||||
|
||||
@ -202,7 +202,9 @@ To check out all the details, see [Configure Delivery Optimization for Windows 1
|
||||
|
||||
### Uninstalled in-box apps no longer automatically reinstall
|
||||
|
||||
When upgrading to Windows 10, version 1703, in-box apps that were uninstalled by the user won't automatically reinstall as part of the feature update installation process. (Apps de-provisioned by IT administrators will still be reinstalled.)
|
||||
Starting with Windows 10, version 1703, in-box apps that were uninstalled by the user won't automatically reinstall as part of the feature update installation process.
|
||||
|
||||
Additionally, apps de-provisioned by admins on Windows 10, version 1703 machines will stay de-provisioned after future feature update installations. This will not apply to the update from Windows 10, version 1607 (or earlier) to version 1703.
|
||||
|
||||
## Management
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user