Common issues when implementing Windows Phone 8 Enterprise Mobile Device Management.
This blog describes a number of common issues encountered when implementing Windows Phone 8 Enterprise Mobile Device Management protocol along with troubleshooting tips which ISVs can use. TIP: check the download link regularly to see if the documentation has been updated and some of the information below may have already been added to the documentation by the time you read this blog.
This blog assumes you have read the Windows Phone 8 Enterprise Mobile Device Management protocol document and are familiar with Open Mobile Alliance: SyncML protocol.
Tools
One major problem ISVs encounter during implementation of an Enterprise MDM service is the lack of debugging capability of the DM client on Windows Phone. At the time of writing this blog the Windows Phone device is effectively a black box... there is no way for an ISV to get logging information out of a retail phone. The alternative is to use network logging tools like Fiddler to examine the traffic to and from the device.
Most of the network traffic we are interested in debugging will be over an SSL encrypted connection. In order to view these communications you need to use a tool which supports SSL packet inspection. Fiddler does this by acting as a proxy and using a man-in-the-middle technique in which the proxy supplies it's own SSL certificate to the client, however this certificate is not trusted by the phone so you must manually install the certificate on the phone. (see the Fiddler documentation for instructions on configuring HTTPS traffic recording. )
A second option is to use a more traditional network capture utility, like NetMon or WireShark, which can decrypt traffic using the servers certificate... One caveat is that decryption requires access to the private key for the server SSL certificate which may be a problem if your server is using a commercial root authority. ( See your preferred network capture tools' documentation for instructions on decrypting SSL packets. )
Discovery and GetPolicies
The Discovery and GetPolicies steps are fairly simple, and well documented, so most problems can be diagnosed by comparing the contents of your network capture against the samples in the documentation.
However, I will point out a few things that people commonly overlook:
- You need a domain name server (DNS) which can resolve the appropriate host name. This means that you cannot use an IP address in place of the host name.
- All services must support secure connection (HTTPS) and the Subject Name, or Subject Alternative Name, of the Server SSL certificate must match the host name of the server. (...wildcard certificates are not allowed.)
- In the GetPoliciesResponse, the only policies which Windows Phone 8 supports are minimalKeyLength, hashAlgorithmOIDReference, and the associated <oID> node... other values in the response payload are ignored.
- TIP: It's a good idea to write some test code to double check your XML payloads. One of the most confusing issues I have had to diagnose was the result of an extra space in a namespace definition in one of the XML payloads. (This applies to all enrollment steps.)
Enrollment
The majority of problems you are likely to run into revolve around the RequestSecurityToken and RequestSecurityTokenResponse.
Generating the Client Certificate:
There are several things you should be aware of in regards to the PKCS#10 request for a client certificate and the resulting client certificate.
- The client certificate you send in response to this request must have the same public key value as specified in the PKCS#10 request.
If you return a client certificate with a different public key the enrollment will report success but the client certificate will not be able to use the pre-generated private key.- This will prevent Company Hub download from working over HTTPS.
- This will also prevent SyncML from connecting if the server requires client certificate
- And will prevent the device from being able to renew the certificate when it expires.
- Note: once the certificate expires the user will be unable to launch any company signed apps associated with this enrollment. The only way to recover from this state is to un-enroll the device and then go through the enrollment process all over again.
The following items only affect Company Hub download over HTTPS... these do not affect any other aspect of device management.
- Windows Phone 8 uses a hard-coded value for Subject in this request, B1C43CD0-1624-5FBB-8E54-34CF17DFD3A1, and assumes that the server will replace this value in the supplied client certificate.
If the server returns a client certificate containing the same Subject value this can prevent the Company Hub download from working so the server should ALWAYS override the Subject.
- The client certificate's Subject property should be encoded using ASN.1 string type: "PRINTABLE_STRING".
Versions of Windows Phone 8 available at the time of writing this blog are unable to retrieve a client certificate unless the Subject property is encoded using ASN.1 string type: "PRINTABLE_STRING". (note: PRINTABLE_STRING is a subset of UTF8STRING.) - The client Certificate's Subject property should not contain any null (0) bytes. Since the CertificateSearchCriteria is stored as a string any null characters will be treated as string terminators causing the string to be truncated which prevents the company hub download service from finding the certificate.
Contents of the wap-provisioningdoc
Next I'll discuss some issues related to the contents of the wap-provisioningdoc supplied in the RequestSecurityTokenResponse.
SSLCLIENTCERTSEARCHCRITERIA
- The value of SSLCLIENTCERTSEARCHCRITERIA must begin with "Subject=" as plain text followed by the URL encoded contents of the Subject property and should end with "&Stores=My%5CUser".
APPAUTH
There seems to be a lot of confusion regarding the function of the APPAUTH entries due to the names associated with the AAUTHLEVEL parameter.
These entries contain the initial credentials used to for authentication during the SyncML process. You must provide entries for both CLIENT and APPSRV in order for Windows Phone to initiate a SyncML session with the server.
The APPAUTH entry with AAUTHLEVEL of "CLIENT" represents the credentials which the server will send to the client. These credentials must use DIGEST authentication.
The APPAUTH entry with AAUTHLEVEL of "APPSRV" represents the credentials which the client will send to the server when initiating a SyncML session.
OmaDmRetry
The OmaDmRetry registry keys control the behavior of the initial SyncML session and subsequent periodic polling schedule. Note: These values only affect the scheduling if set during initial enrollment or during renewal so if you make a mistake you will need to un-enroll then re-enroll.
If the phone fails to connect to your SyncML server immediately after enrollment completes then check to make sure that the values for AuxRetryInterval and AuxNumRetries are greater than zero. The default values are 15 and 10 respectively.
The periodic polling schedule, specified by Aux2RetryInterval and Aux2NumRetries, will not start until the initial SyncML session completes successfully.
If the phone is unable to connect to the SyncML server after exhausting all retries then the user will need to select the manual refresh from the Company Apps detail page in order to kick-start the periodic schedule.
The same problem can occur if the phones clock is moved forward beyond the time when the initial sync would have exhausted all retry attempts. (i.e. Current Time + NumRetries * RetryInterval + AuxNumRetries * AuxRetryInterval)
EnterpriseAppManagement
The first level node under EnterpriseAppManagment is the "Enterprise ID". The values for Enterprise ID and EnrollmentToken should be identical to the values in the *.aetx file created by the AETGenerator tool. see How to generate an application enrollment token.
An enterprise signing certificate is required for creating the EnrollmentToken. If you do not yet have an enterprise signing certificate then you should not include the EnterpriseAppManagment node in your wap-provisioningdoc.
CRLCheck: A certificate authority may include a certificate revocation list (CRL) Uri in the server certificate. In some cases, where the CRL publishing point is not reachable from the internet, you may need to set CRLCheck =0 to disable checking so that connection to the server can succeed.
Company Hub Download troubleshooting:
If your company hub does not install, first check to see if there is any connection attempt at the server side.
Note: normal IIS server logs do not include failed connection attempts so you will need to use a tool like netmon on the server.If you see download begin but abort prematurely:
check to see if your server is responding with 206 (Partial Content)... if so make sure it also includes a Content-Range header. If Content-Range header is missing then the download will fail.
Note: If you have trouble getting the server to send the Content-Range header then try disabling re-startable download for this file type.If using HTTPS scheme:
If you see a connection attempt but download does not start then the problem is likely related to the server SSL certificate or some other server security setting.
If you see no connection attempt at all then the problem is likely with the client certificate or CertificateSearchCriteria.
Use certutil -asn <cert>.cer to dump the raw ASN encoding data for the certificate and check the following items:Make sure the client certificate's Subject property is using ASN.1 string type "PRINTABLE_STRING".
06 03 ; OBJECT_ID (3 Bytes)
| 55 04 03 ; 2.5.4.3 Common Name (CN)
13 06 ; PRINTABLE_STRING (6 Bytes)
54 65 73 74 43 4e ; TestCNMake sure the CertificateSearchCriteria matches the Subject property of the certificate. From the sample above the CertificateSearchCriteria should be: "CN=TestCN".
Make sure there are no null characters in the Subject property.
Certificate Renewal
- You must set the EntDMID of the DMClient CSP prior to certificate renewal. The value of EntDMID is used in the certificate renewal request. If this value is not set then the renewal request will not be sent.
SyncML
Digest (MD5) authentication: When initiating a SyncML session the server must send a hash of the credentials agreed upon previously. (see APPAUTH above.)
This calculation uses a random seed or "nonce" to increase security. Usually, after the initial request and response packages, the client will send a challenge with a 'NextNonce' value. The server must respond with a new hash value calculated using this nonce and must store this nonce value to use in future sessions with that device...until the client sends another challenge request with a new nonce.
Below is a code example of how this hash value is calculated:
///<summary>
/// Calculates the OMA DM MD5 Digest hash for the given input parameters.
///</summary>
///<param name="Name">The ProviderID as specified in the APPLICATION provisioning during enrollment.</param>
///<param name="Password">The AAUTHSECRET from the APPAUTH configuration.</param>
///<param name="ServerNonce">The Base64 encoded AAUTHDATA from the APPAUTH configuration or the NextNonce value from the most recent challenge ('chal'). </param>
///<returns></returns>
private string calculateHash(string Name, string Password, string ServerNonce)
{string hash = "";
// first compute hash of <username>:<password>
string tmp = String.Format("{0}:{1}", Name, Password);byte[] buffer = Encoding.UTF8.GetBytes(tmp);
MD5 md5Hash = MD5.Create();
byte[] output = md5Hash.ComputeHash(buffer);
// convert result to Base64 string, add a colon separator, and get a byte array of the string.
string tmp2 = String.Format("{0}:", Convert.ToBase64String(output));byte[] tmp3 = Encoding.UTF8.GetBytes(tmp2);
// convert input: ServerNonce from Base64 to a byte array.
byte[] tmp4 = Convert.FromBase64String(ServerNonce);// Combine the arrays into a single buffer.
byte[] buffer2 = newbyte[tmp3.Length + tmp4.Length];tmp3.CopyTo(buffer2, 0);
tmp4.CopyTo(buffer2, tmp3.Length);
// Compute the hash of the resulting buffer.
output = md5Hash.ComputeHash(buffer2);// Convert the byte array into a Base64 string for inclusion in XML payload.
hash = Convert.ToBase64String(output);return hash;
}
The items described above are the most frequently asked questions and reported problems which I have encountered.
But there are some minor issues people report less frequently which I did not have space to cover. If there is enough interest, and I have enough content, I may follow up with a second blog.
Comments are welcome,both below and on twitter:#WSDevSol.
Related information:
Introduction to ASN.1 Syntax and Encoding
Debugging Windows Phone 7 device traffic with Fiddler - Fiddler ...
Configure the Windows Phone 8 Emulator to work with Fiddler ...
Comments
- Anonymous
October 03, 2013
Hi, This is what i'm getting from command - certutil -asn clientCertificate.crt
| | | ; 2.5.4.3 Common Name (CN) 00f1: | | 13 25 ; PRINTABLE_STRING (25 Bytes) 00f3: | | 42 31 43 34 33 43 44 30 2d 31 36 32 34 2d 35 46 ; B1C43CD0-1624-5F 0103: | | 42 42 2d 38 45 35 34 2d 33 34 43 46 31 37 44 46 ; BB-8E54-34CF17DF 0113: | | 44 33 41 31 00 ; D3A1 . | | ; "B1C43CD0-1624-5FBB-8E54-34CF17DFD3A1"
so my subject property will be: CN%3DB1C43CD0-1624-5FBB-8E54-34CF17DFD3A1 But this is what i'm using. <parm datatype="string" name="CertificateSearchCriteria" value="CN%3DB1C43CD0-1624-5FBB-8E54-34CF17DFD3A1"/> Still after enrollment company hub doesnt gets installed. Please help in this!! Thanks Rahul.
Anonymous
October 07, 2013
Hello Rahul, Can you try with the CertificateSearchCriteria value like this: <parm datatype="string" name="CertificateSearchCriteria" value="CN=B1C43CD0%2D1624%2D5FBB%2D8E54%2D34CF17DFD3A1"/> I have replaced %3D with the equals sign, and the '='/ dashes with the escaped equivalent %2D characters. Thanks, PrashantAnonymous
October 07, 2013
As you can see, your subject has a null character at the end "...44 33 41 31 00" << '00' is null character. You should be providing a different Subject value instead of using the value from the request.Anonymous
October 07, 2013
Hi !! I tried many things but yet couldn't solve it. Please help me in the below questions:
- Device CSR's subject itself contains a null character. Device CSR => -----BEGIN CERTIFICATE REQUEST----- MIICcTCCAV0CAQAwMDEuMCwGA1UEAxMlQjFDNDNDRDAtMTYyNC01RkJCLThFNTQt MzRDRjE3REZEM0ExADCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOBw glgPqZI47sEadpdTu0Kp7BZfBofCyR+1nt9vvtl3sad65FPw3s88xkoLxwZV1Hve DELalDTANV/iscWrO6RBTKzCVBh1xu4NdZORj4Bt/TjKqgBSqJjXfLRltT+vjBMQ xdvFwQrQogkSxwR9ifAmzTtwOlQ6QtmIneCP0nGUnRJTUwbsNF9pctq7xU58UNv/ OgnynWjfj3LMwIzPbLjBaOF1p5vkPEn6KluAlNRc/mmJAGQ787+dTqtXGKhWhqle b35DZwAZkAMGKb0JK0iBC7aRDxeb0Ux7lSo3ZqUvnxcKbMRbaOXUYVmmvXwSWMeg 3+h4WKDQw4bZqocIZckCAwEAAaAAMAkGBSsOAwIdBQADggEBABScWDepRo0o4wmm Wfmc2ObVEMyHhakKG6GqQaVDz5XxsqBcZkMq+fSV7r499d4j/RrPgTiKy8v+RvnC sQexMNy7HcDK3Xls/qP9dXqP2U28a/llTR1f7O9lhtRESgcXIxQ09+v/7tbhzrnu AhLlRTg1a1FPnanaN8WqpFB67nzk7KDJC3F/1Xs6X5xXlUKq8+hTyZ/whvN7S5/Y zBYSHiGCFJwkwZfSvJgmCbl3NLcXPsbAySDAQHYpBrdp3SDGMgZv1cBNsGUZMQeN 92ZvNxC9TCpI070v0l0vIFIBfd1uv5Hr8p5HYtkVmcL5ON+UFnagYKu9xYvpD3+G SqW7S30= -----END CERTIFICATE REQUEST----- Subject property => $ openssl req -in RequestSecurityToken.csr -noout -subject subject=/CN=B1C43CD0-1624-5FBB-8E54-34CF17DFD3A1x00 2.So after signing, the client certificate has the same subject property name i.e CN=B1C43CD0-1624-5FBB-8E54-34CF17DFD3A1x00 3.Even if we try and change or try to override the property in the CSR's then signing fails saying.. "Signature did not match the certificate request" 4.Is their any other way to get through this ?? stuck here from long time...
Thanks, Rahul.
Anonymous
October 08, 2013
Excellent post I have faced all the issues until the enrollment and stuck at the enrollment now. Basically my enrollment getting success but after that no communication with the MDM. "What you meant by The client certificate you send in response to this request must have the same public key value as specified in the PKCS#10 request." I simply requesting the certificate with the Request token received from the device. Am I suppose to process the request. CCertRequest certReq = new CCertRequest(); CCertConfig certConfig = new CCertConfig(); if(3 == CertReq.Submit(BASE64|PKCS10|FORMATANY, request, "", certConfig.GetConfig(0))) { string clientCert = CertRequest.GetCertificate(BASE64); } Am I doing something wrong here?Anonymous
October 10, 2013
Hi Eric, Whenever I change Subject property of device certificate to any other value let say "CN=MyTestMDM",enrolment always failed. But If I keep subject same as that of CSR from device(CN%3DB1C43CD0-1624-5FBB-8E54-34CF17DFD3A1),then enrolment happens but hub app never get installed.Anonymous
October 13, 2013
Hi Matle Are you using a Certificate Template to change the Client Certificate subject. If not try using a certificate template to set the subject name. Can you also let me know whether after you successfully enrolled does the device calling to your DM URL. I'm not getting the DM URL called even after successfully enrolled. Tharindu.Anonymous
October 13, 2013
Hi TharinduW , After enrolment, device polls successfully.No issues in polling also.but hub app is not installed even though we check the checkbox for installation of hub app. And how yo use certificate template to set the subject name?Anonymous
October 13, 2013
Hi TharinduW, Device polls successfully after enrolment.But company hub app is not getting installed even after we chack the chaeckbox shown for installation of hub app. And how to use certficate template to change client certificate subject?Anonymous
October 13, 2013
Hi Vaibhave, Will you please explain some details how you did the enrollment as we are stuck at enrollment. Service is discovered properly but after that POST request always getting error .................... Thanks.Anonymous
October 15, 2013
The comment has been removedAnonymous
October 20, 2013
Hi, Will you please explain some details how you did the enrollment as we are stuck at enrollment. Service is discovered properly but after that POST request always getting error 404. The 2 GET requests made to the same URL by the device succeed with the code 200 0 0........ All communication is happening on https channel only. Please help. Thanks.Anonymous
October 20, 2013
The comment has been removedAnonymous
February 24, 2014
So many information in one blog. This is awesome man. I am really impressed by the way you share your thoughts about enterprise in your blog.Anonymous
April 07, 2014
I am stuck at the enrollment server setup. I am able to set discovery service but facing issues while proceeding further. What are the XCEP and WSTEP servers? Do I need to actually write code and implement them or I just need to install them and use if yes then how ?Anonymous
April 09, 2014
You need to write some code in your server layer to handle these messages. Your server can leverage an existing Certificate service for the actual certificate allocation but you need to do some validation and translation in your MDM implementation layer. MS-XCEP and MS-WSTEP are SOAP based message protocols. Windows Phone 8 Enterprise Device Management client supports only a subset of these protocols, as defined in the MDM protocol doc. Also, in the Windows Phone 8 MDM clients' implementation of MS-WSTEP the device expects the BinarySecurityToken to contain a wap-provisioning XML, not a simple certificate.Anonymous
April 17, 2014
The comment has been removedAnonymous
May 09, 2014
@zait, the first thing that comes to mind is: are you incrementing the MsgID in your response? (i.e. client sends request MsgID=1, server should respond with MsgID=2.) Also make sure that your response acknowledges the credentials which the client sent with a 212 status.Anonymous
July 02, 2014
Hi Eric, How can I encode the subject name with Printable_String format?Anonymous
December 28, 2014
The comment has been removedAnonymous
February 11, 2015
The comment has been removedAnonymous
August 04, 2015
Are there any other criteria for the SSLCLIENTCERTSEARCHCRITERIA? An MSDN forum thread (social.msdn.microsoft.com/.../windows-81-enrolment-wstep-stage) leads me to believe that there may be something else wrong with mine. Even though it matches the subject of my certificate exactly and is URL encoded, the device still rolls back the certificate installation. It may not be the SSLCLIENTCERTSEARCHCRITERIA which is my issue, but I'm sort of grasping at straws here.Anonymous
August 04, 2015
It may be worth noting that I only experience this issue when using the Federated enrollment scheme. I use the same process to generate certificates and create the provisioning XML when using OnPremise enrollment. The process and values work correctly for OnPrem, but they fail for Federated. Any help would be appreciated.Anonymous
October 05, 2015
Hello Eric, Facing a problem in generating CSR from PKCS#10 device RequestSecurityToken. Is it require to generate on every request from device certificate enrollment web service. Any help would be appreciated.Anonymous
March 08, 2016
Hi Eric, I am having problems in the MDM implementation for win10 devices, specifically the certificate enrollment step (which includes wap creation). Could u please have a look at this forum question that I have raised : social.msdn.microsoft.com/.../mdm-enrollment-for-windows-10-mswstep-certificate-enrollment Any kind of help will be appreciated. Thanks