Inscription de périphériques de l'authentification fédérée
Cette section fournit un exemple de protocole d’inscription d’appareil mobile utilisant une stratégie d’authentification fédérée. Lorsque la stratégie d’authentification est définie sur Fédérée, le répartiteur d’authentification web est utilisé par le client d’inscription pour obtenir un jeton de sécurité. Le client d’inscription appelle l’API du répartiteur d’authentification web dans le message de réponse pour démarrer le processus. Le serveur doit générer les pages du répartiteur d’authentification web pour s’adapter à l’écran de l’appareil et doit être cohérent avec l’interface utilisateur d’inscription existante. Le jeton de sécurité opaque retourné par le répartiteur en tant que page de fin est utilisé par le client d’inscription comme secret de sécurité de l’appareil pendant l’appel de la demande de certificat client.
L’élément <AuthenticationServiceURL> du message de réponse de découverte spécifie l’URL de démarrage de la page broker d’authentification web.
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 téléphone 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 du 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 comme 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>
<AuthPolicy>Federated</AuthPolicy>
</AuthPolicies>
</request>
</Discover>
</s:Body>
</s:Envelope>
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.
- Dans Windows, Federated est ajouté comme autre valeur prise en charge. Cet ajout permet au serveur d’utiliser le service Broker d’authentification web pour effectuer une authentification utilisateur personnalisée et l’acceptation des conditions d’utilisation.
Remarque
La réponse du serveur HTTP ne doit pas définir Transfer-Encoding sur Segmenté ; il doit être envoyé sous la forme d’un seul message.
Lorsque la stratégie d’authentification est définie sur Fédérée, le service Broker d’authentification web (WAB) est utilisé par le client d’inscription pour obtenir un jeton de sécurité. L’URL de la page de démarrage WAB est fournie par le service de découverte dans le message de réponse. Le client d’inscription appelle l’API WAB dans le message de réponse pour démarrer le processus WAB. Les pages WAB sont des pages web hébergées par le serveur. Le serveur doit générer ces pages pour s’adapter à l’écran de l’appareil et être aussi cohérent que possible avec les autres builds de l’interface utilisateur d’inscription MDM. Le jeton de sécurité opaque retourné par WAB en tant que page de fin est utilisé par le client d’inscription comme secret de sécurité de l’appareil pendant l’appel de demande d’inscription de certificat client.
Remarque
Au lieu de vous appuyer sur la chaîne de l’agent utilisateur transmise lors de l’authentification pour obtenir des informations, telles que la version du système d’exploitation, utilisez les conseils suivants :
- Analysez la version du système d’exploitation à partir des données envoyées pendant la demande de découverte.
- Ajoutez la version du système d’exploitation en tant que paramètre dans AuthenticationServiceURL.
- Analysez la version du système d’exploitation à partir d’AuthenticiationServiceURL lorsque le système d’exploitation envoie la réponse pour l’authentification.
Une nouvelle balise XML, AuthenticationServiceUrl, est introduite dans discoveryResponse XML pour permettre au serveur de spécifier l’URL de démarrage de la page WAB. Pour l’authentification fédérée, cette balise XML doit exister.
Remarque
Le client d’inscription est indépendant des flux de protocole pour l’authentification et le retour du jeton de sécurité. Bien que le serveur puisse demander des informations d’identification utilisateur directement ou entrer dans un protocole de fédération avec un autre serveur et un autre service d’annuaire, le client d’inscription est indépendant de tout cela. Pour rester agnostique, tous les flux de protocole relatifs à l’authentification qui impliquent le client d’inscription sont passifs, c’est-à-dire implémentés par le navigateur.
Voici les exigences explicites pour le serveur.
- L’élément
<DiscoveryResponse>``<AuthenticationServiceUrl>doit prendre en charge HTTPS. - Le serveur d’authentification doit utiliser un certificat racine approuvé par l’appareil. Sinon, l’appel WAP échoue.
- WP ne prend pas en charge l’authentification intégrée Windows (WIA) pour ADFS pendant l’authentification WAB. ADFS 2012 R2 si utilisé doit être configuré pour ne pas essayer WIA pour appareil Windows.
Le client d’inscription émet une requête HTTPS comme suit :
AuthenticationServiceUrl?appru=<appid>&login_hint=<User Principal Name>
-
<appid>est de la formems-app://string -
<User Principal Name>est le nom de l’utilisateur qui s’inscrit, par exemple, user@constoso.com en tant qu’entrée par l’utilisateur dans une page de connexion d’inscription. La valeur de cet attribut sert d’indicateur utilisé par le serveur d’authentification dans le cadre de l’authentification.
Une fois l’authentification terminée, le serveur d’authentification doit retourner un document de formulaire HTML avec une action de méthode POST appid identifiée dans le paramètre de chaîne de requête.
Remarque
Pour rendre une application compatible avec une stratégie de sécurité de contenu stricte, il est généralement nécessaire d’apporter des modifications aux modèles HTML et au code côté client, d’ajouter l’en-tête de stratégie et de vérifier que tout fonctionne correctement une fois la stratégie déployée.
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Vary: Accept-Encoding
Content-Length: 556
<!DOCTYPE>
<html>
<head>
<title>Working...</title>
<script>
function formSubmit() {
document.forms[0].submit();
}
window.onload=formSubmit;
</script>
</head>
<body>
<!-- appid below in post command must be same as appid in previous client https request. -->
<form method="post" action="ms-app://appid">
<p><input type="hidden" name="wresult" value="token value"/></p>
<input type="submit"/>
</form>
</body>
</html>
Le serveur doit envoyer une requête POST à une URL de redirection du formulaire ms-app://string (le schéma d’URL est ms-app) comme indiqué dans l’action de la méthode POST. La valeur du jeton de sécurité est la chaîne http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd\#base64binary codée en base64 contenue dans l’attribut <wsse:BinarySecurityToken> EncodingType. Windows effectue l’encodage binaire lorsqu’il le renvoie au serveur d’inscription, sous forme de code HTML uniquement. Cette chaîne est opaque pour le client d’inscription ; le client n’interprète pas la chaîne.
L’exemple suivant montre une réponse reçue du service web de découverte qui nécessite une authentification via WAB.
<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>Federated</AuthPolicy>
<EnrollmentVersion>3.0</EnrollmentVersion>
<EnrollmentPolicyServiceUrl>
https://enrolltest.contoso.com/ENROLLMENTSERVER/DEVICEENROLLMENTWEBSERVICE.SVC
</EnrollmentPolicyServiceUrl>
<EnrollmentServiceUrl>
https://enrolltest.contoso.com/ENROLLMENTSERVER/DEVICEENROLLMENTWEBSERVICE.SVC
</EnrollmentServiceUrl>
<AuthenticationServiceUrl>
https://portal.manage.contoso.com/LoginRedirect.aspx
</AuthenticationServiceUrl>
</DiscoverResult>
</DiscoverResponse>
</s:Body>
</s:Envelope>
Service web de stratégie d’inscription
Le service de stratégie est facultatif. Par défaut, si aucune stratégie n’est spécifiée, la longueur minimale de la clé est de 2 ko et l’algorithme de hachage est SHA-1.
Ce service web implémente la spécification MS-XCEP (Certificate Enrollment Policy Protocol) X.509 qui permet de personnaliser l’inscription des certificats pour répondre aux différents besoins de sécurité des entreprises à différents moments (agilité de chiffrement). Le service traite le message GetPolicies du client, authentifie le client et retourne les stratégies d’inscription correspondantes dans le message GetPoliciesResponse.
Pour la stratégie d’authentification fédérée, les informations d’identification du jeton de sécurité sont fournies dans un message de demande à l’aide de l’élément <wsse:BinarySecurityToken> [WSS]. Le jeton de sécurité est récupéré comme décrit dans la section réponse de découverte. Les informations d’authentification sont les suivantes :
- wsse :Security : le client d’inscription implémente l’élément
<wsse:Security>défini dans [WSS] section 5. L’élément<wsse:Security>doit être un enfant de l’élément<s:Header>. - wsse :BinarySecurityToken : le client d’inscription implémente l’élément
<wsse:BinarySecurityToken>défini dans [WSS] section 6.3. L’élément<wsse:BinarySecurityToken>doit être inclus en tant qu’enfant de l’élément<wsse:Security>dans l’en-tête SOAP.
Comme décrit dans la section réponse de découverte, l’inclusion de l’élément <wsse:BinarySecurityToken> est opaque pour le client d’inscription, et le client n’interprète pas la chaîne, et l’inclusion de l’élément est approuvée par le serveur d’authentification de jeton de sécurité (comme identifié dans l’élément <AuthenticationServiceUrl> et le serveur d’entreprise <DiscoveryResponse> ).
L’élément <wsse:BinarySecurityToken> contient une chaîne encodée en base64. Le client d’inscription utilise le jeton de sécurité reçu du serveur d’authentification et encode en base64 le jeton pour remplir l’élément <wsse:BinarySecurityToken> .
wsse :BinarySecurityToken/attributes/ValueType : l’attribut
<wsse:BinarySecurityToken>ValueType doit êtrehttp://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentUserToken.wsse :BinarySecurityToken/attributes/EncodingType : l’attribut
<wsse:BinarySecurityToken>EncodingType doit êtrehttp://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd\#base64binary.
L’exemple suivant est une demande de stratégie d’inscription avec un jeton de sécurité reçu comme informations d’identification du client.
<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:BinarySecurityToken ValueType="http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentUserToken" 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
</wsse:BinarySecurityToken>
</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. Pour les appareils Windows, nous allons d’abord prendre en charge 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 définir Transfer-Encoding sur Segmenté ; 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 pour provisionner le DMClient.
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 de nombreux é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 fédérée.
<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:BinarySecurityToken
wsse:ValueType="http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentUserToken"
wsse:EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd#base64binary">
B64EncodedSampleBinarySecurityToken
</wsse:BinarySecurityToken>
</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 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>
Après avoir validé la demande, le service web recherche le modèle de certificat attribué pour le client, le met à jour si nécessaire, envoie les requêtes PKCS#10 à l’autorité de certification, traite la réponse de l’autorité de certification, construit un format XML d’approvisionnement du client OMA et le retourne dans le RSTR (RequestSecurityTokenResponse).
Remarque
La réponse du serveur HTTP ne doit pas définir Transfer-Encoding sur Segmenté ; il doit être envoyé sous la forme d’un seul message.
À l’instar de TokenType dans le RST, le RSTR utilise un ValueType personnalisé dans BinarySecurityToken (http://schemas.microsoft.com/ConfigurationManager/Enrollment/DeviceEnrollmentProvisionDoc), car le jeton est plus qu’un certificat X.509 v3.
Le code XML d’approvisionnement contient :
- Certificats demandés (obligatoires)
- Configuration de DMClient (obligatoire)
Le client installe le certificat client, le certificat racine d’entreprise et le certificat d’autorité de certification intermédiaire, le cas échéant. La configuration de DM inclut le nom et l’adresse du serveur DM, le certificat client à utiliser, et planifie quand DMClient rappelle le serveur.
Le code XML d’approvisionnement de l’inscription doit contenir au maximum un certificat racine et un certificat d’autorité de certification intermédiaire nécessaire pour chaîner le certificat client MDM. D’autres certificats d’autorité de certification racine et intermédiaires peuvent être provisionnés pendant une session OMA DM.
Lorsque les certificats d’autorité de certification racine et intermédiaires sont approvisionnés, le chemin du nœud CSP pris en charge est : CertificateStore/Root/System pour l’approvisionnement de certificats racine, CertificateStore/My/User pour l’approvisionnement de certificats d’autorité de certification intermédiaire.
Voici un exemple de message RSTR et un exemple de code XML d’approvisionnement du client OMA dans RSTR. Pour plus d’informations sur les fournisseurs de services de configuration (CSP) utilisés dans l’approvisionnement xml, consultez la section Paramètres d’entreprise, stratégies et gestion des applications.
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>
Le code suivant montre un exemple de code XML d’approvisionnement (présenté dans le package précédent sous forme de jeton de sécurité) :
<wap-provisioningdoc version="1.1">
<characteristic type="CertificateStore">
<characteristic type="Root">
<characteristic type="System">
<characteristic type="Encoded Root Cert Hash Inserted Here">
<parm name="EncodedCertificate" value="B64 encoded cert insert here" />
</characteristic>
</characteristic>
</characteristic>
</characteristic>
<characteristic type="CertificateStore">
<characteristic type="My" >
<characteristic type="User">
<characteristic type="Encoded Root Cert Hash Inserted Here">
<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">
<parm name="UPN" value="UserPrincipalName@contoso.com" datatype="string" />
<parm name="EntDeviceName" value="Administrator_Windows" datatype="string" />
<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>
</characteristic>
</characteristic>
</characteristic>
<!-- For Windows 10, we removed EnterpriseAppManagement from the enrollment protocol. -->
</wap-provisioningdoc>
Remarque
<Parm name>les éléments et<characteristic type=>dans le xml csp w7 APPLICATION respectent la casse et doivent être tous en majuscules.Dans la caractéristique w7 APPLICATION, les informations d’identification CLIENT et APPSRV doivent être fournies au format XML.
Des descriptions détaillées de ces paramètres se trouvent dans la section Paramètres d’entreprise, stratégies et gestion des applications de ce document.
La caractéristique PrivateKeyContainer est obligatoire et doit être présente dans le code XML d’approvisionnement de l’inscription par l’inscription. Les autres paramètres importants sont les éléments de paramètre PROVIDER-ID, NAME et ADDR , qui doivent contenir l’ID et le NOM uniques de votre fournisseur DM et l’adresse où l’appareil peut se connecter pour l’approvisionnement de la configuration. L’ID et le NOM peuvent être des valeurs arbitraires, mais elles doivent être uniques.
SSLCLIENTCERTSEARCHCRITERIA est également important, qui est utilisé pour sélectionner le certificat à utiliser pour l’authentification du client. La recherche est basée sur l’attribut subject du certificat utilisateur signé.
CertificateStore/WSTEP active le renouvellement des certificats. Si le serveur ne le prend pas en charge, ne le définissez pas.
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour