Registrierung von Geräten mit Verbundauthentifizierung
Dieser Abschnitt enthält ein Beispiel für das Registrierungsprotokoll für mobile Geräte mithilfe einer Verbundauthentifizierungsrichtlinie. Wenn die Authentifizierungsrichtlinie auf Verbund festgelegt ist, wird der Webauthentifizierungsbroker vom Registrierungsclient verwendet, um ein Sicherheitstoken abzurufen. Der Registrierungsclient ruft die Webauthentifizierungsbroker-API innerhalb der Antwortnachricht auf, um den Prozess zu starten. Der Server sollte die Webauthentifizierungsbrokerseiten so erstellen, dass sie dem Gerätebildschirm entsprechen und mit der vorhandenen Registrierungsoberfläche konsistent sein. Das undurchsichtige Sicherheitstoken, das vom Broker als Endseite zurückgegeben wird, wird vom Registrierungsclient während des Clientzertifikatanforderungsaufrufs als geheimes Gerätesicherheitsgeheimnis verwendet.
Das <AuthenticationServiceURL> Element der Ermittlungsantwortmeldung gibt die Start-URL der Webauthentifizierungsbrokerseite an.
Ausführliche Informationen zum Microsoft-Registrierungsprotokoll für mobile Geräte für Windows finden Sie unter [MS-MDE2]: Mobile Device Enrollment Protocol Version 2.
Hinweis
Eine Liste der Registrierungsszenarien, die in Windows nicht unterstützt werden, finden Sie unter Nicht unterstützte Registrierungsszenarien.
Ermittlungsdienst
Der Ermittlungswebdienst stellt die Konfigurationsinformationen bereit, die für einen Benutzer erforderlich sind, um ein Telefon bei einem Verwaltungsdienst zu registrieren. Der Dienst ist ein ruhender Webdienst über HTTPS (nur Serverauthentifizierung).
Hinweis
Der Administrator des Ermittlungsdiensts muss einen Host mit der Adresse enterpriseenrollment.<domain_name>.comerstellen.
Der automatische Ermittlungsablauf des Geräts verwendet den Domänennamen der E-Mail-Adresse, die während der Anmeldung an den Bildschirm "Arbeitsplatzeinstellungen" übermittelt wurde. Das System für die automatische Ermittlung erstellt einen URI, der diesen Hostnamen verwendet, indem die Unterdomäne enterpriseenrollment an die Domäne der E-Mail-Adresse angefügt und der Pfad /EnrollmentServer/Discovery.svcangefügt wird. Wenn die E-Mail-Adresse beispielsweise lautet sample@contoso.com, lautet der resultierende URI für die erste Get-Anforderung: http://enterpriseenrollment.contoso.com/EnrollmentServer/Discovery.svc.
Die erste Anforderung ist eine HTTP GET-Standardanforderung.
Das folgende Beispiel zeigt eine Anforderung über HTTP GET an den Ermittlungsserver, der als E-Mail-Adresse angegeben ist user@contoso.com .
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
Nachdem das Gerät eine Antwort vom Server erhalten hat, sendet das Gerät eine POST-Anforderung an enterpriseenrollment.<domain_name>/EnrollmentServer/Discovery.svc. Nachdem es eine weitere Antwort vom Server erhalten hat (der dem Gerät mitteilen sollte, wo sich der Registrierungsserver befindet), wird die nächste Nachricht vom Gerät an enterpriseenrollment.<domain_name> den Registrierungsserver gesendet.
Die folgende Logik wird angewendet:
- Das Gerät versucht zunächst HTTPS. Wenn das Gerät dem Serverzertifikat nicht vertraut, schlägt der HTTPS-Versuch fehl.
- Wenn dies fehlschlägt, versucht das Gerät HTTP, um festzustellen, ob es umgeleitet wird:
- Wenn das Gerät nicht umgeleitet wird, wird der Benutzer zur Eingabe der Serveradresse aufgefordert.
- Wenn das Gerät umgeleitet wird, wird der Benutzer aufgefordert, die Umleitung zuzulassen.
Das folgende Beispiel zeigt eine Anforderung über einen HTTP POST-Befehl an den Ermittlungswebdienst, der als E-Mail-Adresse angegeben ist user@contoso.com .
https://EnterpriseEnrollment.Contoso.com/EnrollmentServer/Discovery.svc
Das folgende Beispiel zeigt die Ermittlungsdienstanforderung.
<?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>
Die Ermittlungsantwort weist das XML-Format auf und enthält die folgenden Felder:
- Registrierungsdienst-URL (EnrollmentServiceUrl): Gibt die URL des Registrierungsendpunkts an, der vom Verwaltungsdienst verfügbar gemacht wird. Das Gerät sollte diese URL aufrufen, nachdem der Benutzer authentifiziert wurde. Dieses Feld ist obligatorisch.
- Authentifizierungsrichtlinie (AuthPolicy): Gibt an, welcher Authentifizierungstyp erforderlich ist. Für den MDM-Server ist OnPremise der unterstützte Wert. Dies bedeutet, dass der Benutzer beim Aufrufen der Verwaltungsdienst-URL authentifiziert wird. Dieses Feld ist obligatorisch.
- In Windows wird Verbund als weiterer unterstützter Wert hinzugefügt. Diese Ergänzung ermöglicht es dem Server, den Webauthentifizierungsbroker zu verwenden, um eine angepasste Benutzerauthentifizierung und die Akzeptanz der Nutzungsdauer durchzuführen.
Hinweis
Die HTTP-Serverantwort darf Transfer-Encoding nicht auf Segmentiert festlegen. Es muss als eine Nachricht gesendet werden.
Wenn die Authentifizierungsrichtlinie als Verbund festgelegt ist, wird der Webauthentifizierungsbroker (WAB) vom Registrierungsclient verwendet, um ein Sicherheitstoken abzurufen. Die WAB-Startseiten-URL wird vom Ermittlungsdienst in der Antwortnachricht bereitgestellt. Der Registrierungsclient ruft die WAB-API in der Antwortnachricht auf, um den WAB-Prozess zu starten. WAB-Seiten sind vom Server gehostete Webseiten. Der Server sollte diese Seiten so erstellen, dass sie gut auf den Gerätebildschirm passen und so konsistent wie möglich mit anderen Builds in der MDM-Registrierungsoberfläche sind. Das undurchsichtige Sicherheitstoken, das von WAB als Endpage zurückgegeben wird, wird vom Registrierungsclient während des Aufrufs der Clientzertifikatregistrierungsanforderung als geheimes Gerätesicherheitsgeheimnis verwendet.
Hinweis
Verwenden Sie die folgende Anleitung, anstatt sich auf die Benutzer-Agent-Zeichenfolge zu verlassen, die während der Authentifizierung übergeben wird, um Informationen wie die Betriebssystemversion abzurufen:
- Analysieren Sie die Betriebssystemversion anhand der Daten, die während der Ermittlungsanforderung gesendet wurden.
- Fügen Sie die Betriebssystemversion als Parameter in authenticationServiceURL an.
- Analysieren Sie die Betriebssystemversion aus authenticiationServiceURL, wenn das Betriebssystem die Antwort für die Authentifizierung sendet.
Das neue XML-Tag AuthenticationServiceUrl wird in discoveryResponse XML eingeführt, damit der Server die Start-URL der WAB-Seite angeben kann. Für die Verbundauthentifizierung muss dieses XML-Tag vorhanden sein.
Hinweis
Der Registrierungsclient ist in Bezug auf die Protokollflows für die Authentifizierung und Rückgabe des Sicherheitstokens agnostisch. Während der Server möglicherweise direkt zur Eingabe von Benutzeranmeldeinformationen auffordert oder ein Verbundprotokoll mit einem anderen Server und Verzeichnisdienst eingibt, ist der Registrierungsclient für all dies agnostisch. Um agnostisch zu bleiben, sind alle Protokollabläufe, die sich auf die Authentifizierung beziehen, die den Registrierungsclient einbeziehen, passiv, d. h. browserimplementiert.
Im Folgenden sind die expliziten Anforderungen für den Server aufgeführt.
- Das
<DiscoveryResponse>``<AuthenticationServiceUrl>-Element muss HTTPS unterstützen. - Der Authentifizierungsserver muss ein vertrauenswürdiges Stammzertifikat des Geräts verwenden. Andernfalls schlägt der WAP-Aufruf fehl.
- WP unterstützt die integrierte Windows-Authentifizierung (Windows Integrated Authentication, WIA) für AD FS während der WAB-Authentifizierung nicht. ADFS 2012 R2 muss bei Verwendung so konfiguriert werden, dass keine WIA für Windows-Geräte versucht wird.
Der Registrierungsclient gibt eine HTTPS-Anforderung wie folgt aus:
AuthenticationServiceUrl?appru=<appid>&login_hint=<User Principal Name>
<appid>ist von der Formms-app://string<User Principal Name>ist der Name des registrierenden Benutzers, user@constoso.com z. B. als Eingabe des Benutzers auf einer Registrierungsanmeldungsseite. Der Wert dieses Attributs dient als Hinweis, der vom Authentifizierungsserver als Teil der Authentifizierung verwendet wird.
Nach Abschluss der Authentifizierung sollte der Authentifizierungsserver ein HTML-Formulardokument mit der POST-Methodenaktion appid zurückgeben, die im Abfragezeichenfolgenparameter identifiziert wird.
Hinweis
Um eine Anwendung mit der strengen Inhaltssicherheitsrichtlinie kompatibel zu machen, ist es in der Regel erforderlich, einige Änderungen an HTML-Vorlagen und clientseitigem Code vorzunehmen, den Richtlinienheader hinzuzufügen und zu testen, ob alles ordnungsgemäß funktioniert, nachdem die Richtlinie bereitgestellt wurde.
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>
Der Server muss einen POST an eine Umleitungs-URL des Formulars ms-app://string (das URL-Schema ist ms-app) senden, wie in der POST-Methodenaktion angegeben. Der Wert des Sicherheitstokens ist die base64-codierte Zeichenfolge http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd\#base64binary , die <wsse:BinarySecurityToken> im EncodingType-Attribut enthalten ist. Windows führt die binäre Codierung durch, wenn es sie zurück an den Registrierungsserver sendet, in der Form, dass es nur HTML-codiert ist. Diese Zeichenfolge ist für den Registrierungsclient nicht transparent. der Client interpretiert die Zeichenfolge nicht.
Das folgende Beispiel zeigt eine Antwort, die vom Ermittlungswebdienst empfangen wurde, der eine Authentifizierung über WAB erfordert.
<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>
Registrierungsrichtlinienwebdienst
Der Richtliniendienst ist optional. Wenn keine Richtlinien angegeben sind, beträgt die minimale Schlüssellänge standardmäßig 2.000, und der Hashalgorithmus ist SHA-1.
Dieser Webdienst implementiert die MS-XCEP-Spezifikation (X.509 Certificate Enrollment Policy Protocol), die es ermöglicht, die Zertifikatregistrierung an die verschiedenen Sicherheitsanforderungen von Unternehmen zu unterschiedlichen Zeiten anzupassen (kryptografische Agilität). Der Dienst verarbeitet die GetPolicies-Nachricht vom Client, authentifiziert den Client und gibt übereinstimmende Registrierungsrichtlinien in der GetPoliciesResponse-Nachricht zurück.
Für die Verbundauthentifizierungsrichtlinie werden die Anmeldeinformationen des Sicherheitstokens mithilfe des <wsse:BinarySecurityToken> Elements [WSS] in einer Anforderungsnachricht bereitgestellt. Das Sicherheitstoken wird wie im Abschnitt zur Ermittlungsantwort beschrieben abgerufen. Die Authentifizierungsinformationen sind wie folgt:
- wsse:Security: Der Registrierungsclient implementiert das
<wsse:Security>in [WSS] Abschnitt 5 definierte Element. Das<wsse:Security>-Element muss ein untergeordnetes Element des<s:Header>-Elements sein. - wsse:BinarySecurityToken: Der Registrierungsclient implementiert das
<wsse:BinarySecurityToken>in [WSS] Abschnitt 6.3 definierte Element. Das<wsse:BinarySecurityToken>Element muss als untergeordnetes Element des<wsse:Security>Elements im SOAP-Header enthalten sein.
Wie im Abschnitt zur Ermittlungsantwort beschrieben, ist die Einbeziehung des <wsse:BinarySecurityToken> Elements für den Registrierungsclient nicht transparent, und der Client interpretiert die Zeichenfolge nicht, und die Einbeziehung des Elements wird vom Sicherheitstokenauthentifizierungsserver vereinbart (wie im <AuthenticationServiceUrl> -Element <DiscoveryResponse> und auf dem Unternehmensserver angegeben).
Das <wsse:BinarySecurityToken> -Element enthält eine base64-codierte Zeichenfolge. Der Registrierungsclient verwendet das vom Authentifizierungsserver empfangene Sicherheitstoken und codiert das Token base64, um das <wsse:BinarySecurityToken> Element aufzufüllen.
wsse:BinarySecurityToken/attributes/ValueType: Das
<wsse:BinarySecurityToken>ValueType-Attribut muss seinhttp://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentUserToken.wsse:BinarySecurityToken/attributes/EncodingType: Das
<wsse:BinarySecurityToken>EncodingType-Attribut muss seinhttp://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd\#base64binary.
Das folgende Beispiel ist eine Registrierungsrichtlinienanforderung mit einem empfangenen Sicherheitstoken als Clientanmeldeinformationen.
<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>
Nachdem der Benutzer authentifiziert wurde, ruft der Webdienst die Zertifikatvorlage ab, bei der der Benutzer registriert werden soll, und erstellt Registrierungsrichtlinien basierend auf den Zertifikatvorlageneigenschaften. Ein Beispiel für die Antwort finden Sie auf MSDN.
MS-XCEP unterstützt flexible Registrierungsrichtlinien mit verschiedenen komplexen Typen und Attributen. Für Windows-Geräte unterstützen wir zunächst minimalKeyLength, hashAlgorithmOIDReference-Richtlinien und CryptoProviders. HashAlgorithmOIDReference verfügt über verwandte OID und OIDReferenceID und policySchema in GetPolicesResponse. PolicySchema bezieht sich auf die Zertifikatvorlagenversion. Version 3 von MS-XCEP unterstützt Hashalgorithmen.
Hinweis
Die HTTP-Serverantwort darf Transfer-Encoding nicht auf Segmentiert festlegen. Es muss als eine Nachricht gesendet werden.
Der folgende Codeausschnitt zeigt die Antwort des Richtlinienwebdiensts.
<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>
Registrierungswebdienst
Dieser Webdienst implementiert das MS-WSTEP-Protokoll. Es verarbeitet die RequestSecurityToken (RST)-Nachricht vom Client, authentifiziert den Client, fordert das Zertifikat von der Zertifizierungsstelle an und gibt es im RequestSecurityTokenResponse (RSTR) an den Client zurück. Neben dem ausgestellten Zertifikat enthält die Antwort auch Konfigurationen, die zum Bereitstellen des DM-Clients erforderlich sind.
Das RequestSecurityToken (RST) muss über die Benutzeranmeldeinformationen und eine Zertifikatanforderung verfügen. Die Benutzeranmeldeinformationen in einem RST-SOAP-Umschlag sind identisch mit den Anmeldeinformationen in GetPolicies und können variieren, je nachdem, ob die Authentifizierungsrichtlinie OnPremise oder Verbund ist. Das BinarySecurityToken in einem RST-SOAP-Text enthält eine Base64-codierte PKCS#10-Zertifikatanforderung, die vom Client basierend auf der Registrierungsrichtlinie generiert wird. Der Client hätte eine Registrierungsrichtlinie mithilfe von MS-XCEP anfordern können, bevor er ein Zertifikat mit MS-WSTEP anfordert. Wenn die PKCS#10-Zertifikatanforderung von der Zertifizierungsstelle akzeptiert wird (Schlüssellänge, Hashalgorithmus usw.), kann der Client erfolgreich registriert werden.
RequestSecurityToken verwendet einen benutzerdefinierten TokenType (http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentToken), da unser Registrierungstoken mehr als ein X.509 v3-Zertifikat ist. Weitere Informationen finden Sie im Abschnitt Antwort.
Der RST kann auch viele AdditionalContext-Elemente angeben, z. B. DeviceType und Version. Basierend auf diesen Werten kann der Webdienst beispielsweise eine gerätespezifische und versionsspezifische DM-Konfiguration zurückgeben.
Hinweis
Der Richtliniendienst und der Registrierungsdienst müssen sich auf demselben Server befinden. Das heißt, sie müssen denselben Hostnamen haben.
Das folgende Beispiel zeigt die Registrierungswebdienstanforderung für die Verbundauthentifizierung.
<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>
Nach der Überprüfung der Anforderung sucht der Webdienst die zugewiesene Zertifikatvorlage für den Client, aktualisiert sie bei Bedarf, sendet die PKCS#10-Anforderungen an die Zertifizierungsstelle, verarbeitet die Antwort von der Zertifizierungsstelle, erstellt ein XML-Format für die OMA-Clientbereitstellung und gibt es im RequestSecurityTokenResponse (RSTR) zurück.
Hinweis
Die HTTP-Serverantwort darf Transfer-Encoding nicht auf Segmentiert festlegen. Es muss als eine Nachricht gesendet werden.
Ähnlich wie tokenType in der RST verwendet RSTR einen benutzerdefinierten ValueType im BinarySecurityToken (http://schemas.microsoft.com/ConfigurationManager/Enrollment/DeviceEnrollmentProvisionDoc), da das Token mehr als ein X.509 v3-Zertifikat ist.
Die Bereitstellungs-XML enthält Folgendes:
- Die angeforderten Zertifikate (erforderlich)
- Die DM-Clientkonfiguration (erforderlich)
Der Client installiert das Clientzertifikat, das Unternehmensstammzertifikat und das Zertifikat der Zwischenzertifizierungsstelle, falls vorhanden. Die DM-Konfiguration enthält den Namen und die Adresse des DM-Servers, das zu verwendende Clientzertifikat und plant, wann der DM-Client den Server zurückruft.
Xml für die Registrierungsbereitstellung sollte maximal ein Stammzertifikat und ein Zwischenzertifikat der Zertifizierungsstelle enthalten, das zum Verketten des MDM-Clientzertifikats erforderlich ist. Während einer OMA DM-Sitzung können weitere Stamm- und Zwischenzertifizierungsstellenzertifikate bereitgestellt werden.
Wenn Stamm- und Zwischenzertifizierungsstellenzertifikate bereitgestellt werden, lautet der unterstützte CSP-Knotenpfad: CertificateStore/Root/System für die Bereitstellung des Stammzertifikats, CertificateStore/My/User für die Zertifikatbereitstellung der Zwischenzertifizierungsstelle.
Hier sehen Sie eine RSTR-Beispielnachricht und ein Beispiel für OMA-Clientbereitstellungs-XML in RSTR. Weitere Informationen zu den Konfigurationsdienstanbietern (CSPs), die bei der Bereitstellung von XML verwendet werden, finden Sie im Abschnitt Unternehmenseinstellungen, Richtlinien und App-Verwaltung.
Das folgende Beispiel zeigt die Antwort des Registrierungswebdiensts.
<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>
Der folgende Code zeigt eine Beispielbereitstellungs-XML (dargestellt im vorherigen Paket als Sicherheitstoken):
<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>
Hinweis
<Parm name>Und<characteristic type=>-Elemente in der w7 APPLICATION CSP XML-Datei beachten Groß-/Kleinschreibung und müssen vollständig groß geschrieben werden.Im w7 APPLICATION-Merkmal sollten sowohl CLIENT- als auch APPSRV-Anmeldeinformationen in XML bereitgestellt werden.
Ausführliche Beschreibungen dieser Einstellungen finden Sie im Abschnitt Unternehmenseinstellungen, Richtlinien und App-Verwaltung dieses Dokuments.
Das PrivateKeyContainer-Merkmal ist erforderlich und muss in der Registrierungsbereitstellungs-XML der Registrierung vorhanden sein. Weitere wichtige Einstellungen sind die Parameterelemente PROVIDER-ID, NAME und ADDR , die die eindeutige ID und den NAMEN Ihres DM-Anbieters sowie die Adresse enthalten müssen, unter der das Gerät eine Verbindung für die Konfigurationsbereitstellung herstellen kann. Id und NAME können beliebige Werte sein, müssen aber eindeutig sein.
Wichtig ist auch SSLCLIENTCERTSEARCHCRITERIA, das zum Auswählen des Zertifikats verwendet wird, das für die Clientauthentifizierung verwendet werden soll. Die Suche basiert auf dem Subject-Attribut des signierten Benutzerzertifikats.
CertificateStore/WSTEP ermöglicht die Zertifikatverlängerung. Wenn der Server dies nicht unterstützt, legen Sie sie nicht fest.
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Tickets als Feedbackmechanismus für Inhalte auslaufen lassen und es durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter: https://aka.ms/ContentUserFeedback.
Einreichen und Feedback anzeigen für