Registrazione dei dispositivi con l'autenticazione federata

Questa sezione fornisce un esempio del protocollo di registrazione dei dispositivi mobili che usa i criteri di autenticazione federata. Quando i criteri di autenticazione sono impostati su Federated, il gestore di autenticazione Web viene usato dal client di registrazione per ottenere un token di sicurezza. Il client di registrazione chiama l'API web authentication broker all'interno del messaggio di risposta per avviare il processo. Il server deve compilare le pagine del gestore di autenticazione Web per adattarle alla schermata del dispositivo e deve essere coerente con l'interfaccia utente di registrazione esistente. Il token di sicurezza opaco restituito dal broker come pagina finale viene usato dal client di registrazione come segreto di sicurezza del dispositivo durante la chiamata alla richiesta di certificato client.

Elemento <AuthenticationServiceURL> che il messaggio di risposta di individuazione specifica l'URL iniziale della pagina del gestore di autenticazione Web.

Per informazioni dettagliate sul protocollo di registrazione dei dispositivi mobili Microsoft per Windows, vedere [MS-MDE2]: Mobile Device Enrollment Protocol versione 2.

Servizio di individuazione

Il servizio Web di individuazione fornisce le informazioni di configurazione necessarie per consentire a un utente di registrare un telefono con un servizio di gestione. Il servizio è un servizio Web inattivi su HTTPS (solo autenticazione server).

Il flusso di individuazione automatica del dispositivo usa il nome di dominio dell'indirizzo di posta elettronica inviato alla schermata Impostazioni area di lavoro durante l'accesso. Il sistema di individuazione automatica crea un URI che usa questo nome host aggiungendo il sottodominio enterpriseenrollment al dominio dell'indirizzo di posta elettronica e aggiungendo il percorso /EnrollmentServer/Discovery.svc. Ad esempio, se l'indirizzo di posta elettronica è sample@contoso.com, l'URI risultante per la prima richiesta Get sarà: http://enterpriseenrollment.contoso.com/EnrollmentServer/Discovery.svc.

La prima richiesta è una richiesta HTTP GET standard.

Nell'esempio seguente viene illustrata una richiesta tramite HTTP GET al server di individuazione specificata user@contoso.com come indirizzo di posta elettronica.

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

Dopo che il dispositivo ottiene una risposta dal server, il dispositivo invia una richiesta POST a enterpriseenrollment.<domain_name>/EnrollmentServer/Discovery.svc. Dopo aver ricevuto un'altra risposta dal server (che dovrebbe indicare al dispositivo dove si trova il server di registrazione), il messaggio successivo inviato dal dispositivo è al enterpriseenrollment.<domain_name> server di registrazione.

Viene applicata la logica seguente:

1. Il dispositivo prova prima HTTPS. Se il dispositivo non considera attendibile il certificato del server, il tentativo HTTPS ha esito negativo.
2. In caso di esito negativo, il dispositivo prova a eseguire un tentativo http per verificare se è stato reindirizzato:
   • Se il dispositivo non viene reindirizzato, all'utente viene richiesto l'indirizzo del server.
   • Se il dispositivo viene reindirizzato, all'utente viene richiesto di consentire il reindirizzamento.

Nell'esempio seguente viene illustrata una richiesta tramite un comando HTTP POST al servizio Web di individuazione specificato user@contoso.com come indirizzo di posta elettronica

https://EnterpriseEnrollment.Contoso.com/EnrollmentServer/Discovery.svc

Nell'esempio seguente viene illustrata la richiesta del servizio di individuazione.

<?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 risposta di individuazione è nel formato XML e include i campi seguenti:

• URL del servizio di registrazione (EnrollmentServiceUrl): specifica l'URL dell'endpoint di registrazione esposto dal servizio di gestione. Il dispositivo deve chiamare questo URL dopo l'autenticazione dell'utente. Questo campo è obbligatorio.
• Criteri di autenticazione (AuthPolicy): indica il tipo di autenticazione necessario. Per il server MDM, OnPremise è il valore supportato, il che significa che l'utente viene autenticato quando chiama l'URL del servizio di gestione. Questo campo è obbligatorio.
• In Windows federato viene aggiunto come altro valore supportato. Questa aggiunta consente al server di usare Web Authentication Broker per eseguire l'autenticazione utente personalizzata e il termine di accettazione dell'utilizzo.

Quando il criterio di autenticazione è impostato su Federated, Web Authentication Broker (WAB) viene usato dal client di registrazione per ottenere un token di sicurezza. L'URL della pagina iniziale wab viene fornito dal servizio di individuazione nel messaggio di risposta. Il client di registrazione chiama l'API WAB all'interno del messaggio di risposta per avviare il processo WAB. Le pagine WAB sono pagine Web ospitate dal server. Il server deve compilare tali pagine in modo che si adattino correttamente allo schermo del dispositivo e siano il più coerenti possibile con altre compilazioni nell'interfaccia utente di registrazione MDM. Il token di sicurezza opaco restituito da WAB come pagina finale viene usato dal client di registrazione come segreto di sicurezza del dispositivo durante la chiamata alla richiesta di registrazione del certificato client.

