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.
Nota
Per l'elenco degli scenari di registrazione non supportati in Windows, vedere Scenari di registrazione non supportati.
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).
Nota
L'amministratore del servizio di individuazione deve creare un host con l'indirizzo enterpriseenrollment.<domain_name>.com.
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:
- Il dispositivo prova prima HTTPS. Se il dispositivo non considera attendibile il certificato del server, il tentativo HTTPS ha esito negativo.
- 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.
Nota
La risposta del server HTTP non deve impostare Transfer-Encoding su Chunked; deve essere inviato come un unico messaggio.
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.
Nota
Invece di basarsi sulla stringa dell'agente utente passata durante l'autenticazione per ottenere informazioni, ad esempio la versione del sistema operativo, usare le indicazioni seguenti:
- Analizzare la versione del sistema operativo dai dati inviati durante la richiesta di individuazione.
- Aggiungere la versione del sistema operativo come parametro in AuthenticationServiceURL.
- Analizzare la versione del sistema operativo da AuthenticiationServiceURL quando il sistema operativo invia la risposta per l'autenticazione.
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.
Nota
Il client di registrazione è indipendente per quanto riguarda i flussi di protocollo per l'autenticazione e la restituzione del token di sicurezza. Anche se il server potrebbe richiedere direttamente le credenziali utente o immettere un protocollo federativo con un altro server e un servizio directory, il client di registrazione non è indipendente da tutto questo. Per rimanere indipendenti, tutti i flussi di protocollo relativi all'autenticazione che coinvolgono il client di registrazione sono passivi, ovvero implementati tramite browser.
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>&login_hint=<User Principal Name>
<appid>è del formatoms-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.
Nota
Per rendere un'applicazione compatibile con criteri di sicurezza del contenuto rigorosi, in genere è necessario apportare alcune modifiche ai modelli HTML e al codice lato client, aggiungere l'intestazione del criterio e verificare che tutto funzioni correttamente dopo la distribuzione dei criteri.
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 appena codificato 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 esserehttp://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentUserToken.wsse:BinarySecurityToken/attributes/EncodingType: l'attributo
<wsse:BinarySecurityToken>EncodingType deve esserehttp://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.
Nota
La risposta del server HTTP non deve impostare Transfer-Encoding su Chunked; deve essere inviato come un unico messaggio.
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 del client dm.
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.
Nota
Il servizio criteri e il servizio di registrazione devono trovarsi nello stesso server; ovvero devono avere lo stesso nome host.
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).
Nota
La risposta del server HTTP non deve impostare Transfer-Encoding su Chunked; deve essere inviato come un unico messaggio.
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 del client dm (obbligatorio)
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 il client dm 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;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>
Nota
<Parm name>Gli elementi e<characteristic type=>nel codice XML CSP application w7 fanno distinzione tra maiuscole e minuscole e devono essere tutti maiuscoli.Nella caratteristica w7 APPLICATION, le credenziali CLIENT e APPSRV devono essere fornite in XML.
Le descrizioni dettagliate di queste impostazioni si trovano nella sezione Impostazioni aziendali, criteri e gestione delle app di questo documento.
La caratteristica PrivateKeyContainer è obbligatoria e deve essere presente nel codice XML di provisioning della registrazione dalla registrazione. Altre impostazioni importanti sono gli elementi del parametro PROVIDER-ID, NAME e ADDR , che devono contenere l'ID univoco e il NOME del provider dm e l'indirizzo in cui il dispositivo può connettersi per il provisioning della configurazione. ID e NAME possono essere valori arbitrari, ma devono essere univoci.
Importante è anche SSLCLIENTCERTSEARCHCRITERIA, usato per selezionare il certificato da usare per l'autenticazione client. La ricerca si basa sull'attributo subject del certificato utente firmato.
CertificateStore/WSTEP abilita il rinnovo del certificato. Se il server non lo supporta, non impostarlo.
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per