2.1 Transport
MDM, both as defined in this document and the OMA-DM protocol [OMA-DMP1.2.1], uses HTTP (as specified in [RFC2616]) as the transport layer. MDM, in compliance with [OMA-SyncML-HTTPBnd], supports both "application/vnd.syncml.dm+xml" (default) and "application/vnd.syncml.dm+wbxml" encoding types. The server can be configured with the DMAcc Configuration Service Provider’s Microsoft/DefaultEncoding, as described in [MSDOCS-DMAcc-CSP]. HTTP operations are performed on resources identified by a URI. MDM extends the resource addressing rules used by HTTP for URI formatting as specified in section 2.2.3.
This document does not prescribe a mechanism to secure (authenticate, encrypt, and so on) MDM communications. For security recommendations relating to the protocol transport layer, see [RFC5023] section 15.
Note 1: The device extends the MDM server request URL to include device OMA-DM mode information.<1> The MDM client can execute under different contexts on the device. The MDM client forwards the context and condition to the DM service via the "mode" parameter in the request URL. The mode parameter contains one of the following values:
• Maintenance
• Machine
For an example, see http://www.contoso.com/omadm/cimhandler.ashx?mode=Machine&Platform=WoA
If the mode parameter is set to "Maintenance", the MDM client is launched when there is an active user login.
If the mode parameter is set "Machine", the MDM client is launched in the System context and the client does not have access the user's profile.
Additionally, the device also includes implementation-specific platform information via the "Platform" parameter in the request URL.<2>
Note 2: When the device is connected to the MDM server via HTTP, the user-agent header value is MSFT OMA DM Client/1.2.0.1.<3>
Note 3: When the device is joined to an Azure Active Domain (AAD) or the login user has an AAD account, the Authorization HTTP header contains the AAD token when the DM client is communicating with the MDM server. <4> The header is in the following format:
-
Bearer CI6MTQxmCF5xgu6yYcmV9ng6vhQfaJYw…
For more information, see [MSDN-ADDToken].
Note 4: When an MDM device establishes an SSL/TLS connection with the MDM server through SSL bridging–enabled proxies, the client device identity certificate obtained by the target MDM server from transport security will be the intermediate proxy server client authentication certificate instead of the actual device client identity certificate.<5> It is required that the MDM client and MDM server have a mechanism to send and verify device identity securely in this case. This is achieved by including a client certificate related HTTP header in a DM package. The MDM server can identify a connecting device by examining the device client identity certificate issued earlier at MDM enrollment time. The device client identity certificate is used to establish the SSL/TLS connection to the MDM server.
Every SyncML message that comes from the MDM client carries an additional HTTP header named MS-Signature and Authorization. This header contains a BASE64-encoded CMS (Cryptographic Message Syntax) Detached Signature of the complete SyncML message (SyncHdr, SyncBody) SHA-2 hash. Signing is performed using the private key of the device identify certificate.
The device identity certificate (public key) and PKCS9 UTC signing time stamp are included as part of the authenticated attributes in the signature.
This is an opt-in function. By default, the MDM client doesn't sign the DM package. During MDM enrollment, the server could require the DM client to sign the outgoing MD package via RequireMessageSigning node in DMClient CSP. For more information about device enrollment and DMClient CSP, see [MS-MDE2].
The MDM server validates the signature, and time stamp using a device identity certificate. It ensures the device's client identity certificate is valid (issued by MDM at enrollment time), the time is valid (optional), and the signature is valid and trusted by the MDM server as of today.
Note 5: The MDM-GenericAlert is a custom HTTP header that hosts one or more instances of OMA DM generic alert information provided in the HTTP messages sent by the device to the server during an OMA DM session<6>. This custom header is sent if the DM session is triggered by the device due to one or more critical or fatal alerts, such as when the Mark element in the Item element of the generic alert contains a value of fatal or critical. The following is the alert format:
-
MDM-GenericAlert: <AlertType1><AlertType2>
Only the Type property of the generic alert is presented in the header. Each generic alert's Type information is delimited with <>. If present, the MDM-GenericAlert header is presented in every outgoing MDM message in the same OMA DM session. For more information about the generic alert message and its format, see section 8.7 in [OMA-DMP1.2.1].
Note 6: Additional bidirectional confidentiality and integrity checks SHOULD<7> be enabled on top of the transport layer. This allows for safer communication beyond SSL termination point and protection against Man in the Middle attacks. Server and client both can ensure that the message has not been tampered with or eavesdropped by any entity on the internet other than the recipient.
This is an opt-in function. By default, the MDM client doesn't enable these operations. Server can configure these using EnhancedAppLayerSecurity nodes in DMClient CSP node. After the account is configured, future MDM sync sessions provide additional confidentiality, integrity, or both confidentiality and integrity checks.
Data sent to server is PKCS#7 signed and enveloped data per [RFC2315].
Server installs MDM Server Certificate using CertificateStore CSP under System\My path before enabling the feature. Server should not delete the certificate chain because these will be deleted during enrollment. These will be deleted when the device un-enrolls from MDM management.
SyncML coming (SyncHdr, SyncBody) from the OMADM client to the MDM server will be enveloped by the MDM server certificate and signed by the client certificate (exchanged during enrollment). SyncML coming from the MDM server to the OMADM client will be enveloped by the client certificate and signed by the MDM server certificate. SHA-2 256-bit encryption and signing algorithms are used to compute the signatures.
Note 7: The client will add an additional header, MS-CV, to the request for the server to use as a correlation ID. The value is generated according to the procedure described in [MSFT-CorrelationVector].<8>
Note 8: If the server has set EntDMID in the DMClient configuration service provider, the client adds client-request-id to the header and sets it to the value of EntDMID.<9> See [MSDOCS-DMClient-CSP] for more information.