mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-05-14 14:27:22 +00:00
Merge pull request #2126 from MicrosoftDocs/master
Publish 2/24/2020 10:32 AM PST
This commit is contained in:
Thomas Raya
GitHub
commit
f9bfa12e5b
@ -1,6 +1,6 @@
|
||||
---
|
||||
title: DMClient CSP
|
||||
description: Understand how the DMClient configuration service provider works. It is used to specify enterprise-specific mobile device management configuration settings.
|
||||
description: Understand how the DMClient configuration service provider (CSP) is used to specify enterprise-specific mobile device management (MDM) configuration settings.
|
||||
ms.assetid: a5cf35d9-ced0-4087-a247-225f102f2544
|
||||
ms.reviewer:
|
||||
manager: dansimp
|
||||
@ -15,9 +15,9 @@ ms.date: 11/01/2017
|
||||
# DMClient CSP
|
||||
|
||||
|
||||
The DMClient configuration service provider is used to specify additional enterprise-specific mobile device management configuration settings for identifying the device in the enterprise domain, security mitigation for certificate renewal, and server-triggered enterprise unenrollment.
|
||||
The DMClient configuration service provider (CSP) is used to specify additional enterprise-specific mobile device management (MDM) configuration settings for identifying the device in the enterprise domain, for security mitigation for certificate renewal, and for server-triggered enterprise unenrollment.
|
||||
|
||||
The following diagram shows the DMClient configuration service provider in tree format.
|
||||
The following diagram shows the DMClient CSP in tree format.
|
||||
|
||||
|
||||
|
||||
@ -25,7 +25,7 @@ The following diagram shows the DMClient configuration service provider in tree
|
||||
Root node for the CSP.
|
||||
|
||||
<a href="" id="updatemanagementserviceaddress"></a>**UpdateManagementServiceAddress**
|
||||
For provisioning packages only. Specifies the list of servers (semicolon delimited). The first server in the semi-colon delimited list is the server that will be used to instantiate MDM sessions. The list can be a permutation or a subset of the existing server list. You cannot add new servers to the list using this node.
|
||||
For provisioning packages only. Specifies the list of servers (semicolon delimited). The first server in the semicolon delimited list is the server that will be used to instantiate MDM sessions. The list can be a permutation or a subset of the existing server list. You cannot add new servers to the list using this node.
|
||||
|
||||
<a href="" id="hwdevid"></a>**HWDevID**
|
||||
Added in Windows 10, version 1703. Returns the hardware device ID.
|
||||
@ -45,16 +45,17 @@ For Intune, use **MS DM Server** for Windows desktop or **SCConfigMgr** for Wind
|
||||
Supported operations are Get and Add.
|
||||
|
||||
<a href="" id="provider-providerid-entdevicename"></a>**Provider/*ProviderID*/EntDeviceName**
|
||||
Optional. Character string that contains the user-friendly device name used by the IT admin console. The value is set during the enrollment process by way of the DMClient configuration service provider. You can retrieve it later during an OMA DM session.
|
||||
Optional. Character string that contains the user-friendly device name used by the IT admin console. The value is set during the enrollment process by way of the DMClient CSP. You can retrieve it later during an OMA DM session.
|
||||
|
||||
Supported operations are Get and Add.
|
||||
|
||||
<a href="" id="provider-providerid-entdmid"></a>**Provider/*ProviderID*/EntDMID**
|
||||
Optional. Character string that contains the unique enterprise device ID. The value is set by the management server during the enrollment process by way of the DMClient configuration service provider. You can retrieve it later during an OMA DM session.
|
||||
Optional. Character string that contains the unique enterprise device ID. The value is set by the management server during the enrollment process by way of the DMClient CSP. You can retrieve it later during an OMA DM session.
|
||||
|
||||
Supported operations are Get and Add.
|
||||
|
||||
> **Note** Although hardware device IDs are guaranteed to be unique, there is a concern that this is not ultimately enforceable during a DM session. The device ID could be changed through the w7 APPLICATION configuration service provider’s **USEHWDEVID** parm by another management server. So during enterprise bootstrap and enrollment, a new device ID is specified by the enterprise server.
|
||||
> [!NOTE]
|
||||
> Although hardware device IDs are guaranteed to be unique, there is a concern that this is not ultimately enforceable during a DM session. The device ID could be changed through the w7 APPLICATION CSP’s **USEHWDEVID** parm by another management server. So during enterprise bootstrap and enrollment, a new device ID is specified by the enterprise server.
|
||||
This node is required and must be set by the server before the client certificate renewal is triggered.
|
||||
|
||||
|
||||
@ -62,7 +63,8 @@ This node is required and must be set by the server before the client certificat
|
||||
<a href="" id="provider-providerid-exchangeid"></a>**Provider/*ProviderID*/ExchangeID**
|
||||
Optional. Character string that contains the unique Exchange device ID used by the Outlook account of the user the session is running against. This is useful for the enterprise management server to correlate and merge records for a device that is managed by exchange and natively managed by a dedicated management server.
|
||||
|
||||
> **Note** In some cases for the desktop, this node will return "not found" until the user sets up their email.
|
||||
> [!NOTE]
|
||||
> In some cases for the desktop, this node will return "not found" until the user sets up their email.
|
||||
|
||||
|
||||
|
||||
@ -87,7 +89,7 @@ The following is a Get command example.
|
||||
Supported operation is Get.
|
||||
|
||||
<a href="" id="provider-providerid-signedentdmid"></a>**Provider/*ProviderID*/SignedEntDMID**
|
||||
Optional. Character string that contains the device ID. This node and the nodes **CertRenewTimeStamp** can be used by the mobile device management server to verify client identity in order to update the registration record after the device certificate is renewed. The device signs the **EntDMID** with the old client certificate during the certificate renewal process and saves the signature locally.
|
||||
Optional. Character string that contains the device ID. This node and the nodes **CertRenewTimeStamp** can be used by the MDM server to verify client identity in order to update the registration record after the device certificate is renewed. The device signs the **EntDMID** with the old client certificate during the certificate renewal process and saves the signature locally.
|
||||
|
||||
Supported operation is Get.
|
||||
|
||||
@ -99,11 +101,12 @@ Supported operation is Get.
|
||||
<a href="" id="provider-providerid-managementserviceaddress"></a>**Provider/*ProviderID*/ManagementServiceAddress**
|
||||
Required. The character string that contains the device management server address. It can be updated during an OMA DM session by the management server to allow the server to load balance to another server in situations where too many devices are connected to the server.
|
||||
|
||||
> **Note** When the ManagementServerAddressList value is set, the device ignores the value in ManagementServiceAddress.
|
||||
> [!NOTE]
|
||||
> When the **ManagementServerAddressList** value is set, the device ignores the value.
|
||||
|
||||
|
||||
|
||||
The DMClient configuration service provider will save the address to the same location as the w7 and DMS configuration service providers to ensure the management client has a single place to retrieve the current server address. The initial value for this node is the same server address value as bootstrapped via the [w7 APPLICATION configuration service provider](w7-application-csp.md).
|
||||
The DMClient CSP will save the address to the same location as the w7 and DMS CSPs to ensure the management client has a single place to retrieve the current server address. The initial value for this node is the same server address value as bootstrapped via the [w7 APPLICATION configuration service provider](w7-application-csp.md).
|
||||
|
||||
Starting in Windows 10, version 1511, this node supports multiple server addresses in the format <URL1><URL2><URL3>. If there is only a single URL, then the <> are not required. This is supported for both desktop and mobile devices.
|
||||
|
||||
@ -143,8 +146,8 @@ Supported operations are Get, Replace, and Delete.
|
||||
<a href="" id="provider-providerid-syncapplicationversion"></a>**Provider/*ProviderID*/SyncApplicationVersion**
|
||||
Optional. Used by the management server to set the DM session version that the server and device should use. Default is 1.0. In Windows 10, the DM session protocol version of the client is 2.0. If the server is updated to support 2.0, then you should set this value to 2.0. In the next session, check to see if there is a client behavior change between 1.0 and 2.0.
|
||||
|
||||
> **Note**
|
||||
This node is only supported in Windows 10 and later.
|
||||
> [!NOTE]
|
||||
> This node is only supported in Windows 10 and later.
|
||||
|
||||
Once you set the value to 2.0, it will not go back to 1.0.
|
||||
|
||||
@ -160,9 +163,9 @@ When you query this node, a Windows 10 client will return 2.0 and a Windows 8.
|
||||
Supported operation is Get.
|
||||
|
||||
<a href="" id="provider-providerid-aadresourceid"></a>**Provider/*ProviderID*/AADResourceID**
|
||||
Optional. This is the ResourceID used when requesting the user token from the OMA DM session for Azure Active Directory enrollments (AAD Join or Add Accounts). The token is audience specific, which allows for different service principals (enrollment vs. device management). It can be an application ID or the endpoint that you are trying to access.
|
||||
Optional. This is the ResourceID used when requesting the user token from the OMA DM session for Azure Active Directory (Azure AD) enrollments (Azure AD Join or Add Accounts). The token is audience-specific, which allows for different service principals (enrollment vs. device management). It can be an application ID or the endpoint that you are trying to access.
|
||||
|
||||
For more information about Azure Active Directory enrollment, see [Azure Active Directory integration with MDM](azure-active-directory-integration-with-mdm.md).
|
||||
For more information about Azure AD enrollment, see [Azure Active Directory integration with MDM](azure-active-directory-integration-with-mdm.md).
|
||||
|
||||
<a href="" id="provider-providerid-enableomadmkeepalivemessage"></a>**Provider/*ProviderID*/EnableOmaDmKeepAliveMessage**
|
||||
Added in Windows 10, version 1511. A boolean value that specifies whether the DM client should send out a request pending alert in case the device response to a DM request is too slow.
|
||||
@ -203,7 +206,7 @@ Here is an example of DM message sent by the device when it is in pending state:
|
||||
```
|
||||
|
||||
<a href="" id="provider-providerid-aaddeviceid"></a>**Provider/*ProviderID*/AADDeviceID**
|
||||
Added in Windows 10, version 1607. Returns the device ID for the Azure Active Directory device registration.
|
||||
Added in Windows 10, version 1607. Returns the device ID for the Azure AD device registration.
|
||||
|
||||
Supported operation is Get.
|
||||
|
||||
@ -223,9 +226,10 @@ Added in Windows 10, version 1607. Configures the identifier used to uniquely a
|
||||
Supported operations are Add, Get, Replace, and Delete.
|
||||
|
||||
<a href="" id="provider-providerid-managementserveraddresslist"></a>**Provider/*ProviderID*/ManagementServerAddressList**
|
||||
Added in Windows 10, version 1607. The list of management server URLs in the format <URL1><URL2><URL3>, etc... If there is only one, the angle brackets (<>) are not required.
|
||||
Added in Windows 10, version 1607. The list of management server URLs in the format <URL1><URL2><URL3>, and so on. If there is only one, the angle brackets (<>) are not required.
|
||||
|
||||
> **Note** The < and > should be escaped.
|
||||
> [!NOTE]
|
||||
> The < and > should be escaped.
|
||||
|
||||
|
||||
|
||||
@ -260,6 +264,7 @@ Optional. Number of days after last successful sync to unenroll.
|
||||
Supported operations are Add, Delete, Get, and Replace. Value type is integer.
|
||||
|
||||
<a href="" id="provider-providerid-aadsenddevicetoken"></a>**Provider/*ProviderID*/AADSendDeviceToken**
|
||||
|
||||
Device. Added in Windows 10 version 1803. For Azure AD backed enrollments, this will cause the client to send a Device Token if the User Token can not be obtained.
|
||||
|
||||
Supported operations are Add, Delete, Get, and Replace. Value type is bool.
|
||||
@ -377,7 +382,8 @@ If there is no infinite schedule set, then a 24-hour schedule is created and sch
|
||||
|
||||
**Invalid poll schedule: disable all poll schedules**
|
||||
|
||||
> **Note** Disabling poll schedules results in UNDEFINED behavior and enrollment may fail if poll schedules are all set to zero.
|
||||
> [!NOTE]
|
||||
> Disabling poll schedules results in UNDEFINED behavior and enrollment may fail if poll schedules are all set to zero.
|
||||
|
||||
|
||||
|
||||
@ -557,7 +563,7 @@ Optional. Not configurable during WAP Provisioning XML. If removed, DM sessions
|
||||
Supported operations are Add and Delete.
|
||||
|
||||
<a href="" id="provider-providerid-push-pfn"></a>**Provider/*ProviderID*/Push/PFN**
|
||||
Required. A string provided by the Windows 10 ecosystem for a Mobile Device Management solution. Used to register a device for Push Notifications. The server must use the same PFN as the devices it is managing.
|
||||
Required. A string provided by the Windows 10 ecosystem for an MDM solution. Used to register a device for Push Notifications. The server must use the same PFN as the devices it is managing.
|
||||
|
||||
Supported operations are Add, Get, and Replace.
|
||||
|
||||
@ -665,7 +671,7 @@ Required. Added in Windows 10, version 1709. This node contains a list of LocURI
|
||||
Supported operations are Add, Delete, Get, and Replace. Value type is string.
|
||||
|
||||
<a href="" id="provider-providerid-firstsyncstatus-expectedmsiapppackages"></a>**Provider/*ProviderID*/FirstSyncStatus/ExpectedMSIAppPackages**
|
||||
Required. Added in Windows 10, version 1709. This node contains a list of LocURIs that refer to App Packages the management service provider expects to provision via EnterpriseDesktopAppManagement CSP, delimited by the character L"\xF000". The LocURI will be followed by a semicolon and a number, representing the amount of apps included in the App Package. We will not verify that number. For example, `./User/Vendor/MSFT/EnterpriseDesktopAppManagement/MSI/ProductID1/Status;4"\xF000" ./User/Vendor/MSFT/EnterpriseDesktopAppManagement/MSI/ProductID2/Status;2` This represents App Package ProductID1 containing 4 apps, and ProductID2 containing 2 apps.
|
||||
Required. Added in Windows 10, version 1709. This node contains a list of LocURIs that refer to App Packages the management service provider expects to provision via EnterpriseDesktopAppManagement CSP, delimited by the character L"\xF000". The LocURI will be followed by a semicolon and a number, representing the number of apps included in the App Package. We will not verify that number. For example, `./User/Vendor/MSFT/EnterpriseDesktopAppManagement/MSI/ProductID1/Status;4"\xF000" ./User/Vendor/MSFT/EnterpriseDesktopAppManagement/MSI/ProductID2/Status;2` This represents App Package ProductID1 containing four apps, and ProductID2 containing two apps.
|
||||
|
||||
Supported operations are Add, Delete, Get, and Replace. Value type is string.
|
||||
|
||||
@ -677,7 +683,7 @@ Required. Added in Windows 10, version 1709. This node contains a list of LocURI
|
||||
./Vendor/MSFT/EnterpriseModernAppManagement/AppManagement/AppStore/PackageFamilyName/PackageFullName2/Name;2
|
||||
```
|
||||
|
||||
This represents App Package PackageFullName containing 4 apps, and PackageFullName2 containing 2 apps.
|
||||
This represents App Package PackageFullName containing four apps, and PackageFullName2 containing two apps.
|
||||
|
||||
Supported operations are Add, Delete, Get, and Replace. Value type is string.
|
||||
|
||||
|
||||
@ -496,7 +496,7 @@
|
||||
|
||||
#### [Pull detections to your SIEM tools]()
|
||||
#### [Raw data streaming API]()
|
||||
##### [Raw data streaming (preview)](microsoft-defender-atp/raw-data-export.md)
|
||||
##### [Raw data streaming](microsoft-defender-atp/raw-data-export.md)
|
||||
##### [Stream advanced hunting events to Azure Events hub](microsoft-defender-atp/raw-data-export-event-hub.md)
|
||||
##### [Stream advanced hunting events to your storage account](microsoft-defender-atp/raw-data-export-storage.md)
|
||||
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 58 KiB After Width: | Height: | Size: 20 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 78 KiB After Width: | Height: | Size: 82 KiB |
@ -79,7 +79,7 @@ To get the data types for event properties do the following:
|
||||
|
||||
```
|
||||
|
||||
- Here is an example for Machine Info event:
|
||||
- Here is an example for Device Info event:
|
||||
|
||||
|
||||
|
||||
|
||||
@ -17,7 +17,7 @@ ms.collection: M365-security-compliance
|
||||
ms.topic: article
|
||||
---
|
||||
|
||||
# Raw Data Streaming API (Preview)
|
||||
# Raw Data Streaming API
|
||||
|
||||
**Applies to:**
|
||||
|
||||
|
||||
@ -12,7 +12,7 @@ ms.localizationpriority: medium
|
||||
author: denisebmsft
|
||||
ms.author: deniseb
|
||||
ms.custom: nextgen
|
||||
ms.date: 09/03/2018
|
||||
ms.date: 02/24/2020
|
||||
ms.reviewer:
|
||||
manager: dansimp
|
||||
---
|
||||
@ -30,13 +30,13 @@ For a list of the cmdlets and their functions and available parameters, see the
|
||||
PowerShell cmdlets are most useful in Windows Server environments that don't rely on a graphical user interface (GUI) to configure software.
|
||||
|
||||
> [!NOTE]
|
||||
> PowerShell cmdlets should not be used as a replacement for a full network policy management infrastructure, such as [Microsoft Endpoint Configuration Manager](https://docs.microsoft.com/configmgr), [Group Policy Management Console](https://technet.microsoft.com/library/cc731212.aspx), or [Windows Defender Antivirus Group Policy ADMX templates](https://support.microsoft.com/kb/927367).
|
||||
> PowerShell cmdlets should not be used as a replacement for a full network policy management infrastructure, such as [Microsoft Endpoint Configuration Manager](https://docs.microsoft.com/configmgr), [Group Policy Management Console](https://docs.microsoft.com/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc731212(v=ws.11)), or [Windows Defender Antivirus Group Policy ADMX templates](https://www.microsoft.com/download/100591).
|
||||
|
||||
Changes made with PowerShell will affect local settings on the endpoint where the changes are deployed or made. This means that deployments of policy with Group Policy, Microsoft Endpoint Configuration Manager, or Microsoft Intune can overwrite changes made with PowerShell.
|
||||
|
||||
You can [configure which settings can be overridden locally with local policy overrides](configure-local-policy-overrides-windows-defender-antivirus.md).
|
||||
|
||||
PowerShell is typically installed under the folder _%SystemRoot%\system32\WindowsPowerShell_.
|
||||
PowerShell is typically installed under the folder `%SystemRoot%\system32\WindowsPowerShell`.
|
||||
|
||||
## Use Windows Defender Antivirus PowerShell cmdlets
|
||||
|
||||
@ -45,7 +45,7 @@ PowerShell is typically installed under the folder _%SystemRoot%\system32\Window
|
||||
3. Enter the PowerShell command and any parameters.
|
||||
|
||||
> [!NOTE]
|
||||
> You may need to open an administrator-level version of PowerShell. Right-click the item in the Start menu, click **Run as administrator** and click **Yes** at the permissions prompt.
|
||||
> You may need to open PowerShell in administrator mode. Right-click the item in the Start menu, click **Run as administrator** and click **Yes** at the permissions prompt.
|
||||
|
||||
To open online help for any of the cmdlets type the following:
|
||||
|
||||
|
||||
@ -14,7 +14,7 @@ author: jsuther1974
|
||||
ms.reviewer: isbrahm
|
||||
ms.author: dansimp
|
||||
manager: dansimp
|
||||
ms.date: 04/20/2018
|
||||
ms.date: 02/24/2020
|
||||
---
|
||||
|
||||
# Understand WDAC policy rules and file rules
|
||||
@ -28,7 +28,7 @@ Windows Defender Application Control (WDAC) provides control over a computer run
|
||||
|
||||
## Windows Defender Application Control policy rules
|
||||
|
||||
To modify the policy rule options of an existing WDAC policy XML, use [Set-RuleOption](https://docs.microsoft.com/powershell/module/configci/set-ruleoption). Note the following examples of how to use this cmdlet to add and remove a rule option on an existing WDAC policy:
|
||||
To modify the policy rule options of an existing WDAC policy XML, use [Set-RuleOption](https://docs.microsoft.com/powershell/module/configci/set-ruleoption). The following examples show how to use this cmdlet to add and remove a rule option on an existing WDAC policy:
|
||||
|
||||
- To ensure that UMCI is enabled for a WDAC policy that was created with the `-UserPEs` (user mode) option, add rule option 0 to an existing policy by running the following command:
|
||||
|
||||
@ -120,9 +120,9 @@ There is a defined list of SIDs which WDAC recognizes as admins. If a filepath a
|
||||
WDAC's list of well-known admin SIDs are: <br>
|
||||
S-1-3-0; S-1-5-18; S-1-5-19; S-1-5-20; S-1-5-32-544; S-1-5-32-549; S-1-5-32-550; S-1-5-32-551; S-1-5-32-577; S-1-5-32-559; S-1-5-32-568; S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394; S-1-15-2-95739096-486727260-2033287795-3853587803-1685597119-444378811-2746676523.
|
||||
|
||||
When generating filepath rules using [New-CIPolicy](https://docs.microsoft.com/powershell/module/configci/new-cipolicy), a unique, fully-qualified path rule is generated for every file discovered in the scanned path(s). To create rules that instead allow all files under a specified folder path, use [New-CIPolicyRule](https://docs.microsoft.com/powershell/module/configci/new-cipolicyrule) to define rules containing wildcards and include them in your [New-CIPolicy](https://docs.microsoft.com/powershell/module/configci/new-cipolicy) scan using the -Rules switch.
|
||||
When generating filepath rules using [New-CIPolicy](https://docs.microsoft.com/powershell/module/configci/new-cipolicy), a unique, fully-qualified path rule is generated for every file discovered in the scanned path(s). To create rules that instead allow all files under a specified folder path, use [New-CIPolicyRule](https://docs.microsoft.com/powershell/module/configci/new-cipolicyrule) to define rules containing wildcards using the [-FilePathRules](https://docs.microsoft.com/powershell/module/configci/new-cipolicyrule#parameters) switch.
|
||||
|
||||
Wildcards can be used at the beginning or end of a path rule: only one wildcard is allowed per path rule. Wildcards placed at the end of a path authorize all files in that path and its subdirectories recursively (ex. C:\\* would include C:\foo\\* ). Wildcards placed at the beginning of a path will allow the exact specified filename under any path (ex. \*\bar.exe would allow C:\bar.exe and C:\foo\bar.exe). Wildcards in the middle of a path are not supported (ex. C:\\*\foo.exe). Without a wildcard, the rule will allow only a specific file (ex. C:\foo\bar.exe). <br> Supported macros: %WINDIR%, %SYSTEM32%, %OSDRIVE%.
|
||||
Wildcards can be used at the beginning or end of a path rule; only one wildcard is allowed per path rule. Wildcards placed at the end of a path authorize all files in that path and its subdirectories recursively (ex. `C:\\*` would include `C:\foo\\*` ). Wildcards placed at the beginning of a path will allow the exact specified filename under any path (ex. `*\bar.exe` would allow `C:\bar.exe` and `C:\foo\bar.exe`). Wildcards in the middle of a path are not supported (ex. `C:\\*\foo.exe`). Without a wildcard, the rule will allow only a specific file (ex. `C:\foo\bar.exe`). <br/> The use of macros is also supported and useful in scenarios where the system drive is different from the `C:\` drive. Supported macros: `%OSDRIVE%`, `%WINDIR%`, `%SYSTEM32%`.
|
||||
|
||||
> [!NOTE]
|
||||
> Due to an existing bug, you can not combine Path-based ALLOW rules with any DENY rules in a single policy. Instead, either separate DENY rules into a separate Base policy or move the Path-based ALLOW rules into a supplemental policy as described in [Deploy multiple WDAC policies.](deploy-multiple-windows-defender-application-control-policies.md)
|
||||
|
||||
@ -14,7 +14,6 @@ author: jsuther1974
|
||||
ms.reviewer: isbrahm
|
||||
ms.author: dansimp
|
||||
manager: dansimp
|
||||
ms.date: 06/14/2018
|
||||
---
|
||||
|
||||
# Authorize reputable apps with the Intelligent Security Graph (ISG)
|
||||
@ -24,34 +23,33 @@ ms.date: 06/14/2018
|
||||
- Windows 10
|
||||
- Windows Server 2016 and above
|
||||
|
||||
Application execution control can be difficult to implement in enterprises that do not have processes to effectively control the deployment of applications centrally through an IT managed system.
|
||||
In such environments, users are empowered to acquire the applications they need for work, making accounting for all the applications that would need to be authorized for execution control a daunting task.
|
||||
Application execution control can be difficult to implement in enterprises that do not have processes to effectively control the deployment of applications centrally through an IT managed system. In such environments, users are empowered to acquire the applications they need for work, making accounting for all the applications that would need to be authorized for execution control a daunting task.
|
||||
|
||||
Windows 10, version 1709 (also known as the Windows 10 Fall Creators Update) provides a new option, known as Intelligent Security Graph (ISG) authorization, that allows IT administrators to automatically authorize applications that Microsoft’s ISG recognizes as having known good reputation. The ISG option helps IT organizations take a significant first step towards going from having no application control at all to a simple means of preventing the execution of unknown and known bad software.
|
||||
Windows 10, version 1709 (also known as the Windows 10 Fall Creators Update) provides a new option, known as the Microsoft Intelligent Security Graph authorization, that allows IT administrators to automatically authorize applications that the Microsoft Intelligent Security Graph recognizes as having known good reputation. The the Microsoft Intelligent Security Graph option helps IT organizations take a significant first step towards going from having no application control at all to a simple means of preventing the execution of unknown and known bad software. To learn more about the Microsoft Intelligent Security Graph, see the Security section in [Major services and features in Microsoft Graph](https://docs.microsoft.com/graph/overview-major-services).
|
||||
|
||||
## How does the integration between WDAC and the Intelligent Security Graph work?
|
||||
|
||||
The ISG relies on Microsoft’s vast security intelligence and machine learning analytics to help classify applications as having known good reputation. When users download applications on a system with WDAC enabled with the ISG authorization option specified, the reputation of the downloaded file, commonly an installer, is used to determine whether to run the installer and then that original reputation information is passed along to any files that were written by the installer. When any of these files try to execute after they are installed, the reputation data is used to help make the right policy authorization decision.
|
||||
The the Microsoft Intelligent Security Graph relies on Microsoft’s vast security intelligence and machine learning analytics to help classify applications as having known good reputation. When users download applications on a system with WDAC enabled with the the Microsoft Intelligent Security Graph authorization option specified, the reputation of the downloaded file, commonly an installer, is used to determine whether to run the installer and then that original reputation information is passed along to any files that were written by the installer. When any of these files try to execute after they are installed, the reputation data is used to help make the right policy authorization decision.
|
||||
|
||||
After that initial download and installation, the WDAC component will check for the presence of the positive reputation 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 known good reputation classification.
|
||||
|
||||
The reputation data on the client is rechecked periodically and enterprises can also specify that any cached reputation results are flushed on reboot.
|
||||
|
||||
>[!NOTE]
|
||||
>Admins needs to ensure that there is a WDAC policy in place to allow the system to boot and run any other authorized applications that may not be classified as being known good by the Intelligent Security Graph, for example custom line-of-business (LOB) apps. Since the Intelligent Security Graph is powered by global prevalence data, internal LOB apps may not be recognized as being known good. Other mechanisms like managed installer and explicit rules will help cover internal applications. Both Microsoft Endpoint Configuration Manager and Microsoft Intune can be used to create and push a WDAC policy to your client machines.
|
||||
>Admins should make sure there is a WDAC policy in place to allow the system to boot and run any other authorized applications that may not be classified as being known good by the Intelligent Security Graph, such as custom line-of-business (LOB) apps. Since the Intelligent Security Graph is powered by global prevalence data, internal LOB apps may not be recognized as being known good. Other mechanisms like managed installer and explicit rules will help cover internal applications. Both Microsoft Endpoint Configuration Manager and Microsoft Intune can be used to create and push a WDAC policy to your client machines.
|
||||
|
||||
Other examples of WDAC policies are available in C:\Windows\schemas\CodeIntegrity\ExamplePolicies and can help authorize Windows OS components, WHQL signed drivers and all Store apps. Admins can reference and customize them as needed for their Windows Defender Application Control deployment or [create a custom WDAC policy](https://docs.microsoft.com/windows/security/threat-protection/windows-defender-application-control/create-initial-default-policy).
|
||||
Other examples of WDAC policies are available in `C:\Windows\schemas\CodeIntegrity\ExamplePolicies` and can help authorize Windows OS components, WHQL signed drivers and all Store apps. Admins can reference and customize them as needed for their Windows Defender Application Control deployment or [create a custom WDAC policy](https://docs.microsoft.com/windows/security/threat-protection/windows-defender-application-control/create-initial-default-policy).
|
||||
|
||||
## Configuring Intelligent Security Graph authorization for Windows Defender Application Control
|
||||
|
||||
Setting up the ISG authorization is easy regardless of what management solution you use. Configuring the ISG option involves these basic steps:
|
||||
Setting up the Microsoft Intelligent Security Graph authorization is easy regardless of what management solution you use. Configuring the Microsoft Intelligent Security Graph option involves these basic steps:
|
||||
|
||||
- [Ensure that the ISG option is enabled in the WDAC policy XML](#ensure-that-the-intelligent-security-graph-option-is-enabled-in-the-wdac-policy-xml)
|
||||
- [Enable the necessary services to allow WDAC to use the ISG correctly on the client](#enable-the-necessary-services-to-allow-wdac-to-use-the-isg-correctly-on-the-client)
|
||||
- [Ensure that the Microsoft Intelligent Security Graph option is enabled in the WDAC policy XML](#ensure-that-the-intelligent-security-graph-option-is-enabled-in-the-wdac-policy-xml)
|
||||
- [Enable the necessary services to allow WDAC to use the Microsoft Intelligent Security Graph correctly on the client](#enable-the-necessary-services-to-allow-wdac-to-use-the-isg-correctly-on-the-client)
|
||||
|
||||
### Ensure that the Intelligent Security Graph option is enabled in the WDAC policy XML
|
||||
|
||||
In order to enable trust for executables based on classifications in the ISG, the **Enabled:Intelligent Security Graph authorization** option must be specified in the WDAC policy. This can be done with the Set-RuleOption cmdlet. In addition, it is recommended from a security perspective to also enable the **Enabled:Invalidate EAs on Reboot** option to invalidate the cached ISG results on reboot to force rechecking of applications against the ISG. Caution is advised if devices will regularly transition to and from environments that may not be able to access the ISG. The following example shows both options being set.
|
||||
In order to enable trust for executables based on classifications in the Microsoft Intelligent Security Graph, the **Enabled:Intelligent Security Graph authorization** option must be specified in the WDAC policy. This can be done with the Set-RuleOption cmdlet. In addition, it is recommended from a security perspective to also enable the **Enabled:Invalidate EAs on Reboot** option to invalidate the cached Intelligent Security Graph results on reboot to force rechecking of applications against the Microsoft Intelligent Security Graph. Caution is advised if devices will regularly transition to and from environments that may not be able to access the Microsoft Intelligent Security Graph. The following example shows both options being set.
|
||||
|
||||
```code
|
||||
<Rules>
|
||||
@ -81,7 +79,7 @@ In order to enable trust for executables based on classifications in the ISG, th
|
||||
|
||||
### Enable the necessary services to allow WDAC to use the ISG correctly on the client
|
||||
|
||||
In order for the heuristics used by the ISG to function properly, a number of component in Windows need to be enabled. The easiest way to do this is to run the appidtel executable in c:\windows\system32.
|
||||
In order for the heuristics used by the Microsoft Intelligent Security Graph to function properly, a number of component in Windows must be enabled. The easiest way to do this is to run the appidtel executable in `c:\windows\system32`.
|
||||
|
||||
```
|
||||
appidtel start
|
||||
@ -91,19 +89,19 @@ For WDAC policies deployed over MDM using the AppLocker CSP this step is not req
|
||||
|
||||
## Security considerations with the Intelligent Security Graph
|
||||
|
||||
Since the ISG is a heuristic-based mechanism, it does not provide the same security guarantees that explicit allow or deny rules do. It is best suited for deployment to systems where each user is configured as a standard user and there are other monitoring systems in place like Windows Defender Advanced Threat Protection to help provide optics into what users are doing.
|
||||
Since the Microsoft Intelligent Security Graph is a heuristic-based mechanism, it does not provide the same security guarantees that explicit allow or deny rules do. It is best suited for deployment to systems where each user is configured as a standard user and there are other monitoring systems in place like Microsoft Defender Advanced Threat Protection to help provide optics into what users are doing.
|
||||
|
||||
Users with administrator privileges or malware running as an administrator user on the system may be able to circumvent the intent of WDAC when the ISG option is allowed by circumventing or corrupting the heuristics used to assign reputation to application executables. The ISG option uses the same heuristic tracking as managed installer and so for application installers that include an option to automatically run the application at the end of the installation process the heuristic may over-authorize.
|
||||
Users with administrator privileges or malware running as an administrator user on the system may be able to circumvent the intent of WDAC when the Microsoft Intelligent Security Graph option is allowed by circumventing or corrupting the heuristics used to assign reputation to application executables. The Microsoft Intelligent Security Graph option uses the same heuristic tracking as managed installer and so for application installers that include an option to automatically run the application at the end of the installation process the heuristic may over-authorize.
|
||||
|
||||
## Known limitations with using the Intelligent Security Graph
|
||||
|
||||
Since the ISG relies on identifying executables as being known good, there are cases where it may classify legitimate executables as unknown, leading to blocks that need to be resolved either with a rule in the WDAC policy, a catalog signed by a certificate trusted in the WDAC policy or by deployment through a WDAC managed installer. Typically, this is due to an installer or application using a dynamic file as part of execution. These files do not tend to build up known good reputation. Auto-updating applications have also been observed using this mechanism and may be flagged by the ISG.
|
||||
Since the Microsoft Intelligent Security Graph relies on identifying executables as being known good, there are cases where it may classify legitimate executables as unknown, leading to blocks that need to be resolved either with a rule in the WDAC policy, a catalog signed by a certificate trusted in the WDAC policy or by deployment through a WDAC managed installer. Typically, this is due to an installer or application using a dynamic file as part of execution. These files do not tend to build up known good reputation. Auto-updating applications have also been observed using this mechanism and may be flagged by the ISG.
|
||||
|
||||
Modern apps are not supported with the ISG heuristic and will need to be separately authorized in your WDAC policy. As modern apps are signed by the Microsoft Store and Microsoft Store for Business, it is straightforward to authorize modern apps with signer rules in the WDAC policy.
|
||||
Modern apps are not supported with the Microsoft Intelligent Security Graph heuristics and will need to be separately authorized in your WDAC policy. As modern apps are signed by the Microsoft Store and Microsoft Store for Business, it is straightforward to authorize modern apps with signer rules in the WDAC policy.
|
||||
|
||||
The ISG heuristic does not authorize kernel mode drivers. The WDAC policy must have rules that allow the necessary drivers to run.
|
||||
The Microsoft Intelligent Security Graph heuristics do not authorize kernel mode drivers. The WDAC policy must have rules that allow the necessary drivers to run.
|
||||
|
||||
In some cases, the code integrity logs where WDAC errors and warnings are written will contain error events for native images generated for .NET assemblies. Typically, the error is functionally benign as a blocked native image will result in the corresponding assembly being re-interpreted. Review for functionality and performance for the related applications using the native images maybe necessary in some cases.
|
||||
|
||||
>[!NOTE]
|
||||
> A rule that explicitly allows an application will take precedence over the ISG rule that does not allow it. In this scenario, this policy is not compatible with Intune, where there is no option to add rules to the template that enables ISG. In most circumstances you would need to build a custom WDAC policy, including ISG if desired.
|
||||
> A rule that explicitly allows an application will take precedence over the Microsoft Intelligent Security Graph rule that does not allow it. In this scenario, this policy is not compatible with Intune, where there is no option to add rules to the template that enables the Microsoft Intelligent Security Graph. In most circumstances you would need to build a custom WDAC policy, including the Microsoft Intelligent Security Graph, if desired.
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user