From a45e71aab3b6ea35447349f48af48d406142b325 Mon Sep 17 00:00:00 2001 From: Siddarth Mandalika Date: Wed, 2 Mar 2022 16:49:50 +0530 Subject: [PATCH] Acrolinx changes --- windows/client-management/mdm/euiccs-csp.md | 16 ++-- ...erated-authentication-device-enrollment.md | 40 ++++---- windows/client-management/mdm/firewall-csp.md | 56 +++++------ .../mdm/get-seats-assigned-to-a-user.md | 6 +- .../mdm/healthattestation-csp.md | 94 +++++++++---------- ...rver-side-mobile-application-management.md | 31 +++--- windows/client-management/mdm/index.md | 4 +- 7 files changed, 125 insertions(+), 122 deletions(-) diff --git a/windows/client-management/mdm/euiccs-csp.md b/windows/client-management/mdm/euiccs-csp.md index 3ac910ac33..aea59b7da0 100644 --- a/windows/client-management/mdm/euiccs-csp.md +++ b/windows/client-management/mdm/euiccs-csp.md @@ -1,6 +1,6 @@ --- title: eUICCs CSP -description: Learn how the eUICCs CSP is used to support eUICC enterprise use cases and enables the IT admin to manage (assign, re-assign, remove) subscriptions to employees. +description: Learn how the eUICCs CSP is used to support eUICC enterprise use cases and enables the IT admin to manage (assign, reassign, remove) subscriptions to employees. ms.author: dansimp ms.topic: article ms.prod: w10 @@ -14,9 +14,9 @@ manager: dansimp # eUICCs CSP -The eUICCs configuration service provider is used to support eUICC enterprise use cases and enables the IT admin to manage (assign, re-assign, remove) subscriptions to employees. This CSP was added in windows 10, version 1709. +The eUICCs configuration service provider is used to support eUICC enterprise use cases and enables the IT admin to manage (assign, reassign, remove) subscriptions to employees. This CSP was added in windows 10, version 1709. -The following shows the eUICCs configuration service provider in tree format. +The following example shows the eUICCs configuration service provider in tree format. ``` ./Device/Vendor/MSFT eUICCs @@ -48,12 +48,12 @@ eUICCs Root node. **_eUICC_** -Interior node. Represents information associated with an eUICC. There is one subtree for each known eUICC, created by the Local Profile Assistant (LPA) when the eUICC is first seen. The node name is meaningful only to the LPA (which associates it with an eUICC ID (EID) in an implementation-specific manner, e.g., this could be a SHA-256 hash of the EID). The node name "Default" represents the currently active eUICC. +Interior node. Represents information associated with an eUICC. There's one subtree for each known eUICC, created by the Local Profile Assistant (LPA) when the eUICC is first seen. The node name is meaningful only to the LPA (which associates it with an eUICC ID (EID) in an implementation-specific manner, for example, this association could be an SHA-256 hash of the EID). The node name "Default" represents the currently active eUICC. Supported operation is Get. **_eUICC_/Identifier** -Required. Identifies an eUICC in an implementation-specific manner, e.g., this could be a SHA-256 hash of the EID. +Required. Identifies an eUICC in an implementation-specific manner, for example, this identification could be an SHA-256 hash of the EID. Supported operation is Get. Value type is string. @@ -63,7 +63,7 @@ Required. Indicates whether this eUICC is physically present and active. Updated Supported operation is Get. Value type is boolean. **_eUICC_/PPR1Allowed** -Profile Policy Rule 1 (PPR1) is required. Indicates whether the download of a profile with PPR1 is allowed. If the eUICC already has a profile (regardless of its origin and policy rules associated with it), the download of a profile with PPR1 is not allowed. +Profile Policy Rule 1 (PPR1) is required. Indicates whether the download of a profile with PPR1 is allowed. If the eUICC already has a profile (regardless of its origin and policy rules associated with it), the download of a profile with PPR1 isn't allowed. Supported operation is Get. Value type is boolean. @@ -88,7 +88,7 @@ Required. Current state of the discovery operation for the parent ServerName (Re Supported operation is Get. Value type is integer. Default value is 1. **_eUICC_/DownloadServers/_ServerName_/AutoEnable** -Required. Indicates whether the discovered profile must be enabled automatically after install. This must be set by the MDM when the ServerName subtree is created. +Required. Indicates whether the discovered profile must be enabled automatically after install. This setting must be defined by the MDM when the ServerName subtree is created. Supported operations are Add, Get, and Replace. Value type is bool. @@ -133,7 +133,7 @@ Required. Determines whether the local user interface of the LUI is available (t Supported operations are Get and Replace. Value type is boolean. Default value is true. **_eUICC_/Actions** -Interior node. Required. Actions that can be performed on the eUICC as a whole (when it is active). +Interior node. Required. Actions that can be performed on the eUICC as a whole (when it's active). Supported operation is Get. diff --git a/windows/client-management/mdm/federated-authentication-device-enrollment.md b/windows/client-management/mdm/federated-authentication-device-enrollment.md index 254ba46424..6dc5301d1b 100644 --- a/windows/client-management/mdm/federated-authentication-device-enrollment.md +++ b/windows/client-management/mdm/federated-authentication-device-enrollment.md @@ -14,7 +14,7 @@ ms.date: 07/28/2017 # Federated authentication device enrollment -This section provides an example of the mobile device enrollment protocol using federated authentication policy. When the authentication policy is set to Federated, the web authentication broker is leveraged by the enrollment client to get a security token. The enrollment client calls the web authentication broker API within the response message to start the process. The server should build the web authentication broker pages to fit the device screen and should be consistent with the existing enrollment UI. The opaque security token that is returned from the broker as an end page is used by the enrollment client as the device security secret during the client certificate request call. +This section provides an example of the mobile device enrollment protocol using federated authentication policy. When the authentication policy is set to Federated, the web authentication broker is used by the enrollment client to get a security token. The enrollment client calls the web authentication broker API within the response message to start the process. The server should build the web authentication broker pages to fit the device screen and should be consistent with the existing enrollment UI. The opaque security token that is returned from the broker as an end page is used by the enrollment client as the device security secret during the client certificate request call. The `` element the discovery response message specifies web authentication broker page start URL. @@ -75,9 +75,9 @@ After the device gets a response from the server, the device sends a POST reques The following logic is applied: -1. The device first tries HTTPS. If the server cert is not trusted by the device, the HTTPS fails. -2. If that fails, the device tries HTTP to see whether it is redirected: - - If the device is not redirected, it prompts the user for the server address. +1. The device first tries HTTPS. If the server cert isn't trusted by the device, the HTTPS fails. +2. If that fails, the device tries HTTP to see whether it's redirected: + - If the device isn't redirected, it prompts the user for the server address. - If the device is redirected, it prompts the user to allow the redirect. The following example shows a request via an HTTP POST command to the discovery web service given user@contoso.com as the email address @@ -126,12 +126,12 @@ The discovery response is in the XML format and includes the following fields: - Enrollment service URL (EnrollmentServiceUrl) – Specifies the URL of the enrollment endpoint that is exposed by the management service. The device should call this URL after the user has been authenticated. This field is mandatory. - Authentication policy (AuthPolicy) – Indicates what type of authentication is required. For the MDM server, OnPremise is the supported value, which means that the user will be authenticated when calling the management service URL. This field is mandatory. -- In Windows, Federated is added as another supported value. This allows the server to leverage the Web Authentication Broker to perform customized user authentication, and term of usage acceptance. +- In Windows, Federated is added as another supported value. This addition allows the server to use the Web Authentication Broker to perform customized user authentication, and term of usage acceptance. > [!Note] > The HTTP server response must not set Transfer-Encoding to Chunked; it must be sent as one message. -When authentication policy is set to be Federated, Web Authentication Broker (WAB) will be leveraged by the enrollment client to get a security token. The WAB start page URL is provided by the discovery service in the response message. The enrollment client will call the WAB API within the response message to start the WAB process. WAB pages are server hosted web pages. The server should build those pages to fit the device screen nicely and be as consistent as possible to other builds in the MDM enrollment UI. The opaque security token that is returned from WAB as an endpage will be used by the enrollment client as the device security secret during the client certificate enrollment request call. +When authentication policy is set to be Federated, Web Authentication Broker (WAB) will be used by the enrollment client to get a security token. The WAB start page URL is provided by the discovery service in the response message. The enrollment client will call the WAB API within the response message to start the WAB process. WAB pages are server hosted web pages. The server should build those pages to fit the device screen nicely and be as consistent as possible to other builds in the MDM enrollment UI. The opaque security token that is returned from WAB as an endpage will be used by the enrollment client as the device security secret during the client certificate enrollment request call. > [!Note] > Instead of relying on the user agent string that is passed during authentication to get information, such as the OS version, use the following guidance: @@ -157,12 +157,12 @@ AuthenticationServiceUrl?appru=&login_hint= ``` - `` is of the form ms-app://string -- `` is the name of the enrolling user, for example, user@constoso.com as input by the user in an enrollment sign in page. The value of this attribute serves as a hint that can be used by the authentication server as part of the authentication. +- `` is the name of the enrolling user, for example, user@constoso.com as input by the user in an enrollment sign-in page. The value of this attribute serves as a hint that can be used by the authentication server as part of the authentication. After authentication is complete, the auth server should return an HTML form document with a POST method action of appid identified in the query string parameter. > [!NOTE] -> To make an application compatible with strict Content Security Policy, it is usually necessary to make some changes to HTML templates and client-side code, add the policy header, and test that everything works properly once the policy is deployed. +> To make an application compatible with strict Content Security Policy, it's usually necessary to make some changes to HTML templates and client-side code, add the policy header, and test that everything works properly once the policy is deployed. ```html HTTP/1.1 200 OK @@ -191,9 +191,9 @@ Content-Length: 556 ``` -The server has to send a POST to a redirect URL of the form ms-app://string (the URL scheme is ms-app) as indicated in the POST method action. The security token value is the base64-encoded string `http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd\#base64binary` contained in the `` EncodingType attribute. Windows does the binary encode when it sends it back to enrollment server, in the form it is just HTML encoded. This string is opaque to the enrollment client; the client does not interpret the string. +The server has to send a POST to a redirect URL of the form ms-app://string (the URL scheme is ms-app) as indicated in the POST method action. The security token value is the base64-encoded string `http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd\#base64binary` contained in the `` EncodingType attribute. Windows does the binary encode when it sends it back to enrollment server, in the form it's just HTML encoded. This string is opaque to the enrollment client; the client doesn't interpret the string. -The following example shows a response received from the discovery web service which requires authentication via WAB. +The following example shows a response received from the discovery web service that requires authentication via WAB. ```xml ` element defined in \[WSS\] section 5. The `` element must be a child of the `` element. - wsse:BinarySecurityToken: The enrollment client implements the `` element defined in \[WSS\] section 6.3. The `` element must be included as a child of the `` element in the SOAP header. -As was described in the discovery response section, the inclusion of the `` element is opaque to the enrollment client, and the client does not interpret the string, and the inclusion of the element is agreed upon by the security token authentication server (as identified in the `` element of `` and the enterprise server. +As was described in the discovery response section, the inclusion of the `` element is opaque to the enrollment client, and the client doesn't interpret the string, and the inclusion of the element is agreed upon by the security token authentication server (as identified in the `` element of `` and the enterprise server. The `` element contains a base64-encoded string. The enrollment client uses the security token received from the authentication server and base64-encodes the token to populate the `` element. @@ -248,7 +248,7 @@ The `` element contains a base64-encoded string. The e - wsse:BinarySecurityToken/attributes/EncodingType: The `` EncodingType attribute must be `http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd\#base64binary`. -The following is an enrollment policy request example with a received security token as client credential. +The following example is an enrollment policy request with a received security token as client credential. ```xml [!NOTE] > The HTTP server response must not set Transfer-Encoding to Chunked; it must be sent as one message. @@ -381,11 +381,11 @@ The following snippet shows the policy web service response. This web service implements the MS-WSTEP protocol. It processes the RequestSecurityToken (RST) message from the client, authenticates the client, requests the certificate from the CA, and returns it in the RequestSecurityTokenResponse (RSTR) to the client. Besides the issued certificate, the response also contains configurations needed to provision the DM client. -The RequestSecurityToken (RST) must have the user credential and a certificate request. The user credential in an RST SOAP envelope is the same as in GetPolicies, and can vary depending on whether the authentication policy is OnPremise or Federated. The BinarySecurityToken in an RST SOAP body contains a Base64-encoded PKCS\#10 certificate request, which is generated by the client based on the enrollment policy. The client could have requested an enrollment policy by using MS-XCEP before requesting a certificate using MS-WSTEP. If the PKCS\#10 certificate request is accepted by the certification authority (CA) (the key length, hashing algorithm, and so on match the certificate template), the client can enroll successfully. +The RequestSecurityToken (RST) must have the user credential and a certificate request. The user credential in an RST SOAP envelope is the same as in GetPolicies, and can vary depending on whether the authentication policy is OnPremise or Federated. The BinarySecurityToken in an RST SOAP body contains a Base64-encoded PKCS\#10 certificate request, which is generated by the client based on the enrollment policy. The client could have requested an enrollment policy by using MS-XCEP before requesting a certificate using MS-WSTEP. If the PKCS\#10 certificate request is accepted by the certification authority (CA) (the key length, hashing algorithm, and so on, match the certificate template), the client can enroll successfully. -Note that the RequestSecurityToken will use a custom TokenType (`http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentToken`), because our enrollment token is more than an X.509 v3 certificate. For more details, see the Response section. +The RequestSecurityToken will use a custom TokenType (`http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentToken`), because our enrollment token is more than an X.509 v3 certificate. For more information, see the Response section. -The RST may also specify a number of AdditionalContext items, such as DeviceType and Version. Based on these values, for example, the web service can return device-specific and version-specific DM configuration. +The RST may also specify many AdditionalContext items, such as DeviceType and Version. Based on these values, for example, the web service can return device-specific and version-specific DM configuration. > [!Note] > The policy service and the enrollment service must be on the same server; that is, they must have the same host name. @@ -485,13 +485,13 @@ The provisioning XML contains: - The requested certificates (required) - The DM client configuration (required) -The client will install the client certificate, the enterprise root certificate, and intermediate CA certificate if there is one. The DM configuration includes the name and address of the DM server, which client certificate to use, and schedules when the DM client calls back to the server. +The client will install the client certificate, the enterprise root certificate, and intermediate CA certificate if there's one. The DM configuration includes the name and address of the DM server, which client certificate to use, and schedules when the DM client calls back to the server. -Enrollment provisioning XML should contain a maximum of one root certificate and one intermediate CA certificate that is needed to chain up the MDM client certificate. Additional root and intermediate CA certificates could be provisioned during an OMA DM session. +Enrollment provisioning XML should contain a maximum of one root certificate and one intermediate CA certificate that is needed to chain up the MDM client certificate. More root and intermediate CA certificates could be provisioned during an OMA DM session. -When provisioning root and intermediate CA certificates, the supported CSP node path is: CertificateStore/Root/System for root certificate provisioning, CertificateStore/My/User for intermediate CA certificate provisioning. +When root and intermediate CA certificates are being provisioned, the supported CSP node path is: CertificateStore/Root/System for root certificate provisioning, CertificateStore/My/User for intermediate CA certificate provisioning. -Here is a sample RSTR message and a sample of OMA client provisioning XML within RSTR. For more information about the configuration service providers (CSPs) used in provisioning XML, see the Enterprise settings, policies and app management section. +Here's a sample RSTR message and a sample of OMA client provisioning XML within RSTR. For more information about the configuration service providers (CSPs) used in provisioning XML, see the Enterprise settings, policies and app management section. The following example shows the enrollment web service response. diff --git a/windows/client-management/mdm/firewall-csp.md b/windows/client-management/mdm/firewall-csp.md index 65b65a3326..a9735120d7 100644 --- a/windows/client-management/mdm/firewall-csp.md +++ b/windows/client-management/mdm/firewall-csp.md @@ -14,13 +14,13 @@ manager: dansimp # Firewall configuration service provider (CSP) -The Firewall configuration service provider (CSP) allows the mobile device management (MDM) server to configure the Windows Defender Firewall global settings, per profile settings, as well as the desired set of custom rules to be enforced on the device. Using the Firewall CSP the IT admin can now manage non-domain devices, and reduce the risk of network security threats across all systems connecting to the corporate network. This CSP was added Windows 10, version 1709. +The Firewall configuration service provider (CSP) allows the mobile device management (MDM) server to configure the Windows Defender Firewall global settings, per profile settings, and the desired set of custom rules to be enforced on the device. Using the Firewall CSP the IT admin can now manage non-domain devices, and reduce the risk of network security threats across all systems connecting to the corporate network. This CSP was added Windows 10, version 1709. Firewall rules in the FirewallRules section must be wrapped in an Atomic block in SyncML, either individually or collectively. -For detailed information on some of the fields below see [[MS-FASP]: Firewall and Advanced Security Protocol documentation](/openspecs/windows_protocols/ms-winerrata/6521c5c4-1f76-4003-9ade-5cccfc27c8ac). +For detailed information on some of the fields below, see [[MS-FASP]: Firewall and Advanced Security Protocol documentation](/openspecs/windows_protocols/ms-winerrata/6521c5c4-1f76-4003-9ade-5cccfc27c8ac). -The following shows the Firewall configuration service provider in tree format. +The following example shows the Firewall configuration service provider in tree format. ``` ./Vendor/MSFT Firewall @@ -113,11 +113,11 @@ Firewall

