次の方法で共有

Windows Hello for Business プロビジョニングのしくみ

  • [アーティクル]

Windows Hello for Businessプロビジョニングを使用すると、ユーザーはパスワードレス認証に使用できる新しい強力な 2 要素資格情報を登録できます。 プロビジョニング エクスペリエンスは、次によって異なります。

  • デバイスをMicrosoft Entra IDに参加させる方法
  • Windows Hello for Businessデプロイの種類
  • 環境が管理またはフェデレーションされている場合

注

このセクションのフローは、考えられるすべてのシナリオを網羅しているわけではありません。 たとえば、フェデレーション キー信頼もサポートされている構成です。

マネージド認証を使用したMicrosoft Entra参加済みデバイスのプロビジョニング

マネージド認証を使用した参加済みデバイスのWindows Hello プロビジョニング フロー Microsoft Entraシーケンス図。

フェーズ 説明
A クラウド エクスペリエンス ホスト (CXH) でホストされているプロビジョニング アプリケーションは、Azure Device Registration Service (ADRS) のアクセス トークンを要求することでプロビジョニングを開始します。 アプリケーションは、Microsoft Entra Web アカウント マネージャー プラグインを使用して要求を行います。
ユーザーは、認証の 2 つの要素を提供する必要があります。 このフェーズでは、ユーザーは認証の 1 要素 (通常はユーザー名とパスワード) を既に提供しています。 Microsoft Entra多要素認証サービスは、認証の 2 番目の要素を提供します。 ユーザーが過去 10 分以内に多要素認証Microsoft Entra実行した場合 (out-of-box-experience (OOBE) からデバイスを登録する場合など)、現在の MFA は有効なままであるため、MFA の入力を求められません。
Microsoft Entra IDは、アクセス トークン要求とそれに関連付けられている MFA 要求を検証し、ADRS アクセス トークンを作成してアプリケーションに返します。
B ADRS アクセス トークンを受信した後、アプリケーションは、デバイスにWindows Hello生体認証互換センサーがあるかどうかを検出します。 アプリケーションが生体認証センサーを検出した場合は、ユーザーに生体認証を登録する選択肢が提供されます。 生体認証登録を完了またはスキップした後、アプリケーションでは、ユーザーが PIN と既定の (生体認証で使用される場合はフォールバック ジェスチャ) を作成する必要があります。 ユーザーは PIN を提供して確認します。 次に、アプリケーションは、構成証明データを含むキーの事前世代プールからWindows Hello for Businessキー ペアを要求します。 これはユーザー キー (ukpub/ukpriv) です。
C アプリケーションは、ユーザー キーの登録のために ADRS トークン、ukpub、構成証明データ、およびデバイス情報を ADRS に送信します。 Azure DRS は、MFA 要求が最新の状態のままであることの検証を行います。 検証が成功すると、Azure DRS はMicrosoft Entra IDでユーザーのオブジェクトを検索し、キー情報を複数値属性に書き込みます。 キー情報には、作成元のデバイスへの参照が含まれます。 Microsoft Entra IDは、キー ID をアプリケーションに返します。これにより、ユーザー プロビジョニングの終了とアプリケーションの終了が通知されます。

フェデレーション認証を使用したMicrosoft Entra参加済みデバイスのプロビジョニング

フェデレーション認証を使用Microsoft Entra参加済みデバイスのWindows Hello プロビジョニング フローのシーケンス図。

