フェデレーション認証デバイスの登録
このセクションでは、フェデレーション認証ポリシーを使用したモバイル デバイス登録プロトコルの例を示します。 認証ポリシーがフェデレーションに設定されている場合、Web 認証ブローカーは登録クライアントによってセキュリティ トークンを取得するために使用されます。 登録クライアントは、応答メッセージ内で Web 認証ブローカー API を呼び出してプロセスを開始します。 サーバーは、デバイス画面に合わせて Web 認証ブローカー ページを構築する必要があり、既存の登録 UI と一致している必要があります。 ブローカーからエンド ページとして返される不透明なセキュリティ トークンは、クライアント証明書要求の呼び出し中に登録クライアントによってデバイス セキュリティ シークレットとして使用されます。
検出応答メッセージの <AuthenticationServiceURL>
要素は、Web 認証ブローカー のページ開始 URL を指定します。
Windows 用 Microsoft モバイル デバイス登録プロトコルの詳細については、「 [MS-MDE2]: モバイル デバイス登録プロトコル バージョン 2」を参照してください。
注
Windows でサポートされていない登録シナリオの一覧については、「 登録シナリオがサポートされていません」を参照してください。
探索サービス
検出 Web サービスは、ユーザーが電話を管理サービスに登録するために必要な構成情報を提供します。 このサービスは、HTTPS 経由の安らかな Web サービスです (サーバー認証のみ)。
注
検出サービスの管理者は、アドレス enterpriseenrollment.<domain_name>.com
を持つホストを作成する必要があります。
デバイスの自動検出フローでは、サインイン中に Workplace 設定画面に送信されたメール アドレスのドメイン名が使用されます。 自動検出システムは、サブドメイン enterpriseenrollment を電子メール アドレスのドメインに追加し、パス /EnrollmentServer/Discovery.svc
を追加することで、このホスト名を使用する URI を構築します。 たとえば、電子メール アドレスが sample@contoso.com
されている場合、最初の Get 要求の結果の URI は http://enterpriseenrollment.contoso.com/EnrollmentServer/Discovery.svc
になります。
最初の要求は、標準の HTTP GET 要求です。
次の例は、電子メール アドレスとして指定された user@contoso.com
検出サーバーへの HTTP GET 経由の要求を示しています。
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
デバイスがサーバーから応答を取得すると、デバイスは POST 要求を enterpriseenrollment.<domain_name>/EnrollmentServer/Discovery.svc
に送信します。 サーバーから別の応答を取得した後 (登録サーバーがどこにあるかをデバイスに通知する必要があります)、デバイスから送信される次のメッセージは、登録サーバー enterpriseenrollment.<domain_name>
です。
次のロジックが適用されます。
- デバイスは最初に HTTPS を試みます。 デバイスがサーバー証明書を信頼しない場合、HTTPS の試行は失敗します。
- 失敗した場合、デバイスは HTTP にリダイレクトされているかどうかを確認しようとします。
- デバイスがリダイレクトされない場合、ユーザーはサーバー アドレスの入力を求められます。
- デバイスがリダイレクトされた場合、ユーザーはリダイレクトを許可するように求められます。
次の例は、電子メール アドレスとして指定された user@contoso.com
検出 Web サービスへの HTTP POST コマンドを使用した要求を示しています
https://EnterpriseEnrollment.Contoso.com/EnrollmentServer/Discovery.svc
次の例は、探索サービス要求を示しています。
<?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>
検出応答は XML 形式であり、次のフィールドが含まれています。
- 登録サービス URL (EnrollmentServiceUrl) - 管理サービスによって公開される登録エンドポイントの URL を指定します。 ユーザーが認証された後、デバイスはこの URL を呼び出す必要があります。 このフィールドは必須です。
- 認証ポリシー (AuthPolicy) - 必要な認証の種類を示します。 MDM サーバーの場合、OnPremise はサポートされている値です。これは、管理サービス URL を呼び出すときにユーザーが認証されることを意味します。 このフィールドは必須です。
- Windows では、フェデレーションは別のサポートされる値として追加されます。 この追加により、サーバーは Web 認証ブローカーを使用して、カスタマイズされたユーザー認証と使用同意期間を実行できます。
注
HTTP サーバーの応答では、Transfer-Encoding を Chunked に設定しないでください。1 つのメッセージとして送信する必要があります。
認証ポリシーがフェデレーションに設定されている場合、Web 認証ブローカー (WAB) は登録クライアントによってセキュリティ トークンを取得するために使用されます。 WAB スタート ページ URL は、応答メッセージの検出サービスによって提供されます。 登録クライアントは、応答メッセージ内で WAB API を呼び出して WAB プロセスを開始します。 WAB ページは、サーバーでホストされる Web ページです。 サーバーは、デバイス画面に合わせてこれらのページをビルドし、MDM 登録 UI の他のビルドと可能な限り一貫性を保つ必要があります。 終了ページとして WAB から返される不透明なセキュリティ トークンは、クライアント証明書登録要求の呼び出し中に、登録クライアントによってデバイス セキュリティ シークレットとして使用されます。
注
認証中に渡されるユーザー エージェント文字列に依存して OS のバージョンなどの情報を取得する代わりに、次のガイダンスを使用します。
- 検出要求中に送信されたデータから OS バージョンを解析します。
- AuthenticationServiceURL に OS バージョンをパラメーターとして追加します。
- OS が認証の応答を送信するときに、AuthenticiationServiceURL から OS バージョンを解析します。
新しい XML タグ AuthenticationServiceUrl が DiscoveryResponse XML に導入され、サーバーが WAB ページの開始 URL を指定できるようになります。 フェデレーション認証の場合は、この XML タグが存在する必要があります。
注
登録クライアントは、セキュリティ トークンを認証して返すプロトコル フローに関しては依存しません。 サーバーは、ユーザー資格情報を直接要求したり、別のサーバーとディレクトリ サービスとのフェデレーション プロトコルに入ったりすることがありますが、登録クライアントはこのすべてに依存しません。 依存しない状態を維持するために、登録クライアントを含む認証に関連するすべてのプロトコル フローはパッシブであり、つまりブラウザーによって実装されます。
サーバーの明示的な要件を次に示します。
-
<DiscoveryResponse>``<AuthenticationServiceUrl>
要素は HTTPS をサポートする必要があります。 - 認証サーバーでは、デバイスの信頼されたルート証明書を使用する必要があります。 それ以外の場合、WAP 呼び出しは失敗します。
- WP では、WAB 認証中に ADFS の Windows 統合認証 (WIA) がサポートされていません。 使用する場合は、Windows デバイスの WIA を試行しないように構成する必要がある場合は、ADFS 2012 R2。
登録クライアントは、次のように HTTPS 要求を発行します。
AuthenticationServiceUrl?appru=<appid>&login_hint=<User Principal Name>
-
<appid>
はフォームのms-app://string
-
<User Principal Name>
は登録ユーザーの名前です。たとえば、登録サインイン ページでユーザーによる入力として user@constoso.com します。 この属性の値は、認証の一部として認証サーバーによって使用されるヒントとして機能します。
認証が完了すると、認証サーバーは、クエリ文字列パラメーターで識別された appid の POST メソッド アクションを含む HTML フォーム ドキュメントを返す必要があります。
注
厳密なコンテンツ セキュリティ ポリシーと互換性のあるアプリケーションを作成するには、通常、HTML テンプレートとクライアント側のコードにいくつかの変更を加え、ポリシー ヘッダーを追加し、ポリシーの展開後にすべてが正常に動作することをテストする必要があります。
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>
サーバーは、POST メソッド アクションで示されているように、フォーム ms-app://string
のリダイレクト URL (URL スキームは ms-app) に POST を送信する必要があります。 セキュリティ トークンの値は、<wsse:BinarySecurityToken>
EncodingType 属性に含まれる base64 でエンコードされた文字列http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd\#base64binary
です。 Windows は、登録サーバーにバイナリエンコードを送信するときに、HTML エンコードされた形式でエンコードします。 この文字列は登録クライアントに対して不透明です。クライアントは文字列を解釈しません。
次の例は、WAB 経由の認証を必要とする探索 Web サービスから受信した応答を示しています。
<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>
登録ポリシー Web サービス
ポリシー サービスは省略可能です。 既定では、ポリシーが指定されていない場合、最小キー長は 2k、ハッシュ アルゴリズムは SHA-1 です。
この Web サービスでは、X.509 証明書登録ポリシー プロトコル (MS-XCEP) 仕様が実装されています。これにより、証明書登録をカスタマイズして、異なる時刻 (暗号化の機敏性) に企業のさまざまなセキュリティ ニーズに合わせてカスタマイズできます。 このサービスは、クライアントからの GetPolicies メッセージを処理し、クライアントを認証し、GetPoliciesResponse メッセージで一致する登録ポリシーを返します。
フェデレーション認証ポリシーの場合、セキュリティ トークン資格情報は、 <wsse:BinarySecurityToken>
要素 [WSS] を使用して要求メッセージに提供されます。 セキュリティ トークンは、「検出応答」セクションの説明に従って取得されます。 認証情報は次のとおりです。
- wsse:Security: 登録クライアントは、[WSS] セクション 5 で定義されている
<wsse:Security>
要素を実装します。<wsse:Security>
要素は、<s:Header>
要素の子である必要があります。 - wsse:BinarySecurityToken: 登録クライアントは、[WSS] セクション 6.3 で定義されている
<wsse:BinarySecurityToken>
要素を実装します。<wsse:BinarySecurityToken>
要素は、SOAP ヘッダーの<wsse:Security>
要素の子として含まれている必要があります。
「検出応答」セクションで説明したように、<wsse:BinarySecurityToken>
要素を含めることは登録クライアントに対して不透明であり、クライアントは文字列を解釈せず、要素のインクルードはセキュリティ トークン認証サーバー (<DiscoveryResponse>
とエンタープライズ サーバーの <AuthenticationServiceUrl>
要素で識別される) によって合意されます。
<wsse:BinarySecurityToken>
要素には、base64 でエンコードされた文字列が含まれています。 登録クライアントは、認証サーバーから受信したセキュリティ トークンを使用し、base64 でエンコードして、 <wsse:BinarySecurityToken>
要素を設定します。
wsse:BinarySecurityToken/attributes/ValueType:
<wsse:BinarySecurityToken>
ValueType 属性をhttp://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentUserToken
する必要があります。wsse:BinarySecurityToken/attributes/EncodingType:
<wsse:BinarySecurityToken>
EncodingType 属性をhttp://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd\#base64binary
する必要があります。
次の例は、受信したセキュリティ トークンをクライアント資格情報として使用する登録ポリシー要求です。
<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>
ユーザーが認証されると、Web サービスは、ユーザーが登録する必要がある証明書テンプレートを取得し、証明書テンプレートのプロパティに基づいて登録ポリシーを作成します。 応答のサンプルは、MSDN で確認できます。
MS-XCEP では、さまざまな複合型と属性を使用した柔軟な登録ポリシーがサポートされています。 Windows デバイスでは、最初に minimalKeyLength、hashAlgorithmOIDReference ポリシー、CryptoProviders がサポートされます。 hashAlgorithmOIDReference には、GetPolicesResponse に関連する OID と OIDReferenceID と policySchema があります。 policySchema は、証明書テンプレートのバージョンを参照します。 MS-XCEP のバージョン 3 では、ハッシュ アルゴリズムがサポートされています。
注
HTTP サーバーの応答では、Transfer-Encoding を Chunked に設定しないでください。1 つのメッセージとして送信する必要があります。
次のスニペットは、ポリシー Web サービスの応答を示しています。
<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>
登録 Web サービス
この Web サービスは、MS-WSTEP プロトコルを実装します。 クライアントから RequestSecurityToken (RST) メッセージを処理し、クライアントを認証し、CA から証明書を要求し、それを RequestSecurityTokenResponse (RSTR) でクライアントに返します。 発行された証明書に加えて、応答には DMClient をプロビジョニングするために必要な構成も含まれています。
RequestSecurityToken (RST) には、ユーザー資格情報と証明書要求が必要です。 RST SOAP エンベロープのユーザー資格情報は GetPolicies と同じであり、認証ポリシーが OnPremise かフェデレーションかに応じて異なる場合があります。 RST SOAP 本文の BinarySecurityToken には、Base64 でエンコードされた PKCS#10 証明書要求が含まれています。これは、登録ポリシーに基づいてクライアントによって生成されます。 クライアントは、MS-WSTEP を使用して証明書を要求する前に、MS-XCEP を使用して登録ポリシーを要求できました。 証明機関 (CA) によって PKCS#10 証明書要求が受け入れられた場合 (キーの長さ、ハッシュ アルゴリズムなど)、証明書テンプレートと一致すると、クライアントは正常に登録できます。
RequestSecurityToken はカスタム TokenType (http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentToken
) を使用します。これは、登録トークンが X.509 v3 証明書を超えるためです。 詳細については、「応答」セクションを参照してください。
RST では、DeviceType や Version など、多数の AdditionalContext 項目を指定することもできます。 たとえば、これらの値に基づいて、Web サービスはデバイス固有の DM 構成とバージョン固有の DM 構成を返すことができます。
注
ポリシー サービスと登録サービスは、同じサーバー上にある必要があります。つまり、同じホスト名が必要です。
次の例は、フェデレーション認証の登録 Web サービス要求を示しています。
<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>
要求を検証した後、Web サービスはクライアントに割り当てられた証明書テンプレートを検索し、必要に応じて更新し、PKCS#10 要求を CA に送信し、CA からの応答を処理し、OMA クライアント プロビジョニング XML 形式を構築して、RequestSecurityTokenResponse (RSTR) で返します。
注
HTTP サーバーの応答では、Transfer-Encoding を Chunked に設定しないでください。1 つのメッセージとして送信する必要があります。
RST の TokenType と同様に、RSTR では、トークンが X.509 v3 証明書を超えるため、BinarySecurityToken (http://schemas.microsoft.com/ConfigurationManager/Enrollment/DeviceEnrollmentProvisionDoc
) でカスタム ValueType が使用されます。
プロビジョニング XML には、次のものが含まれます。
- 要求された証明書 (必須)
- DMClient 構成 (必須)
クライアントは、クライアント証明書、エンタープライズ ルート証明書、中間 CA 証明書がある場合にインストールします。 DM 構成には、DM サーバーの名前とアドレス、使用するクライアント証明書が含まれており、DMClient がサーバーに呼び戻すタイミングをスケジュールします。
登録プロビジョニング XML には、MDM クライアント証明書をチェーンアップするために必要な最大 1 つのルート証明書と 1 つの中間 CA 証明書が含まれている必要があります。 OMA DM セッション中に、より多くのルートおよび中間 CA 証明書をプロビジョニングできます。
ルート CA 証明書と中間 CA 証明書がプロビジョニングされている場合、サポートされている CSP ノード パスは、ルート証明書プロビジョニング用の CertificateStore/Root/System、中間 CA 証明書プロビジョニング用の CertificateStore/My/User です。
RSTR メッセージのサンプルと、RSTR 内の OMA クライアント プロビジョニング XML のサンプルを次に示します。 XML のプロビジョニングで使用される構成サービス プロバイダー (CSP) の詳細については、「エンタープライズ設定、ポリシー、およびアプリ管理」セクションを参照してください。
次の例は、登録 Web サービスの応答を示しています。
<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>
次のコードは、サンプル プロビジョニング XML (前のパッケージでセキュリティ トークンとして表示) を示しています。
<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>
注
<Parm name>
w7 APPLICATION CSP XML の<characteristic type=>
要素では大文字と小文字が区別され、すべて大文字である必要があります。w7 APPLICATION 特性では、CLIENT 資格情報と APPSRV 資格情報の両方を XML で指定する必要があります。
これらの設定の詳細については、このドキュメントの 「エンタープライズ設定、ポリシー、アプリ管理 」セクションを参照してください。
PrivateKeyContainer 特性は必須であり、登録によって登録プロビジョニング XML に存在する必要があります。 その他の重要な設定は、 PROVIDER-ID、 NAME、 ADDR パラメーター要素です。この要素には、DM プロバイダーの一意の ID と名前、デバイスが構成プロビジョニングのために接続できるアドレスを含める必要があります。 ID と NAME には任意の値を指定できますが、一意である必要があります。
また、クライアント認証に使用する証明書を選択するために使用される SSLCLIENTCERTSEARCHCRITERIA も重要です。 検索は、署名されたユーザー証明書のサブジェクト属性に基づいています。
CertificateStore/WSTEP では、証明書の更新が有効になります。 サーバーがサポートしていない場合は、設定しないでください。