Un nuovo tag XML, AuthenticationServiceUrl, è stato introdotto in DiscoveryResponse XML per consentire al server di specificare l'URL iniziale della pagina WAB. Per l'autenticazione federata, questo tag XML deve esistere.

Di seguito sono riportati i requisiti espliciti per il server.

• L'elemento <DiscoveryResponse>``<AuthenticationServiceUrl> deve supportare HTTPS.
• Il server di autenticazione deve usare un certificato radice attendibile del dispositivo. In caso contrario, la chiamata WAP ha esito negativo.
• WP non supporta l'autenticazione integrata di Windows (WIA) per ADFS durante l'autenticazione WAB. ADFS 2012 R2 se usato deve essere configurato per non tentare WIA per il dispositivo Windows.

Il client di registrazione invia una richiesta HTTPS come indicato di seguito:

AuthenticationServiceUrl?appru=<appid>&amp;login_hint=<User Principal Name>

• <appid> è del formato ms-app://string
• <User Principal Name> è il nome dell'utente che esegue la registrazione, ad esempio come user@constoso.com input da parte dell'utente in una pagina di accesso alla registrazione. Il valore di questo attributo funge da hint usato dal server di autenticazione come parte dell'autenticazione.

Al termine dell'autenticazione, il server di autenticazione deve restituire un documento modulo HTML con un'azione del metodo POST di appid identificata nel parametro della stringa di query.

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>

Il server deve inviare un POST a un URL di reindirizzamento del modulo ms-app://string (lo schema URL è ms-app) come indicato nell'azione del metodo POST. Il valore del token di sicurezza è la stringa http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd\#base64binary con codifica base64 contenuta nell'attributo <wsse:BinarySecurityToken> EncodingType. Windows esegue la codifica binaria quando la invia di nuovo al server di registrazione, nel formato è solo codifica HTML. Questa stringa è opaca per il client di registrazione; il client non interpreta la stringa.

Nell'esempio seguente viene illustrata una risposta ricevuta dal servizio Web di individuazione che richiede l'autenticazione tramite 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>

Servizio Web dei criteri di registrazione

Il servizio criteri è facoltativo. Per impostazione predefinita, se non vengono specificati criteri, la lunghezza minima della chiave è 2k e l'algoritmo hash è SHA-1.

Questo servizio Web implementa la specifica X.509 Certificate Enrollment Policy Protocol (MS-XCEP) che consente di personalizzare la registrazione dei certificati in modo che corrisponda alle diverse esigenze di sicurezza delle aziende in momenti diversi (agilità crittografica). Il servizio elabora il messaggio GetPolicies dal client, autentica il client e restituisce criteri di registrazione corrispondenti nel messaggio GetPoliciesResponse.

Per i criteri di autenticazione federata, le credenziali del token di sicurezza vengono fornite in un messaggio di richiesta usando l'elemento <wsse:BinarySecurityToken> [WSS]. Il token di sicurezza viene recuperato come descritto nella sezione relativa alla risposta di individuazione. Le informazioni di autenticazione sono le seguenti:

• wsse:Security: il client di registrazione implementa l'elemento <wsse:Security> definito nella sezione 5 di [WSS]. L'elemento <wsse:Security> deve essere un elemento figlio dell'elemento <s:Header> .
• wsse:BinarySecurityToken: il client di registrazione implementa l'elemento <wsse:BinarySecurityToken> definito nella sezione [WSS] 6.3. L'elemento <wsse:BinarySecurityToken> deve essere incluso come elemento figlio dell'elemento <wsse:Security> nell'intestazione SOAP.

Come descritto nella sezione relativa alla risposta di individuazione, l'inclusione dell'elemento <wsse:BinarySecurityToken> è opaca per il client di registrazione e il client non interpreta la stringa e l'inclusione dell'elemento viene concordata dal server di autenticazione del token di sicurezza ,come identificato nell'elemento <AuthenticationServiceUrl> di <DiscoveryResponse> e nel server aziendale.

L'elemento <wsse:BinarySecurityToken> contiene una stringa con codifica base64. Il client di registrazione usa il token di sicurezza ricevuto dal server di autenticazione e codifica il token in base 64 per popolare l'elemento <wsse:BinarySecurityToken> .

• wsse:BinarySecurityToken/attributes/ValueType: l'attributo <wsse:BinarySecurityToken> ValueType deve essere http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentUserToken.