フェーズ 説明
A クラウド エクスペリエンス ホスト (CXH) でホストされているプロビジョニング アプリケーションは、Azure Device Registration Service (ADRS) のアクセス トークンを要求することでプロビジョニングを開始します。 アプリケーションは、Microsoft Entra Web アカウント マネージャー プラグインを使用して要求を行います。
フェデレーション環境では、プラグインは、Active Directory フェデレーション サービス (AD FS)などのトークン要求をオンプレミスの STS に送信します。 オンプレミスの STS はユーザーを認証し、ユーザーが別の認証要素を実行する必要があるかどうかを判断します。
ユーザーは、認証の 2 つの要素を提供する必要があります。 このフェーズでは、ユーザーは認証の 1 要素 (通常はユーザー名とパスワード) を既に提供しています。 Microsoft Entra多要素認証サービスは、認証の 2 番目の要素を提供します。 ユーザーが過去 10 分以内に多要素認証Microsoft Entra実行した場合 (out-of-box-experience (OOBE) からデバイスを登録する場合など)、現在の MFA は有効なままであるため、MFA の入力を求められません。
オンプレミスの STS サーバーは、成功した MFA でエンタープライズ トークンを発行します。 アプリケーションはトークンをMicrosoft Entra IDに送信します。
Microsoft Entra IDは、アクセス トークン要求とそれに関連付けられている MFA 要求を検証し、ADRS アクセス トークンを作成してアプリケーションに返します。
B ADRS アクセス トークンを受信した後、アプリケーションは、デバイスにWindows Hello生体認証互換センサーがあるかどうかを検出します。 アプリケーションが生体認証センサーを検出した場合は、ユーザーに生体認証を登録する選択肢が提供されます。 生体認証登録を完了またはスキップした後、アプリケーションでは、ユーザーが PIN と既定の (生体認証で使用される場合はフォールバック ジェスチャ) を作成する必要があります。 ユーザーは PIN を提供して確認します。 次に、アプリケーションは、構成証明データを含むキーの事前世代プールからWindows Hello for Businessキー ペアを要求します。 これはユーザー キー (ukpub/ukpriv) です。
C アプリケーションは、ユーザー キーの登録のために ADRS トークン、ukpub、構成証明データ、およびデバイス情報を ADRS に送信します。 Azure DRS は、MFA 要求が最新の状態を維持すると検証します。 検証が成功すると、Azure DRS はMicrosoft Entra IDでユーザーのオブジェクトを検索し、キー情報を複数値属性に書き込みます。 キー情報には、作成元のデバイスへの参照が含まれます。 Microsoft Entra IDは、アプリケーションにキー ID を返します。これにより、ユーザー プロビジョニングの終了とアプリケーションの終了が通知されます。

マネージド認証を使用したクラウド Kerberos 信頼デプロイ モデルでのプロビジョニング

マネージド認証を使用したハイブリッド クラウド Kerberos 信頼デプロイ モデルのWindows Hello プロビジョニング フローのシーケンス図。

フェーズ 説明
A クラウド エクスペリエンス ホスト (CXH) でホストされているプロビジョニング アプリケーションは、Azure Device Registration Service (ADRS) のアクセス トークンを要求することでプロビジョニングを開始します。 アプリケーションは、Microsoft Entra Web アカウント マネージャー プラグインを使用して要求を行います。
ユーザーは、認証の 2 つの要素を提供する必要があります。 このフェーズでは、ユーザーは認証の 1 要素 (通常はユーザー名とパスワード) を既に提供しています。 Microsoft Entra多要素認証サービスは、認証の 2 番目の要素を提供します。 ユーザーが過去 10 分以内に多要素認証Microsoft Entra実行した場合 (out-of-box-experience (OOBE) からデバイスを登録する場合など)、現在の MFA は有効なままであるため、MFA の入力を求められません。
Microsoft Entra IDは、アクセス トークン要求とそれに関連付けられている MFA 要求を検証し、ADRS アクセス トークンを作成してアプリケーションに返します。
B ADRS アクセス トークンを受信した後、アプリケーションは、デバイスにWindows Hello生体認証互換センサーがあるかどうかを検出します。 アプリケーションが生体認証センサーを検出した場合は、ユーザーに生体認証を登録する選択肢が提供されます。 生体認証登録を完了またはスキップした後、アプリケーションでは、ユーザーが PIN と既定の (生体認証で使用される場合はフォールバック ジェスチャ) を作成する必要があります。 ユーザーは PIN を提供して確認します。 次に、アプリケーションは、構成証明データを含むキーの事前世代プールからWindows Hello for Businessキー ペアを要求します。 これはユーザー キー (ukpub/ukpriv) です。
C アプリケーションは、ユーザー キーの登録のために ADRS トークン、ukpub、構成証明データ、およびデバイス情報を ADRS に送信します。 Azure DRS は、MFA 要求が最新の状態のままであることの検証を行います。 検証が成功すると、Azure DRS はMicrosoft Entra IDでユーザーのオブジェクトを検索し、キー情報を複数値属性に書き込みます。 キー情報には、作成元のデバイスへの参照が含まれます。 Microsoft Entra IDは、キー ID をアプリケーションに返します。これにより、ユーザー プロビジョニングの終了とアプリケーションの終了が通知されます。

注

クラウド Kerberos 信頼Windows Hello for Business、ユーザーのキーを Microsoft Entra ID から Active Directory に同期する必要はありません。 ユーザーは、資格情報をプロビジョニングした後、Microsoft Entra IDと AD に対してすぐに認証できます。

マネージド認証を使用したハイブリッド キー信頼デプロイ モデルでのプロビジョニング

マネージド認証を使用したハイブリッド キー信頼デプロイ モデルのWindows Hello プロビジョニング フローのシーケンス図。

フェーズ 説明
A クラウド エクスペリエンス ホスト (CXH) でホストされているプロビジョニング アプリケーションは、Azure Device Registration Service (ADRS) のアクセス トークンを要求することでプロビジョニングを開始します。 アプリケーションは、Microsoft Entra Web アカウント マネージャー プラグインを使用して要求を行います。
ユーザーは、認証の 2 つの要素を提供する必要があります。 このフェーズでは、ユーザーは認証の 1 要素 (通常はユーザー名とパスワード) を既に提供しています。 Microsoft Entra多要素認証サービスは、認証の 2 番目の要素を提供します。 ユーザーが過去 10 分以内に多要素認証Microsoft Entra実行した場合 (out-of-box-experience (OOBE) からデバイスを登録する場合など)、現在の MFA は有効なままであるため、MFA の入力を求められません。
Microsoft Entra IDは、アクセス トークン要求とそれに関連付けられている MFA 要求を検証し、ADRS アクセス トークンを作成してアプリケーションに返します。
B ADRS アクセス トークンを受信した後、アプリケーションは、デバイスにWindows Hello生体認証互換センサーがあるかどうかを検出します。 アプリケーションが生体認証センサーを検出した場合は、ユーザーに生体認証を登録する選択肢が提供されます。 生体認証登録を完了またはスキップした後、アプリケーションでは、ユーザーが PIN と既定の (生体認証で使用される場合はフォールバック ジェスチャ) を作成する必要があります。 ユーザーは PIN を提供して確認します。 次に、アプリケーションは、構成証明データを含むキーの事前世代プールからWindows Hello for Businessキー ペアを要求します。 これはユーザー キー (ukpub/ukpriv) です。
C アプリケーションは、ユーザー キーの登録のために ADRS トークン、ukpub、構成証明データ、およびデバイス情報を ADRS に送信します。 Azure DRS は、MFA 要求が最新の状態のままであることの検証を行います。 検証が成功すると、Azure DRS はMicrosoft Entra IDでユーザーのオブジェクトを検索し、キー情報を複数値属性に書き込みます。 キー情報には、作成元のデバイスへの参照が含まれます。 Microsoft Entra IDは、キー ID をアプリケーションに返します。これにより、ユーザー プロビジョニングの終了とアプリケーションの終了が通知されます。
D Microsoft Entra Connect は、次の同期サイクルで更新プログラムを要求します。 Microsoft Entra IDは、プロビジョニングによって安全に登録されたユーザーの公開キーを送信します。 Microsoft Entra Connect は公開キーを受け取り、Active Directory のユーザーのmsDS-KeyCredentialLink属性に書き込みます。

重要

新しくプロビジョニングされたユーザーは、Microsoft Entra Connect が公開キーをオンプレミスの Active Directoryに正常に同期するまで、Windows Hello for Businessを使用してサインインできません。

フェデレーション認証を使用したハイブリッド証明書信頼デプロイ モデルでのプロビジョニング

フェデレーション認証を使用したハイブリッド証明書信頼デプロイ モデルのWindows Hello プロビジョニング フローのシーケンス図。

フェーズ 説明
A クラウド エクスペリエンス ホスト (CXH) でホストされているプロビジョニング アプリケーションは、Azure Device Registration Service (ADRS) のアクセス トークンを要求することでプロビジョニングを開始します。 アプリケーションは、Microsoft Entra Web アカウント マネージャー プラグインを使用して要求を行います。
フェデレーション環境では、プラグインは、Active Directory フェデレーション サービス (AD FS)などのトークン要求をオンプレミスの STS に送信します。 オンプレミスの STS はユーザーを認証し、ユーザーが別の認証要素を実行する必要があるかどうかを判断します。
ユーザーは、認証の 2 つの要素を提供する必要があります。 このフェーズでは、ユーザーは認証の 1 要素 (通常はユーザー名とパスワード) を既に提供しています。 Microsoft Entra多要素認証サービス (または Microsoft 以外の MFA サービス) は、認証の 2 番目の要素を提供します。
オンプレミスの STS サーバーは、成功した MFA でエンタープライズ トークンを発行します。 アプリケーションはトークンをMicrosoft Entra IDに送信します。
Microsoft Entra IDは、アクセス トークン要求とそれに関連付けられている MFA 要求を検証し、ADRS アクセス トークンを作成してアプリケーションに返します。
B ADRS アクセス トークンを受信した後、アプリケーションは、デバイスにWindows Hello生体認証互換センサーがあるかどうかを検出します。 アプリケーションが生体認証センサーを検出した場合は、ユーザーに生体認証を登録する選択肢が提供されます。 生体認証登録を完了またはスキップした後、アプリケーションでは、ユーザーが PIN と既定の (生体認証で使用される場合はフォールバック ジェスチャ) を作成する必要があります。 ユーザーは PIN を提供して確認します。 次に、アプリケーションは、構成証明データを含むキーの事前世代プールからWindows Hello for Businessキー ペアを要求します。 これはユーザー キー (ukpub/ukpriv) です。
C アプリケーションは、ユーザー キーの登録のために ADRS トークン、ukpub、構成証明データ、およびデバイス情報を ADRS に送信します。 Azure DRS は、MFA 要求が最新の状態のままであることの検証を行います。 検証が成功すると、Azure DRS はMicrosoft Entra IDでユーザーのオブジェクトを検索し、キー情報を複数値属性に書き込みます。 キー情報には、作成元のデバイスへの参照が含まれます。 Microsoft Entra IDは、キー ID とキー受領書をアプリケーションに返します。これは、ユーザー キー登録の終了を表します。
D プロビジョニングの証明書要求部分は、アプリケーションがキー登録から正常な応答を受け取った後に開始されます。 アプリケーションによって PKCS#10 証明書要求が作成されます。 証明書要求で使用されるキーは、安全にプロビジョニングされたキーと同じです。
アプリケーションは、公開キーを含むキーの受信と証明書の要求を、Active Directory フェデレーション サービス (AD FS) (AD FS) ファームでホストされている証明機関に送信します。
証明書要求を受け取った後、証明機関は、登録されている公開キーの一覧について、msDS-KeyCredentialsLink の Active Directory に対してクエリを実行します。
E 登録機関は、証明書要求の公開キーがユーザーの登録済みキーと一致すると検証します。
証明書の公開キーが登録されている公開キーの一覧に見つからない場合は、キーの受信を検証して、キーが Azure に安全に登録されていることを確認します。
キーの受信または公開キーを検証した後、登録機関は、その登録エージェント証明書を使用して証明書要求に署名します。
F 登録機関は、証明書要求をエンタープライズ発行元の証明機関に送信します。 証明機関は、証明書要求が有効な登録エージェントによって署名されていることを検証し、成功すると証明書を発行して登録機関に返し、証明書をアプリケーションに返します。
G アプリケーションは、新しく発行された証明書を受け取り、ユーザーの個人用ストアにインストールします。 これにより、プロビジョニングの終了が通知されます。

重要

同期証明書の登録は、Windows Hello for Business認証証明書を発行するためにユーザーの公開キーを同期する connect Microsoft Entraに依存しません。 ユーザーは、プロビジョニングが完了した直後に証明書を使用してサインインできます。 Microsoft Entra Connect は引き続き公開キーを Active Directory に同期しますが、このフローには表示されません。

オンプレミスのキー信頼デプロイ モデルでのプロビジョニング

オンプレミスのキー信頼デプロイ モデルのWindows Hello プロビジョニング フローのシーケンス図。

フェーズ 説明
A クラウド エクスペリエンス ホスト (CXH) でホストされているプロビジョニング アプリケーションは、エンタープライズ デバイス登録サービス (EDRS) のアクセス トークンを要求することでプロビジョニングを開始します。 アプリケーションは、Microsoft Entra Web アカウント マネージャー プラグインを使用して要求を行います。
オンプレミスのデプロイでは、プラグインは、Active Directory フェデレーション サービス (AD FS)などのトークン要求をオンプレミスの STS に送信します。 オンプレミスの STS はユーザーを認証し、ユーザーが別の認証要素を実行する必要があるかどうかを判断します。
ユーザーは、認証の 2 つの要素を提供する必要があります。 このフェーズでは、ユーザーは認証の 1 要素 (通常はユーザー名とパスワード) を既に提供しています。 Microsoft Entra多要素認証サーバー (または Microsoft 以外の MFA サービス) は、認証の 2 番目の要素を提供します。
オンプレミスの STS サーバーは、成功した MFA でエンタープライズ DRS トークンを発行します。
B EDRS アクセス トークンを受信した後、アプリケーションは、デバイスにWindows Hello生体認証互換センサーがあるかどうかを検出します。 アプリケーションが生体認証センサーを検出した場合は、ユーザーに生体認証を登録する選択肢が提供されます。 生体認証登録を完了またはスキップした後、アプリケーションでは、ユーザーが PIN と既定の (生体認証で使用される場合はフォールバック ジェスチャ) を作成する必要があります。 ユーザーは PIN を提供して確認します。 次に、アプリケーションは、構成証明データを含むキーの事前世代プールからWindows Hello for Businessキー ペアを要求します。 これはユーザー キー (ukpub/ukpriv) です。
C アプリケーションは、EDRS トークン、ukpub、構成証明データ、デバイス情報を Enterprise DRS に送信して、ユーザー キーの登録を行います。 Enterprise DRS は、MFA 要求が最新の状態のままであることの検証を行います。 検証が成功すると、Enterprise DRS は Active Directory でユーザーのオブジェクトを検索し、キー情報を複数値属性に書き込みます。 キー情報には、作成元のデバイスへの参照が含まれます。 Enterprise DRS は、ユーザー キー登録の終了を表すキー ID をアプリケーションに返します。