Supported operations are Get.

**MdmStore/Global/PolicyVersionSupported** -

Integer value that contains the maximum policy version that the server host can accept. The version number is two octets in size. The lowest-order octet is the minor version; the second-to-lowest octet is the major version. This value is not merged and is always a fixed value for a particular firewall and advanced security components software build.

+

Integer value that contains the maximum policy version that the server host can accept. The version number is two octets in size. The lowest-order octet is the minor version; the second-to-lowest octet is the major version. This value isn't merged and is always a fixed value for a particular firewall and advanced security components software build.

Value type in integer. Supported operation is Get.

**MdmStore/Global/CurrentProfiles** -

Integer value that contains a bitmask of the current enforced profiles that are maintained by the server firewall host. See FW_PROFILE_TYPE for the bitmasks that are used to identify profile types. This value is available only in the dynamic store; therefore, it is not merged and has no merge law.

+

Integer value that contains a bitmask of the current enforced profiles that are maintained by the server firewall host. See FW_PROFILE_TYPE for the bitmasks that are used to identify profile types. This value is available only in the dynamic store; therefore, it's not merged and has no merge law.

Value type in integer. Supported operation is Get.

**MdmStore/Global/DisableStatefulFtp** @@ -126,40 +126,40 @@ Firewall

Data type is bool. Supported operations are Add, Get, Replace, and Delete.

**MdmStore/Global/SaIdleTime** -

This value configures the security association idle time, in seconds. Security associations are deleted after network traffic is not seen for this specified period of time. The value is integer and MUST be in the range of 300 to 3,600 inclusive. The merge law for this option is to let the value of the GroupPolicyRSoPStore win if it is configured; otherwise, use the local store value.