• wsse:BinarySecurityToken/attributes/EncodingType: l'attributo <wsse:BinarySecurityToken> EncodingType deve essere http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd\#base64binary.

L'esempio seguente è una richiesta di criteri di registrazione con un token di sicurezza ricevuto come credenziali 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>

Dopo l'autenticazione dell'utente, il servizio Web recupera il modello di certificato con cui l'utente deve eseguire la registrazione e crea i criteri di registrazione in base alle proprietà del modello di certificato. Un esempio della risposta è disponibile in MSDN.

MS-XCEP supporta criteri di registrazione flessibili usando vari tipi e attributi complessi. Per i dispositivi Windows, supporteremo prima di tutto i criteri minimalKeyLength, hashAlgorithmOIDReference e CryptoProviders. HashAlgorithmOIDReference include OID e OIDReferenceID e policySchema correlati in GetPolicesResponse. PolicySchema fa riferimento alla versione del modello di certificato. La versione 3 di MS-XCEP supporta gli algoritmi hash.

Il frammento di codice seguente mostra la risposta del servizio Web dei criteri.

<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>

Servizio Web di registrazione

Questo servizio Web implementa il protocollo MS-WSTEP. Elabora il messaggio RequestSecurityToken (RST) dal client, autentica il client, richiede il certificato dalla CA e lo restituisce in RequestSecurityTokenResponse (RSTR) al client. Oltre al certificato emesso, la risposta contiene anche le configurazioni necessarie per effettuare il provisioning di DMClient.

RequestSecurityToken (RST) deve avere le credenziali utente e una richiesta di certificato. Le credenziali utente in una busta SOAP RST sono le stesse di GetPolicies e possono variare a seconda che il criterio di autenticazione sia OnPremise o Federated. BinarySecurityToken in un corpo SOAP RST contiene una richiesta di certificato PKCS#10 con codifica Base64, generata dal client in base ai criteri di registrazione. Il client potrebbe aver richiesto un criterio di registrazione usando MS-XCEP prima di richiedere un certificato tramite MS-WSTEP. Se la richiesta di certificato PKCS#10 viene accettata dall'autorità di certificazione (CA) (la lunghezza della chiave, l'algoritmo hash e così via, corrisponde al modello di certificato), il client può eseguire correttamente la registrazione.

RequestSecurityToken usa un TokenType personalizzato (http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentToken), perché il token di registrazione è più di un certificato X.509 v3. Per altre informazioni, vedere la sezione Risposta.

RST può anche specificare molti elementi AdditionalContext, ad esempio DeviceType e Version. In base a questi valori, ad esempio, il servizio Web può restituire la configurazione di Gestione dei database specifica del dispositivo e della versione.

Nell'esempio seguente viene illustrata la richiesta del servizio Web di registrazione per l'autenticazione federata.

<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>

Dopo aver convalidato la richiesta, il servizio Web cerca il modello di certificato assegnato per il client, lo aggiorna se necessario, invia le richieste PKCS#10 alla CA, elabora la risposta dalla CA, costruisce un formato XML di provisioning client OMA e lo restituisce in RequestSecurityTokenResponse (RSTR).

Analogamente a TokenType in RST, RSTR usa un ValueType personalizzato in BinarySecurityToken (http://schemas.microsoft.com/ConfigurationManager/Enrollment/DeviceEnrollmentProvisionDoc), perché il token è più di un certificato X.509 v3.

Il codice XML di provisioning contiene:

• Certificati richiesti (obbligatorio)
• Configurazione DMClient (obbligatoria)

Il client installa il certificato client, il certificato radice dell'organizzazione e il certificato CA intermedio, se presente. La configurazione di Dm include il nome e l'indirizzo del server dm, il certificato client da usare e pianifica quando dmClient richiama il server.

Il codice XML di provisioning della registrazione deve contenere un massimo di un certificato radice e un certificato CA intermedio necessario per concatenare il certificato client MDM. È possibile effettuare il provisioning di più certificati ca radice e intermedi durante una sessione di Gestione migrazione OMA.

Quando viene eseguito il provisioning dei certificati CA radice e intermedia, il percorso del nodo CSP supportato è: CertificateStore/Root/System per il provisioning dei certificati radice, CertificateStore/My/User per il provisioning intermedio dei certificati CA.

Ecco un messaggio RSTR di esempio e un esempio di codice XML di provisioning client OMA all'interno di RSTR. Per altre informazioni sui provider di servizi di configurazione usati nel provisioning XML, vedere la sezione Impostazioni aziendali, criteri e gestione delle app.

L'esempio seguente mostra la risposta del servizio Web di registrazione.

<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>

Il codice seguente mostra il codice XML di provisioning di esempio (presentato nel pacchetto precedente come token di sicurezza):

<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;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>