Inscription d'appareils à l'authentification sur site
Cette section fournit un exemple de protocole d’inscription d’appareil mobile utilisant une stratégie d’authentification locale. Pour plus d’informations sur le protocole d’inscription des appareils mobiles Microsoft pour Windows, consultez [MS-MDE2] : Protocole d’inscription des appareils mobiles version 2.
Remarque
Pour obtenir la liste des scénarios d’inscription non pris en charge dans Windows, consultez Scénarios d’inscription non pris en charge.
Service de découverte
Le service web de découverte fournit les informations de configuration nécessaires à un utilisateur pour inscrire un appareil auprès d’un service de gestion. Le service est un service web reposant sur HTTPS (authentification serveur uniquement).
Remarque
L’administrateur du service de découverte doit créer un hôte avec l’adresse enterpriseenrollment.<domain_name>.com
.
Le flux de découverte automatique de l’appareil utilise le nom de domaine de l’adresse e-mail qui a été envoyée à l’écran paramètres de l’espace de travail lors de la connexion. Le système de découverte automatique construit un URI qui utilise ce nom d’hôte en ajoutant le sous-domaine enterpriseenrollment au domaine de l’adresse e-mail et en ajoutant le chemin d’accès /EnrollmentServer/Discovery.svc
. Par exemple, si l’adresse e-mail est sample@contoso.com
, l’URI obtenu pour la première requête Get serait : http://enterpriseenrollment.contoso.com/EnrollmentServer/Discovery.svc
.
La première requête est une requête HTTP GET standard.
L’exemple suivant montre une requête via HTTP GET au serveur de découverte donné user@contoso.com comme adresse e-mail.
Request Full Url: http://EnterpriseEnrollment.contoso.com/EnrollmentServer/Discovery.svc
Content Type: unknown
Header Byte Count: 153
Body Byte Count: 0
GET /EnrollmentServer/Discovery.svc HTTP/1.1
User-Agent: Windows Phone 8 Enrollment Client
Host: EnterpriseEnrollment.contoso.com
Pragma: no-cache
Request Full Url: http://EnterpriseEnrollment.contoso.com/EnrollmentServer/Discovery.svc
Content Type: text/html
Header Byte Count: 248
Body Byte Count: 0
HTTP/1.1 200 OK
Connection: Keep-Alive
Pragma: no-cache
Cache-Control: no-cache
Content-Type: text/html
Content-Length: 0
Une fois que l’appareil reçoit une réponse du serveur, il envoie une requête POST à enterpriseenrollment.<domain_name>/EnrollmentServer/Discovery.svc
. Une fois qu’il a reçu une autre réponse du serveur (qui doit indiquer à l’appareil où se trouve le serveur d’inscription), le message suivant envoyé à partir de l’appareil est au enterpriseenrollment.<domain_name>
serveur d’inscription.
La logique suivante est appliquée :
- L’appareil tente d’abord le protocole HTTPS. Si l’appareil n’approuve pas le certificat de serveur, la tentative HTTPS échoue.
- En cas d’échec, l’appareil tente http pour voir s’il est redirigé :
- Si l’appareil n’est pas redirigé, l’utilisateur est invité à entrer l’adresse du serveur.
- Si l’appareil est redirigé, l’utilisateur est invité à autoriser la redirection.
L’exemple suivant montre une requête via une commande HTTP POST au service web de découverte donné user@contoso.com en tant qu’adresse e-mail :
https://EnterpriseEnrollment.Contoso.com/EnrollmentServer/Discovery.svc
L’exemple suivant montre la demande de service de découverte.
<?xml version="1.0"?>
<s:Envelope xmlns:a="http://www.w3.org/2005/08/addressing"
xmlns:s="http://www.w3.org/2003/05/soap-envelope">
<s:Header>
<a:Action s:mustUnderstand="1">
http://schemas.microsoft.com/windows/management/2012/01/enrollment/IDiscoveryService/Discover
</a:Action>
<a:MessageID>urn:uuid: 748132ec-a575-4329-b01b-6171a9cf8478</a:MessageID>
<a:ReplyTo>
<a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
</a:ReplyTo>
<a:To s:mustUnderstand="1">
https://ENROLLTEST.CONTOSO.COM/EnrollmentServer/Discovery.svc
</a:To>
</s:Header>
<s:Body>
<Discover xmlns="http://schemas.microsoft.com/windows/management/2012/01/enrollment/">
<request xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<EmailAddress>user@contoso.com</EmailAddress>
<OSEdition>3</OSEdition> <!--New -->
<RequestVersion>3.0</RequestVersion> <!-- Updated -->
<DeviceType>WindowsPhone</DeviceType> <!--Updated -->
<ApplicationVersion>10.0.0.0</ApplicationVersion>
<AuthPolicies>
<AuthPolicy>OnPremise</AuthPolicy>
</AuthPolicies>
</request>
</Discover>
</s:Body>
</s:Envelope>
Si un domaine et un nom d’utilisateur sont fournis par l’utilisateur au lieu d’une adresse e-mail, la <balise EmailAddress> doit contenir domaine\username. Dans ce cas, l’utilisateur doit entrer directement l’adresse du serveur.
<EmailAddress>contoso\user</EmailAddress> Response
La réponse de découverte est au format XML et inclut les champs suivants :
- URL du service d’inscription (EnrollmentServiceUrl) : spécifie l’URL du point de terminaison d’inscription exposé par le service de gestion. L’appareil doit appeler cette URL une fois que l’utilisateur a été authentifié. Ce champ est obligatoire.
- Stratégie d’authentification (AuthPolicy) : indique le type d’authentification requis. Pour le serveur MDM, OnPremise est la valeur prise en charge, ce qui signifie que l’utilisateur est authentifié lors de l’appel de l’URL du service de gestion. Ce champ est obligatoire.
- Federated est ajouté comme autre valeur prise en charge. Il permet au serveur d’utiliser le service Broker d’authentification web pour effectuer une authentification utilisateur personnalisée et l’acceptation de la durée d’utilisation.
Remarque
La réponse du serveur HTTP ne doit pas être segmentée ; il doit être envoyé sous la forme d’un seul message.
L’exemple suivant montre une réponse reçue du service web de découverte pour l’authentification OnPremise :
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing">
<s:Header>
<a:Action s:mustUnderstand="1">
http://schemas.microsoft.com/windows/management/2012/01/enrollment/IDiscoveryService/DiscoverResponse
</a:Action>
<ActivityId>
d9eb2fdd-e38a-46ee-bd93-aea9dc86a3b8
</ActivityId>
<a:RelatesTo>urn:uuid: 748132ec-a575-4329-b01b-6171a9cf8478</a:RelatesTo>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<DiscoverResponse
xmlns="http://schemas.microsoft.com/windows/management/2012/01/enrollment">
<DiscoverResult>
<AuthPolicy>OnPremise</AuthPolicy>
<EnrollmentVersion>3.0</EnrollmentVersion>
<EnrollmentPolicyServiceUrl>
https://enrolltest.contoso.com/ENROLLMENTSERVER/DEVICEENROLLMENTWEBSERVICE.SVC
</EnrollmentPolicyServiceUrl>
<EnrollmentServiceUrl>
https://enrolltest.contoso.com/ENROLLMENTSERVER/DEVICEENROLLMENTWEBSERVICE.SVC
</EnrollmentServiceUrl>
</DiscoverResult>
</DiscoverResponse>
</s:Body>
</s:Envelope>
Service web de stratégie d’inscription
Pour la stratégie d’authentification OnPremise, usernameToken dans GetPolicies contient les informations d’identification de l’utilisateur, dont la valeur est basée sur la stratégie d’authentification dans la découverte. L’exemple suivant montre la demande de service web de stratégie et utilise user@contoso.com
comme nom d’utilisateur et mypassword
comme mot de passe.
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"
xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"
xmlns:ac="http://schemas.xmlsoap.org/ws/2006/12/authorization">
<s:Header>
<a:Action s:mustUnderstand="1">
http://schemas.microsoft.com/windows/pki/2009/01/enrollmentpolicy/IPolicy/GetPolicies
</a:Action>
<a:MessageID>urn:uuid:72048B64-0F19-448F-8C2E-B4C661860AA0</a:MessageID>
<a:ReplyTo>
<a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
</a:ReplyTo>
<a:To s:mustUnderstand="1">
https://enrolltest.contoso.com/ENROLLMENTSERVER/DEVICEENROLLMENTWEBSERVICE.SVC
</a:To>
<wsse:Security s:mustUnderstand="1">
<wsse:UsernameToken u:Id="uuid-cc1ccc1f-2fba-4bcf-b063-ffc0cac77917-4">
<wsse:Username>user@contoso.com</wsse:Username>
<wsse:Password wsse:Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">mypassword</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<GetPolicies
xmlns="http://schemas.microsoft.com/windows/pki/2009/01/enrollmentpolicy">
<client>
<lastUpdate xsi:nil="true"/>
<preferredLanguage xsi:nil="true"/>
</client>
<requestFilter xsi:nil="true"/>
</GetPolicies>
</s:Body>
</s:Envelope>
Une fois l’utilisateur authentifié, le service web récupère le modèle de certificat avec lequel l’utilisateur doit s’inscrire et crée des stratégies d’inscription basées sur les propriétés du modèle de certificat. Vous trouverez un exemple de réponse sur MSDN.
MS-XCEP prend en charge les stratégies d’inscription flexibles à l’aide de différents types complexes et attributs qui incluent les stratégies minimalKeyLength, hashAlgorithmOIDReference et CryptoProviders. HashAlgorithmOIDReference a des OID et OIDReferenceID et policySchema associés dans getPolicesResponse. PolicySchema fait référence à la version du modèle de certificat. La version 3 de MS-XCEP prend en charge les algorithmes de hachage.
Remarque
La réponse du serveur HTTP ne doit pas être segmentée ; il doit être envoyé sous la forme d’un seul message.
L’extrait de code suivant montre la réponse du service web de stratégie.
<s:Envelope
xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing">
<s:Header>
<a:Action s:mustUnderstand="1">
http://schemas.microsoft.com/windows/pki/2009/01/enrollmentpolicy/IPolicy/GetPoliciesResponse
</a:Action>
<a:RelatesTo>urn:uuid: 69960163-adad-4a72-82d2-bb0e5cff5598</a:RelatesTo>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<GetPoliciesResponse
xmlns="http://schemas.microsoft.com/windows/pki/2009/01/enrollmentpolicy">
<response>
<policyID />
<policyFriendlyName xsi:nil="true"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
<nextUpdateHours xsi:nil="true"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
<policiesNotChanged xsi:nil="true"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
<policies>
<policy>
<policyOIDReference>0</policyOIDReference>
<cAs xsi:nil="true" />
<attributes>
<commonName>CEPUnitTest</commonName>
<policySchema>3</policySchema>
<certificateValidity>
<validityPeriodSeconds>1209600</validityPeriodSeconds>
<renewalPeriodSeconds>172800</renewalPeriodSeconds>
</certificateValidity>
<permission>
<enroll>true</enroll>
<autoEnroll>false</autoEnroll>
</permission>
<privateKeyAttributes>
<minimalKeyLength>2048</minimalKeyLength>
<keySpec xsi:nil="true" />
<keyUsageProperty xsi:nil="true" />
<permissions xsi:nil="true" />
<algorithmOIDReference xsi:nil="true" />
<cryptoProviders xsi:nil="true" />
</privateKeyAttributes>
<revision>
<majorRevision>101</majorRevision>
<minorRevision>0</minorRevision>
</revision>
<supersededPolicies xsi:nil="true" />
<privateKeyFlags xsi:nil="true" />
<subjectNameFlags xsi:nil="true" />
<enrollmentFlags xsi:nil="true" />
<generalFlags xsi:nil="true" />
<hashAlgorithmOIDReference>0</hashAlgorithmOIDReference>
<rARequirements xsi:nil="true" />
<keyArchivalAttributes xsi:nil="true" />
<extensions xsi:nil="true" />
</attributes>
</policy>
</policies>
</response>
<cAs xsi:nil="true" />
<oIDs>
<oID>
<value>1.3.14.3.2.29</value>
<group>1</group>
<oIDReferenceID>0</oIDReferenceID>
<defaultName>szOID_OIWSEC_sha1RSASign</defaultName>
</oID>
</oIDs>
</GetPoliciesResponse>
</s:Body>
</s:Envelope>
Service web d’inscription
Ce service web implémente le protocole MS-WSTEP. Il traite le message RequestSecurityToken (RST) du client, authentifie le client, demande le certificat à l’autorité de certification et le retourne au client dans le RequestSecurityTokenResponse (RSTR). Outre le certificat émis, la réponse contient également les configurations nécessaires à l’approvisionnement du client DM.
Le RequestSecurityToken (RST) doit avoir les informations d’identification de l’utilisateur et une demande de certificat. Les informations d’identification de l’utilisateur dans une enveloppe SOAP RST sont les mêmes que dans GetPolicies et peuvent varier selon que la stratégie d’authentification est OnPremise ou Federated. BinarySecurityToken dans un corps SOAP RST contient une demande de certificat PKCS#10 codée en Base64, qui est générée par le client en fonction de la stratégie d’inscription. Le client aurait pu demander une stratégie d’inscription à l’aide de MS-XCEP avant de demander un certificat à l’aide de MS-WSTEP. Si la demande de certificat PKCS#10 est acceptée par l’autorité de certification (ca) (la longueur de clé, l’algorithme de hachage, etc., correspond au modèle de certificat), le client peut s’inscrire correctement.
RequestSecurityToken utilise un TokenType personnalisé (http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentToken
), car notre jeton d’inscription est plus qu’un certificat X.509 v3. Pour plus d’informations, consultez la section Réponse.
Le RST peut également spécifier un certain nombre d’éléments AdditionalContext, tels que DeviceType et Version. En fonction de ces valeurs, par exemple, le service web peut retourner une configuration de DM spécifique à l’appareil et à la version.
Remarque
Le service de stratégie et le service d’inscription doivent se trouver sur le même serveur ; autrement dit, ils doivent avoir le même nom d’hôte.
L’exemple suivant montre la demande de service web d’inscription pour l’authentification OnPremise.
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"
xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"
xmlns:ac="http://schemas.xmlsoap.org/ws/2006/12/authorization">
<s:Header>
<a:Action s:mustUnderstand="1">
http://schemas.microsoft.com/windows/pki/2009/01/enrollment/RST/wstep
</a:Action>
<a:MessageID>urn:uuid:0d5a1441-5891-453b-becf-a2e5f6ea3749</a:MessageID>
<a:ReplyTo>
<a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
</a:ReplyTo>
<a:To s:mustUnderstand="1">
https://enrolltest.contoso.com:443/ENROLLMENTSERVER/DEVICEENROLLMENTWEBSERVICE.SVC
</a:To>
<wsse:Security s:mustUnderstand="1">
<wsse:UsernameToken u:Id="uuid-cc1ccc1f-2fba-4bcf-b063-ffc0cac77917-4">
<wsse:Username>user@contoso.com</wsse:Username>
<wsse:Password wsse:Type=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">mypassword
</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
</s:Header>
<s:Body>
<wst:RequestSecurityToken>
<wst:TokenType>
http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentToken
</wst:TokenType>
<wst:RequestType>
http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</wst:RequestType>
<wsse:BinarySecurityToken
ValueType="http://schemas.microsoft.com/windows/pki/2009/01/enrollment#PKCS10"
EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd#base64binary">
DER format PKCS#10 certificate request in Base64 encoding Insterted Here
</wsse:BinarySecurityToken>
<ac:AdditionalContext xmlns="http://schemas.xmlsoap.org/ws/2006/12/authorization">
<ac:ContextItem Name="OSEdition">
<ac:Value> 4</ac:Value>
</ac:ContextItem>
<ac:ContextItem Name="OSVersion">
<ac:Value>10.0.9999.0</ac:Value>
</ac:ContextItem>
<ac:ContextItem Name="DeviceName">
<ac:Value>MY_WINDOWS_DEVICE</ac:Value>
</ac:ContextItem>
<ac:ContextItem Name="MAC">
<ac:Value>FF:FF:FF:FF:FF:FF</ac:Value>
</ac:ContextItem>
<ac:ContextItem Name="MAC">
<ac:Value>CC:CC:CC:CC:CC:CC</ac:Value>
</ac:ContextItem>
<ac:ContextItem Name="IMEI">
<ac:Value>49015420323756</ac:Value>
</ac:ContextItem>
<ac:ContextItem Name="IMEI">
<ac:Value>30215420323756</ac:Value>
</ac:ContextItem>
<ac:ContextItem Name="EnrollmentType">
<ac:Value>Full</ac:Value>
</ac:ContextItem>
<ac:ContextItem Name="DeviceType">
<ac:Value>CIMClient_Windows</ac:Value>
</ac:ContextItem>
<ac:ContextItem Name="ApplicationVersion">
<ac:Value>10.0.9999.0</ac:Value>
</ac:ContextItem>
<ac:ContextItem Name="DeviceID">
<ac:Value>7BA748C8-703E-4DF2-A74A-92984117346A</ac:Value>
</ac:ContextItem>
<ac:ContextItem Name="TargetedUserLoggedIn">
<ac:Value>True</ac:Value>
</ac:ContextItem>
</ac:AdditionalContext>
</wst:RequestSecurityToken>
</s:Body>
</s:Envelope>
L’exemple suivant montre la réponse du service web d’inscription.
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:a="http://www.w3.org/2005/08/addressing"
xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<s:Header>
<a:Action s:mustUnderstand="1" >
http://schemas.microsoft.com/windows/pki/2009/01/enrollment/RSTRC/wstep
</a:Action>
<a:RelatesTo>urn:uuid:81a5419a-496b-474f-a627-5cdd33eed8ab</a:RelatesTo>
<o:Security s:mustUnderstand="1" xmlns:o=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<u:Timestamp u:Id="_0">
<u:Created>2012-08-02T00:32:59.420Z</u:Created>
<u:Expires>2012-08-02T00:37:59.420Z</u:Expires>
</u:Timestamp>
</o:Security>
</s:Header>
<s:Body>
<RequestSecurityTokenResponseCollection
xmlns="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
<RequestSecurityTokenResponse>
<TokenType>
http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentToken
</TokenType>
<DispositionMessage xmlns="http://schemas.microsoft.com/windows/pki/2009/01/enrollment"/>
<RequestedSecurityToken>
<BinarySecurityToken
ValueType=
"http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentProvisionDoc"
EncodingType=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd#base64binary"
xmlns=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
B64EncodedSampleBinarySecurityToken
</BinarySecurityToken>
</RequestedSecurityToken>
<RequestID xmlns="http://schemas.microsoft.com/windows/pki/2009/01/enrollment">0
</RequestID>
</RequestSecurityTokenResponse>
</RequestSecurityTokenResponseCollection>
</s:Body>
</s:Envelope>
L’exemple suivant montre le code XML d’approvisionnement encodé.
<wap-provisioningdoc version="1.1">
<characteristic type="CertificateStore">
<characteristic type="Root">
<characteristic type="System">
<characteristic type="031336C933CC7E228B88880D78824FB2909A0A2F">
<parm name="EncodedCertificate" value="B64 encoded cert insert here" />
</characteristic>
</characteristic>
</characteristic>
</characteristic>
<characteristic type="CertificateStore">
<characteristic type="My" >
<characteristic type="User">
<characteristic type="F9A4F20FC50D990FDD0E3DB9AFCBF401818D5462">
<parm name="EncodedCertificate" value="B64EncodedCertInsertedHere" />
</characteristic>
<characteristic type="PrivateKeyContainer"/>
<!-- This tag must be present for XML syntax correctness. -->
</characteristic>
<characteristic type="WSTEP">
<characteristic type="Renew">
<!--If the datatype for ROBOSupport, RenewPeriod, and RetryInterval tags exist, they must be set explicitly. -->
<parm name="ROBOSupport" value="true" datatype="boolean"/>
<parm name="RenewPeriod" value="60" datatype="integer"/>
<parm name="RetryInterval" value="4" datatype="integer"/>
</characteristic>
</characteristic>
</characteristic>
</characteristic>
<characteristic type="APPLICATION">
<parm name="APPID" value="w7"/>
<parm name="PROVIDER-ID" value="TestMDMServer"/>
<parm name="NAME" value="Microsoft"/>
<parm name="ADDR" value="https://DM.contoso.com:443/omadm/Windows.ashx"/>
<parm name="CONNRETRYFREQ" value="6" />
<parm name="INITIALBACKOFFTIME" value="30000" />
<parm name="MAXBACKOFFTIME" value="120000" />
<parm name="BACKCOMPATRETRYDISABLED" />
<parm name="DEFAULTENCODING" value="application/vnd.syncml.dm+wbxml" />
<parm name="SSLCLIENTCERTSEARCHCRITERIA" value=
"Subject=DC%3dcom%2cDC%3dmicrosoft%2cCN%3dUsers%2cCN%3dAdministrator&amp;Stores=My%5CUser"/>
<characteristic type="APPAUTH">
<parm name="AAUTHLEVEL" value="CLIENT"/>
<parm name="AAUTHTYPE" value="DIGEST"/>
<parm name="AAUTHSECRET" value="password1"/>
<parm name="AAUTHDATA" value="B64encodedBinaryNonceInsertedHere"/>
</characteristic>
<characteristic type="APPAUTH">
<parm name="AAUTHLEVEL" value="APPSRV"/>
<parm name="AAUTHTYPE" value="BASIC"/>
<parm name="AAUTHNAME" value="testclient"/>
<parm name="AAUTHSECRET" value="password2"/>
</characteristic>
</characteristic>
<characteristic type="DMClient"> <!-- In Windows 10, an enrollment server should use DMClient CSP XML to configure DM polling schedules. -->
<characteristic type="Provider">
<!-- ProviderID in DMClient CSP must match to PROVIDER-ID in w7 APPLICATION characteristics -->
<characteristic type="TestMDMServer">
<characteristic type="Poll">
<parm name="NumberOfFirstRetries" value="8" datatype="integer" />
<parm name="IntervalForFirstSetOfRetries" value="15" datatype="integer" />
<parm name="NumberOfSecondRetries" value="5" datatype="integer" />
<parm name="IntervalForSecondSetOfRetries" value="3" datatype="integer" />
<parm name="NumberOfRemainingScheduledRetries" value="0" datatype="integer" />
<!-- Windows 10 supports MDM push for real-time communication. The DM client long term polling schedule's retry waiting interval should be more than 24 hours (1440) to reduce the impact to data consumption and battery life. Refer to the DMClient Configuration Service Provider section for information about polling schedule parameters.-->
<parm name="IntervalForRemainingScheduledRetries" value="1560" datatype="integer" />
<parm name="PollOnLogin" value="true" datatype="boolean" />
</characteristic>
<parm name="EntDeviceName" value="Administrator_Windows" datatype="string" />
</characteristic>
</characteristic>
</characteristic>
<!-- For Windows 10, we removed EnterpriseAppManagement from the enrollment
protocol. This configuration service provider is being deprecated for Windows 10. -->
</wap-provisioningdoc>