+

This value configures the security association idle time, in seconds. Security associations are deleted after network traffic isn't seen for this specified period of time. The value is integer and MUST be in the range of 300 to 3,600 inclusive. The merge law for this option is to let the value of the GroupPolicyRSoPStore win if it's configured; otherwise, use the local store value.

Default value is 300.

Value type is integer. Supported operations are Add, Get, Replace, and Delete.

**MdmStore/Global/PresharedKeyEncoding** -

Specifies the preshared key encoding that is used. The value is integer and MUST be a valid value from the PRESHARED_KEY_ENCODING_VALUES enumeration. The merge law for this option is to let the value of the GroupPolicyRSoPStore win if it is configured; otherwise, use the local store value.

+

Specifies the preshared key encoding that is used. The value is integer and MUST be a valid value from the PRESHARED_KEY_ENCODING_VALUES enumeration. The merge law for this option is to let the value of the GroupPolicyRSoPStore win if it's configured; otherwise, use the local store value.

Default value is 1.

Value type is integer. Supported operations are Add, Get, Replace, and Delete.

**MdmStore/Global/IPsecExempt** -

This value configures IPsec exceptions. The value is integer and MUST be a combination of the valid flags that are defined in IPSEC_EXEMPT_VALUES; therefore, the maximum value MUST always be IPSEC_EXEMPT_MAX-1 for servers supporting a schema version of 0x0201 and IPSEC_EXEMPT_MAX_V2_0-1 for servers supporting a schema version of 0x0200. If the maximum value is exceeded when the method RRPC_FWSetGlobalConfig (Opnum 4) is called, the method returns ERROR_INVALID_PARAMETER. This error code is returned if no other preceding error is discovered. The merge law for this option is to let the value of the GroupPolicyRSoPStore win if it is configured; otherwise, use the local store value.

+

This value configures IPsec exceptions. The value is integer and MUST be a combination of the valid flags that are defined in IPSEC_EXEMPT_VALUES; therefore, the maximum value MUST always be IPSEC_EXEMPT_MAX-1 for servers supporting a schema version of 0x0201 and IPSEC_EXEMPT_MAX_V2_0-1 for servers supporting a schema version of 0x0200. If the maximum value is exceeded when the method RRPC_FWSetGlobalConfig (Opnum 4) is called, the method returns ERROR_INVALID_PARAMETER. This error code is returned if no other preceding error is discovered. The merge law for this option is to let the value of the GroupPolicyRSoPStore win if it's configured; otherwise, use the local store value.

Default value is 0.

Value type is integer. Supported operations are Add, Get, Replace, and Delete.

**MdmStore/Global/CRLcheck** -

This value specifies how certificate revocation list (CRL) verification is enforced. The value is integer and MUST be 0, 1, or 2. The merge law for this option is to let the value of the GroupPolicyRSoPStore win if it is configured; otherwise, use the local store value. Valid valued:

+

This value specifies how certificate revocation list (CRL) verification is enforced. The value is integer and MUST be 0, 1, or 2. The merge law for this option is to let the value of the GroupPolicyRSoPStore win if it's configured; otherwise, use the local store value. Valid valued:

  • 0 disables CRL checking
    • -
  • 1 specifies that CRL checking is attempted and that certificate validation fails only if the certificate is revoked. Other failures that are encountered during CRL checking (such as the revocation URL being unreachable) do not cause certificate validation to fail.
    • +
  • 1 specifies that CRL checking is attempted and that certificate validation fails only if the certificate is revoked. Other failures that are encountered during CRL checking (such as the revocation URL being unreachable) don't cause certificate validation to fail.
  • 2 means that checking is required and that certificate validation fails if any error is encountered during CRL processing

Default value is 0.

Value type is integer. Supported operations are Add, Get, Replace, and Delete.

**MdmStore/Global/PolicyVersion** -

This value contains the policy version of the policy store being managed. This value is not merged and therefore, has no merge law.

+

This value contains the policy version of the policy store being managed. This value isn't merged and therefore, has no merge law.

Value type is string. Supported operation is Get.

**MdmStore/Global/BinaryVersionSupported** -

This value contains the binary version of the structures and data types that are supported by the server. This value is not merged. In addition, this value is always a fixed value for a specific firewall and advanced security component's software build. This value identifies a policy configuration option that is supported only on servers that have a schema version of 0x0201.

+

This value contains the binary version of the structures and data types that are supported by the server. This value isn't merged. In addition, this value is always a fixed value for a specific firewall and advanced security component's software build. This value identifies a policy configuration option that is supported only on servers that have a schema version of 0x0201.

Value type is string. Supported operation is Get.

**MdmStore/Global/OpportunisticallyMatchAuthSetPerKM** -

This value is bool used as an on/off switch. When this option is false (off), keying modules MUST ignore the entire authentication set if they do not support all of the authentication suites specified in the set. When this option is true (on), keying modules MUST ignore only the authentication suites that they don’t support. For schema versions 0x0200, 0x0201, and 0x020A, this value is invalid and MUST NOT be used.

+

This value is bool used as an on/off switch. When this option is false (off), keying modules MUST ignore the entire authentication set if they don't support all of the authentication suites specified in the set. When this option is true (on), keying modules MUST ignore only the authentication suites that they don’t support. For schema versions 0x0200, 0x0201, and 0x020A, this value is invalid and MUST NOT be used.

Boolean value. Supported operations are Add, Get, Replace, and Delete.

**MdmStore/Global/EnablePacketQueue** @@ -184,12 +184,12 @@ Firewall

Interior node. Supported operation is Get.

**/EnableFirewall** -

Boolean value for the firewall and advanced security enforcement. If this value is false, the server MUST NOT block any network traffic, regardless of other policy settings. The merge law for this option is to let the value of the GroupPolicyRSoPStore win if it is configured; otherwise, the local store value is used.

+

Boolean value for the firewall and advanced security enforcement. If this value is false, the server MUST NOT block any network traffic, regardless of other policy settings. The merge law for this option is to let the value of the GroupPolicyRSoPStore win if it's configured; otherwise, the local store value is used.

Default value is true.

Value type is bool. Supported operations are Add, Get and Replace.

**/DisableStealthMode** -

Boolean value. When this option is false, the server operates in stealth mode. The firewall rules used to enforce stealth mode are implementation-specific. The merge law for this option is to let the value of the GroupPolicyRSoPStore win if it is configured; otherwise, the local store value is used.

+

Boolean value. When this option is false, the server operates in stealth mode. The firewall rules used to enforce stealth mode are implementation-specific. The merge law for this option is to let the value of the GroupPolicyRSoPStore win if it's configured; otherwise, the local store value is used.

Default value is false.

Value type is bool. Supported operations are Add, Get and Replace.

@@ -199,22 +199,22 @@ Firewall

Value type is bool. Supported operations are Get and Replace.

**/DisableUnicastResponsesToMulticastBroadcast** -

Boolean value. If it is true, unicast responses to multicast broadcast traffic is blocked. The merge law for this option is to let the value of the GroupPolicyRSoPStore win if it is configured; otherwise, the local store value is used.

+

Boolean value. If it's true, unicast responses to multicast broadcast traffic are blocked. The merge law for this option is to let the value of the GroupPolicyRSoPStore win if it's configured; otherwise, the local store value is used.

Default value is false.

Value type is bool. Supported operations are Add, Get and Replace.

**/DisableInboundNotifications** -

Boolean value. If this value is false, the firewall MAY display a notification to the user when an application is blocked from listening on a port. If this value is on, the firewall MUST NOT display such a notification. The merge law for this option is to let the value of the GroupPolicyRSoPStore win if it is configured; otherwise, the local store value is used.

+

Boolean value. If this value is false, the firewall MAY display a notification to the user when an application is blocked from listening on a port. If this value is on, the firewall MUST NOT display such a notification. The merge law for this option is to let the value of the GroupPolicyRSoPStore win if it's configured; otherwise, the local store value is used.

Default value is false.

Value type is bool. Supported operations are Add, Get and Replace.

**/AuthAppsAllowUserPrefMerge** -

Boolean value. If this value is false, authorized application firewall rules in the local store are ignored and not enforced. The merge law for this option is to let the value of the GroupPolicyRSoPStore win if it is configured; otherwise, the local store value is used.

+

Boolean value. If this value is false, authorized application firewall rules in the local store are ignored and not enforced. The merge law for this option is to let the value of the GroupPolicyRSoPStore win if it's configured; otherwise, the local store value is used.

Default value is true.

Value type is bool. Supported operations are Add, Get and Replace.

**/GlobalPortsAllowUserPrefMerge** -

Boolean value. If this value is false, global port firewall rules in the local store are ignored and not enforced. The setting only has meaning if it is set or enumerated in the Group Policy store or if it is enumerated from the GroupPolicyRSoPStore. The merge law for this option is to let the value GroupPolicyRSoPStore win if it is configured; otherwise, the local store value is used.

+

Boolean value. If this value is false, global port firewall rules in the local store are ignored and not enforced. The setting only has meaning if it's set or enumerated in the Group Policy store or if it's enumerated from the GroupPolicyRSoPStore. The merge law for this option is to let the value GroupPolicyRSoPStore win if it's configured; otherwise, the local store value is used.

Default value is true.

Value type is bool. Supported operations are Add, Get and Replace.

@@ -229,7 +229,7 @@ Firewall

Value type is bool. Supported operations are Add, Get and Replace.

**/DefaultOutboundAction** -

This value is the action that the firewall does by default (and evaluates at the very end) on outbound connections. The merge law for this option is to let the value of the GroupPolicyRSoPStore win if it is configured; otherwise, the local store value is used. DefaultOutboundAction will block all outbound traffic unless it is explicitly specified not to block.