オンプレミス証明書信頼デプロイ モデルでのプロビジョニング

オンプレミス証明書信頼デプロイ モデルのWindows Hello プロビジョニング フローのシーケンス図。

フェーズ 説明
A クラウド エクスペリエンス ホスト (CXH) でホストされているプロビジョニング アプリケーションは、エンタープライズ デバイス登録サービス (EDRS) のアクセス トークンを要求することでプロビジョニングを開始します。 アプリケーションは、Microsoft Entra Web アカウント マネージャー プラグインを使用して要求を行います。
オンプレミスのデプロイでは、プラグインは、Active Directory フェデレーション サービス (AD FS)などのトークン要求をオンプレミスの STS に送信します。 オンプレミスの STS はユーザーを認証し、ユーザーが別の認証要素を実行する必要があるかどうかを判断します。
ユーザーは、認証の 2 つの要素を提供する必要があります。 このフェーズでは、ユーザーは認証の 1 要素 (通常はユーザー名とパスワード) を既に提供しています。 Microsoft Entra多要素認証サーバー (または Microsoft 以外の MFA サービス) は、認証の 2 番目の要素を提供します。
オンプレミスの STS サーバーは、成功した MFA でエンタープライズ DRS トークンを発行します。
B EDRS アクセス トークンを受信した後、アプリケーションは、デバイスにWindows Hello生体認証互換センサーがあるかどうかを検出します。 アプリケーションが生体認証センサーを検出した場合は、ユーザーに生体認証を登録する選択肢が提供されます。 生体認証登録を完了またはスキップした後、アプリケーションでは、ユーザーが PIN と既定の (生体認証で使用される場合はフォールバック ジェスチャ) を作成する必要があります。 ユーザーは PIN を提供して確認します。 次に、アプリケーションは、構成証明データを含むキーの事前世代プールからWindows Hello for Businessキー ペアを要求します。 これはユーザー キー (ukpub/ukpriv) です。
C アプリケーションは、EDRS トークン、ukpub、構成証明データ、デバイス情報を Enterprise DRS に送信して、ユーザー キーの登録を行います。 Enterprise DRS は、MFA 要求が最新の状態のままであることの検証を行います。 検証が成功すると、Enterprise DRS は Active Directory でユーザーのオブジェクトを検索し、キー情報を複数値属性に書き込みます。 キー情報には、作成元のデバイスへの参照が含まれます。 Enterprise DRS は、ユーザー キー登録の終了を表すキー ID をアプリケーションに返します。
D プロビジョニングの証明書要求部分は、アプリケーションがキー登録から正常な応答を受け取った後に開始されます。 アプリケーションによって PKCS#10 証明書要求が作成されます。 証明書要求で使用されるキーは、安全にプロビジョニングされたキーと同じです。
アプリケーションは、公開キーを含む証明書要求を、Active Directory フェデレーション サービス (AD FS) (AD FS) ファームでホストされている証明機関に送信します。
証明書要求を受け取った後、証明機関は、登録されている公開キーの一覧について、msDS-KeyCredentialsLink の Active Directory に対してクエリを実行します。
E 登録機関は、証明書要求の公開キーがユーザーの登録済みキーと一致すると検証します。
公開キーを検証した後、登録機関は登録エージェント証明書を使用して証明書要求に署名します。
F 登録機関は、証明書要求をエンタープライズ発行元の証明機関に送信します。 証明機関は、証明書要求が有効な登録エージェントによって署名されていることを検証し、成功すると証明書を発行して登録機関に返し、証明書をアプリケーションに返します。
G アプリケーションは、新しく発行された証明書を受け取り、ユーザーの個人用ストアにインストールします。 これにより、プロビジョニングの終了が通知されます。