mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-22 13:53:39 +00:00
Copy edits for 401116 fixed
fixed note coding,
This commit is contained in:
@ -16,8 +16,8 @@ ms.date: 06/26/2017
|
||||
|
||||
This section provides an example of the mobile device enrollment protocol using certificate authentication policy. For details about the Microsoft mobile device enrollment protocol for Windows 10, see [\[MS-MDE2\]: Mobile Device Enrollment Protocol Version 2]( https://go.microsoft.com/fwlink/p/?LinkId=619347).
|
||||
|
||||
>[!Note]
|
||||
>To set up devices to use certificate authentication for enrollment, you should create a provisioning package. For more information about provisioning packages, see [Build and apply a provisioning package](https://msdn.microsoft.com/library/windows/hardware/dn916107).
|
||||
> [!Note]
|
||||
> To set up devices to use certificate authentication for enrollment, you should create a provisioning package. For more information about provisioning packages, see [Build and apply a provisioning package](https://msdn.microsoft.com/library/windows/hardware/dn916107).
|
||||
|
||||
## In this topic
|
||||
|
||||
|
@ -32,8 +32,8 @@ For the list of enrollment scenarios not supported in Windows 10, see [Enrollme
|
||||
|
||||
The discovery web service provides the configuration information necessary for a user to enroll a phone with a management service. The service is a restful web service over HTTPS (server authentication only).
|
||||
|
||||
>[!Note]
|
||||
>The administrator of the discovery service must create a host with the address enterpriseenrollment.*domain\_name*.com.
|
||||
> [!Note]
|
||||
> The administrator of the discovery service must create a host with the address enterpriseenrollment.*domain\_name*.com.
|
||||
|
||||
The automatic discovery flow of the device uses the domain name of the email address that was submitted to the Workplace settings screen during sign in. The automatic discovery system constructs a URI that uses this hostname by appending the subdomain “enterpriseenrollment” to the domain of the email address, and by appending the path “/EnrollmentServer/Discovery.svc”. For example, if the email address is “sample@contoso.com”, the resulting URI for first Get request would be: http:<span></span>//enterpriseenrollment.contoso.com/EnrollmentServer/Discovery.svc
|
||||
|
||||
@ -127,21 +127,21 @@ The discovery response is in the XML format and includes the following fields:
|
||||
- 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.
|
||||
|
||||
>[!Note]
|
||||
>The HTTP server response must not set Transfer-Encoding to Chunked; it must be sent as one message.
|
||||
> [!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.
|
||||
|
||||
>[!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:
|
||||
> [!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:
|
||||
> - Parse the OS version from the data sent up during the discovery request.
|
||||
> - Append the OS version as a parameter in the AuthenticationServiceURL.
|
||||
> - Parse out the OS version from the AuthenticiationServiceURL when the OS sends the response for authentication.
|
||||
|
||||
A new XML tag, AuthenticationServiceUrl, is introduced in the DiscoveryResponse XML to allow the server to specify the WAB page start URL. For Federated authentication, this XML tag must exist.
|
||||
|
||||
>[!Note]
|
||||
>The enrollment client is agnostic with regards to the protocol flows for authenticating and returning the security token. While the server might prompt for user credentials directly or enter into a federation protocol with another server and directory service, the enrollment client is agnostic to all of this. To remain agnostic, all protocol flows pertaining to authentication that involve the enrollment client are passive, that is, browser-implemented.
|
||||
> [!Note]
|
||||
> The enrollment client is agnostic with regards to the protocol flows for authenticating and returning the security token. While the server might prompt for user credentials directly or enter into a federation protocol with another server and directory service, the enrollment client is agnostic to all of this. To remain agnostic, all protocol flows pertaining to authentication that involve the enrollment client are passive, that is, browser-implemented.
|
||||
|
||||
The following are the explicit requirements for the server.
|
||||
|
||||
@ -294,8 +294,8 @@ After the user is authenticated, the web service retrieves the certificate templ
|
||||
|
||||
MS-XCEP supports very flexible enrollment policies using various Complex Types and Attributes. For Windows device, we will first support the minimalKeyLength, the hashAlgorithmOIDReference policies, and the CryptoProviders. The hashAlgorithmOIDReference has related OID and OIDReferenceID and policySchema in the GetPolicesResponse. The policySchema refers to the certificate template version. Version 3 of MS-XCEP supports hashing algorithms.
|
||||
|
||||
>[!Note]
|
||||
>The HTTP server response must not set Transfer-Encoding to Chunked; it must be sent as one message.
|
||||
> [!Note]
|
||||
> The HTTP server response must not set Transfer-Encoding to Chunked; it must be sent as one message.
|
||||
|
||||
The following snippet shows the policy web service response.
|
||||
|
||||
@ -386,8 +386,8 @@ Note that the RequestSecurityToken will use a custom TokenType (http:<span></spa
|
||||
|
||||
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.
|
||||
|
||||
>[!Note]
|
||||
>The policy service and the enrollment service must be on the same server; that is, they must have the same host name.
|
||||
> [!Note]
|
||||
> The policy service and the enrollment service must be on the same server; that is, they must have the same host name.
|
||||
|
||||
The following example shows the enrollment web service request for federated authentication.
|
||||
|
||||
@ -476,8 +476,8 @@ The following example shows the enrollment web service request for federated aut
|
||||
|
||||
After validating the request, the web service looks up the assigned certificate template for the client, update it if needed, sends the PKCS\#10 requests to the CA, processes the response from the CA, constructs an OMA Client Provisioning XML format, and returns it in the RequestSecurityTokenResponse (RSTR).
|
||||
|
||||
>[!Note]
|
||||
>The HTTP server response must not set Transfer-Encoding to Chunked; it must be sent as one message.
|
||||
> [!Note]
|
||||
> The HTTP server response must not set Transfer-Encoding to Chunked; it must be sent as one message.
|
||||
|
||||
Similar to the TokenType in the RST, the RSTR will use a custom ValueType in the BinarySecurityToken (http:<span></span>//schemas.microsoft.com/ConfigurationManager/Enrollment/DeviceEnrollmentProvisionDoc), because the token is more than an X.509 v3 certificate.
|
||||
|
||||
|
@ -54,8 +54,8 @@ The following topics describe the end-to-end enrollment process using various au
|
||||
- [Certificate authentication device enrollment](certificate-authentication-device-enrollment.md)
|
||||
- [On-premise authentication device enrollment](on-premise-authentication-device-enrollment.md)
|
||||
|
||||
>[!Note]
|
||||
>As a best practice, do not use hardcoded server-side checks on values such as:
|
||||
> [!Note]
|
||||
> As a best practice, do not use hardcoded server-side checks on values such as:
|
||||
> - User agent string
|
||||
> - Any fixed URIs that are passed during enrollment
|
||||
> - Specific formatting of any value unless otherwise noted, such as the format of the device ID.
|
||||
@ -292,9 +292,3 @@ TraceID is a freeform text node which is logged. It should identify the server s
|
||||
- [Federated authentication device enrollment](federated-authentication-device-enrollment.md)
|
||||
- [Certificate authentication device enrollment](certificate-authentication-device-enrollment.md)
|
||||
- [On-premise authentication device enrollment](on-premise-authentication-device-enrollment.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -30,8 +30,8 @@ For the list of enrollment scenarios not supported in Windows 10, see [Enrollme
|
||||
|
||||
The discovery web service provides the configuration information necessary for a user to enroll a device with a management service. The service is a restful web service over HTTPS (server authentication only).
|
||||
|
||||
>[!NOTE]
|
||||
>The administrator of the discovery service must create a host with the address enterpriseenrollment.*domain\_name*.com.
|
||||
> [!NOTE]
|
||||
> The administrator of the discovery service must create a host with the address enterpriseenrollment.*domain\_name*.com.
|
||||
|
||||
The device’s automatic discovery flow uses the domain name of the email address that was submitted to the Workplace settings screen during sign in. The automatic discovery system constructs a URI that uses this hostname by appending the subdomain “enterpriseenrollment” to the domain of the email address, and by appending the path “/EnrollmentServer/Discovery.svc”. For example, if the email address is “sample@contoso.com”, the resulting URI for first Get request would be: http:<span></span>//enterpriseenrollment.contoso.com/EnrollmentServer/Discovery.svc
|
||||
|
||||
@ -129,8 +129,8 @@ The discovery response is in the XML format and includes the following fields:
|
||||
- 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.
|
||||
- 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.
|
||||
|
||||
>[!NOTE]
|
||||
>The HTTP server response must not be chunked; it must be sent as one message.
|
||||
> [!NOTE]
|
||||
> The HTTP server response must not be chunked; it must be sent as one message.
|
||||
|
||||
The following example shows a response received from the discovery web service for OnPremise authentication:
|
||||
|
||||
@ -214,8 +214,8 @@ After the user is authenticated, the web service retrieves the certificate templ
|
||||
|
||||
MS-XCEP supports very flexible enrollment policies using various Complex Types and Attributes. We will first support the minimalKeyLength, the hashAlgorithmOIDReference policies, and the CryptoProviders. The hashAlgorithmOIDReference has related OID and OIDReferenceID and policySchema in the GetPolicesResponse. The policySchema refers to the certificate template version. Version 3 of MS-XCEP supports hashing algorithms.
|
||||
|
||||
>[!NOTE]
|
||||
>The HTTP server response must not be chunked; it must be sent as one message.
|
||||
> [!NOTE]
|
||||
> The HTTP server response must not be chunked; it must be sent as one message.
|
||||
|
||||
The following snippet shows the policy web service response.
|
||||
|
||||
@ -306,8 +306,8 @@ The RequestSecurityToken will use a custom TokenType (http:<span></span>//schema
|
||||
|
||||
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.
|
||||
|
||||
>[!NOTE]
|
||||
>The policy service and the enrollment service must be on the same server; that is, they must have the same host name.
|
||||
> [!NOTE]
|
||||
> The policy service and the enrollment service must be on the same server; that is, they must have the same host name.
|
||||
|
||||
The following example shows the enrollment web service request for OnPremise authentication.
|
||||
|
||||
|
Reference in New Issue
Block a user