+

This value is the action that the firewall does by default (and evaluates at the very end) on outbound connections. The merge law for this option is to let the value of the GroupPolicyRSoPStore win if it's configured; otherwise, the local store value is used. DefaultOutboundAction will block all outbound traffic unless it's explicitly specified not to block.

  • 0x00000000 - allow
  • 0x00000001 - block
    • @@ -262,7 +262,7 @@ Sample syncxml to provision the firewall settings to evaluate ``` **/DefaultInboundAction** -

    This value is the action that the firewall does by default (and evaluates at the very end) on inbound connections. The merge law for this option is to let the value of the GroupPolicyRSoPStore.win if it is configured; otherwise, the local store value is used.

    +

    This value is the action that the firewall does by default (and evaluates at the very end) on inbound connections. The merge law for this option is to let the value of the GroupPolicyRSoPStore.win if it's configured; otherwise, the local store value is used.

    • 0x00000000 - allow
    • 0x00000001 - block
      • @@ -271,7 +271,7 @@ Sample syncxml to provision the firewall settings to evaluate

      Value type is integer. Supported operations are Add, Get and Replace.

      **/DisableStealthModeIpsecSecuredPacketExemption** -

      Boolean value. This option is ignored if DisableStealthMode is true. Otherwise, when this option is true, the firewall's stealth mode rules MUST NOT prevent the host computer from responding to unsolicited network traffic if that traffic is secured by IPsec. The merge law for this option is to let the value of the GroupPolicyRSoPStore win if it is configured; otherwise, the local store value is used. For schema versions 0x0200, 0x0201, and 0x020A, this value is invalid and MUST NOT be used.

      +

      Boolean value. This option is ignored if DisableStealthMode is true. Otherwise, when this option is true, the firewall's stealth mode rules MUST NOT prevent the host computer from responding to unsolicited network traffic if that traffic is secured by IPsec. The merge law for this option is to let the value of the GroupPolicyRSoPStore win if it's configured; otherwise, the local store value is used. For schema versions 0x0200, 0x0201, and 0x020A, this value is invalid and MUST NOT be used.

      Default value is true.

      Value type is bool. Supported operations are Add, Get and Replace.

      @@ -306,7 +306,7 @@ Sample syncxml to provision the firewall settings to evaluate

      Value type is string. Supported operations are Add, Get, Replace, and Delete.

      **FirewallRules/_FirewallRuleName_/App/ServiceName** -

      This is a service name used in cases when a service, not an application, is sending or receiving traffic.

      +

      This parameter is a service name used in cases when a service, not an application, is sending or receiving traffic.

      Value type is string. Supported operations are Add, Get, Replace, and Delete.

      **FirewallRules/_FirewallRuleName_/Protocol** @@ -325,9 +325,9 @@ Sample syncxml to provision the firewall settings to evaluate

      Value type is string. Supported operations are Add, Get, Replace, and Delete.

      **FirewallRules/*FirewallRuleName*/LocalAddressRanges** -

      Comma separated list of local addresses covered by the rule. The default value is "*". Valid tokens include:

      +

      Comma-separated list of local addresses covered by the rule. The default value is "*". Valid tokens include:

        -
      • "*" indicates any local address. If present, this must be the only token included.
        • +
      • "*" indicates any local address. If present, the local address must be the only token included.
      • A subnet can be specified using either the subnet mask or network prefix notation. If neither a subnet mask nor a network prefix is specified, the subnet mask defaults to 255.255.255.255.
      • A valid IPv6 address.
      • An IPv4 address range in the format of "start address - end address" with no spaces included.
        • @@ -339,7 +339,7 @@ Sample syncxml to provision the firewall settings to evaluate **FirewallRules/*FirewallRuleName*/RemoteAddressRanges**

        List of comma separated tokens specifying the remote addresses covered by the rule. The default value is "*". Valid tokens include:

          -
        • "*" indicates any remote address. If present, this must be the only token included.
          • +
        • "*" indicates any remote address. If present, the address must be the only token included.
        • "Defaultgateway"
        • "DHCP"
        • "DNS"
          • @@ -348,7 +348,7 @@ Sample syncxml to provision the firewall settings to evaluate
        • "RmtIntranet"
        • "Internet"
        • "Ply2Renders"
          • -
        • "LocalSubnet" indicates any local address on the local subnet. This token is not case-sensitive.
          • +
        • "LocalSubnet" indicates any local address on the local subnet. This token isn't case-sensitive.
        • A subnet can be specified using either the subnet mask or network prefix notation. If neither a subnet mask not a network prefix is specified, the subnet mask defaults to 255.255.255.255.
        • A valid IPv6 address.
        • An IPv4 address range in the format of "start address - end address" with no spaces included.
          • @@ -411,7 +411,7 @@ Sample syncxml to provision the firewall settings to evaluate

          Value type is bool. Supported operations are Add, Get, Replace, and Delete.

          **FirewallRules/_FirewallRuleName_/LocalUserAuthorizationList** -

          Specifies the list of authorized local users for this rule. This is a string in Security Descriptor Definition Language (SDDL) format.

          +

          Specifies the list of authorized local users for this rule. This list is a string in Security Descriptor Definition Language (SDDL) format.

          Value type is string. Supported operations are Add, Get, Replace, and Delete.

          **FirewallRules/_FirewallRuleName_/Status** diff --git a/windows/client-management/mdm/get-seats-assigned-to-a-user.md b/windows/client-management/mdm/get-seats-assigned-to-a-user.md index d7167f4626..5f70d09f93 100644 --- a/windows/client-management/mdm/get-seats-assigned-to-a-user.md +++ b/windows/client-management/mdm/get-seats-assigned-to-a-user.md @@ -1,6 +1,6 @@ --- title: Get seats assigned to a user -description: The Get seats assigned to a user operation retrieves information about assigned seats in the Micosoft Store for Business. +description: The Get seats assigned to a user operation retrieves information about assigned seats in the Microsoft Store for Business. ms.assetid: CB963E44-8C7C-46F9-A979-89BBB376172B ms.reviewer: manager: dansimp @@ -14,7 +14,7 @@ ms.date: 09/18/2017 # Get seats assigned to a user -The **Get seats assigned to a user** operation retrieves information about assigned seats in the Micosoft Store for Business. +The **Get seats assigned to a user** operation retrieves information about assigned seats in the Microsoft Store for Business. ## Request @@ -39,7 +39,7 @@ The following parameters may be specified in the request URI. ### Response body -The response body contain [SeatDetailsResultSet](data-structures-windows-store-for-business.md#seatdetailsresultset). +The response body contains [SeatDetailsResultSet](data-structures-windows-store-for-business.md#seatdetailsresultset). |Error code|Description|Retry|Data field| |--- |--- |--- |--- | diff --git a/windows/client-management/mdm/healthattestation-csp.md b/windows/client-management/mdm/healthattestation-csp.md index 2513599a28..b5adad8cb7 100644 --- a/windows/client-management/mdm/healthattestation-csp.md +++ b/windows/client-management/mdm/healthattestation-csp.md @@ -16,7 +16,7 @@ ms.date: The Device HealthAttestation configuration service provider (DHA-CSP) enables enterprise IT administrators to assess if a device is booted to a trusted and compliant state, and to take enterprise policy actions. -The following is a list of functions performed by the Device HealthAttestation CSP: +The following list is a description of the functions performed by the Device HealthAttestation CSP: - Collects device boot logs, Trusted Platform Module (TPM) audit trails and the TPM certificate (DHA-BootData) from a managed device - Forwards DHA-BootData to a Device Health Attestation Service (DHA-Service) @@ -25,7 +25,7 @@ The following is a list of functions performed by the Device HealthAttestation C ## Windows 11 Device health attestation -Windows 11 introduces an update to the device health attestation feature. This helps add support for deeper insights to Windows boot security, supporting a zero trust approach to device security. Device health attestation on Windows can be accessed by using the HealthAttestation CSP. This CSP helps assess if a device is booted to a trusted and compliant state and then to take appropriate action. Windows 11 introduces additional child nodes to the HealthAttestation node for the MDM providers to connect to the Microsoft Azure Attestation service, which provides a simplified approach to attestation. +Windows 11 introduces an update to the device health attestation feature. This update helps add support for deeper insights to Windows boot security, supporting a zero trust approach to device security. Device health attestation on Windows can be accessed by using the HealthAttestation CSP. This CSP helps assess if a device is booted to a trusted and compliant state and then to take appropriate action. Windows 11 introduces more child nodes to the HealthAttestation node for the MDM providers to connect to the Microsoft Azure Attestation service, which provides a simplified approach to attestation. The attestation report provides a health assessment of the boot-time properties of the device to ensure that the devices are automatically secure as soon as they power on. The health attestation result can then be used to allow or deny access to networks, apps, or services, depending on the health of the device. @@ -48,7 +48,7 @@ The attestation report provides a health assessment of the boot-time properties - **MAA endpoint**: Microsoft Azure attestation service is an Azure resource, and every instance of the service gets administrator configured URL. The URI generated is unique in nature and for the purposes of device health attestation is known as the MAA endpoint. -- **JWT (JSON Web Token)**: JSON Web Token (JWT) is an open standard RFC7519 method for securely transmitting information between parties as a JavaScript Object Notation (JSON) object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret or a public/private key pair. +- **JWT (JSON Web Token)**: JSON Web Token (JWT) is an open standard RFC7519 method for securely transmitting information between parties as a JavaScript Object Notation (JSON) object. This information can be verified and trusted because it's digitally signed. JWTs can be signed using a secret or a public/private key pair. ### Attestation Flow with Microsoft Azure Attestation Service @@ -126,9 +126,9 @@ Data fields: - rpID (Relying Party Identifier): This field contains an identifier that can be used to help determine the caller. - serviceEndpoint : This field contains the complete URL of the Microsoft Azure Attestation provider instance to be used for evaluation. -- nonce : This field contains an arbitrary number that can be used just once in a cryptographic communication. It is often a random or pseudo-random number issued in an authentication protocol to ensure that old communications cannot be reused in replay attacks. +- nonce: This field contains an arbitrary number that can be used only once in a cryptographic communication. It's often a random or pseudo-random number issued in an authentication protocol to ensure that old communications can't be reused in replay attacks. - aadToken: The AAD token to be used for authentication against the Microsoft Azure Attestation service. -- cv: This field contains an identifier(Correlation Vector) that will passed in to the service call, that can be used for diagnostics purposes. +- cv: This field contains an identifier(Correlation Vector) that will be passed in to the service call, and that can be used for diagnostics purposes. Sample Data: @@ -182,7 +182,7 @@ Example: 0x80072efd, WININET_E_CANNOT_CONNECT Node type: GET -This node will retrieve the attestation report per the call made by the TriggerAttestation, if there is any, for the given MDM provider. The report is stored in a registry key in the respective MDM enrollment store. +This node will retrieve the attestation report per the call made by the TriggerAttestation, if there's any, for the given MDM provider. The report is stored in a registry key in the respective MDM enrollment store. Templated SyncML Call: @@ -217,7 +217,7 @@ OR Sync ML 404 error if not cached report available. Node type: GET -This node will retrieve the service-generated correlation IDs for the given MDM provider. If there is more than one correlation ID, they are separated by “;” in the string. +This node will retrieve the service-generated correlation IDs for the given MDM provider. If there's more than one correlation ID, they're separated by “;” in the string. Templated SyncML Call: @@ -249,7 +249,7 @@ calls between client and MAA and for each call the GUID is separated by semicolo ``` > [!NOTE] -> > MAA CSP nodes are available on arm64 but is not currently supported. +> > MAA CSP nodes are available on arm64 but isn't currently supported. ### MAA CSP Integration Steps @@ -372,7 +372,7 @@ calls between client and MAA and for each call the GUID is separated by semicolo // Find the first EV_SEPARATOR in PCR 12, 13, Or 14 c:[type=="events", issuer=="AttestationService"] => add(type="evSeparatorSeq", value=JmesPath(c.value, "Events[? EventTypeString == 'EV_SEPARATOR' && (PcrIndex == `12` || PcrIndex == `13` || PcrIndex == `14`)] | @[0].EventSeq")); c:[type=="evSeparatorSeq", value != "null", issuer=="AttestationPolicy"] => add(type="beforeEvSepClause", value=AppendString(AppendString("Events[? EventSeq < `", c.value), "`")); - [type=="evSeparatorSeq", value=="null", issuer=="AttestationPolicy"] => add(type="beforeEvSepClause", value="Events[? `true` "); // No restriction of EV_SEPARATOR in case it is not present + [type=="evSeparatorSeq", value=="null", issuer=="AttestationPolicy"] => add(type="beforeEvSepClause", value="Events[? `true` "); // No restriction of EV_SEPARATOR in case it's not present //Finding the Boot App SVN // Find the first EVENT_TRANSFER_CONTROL with value 1 or 2 in PCR 12 which is before the EV_SEPARATOR @@ -490,7 +490,7 @@ More information about TPM attestation can be found here: [Microsoft Azure Attes - DHA-BootData: the device boot data (TCG logs, PCR values, device/TPM certificate, boot, and TPM counters) that are required for validating device boot health. - DHA-EncBlob: an encrypted summary report that DHA-Service issues to a device after reviewing the DHA-BootData it receives from devices. - - DHA-SignedBlob: it is a signed snapshot of the current state of a device’s runtime that is captured by DHA-CSP at device health attestation time. + - DHA-SignedBlob: it's a signed snapshot of the current state of a device’s runtime that is captured by DHA-CSP at device health attestation time. - DHA-Data: an XML formatted data blob that devices forward for device health validation to DHA-Service via MDM-Server. DHA-Data has two parts: - DHA-EncBlob: the encrypted data blob that the device receives from DHA-Service @@ -510,7 +510,7 @@ More information about TPM attestation can be found here: [Microsoft Azure Attes - Collects device health attestation data (DHA-Data), and sends it to Device Health Attestation Service (DHA-Service) for verification - Gets the device health report (DHA-Report) from DHA-Service, which triggers compliance action -- **DHA-CSP (Device HealthAttestation Configuration Service Provider)**: The Device HealthAttestation Configuration Service Provider (DHA-CSP) uses a device’s TPM and firmware to measure critical security properties of the device’s BIOS and Windows boot, such that even on a system infected with kernel level malware or a rootkit, these properties cannot be spoofed. +- **DHA-CSP (Device HealthAttestation Configuration Service Provider)**: The Device HealthAttestation Configuration Service Provider (DHA-CSP) uses a device’s TPM and firmware to measure critical security properties of the device’s BIOS and Windows boot, such that even on a system infected with kernel level malware or a rootkit, these properties can't be spoofed. The following list of operations is performed by DHA-CSP: @@ -535,8 +535,8 @@ More information about TPM attestation can be found here: [Microsoft Azure Attes |DHA-Service type|Description|Operation cost| |--- |--- |--- | |Device Health Attestation – Cloud (DHA-Cloud)|DHA-Cloud is a Microsoft owned and operated DHA-Service that is:
        • Available in Windows for free
        • Running on a high-availability and geo-balanced cloud infrastructure
        • Supported by most DHA-Enabled device management solutions as the default device attestation service provider
        • Accessible to all enterprise-managed devices via following:
          • FQDN = has.spserv.microsoft.com port
          • Port = 443
          • Protocol = TCP|No cost
          • | -|Device Health Attestation – On Premise(DHA-OnPrem)|DHA-OnPrem refers to DHA-Service that is running on premises:
        • Offered to Windows Server 2016 customer (no added licensing cost for enabling/running DHA-Service)
        • Hosted on an enterprise owned and managed server device/hardware
        • Supported by 1st and 3rd party DHA-Enabled device management solution providers that support on-premises and hybrid (Cloud + OnPrem) hardware attestation scenarios
        • Accessible to all enterprise-managed devices via following:
          • FQDN = (enterprise assigned)
          • Port = (enterprise assigned)
          • Protocol = TCP|The operation cost of running one or more instances of Server 2016 on-premises.
          • | -|Device Health Attestation - Enterprise-Managed Cloud(DHA-EMC)|DHA-EMC refers to an enterprise-managed DHA-Service that is running as a virtual host/service on a Windows Server 2016 compatible - enterprise-managed cloud service, such as Microsoft Azure.
        • Offered to Windows Server 2016 customers with no additional licensing cost (no added licensing cost for enabling/running DHA-Service)
        • Supported by 1st and 3rd party DHA-Enabled device management solution providers that support on-premises and hybrid (Cloud + OnPrem) hardware attestation scenarios
        • Accessible to all enterprise-managed devices via following:
          • FQDN = (enterprise assigned)
          • Port = (enterprise assigned)
          • Protocol = TCP|The operation cost of running Server 2016 on a compatible cloud service, such as Microsoft Azure.
          • | +|Device Health Attestation – On Premise(DHA-OnPrem)|DHA-OnPrem refers to DHA-Service that is running on premises:
        • Offered to Windows Server 2016 customer (no added licensing cost for enabling/running DHA-Service)
        • Hosted on an enterprise owned and managed server device/hardware
        • Supported by 1st and 3rd party DHA-Enabled device management solution providers that support on-premises and hybrid (Cloud + OnPrem) hardware attestation scenarios
        • Accessible to all enterprise-managed devices via following settings:
          • FQDN = (enterprise assigned)
          • Port = (enterprise assigned)
          • Protocol = TCP|The operation cost of running one or more instances of Server 2016 on-premises.
          • | +|Device Health Attestation - Enterprise-Managed Cloud(DHA-EMC)|DHA-EMC refers to an enterprise-managed DHA-Service that is running as a virtual host/service on a Windows Server 2016 compatible - enterprise-managed cloud service, such as Microsoft Azure.
        • Offered to Windows Server 2016 customers with no extra licensing cost (no added licensing cost for enabling/running DHA-Service)
        • Supported by 1st and 3rd party DHA-Enabled device management solution providers that support on-premises and hybrid (Cloud + OnPrem) hardware attestation scenarios
        • Accessible to all enterprise-managed devices via following settings:
          • FQDN = (enterprise assigned)
          • Port = (enterprise assigned)
          • Protocol = TCP|The operation cost of running Server 2016 on a compatible cloud service, such as Microsoft Azure.
          • | ### CSP diagram and node descriptions @@ -578,7 +578,7 @@ The following list shows some examples of supported values. For the complete lis - 0 - (HEALTHATTESTATION\_CERT\_RETRIEVAL_UNINITIALIZED): DHA-CSP is preparing a request to get a new DHA-EncBlob from DHA-Service - 1 - (HEALTHATTESTATION\_CERT\_RETRIEVAL_REQUESTED): DHA-CSP is waiting for the DHA-Service to respond back, and issue a DHA-EncBlob to the device -- 2 - (HEALTHATTESTATION\_CERT\_RETRIEVAL_FAILED): A valid DHA-EncBlob could not be retrieved from the DHA-Service for reasons other than discussed in the DHA error/status codes +- 2 - (HEALTHATTESTATION\_CERT\_RETRIEVAL_FAILED): A valid DHA-EncBlob couldn't be retrieved from the DHA-Service for reasons other than discussed in the DHA error/status codes - 3 - (HEALTHATTESTATION\_CERT\_RETRIEVAL_COMPLETE): DHA-Data is ready for pickup **ForceRetrieve** (Optional) @@ -609,7 +609,7 @@ Value type is integer, the minimum value is - 2,147,483,648 and the maximum valu **HASEndpoint** (Optional) -Identifies the fully qualified domain name (FQDN) of the DHA-Service that is assigned to perform attestation. If an FQDN is not assigned, DHA-Cloud (Microsoft owned and operated cloud service) will be used as the default attestation service. +Identifies the fully qualified domain name (FQDN) of the DHA-Service that is assigned to perform attestation. If an FQDN isn't assigned, DHA-Cloud (Microsoft owned and operated cloud service) will be used as the default attestation service. Value type is string. The supported operations are Get and Replace. The default value is has.spserv.microsoft.com. @@ -638,7 +638,7 @@ Each step is described in detail in the following sections of this topic. Validate that both the MDM server and the device (MDM client) can access has.spserv.microsoft.com using the TCP protocol over port 443 (HTTPS). -You can use OpenSSL to validate access to DHA-Service. Here is a sample OpenSSL command and the response that was generated by DHA-Service: +You can use OpenSSL to validate access to DHA-Service. Here's a sample OpenSSL command and the response that was generated by DHA-Service: ```console PS C:\openssl> ./openssl.exe s_client -connect has.spserv.microsoft.com:443 @@ -736,7 +736,7 @@ The following example shows a sample call that triggers collection and verificat ``` -### Step 4: Take action based on the clients response +### Step 4: Take action based on the client's response After the client receives the health attestation request, it sends a response. The following list describes the responses, along with a recommended action to take. @@ -744,7 +744,7 @@ After the client receives the health attestation request, it sends a response. T - If the response is HEALTHATTESTATION\_CERT_RETRIEVAL_COMPLETE (3) then proceed to the next section. - If the response is HEALTHATTESTATION_CERT_RETRIEVAL_REQUESTED (1) or HEALTHATTESTATION_CERT_RETRIEVAL_UNINITIALIZED (0) wait for an alert, then proceed to the next section. -Here is a sample alert that is issued by DHA_CSP: +Here's a sample alert that is issued by DHA_CSP: ```xml @@ -762,14 +762,14 @@ Here is a sample alert that is issued by DHA_CSP: ``` -- If the response to the status node is not 0, 1 or 3, then troubleshoot the issue. For the complete list of status codes, see [Device HealthAttestation CSP status and error codes](#device-healthattestation-csp-status-and-error-codes). +- If the response to the status node isn't 0, 1 or 3, then troubleshoot the issue. For the complete list of status codes, see [Device HealthAttestation CSP status and error codes](#device-healthattestation-csp-status-and-error-codes). ### Step 5: Instruct the client to forward health attestation data for verification Create a call to the **Nonce**, **Certificate** and **CorrelationId** nodes, and pick up an encrypted payload that includes a health certificate and related data from the device. -Here is an example: +Here's an example: ```xml @@ -876,7 +876,7 @@ The following list of data points is verified by the DHA-Service in DHA-Report v \*\* Reports if BitLocker was enabled during initial boot. \*\*\* The "Hybrid Resume" must be disabled on the device. Reports first-party ELAM "Defender" was loaded during boot. -Each of these are described in further detail in the following sections, along with the recommended actions to take. +Each of these data points is described in further detail in the following sections, along with the recommended actions to take. **Issued** @@ -907,7 +907,7 @@ This attribute reports the number of times a PC device has rebooted. A device can be trusted more if the DEP Policy is enabled on the device. -Data Execution Prevention (DEP) Policy defines is a set of hardware and software technologies that perform additional checks on memory to help prevent malicious code from running on a system. Secure boot allows a limited list on x86/amd64 and on ARM NTOS locks it to on. +Data Execution Prevention (DEP) Policy defines a set of hardware and software technologies that perform extra checks on memory to help prevent malicious code from running on a system. Secure boot allows a limited list on x86/amd64 and on ARM NTOS locks it to on. DEPPolicy can be disabled or enabled by using the following commands in WMI or a PowerShell script: @@ -927,9 +927,9 @@ If DEPPolicy = 0 (Off), then take one of the following actions that align with y When BitLocker is reported "on" at boot time, the device is able to protect data that is stored on the drive from unauthorized access, when the system is turned off or goes to hibernation. -Windows BitLocker Drive Encryption, encrypts all data stored on the Windows operating system volume. BitLocker uses the TPM to help protect the Windows operating system and user data and helps to ensure that a computer is not tampered with, even if it is left unattended, lost, or stolen. +Windows BitLocker Drive Encryption, encrypts all data stored on the Windows operating system volume. BitLocker uses the TPM to help protect the Windows operating system and user data and helps to ensure that a computer isn't tampered with, even if it's left unattended, lost, or stolen. -If the computer is equipped with a compatible TPM, BitLocker uses the TPM to lock the encryption keys that protect the data. As a result, the keys cannot be accessed until the TPM has verified the state of the computer. +If the computer is equipped with a compatible TPM, BitLocker uses the TPM to lock the encryption keys that protect the data. As a result, the keys can't be accessed until the TPM has verified the state of the computer. If BitLockerStatus = 1 (On), then allow access. @@ -955,7 +955,7 @@ If BootManagerRevListVersion != [CurrentVersion], then take one of the following **CodeIntegrityRevListVersion** -This attribute indicates the version of the code that is performing integrity checks during the boot sequence. Using this attribute can help you detect if the device is running the latest version of the code that performs integrity checks, or if it is exposed to security risks (revoked) and enforce an appropriate policy action. +This attribute indicates the version of the code that is performing integrity checks during the boot sequence. Using this attribute can help you detect if the device is running the latest version of the code that performs integrity checks, or if it's exposed to security risks (revoked), and enforce an appropriate policy action. If CodeIntegrityRevListVersion = [CurrentVersion], then allow access. @@ -968,7 +968,7 @@ If CodeIntegrityRevListVersion != [CurrentVersion], then take one of the followi **SecureBootEnabled** -When Secure Boot is enabled the core components used to boot the machine must have correct cryptographic signatures that are trusted by the organization that manufactured the device. The UEFI firmware verifies this before it lets the machine start. If any files have been tampered with, breaking their signature, the system will not boot. +When Secure Boot is enabled, the core components used to boot the machine must have correct cryptographic signatures that are trusted by the organization that manufactured the device. The UEFI firmware verifies this requirement before it lets the machine start. If any files have been tampered with, breaking their signature, the system won't boot. If SecureBootEnabled = 1 (True), then allow access. @@ -1014,7 +1014,7 @@ If OSKernelDebuggingEnabled = 1 (True), then take one of the following actions t When code integrity is enabled, code execution is restricted to integrity verified code. -Code integrity is a feature that validates the integrity of a driver or system file each time it is loaded into memory. Code integrity detects whether an unsigned driver or system file is being loaded into the kernel, or whether a system file has been modified by malicious software that is being run by a user account with administrator privileges. +Code integrity is a feature that validates the integrity of a driver or system file each time it's loaded into memory. Code integrity detects whether an unsigned driver or system file is being loaded into the kernel, or whether a system file has been modified by malicious software that is being run by a user account with administrator privileges. On x64-based versions of the operating system, kernel-mode drivers must be digitally signed. @@ -1029,7 +1029,7 @@ If CodeIntegrityEnabled = 0 (False), then take one of the following actions that **TestSigningEnabled** -When test signing is enabled, the device does not enforce signature validation during boot, and allows the unsigned drivers (such as unsigned UEFI modules) to load during boot. +When test signing is enabled, the device doesn't enforce signature validation during boot, and allows the unsigned drivers (such as unsigned UEFI modules) to load during boot. Test signing can be disabled or enabled by using the following commands in WMI or a PowerShell script: @@ -1116,7 +1116,7 @@ This attribute identifies the security version number of the Boot Application th If reported BootAppSVN equals an accepted value, then allow access. -If reported BootAppSVN does not equal an accepted value, then take one of the following actions that align with your enterprise policies: +If reported BootAppSVN doesn't equal an accepted value, then take one of the following actions that align with your enterprise policies: - Disallow all access - Direct the device to an enterprise honeypot, to further monitor the device's activities. @@ -1127,7 +1127,7 @@ This attribute identifies the security version number of the Boot Manager that w If reported BootManagerSVN equals an accepted value, then allow access. -If reported BootManagerSVN does not equal an accepted value, then take one of the following actions that align with your enterprise policies: +If reported BootManagerSVN doesn't equal an accepted value, then take one of the following actions that align with your enterprise policies: - Disallow all access - Direct the device to an enterprise honeypot, to further monitor the device's activities. @@ -1142,7 +1142,7 @@ This attribute identifies the version of the TPM that is running on the attested Based on the reply you receive from TPMVersion node: - If reported TPMVersion equals an accepted value, then allow access. -- If reported TPMVersion does not equal an accepted value, then take one of the following actions that align with your enterprise policies: +- If reported TPMVersion doesn't equal an accepted value, then take one of the following actions that align with your enterprise policies: - Disallow all access - Direct the device to an enterprise honeypot, to further monitor the device's activities. @@ -1150,13 +1150,13 @@ Based on the reply you receive from TPMVersion node: The measurement that is captured in PCR[0] typically represents a consistent view of the Host Platform between boot cycles. It contains a measurement of components that are provided by the host platform manufacturer. -Enterprise managers can create an allow list of trusted PCR[0] values, compare the PCR[0] value of the managed devices (the value that is verified and reported by HAS) with the allow list, and then make a trust decision based on the result of the comparison. +Enterprise managers can create an allowlist of trusted PCR[0] values, compare the PCR[0] value of the managed devices (the value that is verified and reported by HAS) with the allowlist, and then make a trust decision based on the result of the comparison. -If your enterprise does not have a allow list of accepted PCR[0] values, then take no action. +If your enterprise doesn't have an allowlist of accepted PCR[0] values, then take no action. -If PCR[0] equals an accepted allow list value, then allow access. +If PCR[0] equals an accepted allowlist value, then allow access. -If PCR[0] does not equal any accepted listed value, then take one of the following actions that align with your enterprise policies: +If PCR[0] doesn't equal any accepted listed value, then take one of the following actions that align with your enterprise policies: - Disallow all access - Direct the device to an enterprise honeypot, to further monitor the device's activities. @@ -1165,9 +1165,9 @@ If PCR[0] does not equal any accepted listed value, then take one of the followi SBCPHash is the finger print of the Custom Secure Boot Configuration Policy (SBCP) that was loaded during boot in Windows devices, except PCs. -If SBCPHash is not present, or is an accepted allow-listed value, then allow access. +If SBCPHash isn't present, or is an accepted allow-listed value, then allow access. -If SBCPHash is present in DHA-Report, and is not an allow-listed value, then take one of the following actions that align with your enterprise policies: +If SBCPHash is present in DHA-Report, and isn't an allowlisted value, then take one of the following actions that align with your enterprise policies: - Disallow all access - Place the device in a watch list to monitor the device more closely for potential risks. @@ -1176,9 +1176,9 @@ If SBCPHash is present in DHA-Report, and is not an allow-listed value, then tak This attribute indicates the Code Integrity policy that is controlling the security of the boot environment. -If CIPolicy is not present, or is an accepted allow-listed value, then allow access. +If CIPolicy isn't present, or is an accepted allow-listed value, then allow access. -If CIPolicy is present and is not an allow-listed value, then take one of the following actions that align with your enterprise policies: +If CIPolicy is present and isn't an allow-listed value, then take one of the following actions that align with your enterprise policies: - Disallow all access - Place the device in a watch list to monitor the device more closely for potential risks. @@ -1189,7 +1189,7 @@ This attribute identifies the Boot Revision List that was loaded during initial If reported BootRevListInfo version equals an accepted value, then allow access. -If reported BootRevListInfo version does not equal an accepted value, then take one of the following actions that align with your enterprise policies: +If reported BootRevListInfo version doesn't equal an accepted value, then take one of the following actions that align with your enterprise policies: - Disallow all access - Direct the device to an enterprise honeypot, to further monitor the device's activities. @@ -1200,7 +1200,7 @@ This attribute identifies the Operating System Revision List that was loaded dur If reported OSRevListInfo version equals an accepted value, then allow access. -If reported OSRevListInfo version does not equal an accepted value, then take one of the following actions that align with your enterprise policies: +If reported OSRevListInfo version doesn't equal an accepted value, then take one of the following actions that align with your enterprise policies: - Disallow all access - Direct the device to an enterprise honeypot, to further monitor the device's activities. @@ -1209,12 +1209,12 @@ If reported OSRevListInfo version does not equal an accepted value, then take on HealthStatusMismatchFlags attribute appears if DHA-Service detects an integrity issue (mismatch) in the DHA-Data it receives from device management solutions, for validation. -In case of a detected issue a list of impacted DHA-report elements will be listed under the HealthStatusMismatchFlags attribute. +If an issue is detected, a list of impacted DHA-report elements will be listed under the HealthStatusMismatchFlags attribute. ### Device HealthAttestation CSP status and error codes Error code: 0 | Error name: HEALTHATTESTATION_CERT_RETRIEVAL_UNINITIALIZED -Error description: This is the initial state for devices that have never participated in a DHA-Session. +Error description: This state is the initial state for devices that have never participated in a DHA-Session. Error code: 1 | Error name: HEALTHATTESTATION_CERT_RETRIEVAL_REQUESTED Error description: This state signifies that MDM client’s Exec call on the node VerifyHealth has been triggered and now the OS is trying to retrieve DHA-EncBlob from DHA-Server. @@ -1241,13 +1241,13 @@ Error code: 8 | Error name: HEALTHATTESTATION_CERT_RETRIEVAL_FROM_WEB_FAIL Error description: Deprecated in Windows 10, version 1607. Error code: 9 | Error name: HEALTHATTESTATION_CERT_RETRIEVAL_INVALID_TPM_VERSION -Error description: Invalid TPM version (TPM version is not 1.2 or 2.0) +Error description: Invalid TPM version (TPM version isn't 1.2 or 2.0) Error code: 10 | Error name: HEALTHATTESTATION_CERT_RETRIEVAL_GETNONCE_FAIL -Error description: Nonce was not found in the registry. +Error description: Nonce wasn't found in the registry. Error code: 11 | Error name: HEALTHATTESTATION_CERT_RETRIEVAL_GETCORRELATIONID_FAIL -Error description: Correlation ID was not found in the registry. +Error description: Correlation ID wasn't found in the registry. Error code: 12 | Error name: HEALTHATTESTATION_CERT_RETRIEVAL_GETCERT_FAIL Error description: Deprecated in Windows 10, version 1607. @@ -1331,7 +1331,7 @@ Error code: 400 | Error name: Bad_Request_From_Client Error description: DHA-CSP has received a bad (malformed) attestation request. Error code: 404 | Error name: Endpoint_Not_Reachable -Error description: DHA-Service is not reachable by DHA-CSP +Error description: DHA-Service isn't reachable by DHA-CSP ### DHA-Report V3 schema diff --git a/windows/client-management/mdm/implement-server-side-mobile-application-management.md b/windows/client-management/mdm/implement-server-side-mobile-application-management.md index 396d3ea018..35bed03a19 100644 --- a/windows/client-management/mdm/implement-server-side-mobile-application-management.md +++ b/windows/client-management/mdm/implement-server-side-mobile-application-management.md @@ -20,7 +20,7 @@ The Windows version of mobile application management (MAM) is a lightweight solu MAM on Windows is integrated with Azure Active Directory (Azure AD) identity service. The MAM service supports Azure AD-integrated authentication for the user and the device during enrollment and the downloading of MAM policies. MAM integration with Azure AD is similar to mobile device management (MDM) integration. See [Azure Active Directory integration with MDM](azure-active-directory-integration-with-mdm.md).  -MAM enrollment is integrated with adding a work account flow to a personal device. If both MAM and Azure AD-integrated MDM services are provided in an organization, a users’ personal devices will be enrolled to MAM or MDM, depending on the user’s actions. If a user adds their work or school Azure AD account as a secondary account to the machine, their device will be enrolled to MAM. If a user joins their device to Azure AD, it will be enrolled to MDM.  In general, a device that has a personal account as its primary account is considered a personal device and should be enrolled to MAM. An Azure AD join, and enrollment to MDM, should be used to manage corporate devices. +MAM enrollment is integrated with adding a work account flow to a personal device. If both MAM and Azure AD-integrated MDM services are provided in an organization, a user's personal devices will be enrolled to MAM or MDM, depending on the user’s actions. If a user adds their work or school Azure AD account as a secondary account to the machine, their device will be enrolled to MAM. If a user joins their device to Azure AD, it will be enrolled to MDM.  In general, a device that has a personal account as its primary account is considered a personal device and should be enrolled to MAM. An Azure AD join, and enrollment to MDM, should be used to manage corporate devices. On personal devices, users can add an Azure AD account as a secondary account to the device while keeping their personal account as primary. Users can add an Azure AD account to the device from a supported Azure AD-integrated application, such as the next update of Microsoft Office 365 or Microsoft Office Mobile. Alternatively, users can add an Azure AD account from **Settings > Accounts > Access work or school**. @@ -28,7 +28,7 @@ Regular non-admin users can enroll to MAM.  ## Integration with Windows Information Protection -MAM on Windows takes advantage of [built-in Windows Information Protection (WIP) policies](/windows/security/information-protection/windows-information-protection/protect-enterprise-data-using-wip) to protect company data on the device. To protect user-owned applications on personal devices, MAM limits enforcement of WIP policies to [enlightened apps](/windows/security/information-protection/windows-information-protection/enlightened-microsoft-apps-and-wip) and WIP-aware apps. Enlightened apps can differentiate between corporate and personal data, correctly determining which to protect based on WIP policies. WIP-aware apps indicate to Windows that they do not handle personal data, and therefore it is safe for Windows to protect data on their behalf.  +MAM on Windows takes advantage of [built-in Windows Information Protection (WIP) policies](/windows/security/information-protection/windows-information-protection/protect-enterprise-data-using-wip) to protect company data on the device. To protect user-owned applications on personal devices, MAM limits enforcement of WIP policies to [enlightened apps](/windows/security/information-protection/windows-information-protection/enlightened-microsoft-apps-and-wip) and WIP-aware apps. Enlightened apps can differentiate between corporate and personal data, correctly determining which to protect based on WIP policies. WIP-aware apps indicate to Windows that they don't handle personal data, and therefore, it's safe for Windows to protect data on their behalf.  To make applications WIP-aware, app developers need to include the following data in the app resource file. @@ -42,22 +42,25 @@ To make applications WIP-aware, app developers need to include the following dat ## Configuring an Azure AD tenant for MAM enrollment -MAM enrollment requires integration with Azure AD. The MAM service provider needs to publish the Management MDM app to the Azure AD app gallery. Starting with Azure AD in Windows 10, version 1703, the same cloud-based Management MDM app will support both MDM and MAM enrollments. If you have already published your MDM app, it needs to be updated to include MAM Enrollment and Terms of use URLs. The screenshot below illustrates the management app for an IT admin configuration.  +MAM enrollment requires integration with Azure AD. The MAM service provider needs to publish the Management MDM app to the Azure AD app gallery. With Azure AD in Windows 10, version 1703, onward, the same cloud-based Management MDM app will support both MDM and MAM enrollments. If you've already published your MDM app, it needs to be updated to include MAM Enrollment and Terms of use URLs. The screenshot below illustrates the management app for an IT admin configuration.  :::image type="content" alt-text="Mobile application management app." source="images/implement-server-side-mobile-application-management.png"::: -MAM and MDM services in an organization could be provided by different vendors. Depending on the company configuration, IT admin typically needs to add one or two Azure AD Management apps to configure MAM and MDM policies. For example, if both MAM and MDM are provided by the same vendor, then an IT Admin needs to add one Management app from this vendor that will contain both MAM and MDM policies for the organization. Alternatively, if the MAM and MDM services in an organization are provided by two different vendors, then two Management apps from the two vendors need to be configured for the company in Azure AD: one for MAM and one for MDM. Please note: if the MDM service in an organization is not integrated with Azure AD and uses auto-discovery, only one Management app for MAM needs to be configured.  +MAM and MDM services in an organization could be provided by different vendors. Depending on the company configuration, IT admin typically needs to add one or two Azure AD Management apps to configure MAM and MDM policies. For example, if both MAM and MDM are provided by the same vendor, then an IT Admin needs to add one Management app from this vendor that will contain both MAM and MDM policies for the organization. Alternatively, if the MAM and MDM services in an organization are provided by two different vendors, then two Management apps from the two vendors need to be configured for the company in Azure AD: one for MAM and one for MDM. + +> [!NOTE] +> If the MDM service in an organization isn't integrated with Azure AD and uses auto-discovery, only one Management app for MAM needs to be configured.  ## MAM enrollment MAM enrollment is based on the MAM extension of [[MS-MDE2] protocol](/openspecs/windows_protocols/ms-mde2/4d7eadd5-3951-4f1c-8159-c39e07cbe692). MAM enrollment supports Azure AD [federated authentication](federated-authentication-device-enrollment.md) as the only authentication method.  Below are protocol changes for MAM enrollment:  -- MDM discovery is not supported. +- MDM discovery isn't supported. - APPAUTH node in [DMAcc CSP](dmacc-csp.md) is optional. -- MAM enrollment variation of [MS-MDE2] protocol does not support the client authentication certificate, and therefore does not support the [MS-XCEP] protocol. Servers must use an Azure AD token for client authentication during policy syncs. Policy sync sessions must be performed over one-way SSL using server certificate authentication. +- MAM enrollment variation of [MS-MDE2] protocol doesn't support the client authentication certificate, and therefore doesn't support the [MS-XCEP] protocol. Servers must use an Azure AD token for client authentication during policy syncs. Policy sync sessions must be performed over one-way SSL using server certificate authentication. -Here is an example provisioning XML for MAM enrollment. +Here's an example provisioning XML for MAM enrollment. ```xml @@ -97,10 +100,10 @@ MAM on Windows supports the following configuration service providers (CSPs). Al MAM supports device lock policies similar to MDM. The policies are configured by DeviceLock area of Policy CSP and PassportForWork CSP. -We do not recommend configuring both Exchange ActiveSync (EAS) and MAM policies for the same device. However, if both are configured, the client will behave as follows: +We don't recommend configuring both Exchange ActiveSync (EAS) and MAM policies for the same device. However, if both are configured, the client will behave as follows: -- When EAS policies are sent to a device that already has MAM policies, Windows evaluates whether the existing MAM policies are compliant with the configured EAS policies and reports compliance to EAS. -- If the device is found to be compliant, EAS will report compliance to the server to allow mail to sync. MAM supports mandatory EAS policies only. Checking EAS compliance does not require device admin rights. +- When EAS policies are sent to a device that already has MAM policies, Windows evaluates whether the existing MAM policies are compliant with the configured EAS policies, and reports compliance with EAS. +- If the device is found to be compliant, EAS will report compliance with the server to allow mail to sync. MAM supports mandatory EAS policies only. Checking EAS compliance doesn't require device admin rights. - If the device is found to be non-compliant, EAS will enforce its own policies to the device and the resultant set of policies will be a superset of both. Applying EAS policies to the device requires admin rights. - If a device that already has EAS policies is enrolled to MAM, the device will have both sets of policies: MAM and EAS, and the resultant set of policies will be a superset of both. @@ -110,10 +113,10 @@ MAM policy syncs are modeled after MDM. The MAM client uses an Azure AD token to ## Change MAM enrollment to MDM -Windows does not support applying both MAM and MDM policies to the same devices. If configured by the admin, a user can change his MAM enrollment to MDM. +Windows doesn't support applying both MAM and MDM policies to the same devices. If configured by the admin, users can change their MAM enrollment to MDM. > [!NOTE] -> When users upgrade from MAM to MDM on Windows Home edition, they lose access to WIP. On Windows Home edition, we do not recommend pushing MDM policies to enable users to upgrade. +> When users upgrade from MAM to MDM on Windows Home edition, they lose access to WIP. On Windows Home edition, we don't recommend pushing MDM policies to enable users to upgrade. To configure MAM device for MDM enrollment, the admin needs to configure the MDM Discovery URL in the DMClient CSP. This URL will be used for MDM enrollment. @@ -123,11 +126,11 @@ In the process of changing MAM enrollment to MDM, MAM policies will be removed f - EDP CSP Enterprise ID is the same for both MAM and MDM. - EDP CSP RevokeOnMDMHandoff is set to false. -If the MAM device is properly configured for MDM enrollment, then the Enroll only to device management link will be displayed in **Settings > Accounts > Access work or school**. The user can select this link, provide their credentials, and the enrollment will be changed to MDM. Their Azure AD account will not be affected. +If the MAM device is properly configured for MDM enrollment, then the Enroll only to device management link will be displayed in **Settings > Accounts > Access work or school**. The user can select this link, provide their credentials, and the enrollment will be changed to MDM. Their Azure AD account won't be affected. ## Skype for Business compliance with MAM -We have updated Skype for Business to work with MAM. The following table explains Office release channels and release dates for Skype for Business compliance with the MAM feature. +We've updated Skype for Business to work with MAM. The following table explains Office release channels and release dates for Skype for Business compliance with the MAM feature. |Update channel|Primary purpose|LOB Tattoo availability|Default update channel for the products| |--- |--- |--- |--- | diff --git a/windows/client-management/mdm/index.md b/windows/client-management/mdm/index.md index bf8ff417c4..7fe9cd95eb 100644 --- a/windows/client-management/mdm/index.md +++ b/windows/client-management/mdm/index.md @@ -22,7 +22,7 @@ There are two parts to the Windows management component: - The enrollment client, which enrolls and configures the device to communicate with the enterprise management server. - The management client, which periodically synchronizes with the management server to check for updates and apply the latest policies set by IT. -Third-party MDM servers can manage Windows 10 by using the MDM protocol. The built-in management client is able to communicate with a third-party server proxy that supports the protocols outlined in this document to perform enterprise management tasks. The third-party server will have the same consistent first-party user experience for enrollment, which also provides simplicity for Windows 10 users. MDM servers do not need to create or download a client to manage Windows 10. For details about the MDM protocols, see [\[MS-MDM\]: Mobile Device Management Protocol](/openspecs/windows_protocols/ms-mdm/33769a92-ac31-47ef-ae7b-dc8501f7104f) and [\[MS-MDE2\]: Mobile Device Enrollment Protocol Version 2](/openspecs/windows_protocols/ms-mde2/4d7eadd5-3951-4f1c-8159-c39e07cbe692). +Third-party MDM servers can manage Windows 10 by using the MDM protocol. The built-in management client is able to communicate with a third-party server proxy that supports the protocols outlined in this document to perform enterprise management tasks. The third-party server will have the same consistent first-party user experience for enrollment, which also provides simplicity for Windows 10 users. MDM servers don't need to create or download a client to manage Windows 10. For details about the MDM protocols, see [\[MS-MDM\]: Mobile Device Management Protocol](/openspecs/windows_protocols/ms-mdm/33769a92-ac31-47ef-ae7b-dc8501f7104f) and [\[MS-MDE2\]: Mobile Device Enrollment Protocol Version 2](/openspecs/windows_protocols/ms-mde2/4d7eadd5-3951-4f1c-8159-c39e07cbe692). ## MDM security baseline @@ -52,7 +52,7 @@ For information about the MDM policies defined in the Intune security baseline, ## Learn about migrating to MDM -When an organization wants to move to MDM to manage devices, they should prepare by analyzing their current Group Policy settings to see what they need to transition to MDM management. Microsoft created the [MDM Migration Analysis Tool](https://aka.ms/mmat/) (MMAT) to help. MMAT determines which Group Policies have been set for a target user or computer and then generates a report that lists the level of support for each policy settings in MDM equivalents. For more information, see [MMAT Instructions](https://github.com/WindowsDeviceManagement/MMAT/blob/master/MDM%20Migration%20Analysis%20Tool%20Instructions.pdf). +When an organization wants to move to MDM to manage devices, they should prepare by analyzing their current Group Policy settings to see what they need to transition to MDM management. Microsoft created the [MDM Migration Analysis Tool](https://aka.ms/mmat/) (MMAT) to help. MMAT determines which Group Policies have been set for a target user or computer and then generates a report that lists the level of support for each policy setting in MDM equivalents. For more information, see [MMAT Instructions](https://github.com/WindowsDeviceManagement/MMAT/blob/master/MDM%20Migration%20Analysis%20Tool%20Instructions.pdf). ## Learn about device enrollment