Windows Hello for Business認証
Windows Hello for Business認証は、パスワードレスの 2 要素認証です。 Windows Hello for Businessによる認証は、Microsoft Entra IDリソースと Active Directory リソースの両方に対してユーザーを認証する便利なサインイン エクスペリエンスを提供します。
Microsoft Entra参加済みデバイスは、サインイン中にMicrosoft Entra IDに対して認証を行い、必要に応じて Active Directory に対して認証できます。 ハイブリッド参加済みデバイスMicrosoft Entraサインイン中に Active Directory に対して認証され、バックグラウンドでMicrosoft Entra IDに対して認証されます。
認証をMicrosoft Entra IDに参加させるMicrosoft Entra
注
参加しているすべてのMicrosoft EntraデバイスがWindows Hello for Businessで認証され、同じ方法でMicrosoft Entra IDされます。 Windows Hello for Business信頼の種類は、デバイスがオンプレミス AD に対して認証する方法にのみ影響します。
| フェーズ | 説明 |
|---|---|
| A | ユーザーがロック画面を閉じると認証が開始され、Winlogon がトリガーされ、Windows Hello for Business資格情報プロバイダーが表示されます。 ユーザーは、Windows Hello ジェスチャ (PIN または生体認証) を提供します。 資格情報プロバイダーは、これらの資格情報をパッケージし、Winlogon に返します。 Winlogon は、収集された資格情報を lsass に渡します。 Lsass は、収集された資格情報をクラウド認証セキュリティ サポート プロバイダー (クラウド AP プロバイダーと呼ばれます) に渡します。 |
| B | クラウド AP プロバイダーは、Microsoft Entra IDから nonce を要求します。 Microsoft Entra IDは nonce を返します。 クラウド AP プロバイダーは、ユーザーの秘密キーを使用して nonce に署名し、署名された nonce をMicrosoft Entra IDに返します。 |
| C | Microsoft Entra IDは、ユーザーの安全に登録された公開キーを使用して、署名された nonce を nonce 署名に対して検証します。 Microsoft Entra ID返された署名付き nonce を検証し、デバイスのトランスポート キーに暗号化されたセッション キーを使用して PRT を作成し、クラウド AP プロバイダーに返します。 |
| D | クラウド AP プロバイダーは、セッション キーを使用して暗号化された PRT を受け取ります。 デバイスのプライベート トランスポート キーを使用して、クラウド AP プロバイダーはセッション キーを復号化し、デバイスの TPM を使用してセッション キーを保護します。 |
| E | クラウド AP プロバイダーは、lsass に正常な認証応答を返します。 Lsass は PRT をキャッシュし、成功認証について Winlogon に通知します。 Winlogon はログオン セッションを作成し、ユーザーのプロファイルを読み込み、explorer.exe を開始します。 |
クラウド Kerberos 信頼を使用して認証を Active Directory に参加させるMicrosoft Entra
| フェーズ | 説明 |
|---|---|
| A | Microsoft Entra参加済みデバイスからの Active Directory への認証は、ユーザーが最初に Kerberos 認証を必要とするリソースの使用を試みます。 lsass でホストされる Kerberos セキュリティ サポート プロバイダーは、Windows Hello for Business キーのメタデータを使用して、ユーザーのドメインのヒントを取得します。 このヒントを使用して、プロバイダーは DClocator サービスを使用してドメイン コントローラーを見つけます。 |
| B | ドメイン コントローラーを見つけた後、Kerberos プロバイダーは、以前のMicrosoft Entra認証からMicrosoft Entra IDから受信した部分的な TGT をドメイン コントローラーに送信します。 部分的な TGT にはユーザー SID のみが含まれており、Kerberos Microsoft Entra署名されています。 ドメイン コントローラーは、部分的な TGT が有効であることを確認します。 成功すると、KDC は TGT をクライアントに返します。 |
キーを使用して認証を Active Directory に参加させるMicrosoft Entra
| フェーズ | 説明 |
|---|---|
| A | Microsoft Entra参加済みデバイスからの Active Directory への認証は、ユーザーが最初に Kerberos 認証を必要とするリソースの使用を試みます。 lsass でホストされる Kerberos セキュリティ サポート プロバイダーは、Windows Hello for Business キーのメタデータを使用して、ユーザーのドメインのヒントを取得します。 このヒントを使用して、プロバイダーは DClocator サービスを使用してドメイン コントローラーを見つけます。 プロバイダーがドメイン コントローラーを見つけた後、プロバイダーは秘密キーを使用して Kerberos 事前認証データに署名します。 |
| B | Kerberos プロバイダーは、署名された事前認証データとその公開キー (自己署名証明書の形式) を、ドメイン コントローラーで実行されているキー配布センター (KDC) サービスにKERB_AS_REQの形式で送信します。 ドメイン コントローラーは、証明書が自己署名証明書であると判断します。 KERB_AS_REQに含まれる証明書から公開キーを取得し、Active Directory で公開キーを検索します。 認証要求の UPN が Active Directory に登録されている UPN と一致し、Active Directory の公開キーを使用して署名された事前認証データを検証します。 成功すると、KDC は証明書をKERB_AS_REPに含む TGT をクライアントに返します。 |
| C | Kerberos プロバイダーは、ドメイン コントローラーからの応答を信頼できることを確認します。 まず、KDC 証明書が、デバイスによって信頼されているルート証明書にチェーンされます。 次に、証明書が有効期間内にあり、失効していないことを確認します。 次に、Kerberos プロバイダーは、証明書に KDC 認証が存在し、KDC の証明書に一覧表示されているサブジェクト代替名が、ユーザーが認証するドメイン名と一致することを確認します。 この条件に合格すると、Kerberos は TGT を lsass に返します。ここで、TGT はキャッシュされ、後続のサービス チケット要求に使用されます。 |
注
オンプレミス ドメインがMicrosoft Entra IDとフェデレーションされている可能性があります。 Microsoft Entra参加済みデバイスWindows Hello for Business PIN/Bio を正常にプロビジョニングすると、Windows Hello for Business (PIN/Bio) サインインの今後のログインは、Microsoft Entra IDに対して直接認証されます。PRT を取得し、(LOS から DC が使用可能な場合) DC に対する認証をトリガーして Kerberos を取得します。 WINDOWS HELLO FOR BUSINESS サインインの認証に AD FS を使用しなくなりました。
証明書を使用して認証を Active Directory に参加させるMicrosoft Entra
| フェーズ | 説明 |
|---|---|
| A | Microsoft Entra参加済みデバイスからの Active Directory への認証は、ユーザーが最初に Kerberos 認証を必要とするリソースの使用を試みます。 lsass でホストされている Kerberos セキュリティ サポート プロバイダーは、証明書からの情報を使用して、ユーザーのドメインのヒントを取得します。 Kerberos では、証明書のサブジェクトで見つかったユーザーの識別名を使用することも、証明書のサブジェクト代替名で見つかったユーザーのユーザー プリンシパル名を使用することもできます。 このヒントを使用して、プロバイダーは DClocator サービスを使用してドメイン コントローラーを見つけます。 プロバイダーがアクティブなドメイン コントローラーを見つけた後、プロバイダーは秘密キーを使用して Kerberos の事前認証データに署名します。 |
| B | Kerberos プロバイダーは、署名された事前認証データと、公開キーを含むユーザーの証明書を、ドメイン コントローラーで実行されているキー配布センター (KDC) サービスにKERB_AS_REQの形式で送信します。 ドメイン コントローラーは、証明書が自己署名証明書ではないと判断します。 ドメイン コントローラーは、信頼されたルート証明書への証明書チェーンが、その有効期間内にあり、認証に使用でき、取り消されていないことを確認します。 KERB_AS_REQに含まれる証明書から公開キーと UPN を取得し、Active Directory で UPN を検索します。 証明書の公開キーを使用して、署名された事前認証データを検証します。 成功すると、KDC は証明書をKERB_AS_REPに含む TGT をクライアントに返します。 |
| C | Kerberos プロバイダーは、ドメイン コントローラーからの応答を信頼できることを確認します。 まず、KDC 証明書が、デバイスによって信頼されているルート証明書にチェーンされます。 次に、証明書が有効期間内にあり、失効していないことを確認します。 次に、Kerberos プロバイダーは、証明書に KDC 認証が存在し、KDC の証明書に一覧表示されているサブジェクト代替名が、ユーザーが認証するドメイン名と一致することを確認します。 この条件に合格すると、Kerberos は TGT を lsass に返します。ここで、TGT はキャッシュされ、後続のサービス チケット要求に使用されます。 |
注
オンプレミス ドメインがMicrosoft Entra IDとフェデレーションされている可能性があります。 PIN/Bio on Windows Hello for Business正常にプロビジョニングされると、Windows Hello for Business (PIN/Bio) サインインの今後のログインは、Microsoft Entra IDに対して直接認証されます。PRT を取得し、前に説明したように Kerberos を取得するための DC に対する認証 (LOS から DC が使用可能な場合) を取得します。 AD FS フェデレーションは、Enterprise PRT 呼び出しがクライアントから発信された場合にのみ使用されます。 フェデレーションから "Enterprise PRT" を取得するには、デバイスのライトバックを有効にする必要があります。
クラウド Kerberos 信頼を使用したハイブリッド参加認証のMicrosoft Entra
| フェーズ | 説明 |
|---|---|
| A | ユーザーがロック画面を閉じると認証が開始され、Winlogon がトリガーされ、Windows Hello for Business資格情報プロバイダーが表示されます。 ユーザーは、Windows Hello ジェスチャ (PIN または生体認証) を提供します。 資格情報プロバイダーは、これらの資格情報をパッケージし、Winlogon に返します。 Winlogon は、収集された資格情報を lsass に渡します。 Lsass は、ポリシー Windows Hello for Businessクエリして、クラウド Kerberos 信頼が有効になっている場合にチェックします。 クラウド Kerberos 信頼が有効になっている場合、Lsass は収集した資格情報をクラウド認証セキュリティ サポート プロバイダー (クラウド AP) に渡します。 クラウド AP は、Microsoft Entra IDから nonce を要求します。 Microsoft Entra IDは nonce を返します。 |
| B | クラウド AP は、ユーザーの秘密キーを使用して nonce に署名し、署名された nonce をMicrosoft Entra IDに返します。 |
| C | Microsoft Entra IDは、ユーザーの安全に登録された公開キーを使用して、署名された nonce を nonce 署名に対して検証します。 署名を検証した後、Microsoft Entra ID返された署名付き nonce を検証します。 nonce を検証した後、Microsoft Entra IDは、デバイスのトランスポート キーに暗号化されたセッション キーを持つ PRT を作成し、Microsoft Entra Kerberos から Partial TGT を作成し、それらを Cloud AP に返します。 |
| D | クラウド AP は、セッション キーを使用して暗号化された PRT を受け取ります。 デバイスのプライベート トランスポート キーを使用して、Cloud AP はセッション キーを復号化し、デバイスの TPM (使用可能な場合) を使用してセッション キーを保護します。 クラウド AP は lsass に成功した認証応答を返します。 Lsass は PRT と部分 TGT をキャッシュします。 |
| E | lsass でホストされる Kerberos セキュリティ サポート プロバイダーは、Windows Hello for Business キーのメタデータを使用して、ユーザーのドメインのヒントを取得します。 このヒントを使用して、プロバイダーは DClocator サービスを使用してドメイン コントローラーを見つけます。 アクティブなドメイン コントローラーを見つけた後、Kerberos プロバイダーは、Microsoft Entra IDから受信した部分的な TGT をドメイン コントローラーに送信します。 部分的な TGT にはユーザー SID のみが含まれており、Kerberos Microsoft Entra署名されています。 ドメイン コントローラーは、部分的な TGT が有効であることを確認します。 成功すると、KDC は TGT をクライアントに返します。 Kerberos は TGT を lsass に返します。ここで、TGT はキャッシュされ、後続のサービス チケット要求に使用されます。 Lsass は、成功認証について Winlogon に通知します。 Winlogon はログオン セッションを作成し、ユーザーのプロファイルを読み込み、explorer.exe を開始します。 |
キーを使用したハイブリッド参加認証のMicrosoft Entra
| フェーズ | 説明 |
|---|---|
| A | ユーザーがロック画面を閉じると認証が開始され、Winlogon がトリガーされ、Windows Hello for Business資格情報プロバイダーが表示されます。 ユーザーは、Windows Hello ジェスチャ (PIN または生体認証) を提供します。 資格情報プロバイダーは、これらの資格情報をパッケージし、Winlogon に返します。 Winlogon は、収集された資格情報を lsass に渡します。 Lsass は、収集された資格情報を Kerberos セキュリティ サポート プロバイダーに渡します。 Kerberos プロバイダーは、ドメインに参加しているワークステーションからドメイン ヒントを取得して、ユーザーのドメイン コントローラーを見つけます。 |
| B | Kerberos プロバイダーは、署名された事前認証データとユーザーの公開キー (自己署名証明書の形式) を、ドメイン コントローラーで実行されているキー配布センター (KDC) サービスにKERB_AS_REQの形式で送信します。 ドメイン コントローラーは、証明書が自己署名証明書であると判断します。 KERB_AS_REQに含まれる証明書から公開キーを取得し、Active Directory で公開キーを検索します。 認証要求の UPN が Active Directory に登録されている UPN と一致し、Active Directory の公開キーを使用して署名された事前認証データを検証します。 成功すると、KDC は証明書をKERB_AS_REPに含む TGT をクライアントに返します。 |
| C | Kerberos プロバイダーは、ドメイン コントローラーからの応答を信頼できることを確認します。 まず、KDC 証明書が、デバイスによって信頼されているルート証明書にチェーンされます。 次に、証明書が有効期間内にあり、失効していないことを確認します。 次に、Kerberos プロバイダーは、証明書に KDC 認証が存在し、KDC の証明書に一覧表示されているサブジェクト代替名が、ユーザーが認証するドメイン名と一致することを確認します。 |
| D | この条件に合格すると、Kerberos は TGT を lsass に返します。ここで、TGT はキャッシュされ、後続のサービス チケット要求に使用されます。 |
| E | Lsass は、成功認証について Winlogon に通知します。 Winlogon はログオン セッションを作成し、ユーザーのプロファイルを読み込み、explorer.exe を開始します。 |
| F | Windows がユーザーのデスクトップを読み込む間、lsass は収集した資格情報をクラウド認証セキュリティ サポート プロバイダー (クラウド AP プロバイダーと呼ばれます) に渡します。 クラウド AP プロバイダーは、Microsoft Entra IDから nonce を要求します。 Microsoft Entra IDは nonce を返します。 |
| G | クラウド AP プロバイダーは、ユーザーの秘密キーを使用して nonce に署名し、署名された nonce をMicrosoft Entra IDに返します。 Microsoft Entra IDは、ユーザーの安全に登録された公開キーを使用して、署名された nonce を nonce 署名に対して検証します。 署名を検証した後、Microsoft Entra ID返された署名付き nonce を検証します。 nonce を検証した後、Microsoft Entra IDは、デバイスのトランスポート キーに暗号化されたセッション キーを持つ PRT を作成し、それをクラウド AP プロバイダーに返します。 クラウド AP プロバイダーは、セッション キーを使用して暗号化された PRT を受け取ります。 デバイスのプライベート トランスポート キーを使用して、クラウド AP プロバイダーはセッション キーを復号化し、デバイスの TPM を使用してセッション キーを保護します。 クラウド AP プロバイダーは、lsass に正常な認証応答を返します。 Lsass は PRT をキャッシュします。 |
重要
上記のデプロイ モデルでは、新しくプロビジョニングされたユーザーは、(a) Microsoft Entra Connect が公開キーをオンプレミスの Active Directoryに正常に同期し、(b) デバイスが初めてドメイン コントローラーに視線を持つまで、Windows Hello for Businessを使用してサインインできません。
証明書を使用したハイブリッド参加認証のMicrosoft Entra
| フェーズ | 説明 |
|---|---|
| A | ユーザーがロック画面を閉じると認証が開始され、Winlogon がトリガーされ、Windows Hello for Business資格情報プロバイダーが表示されます。 ユーザーは、Windows Hello ジェスチャ (PIN または生体認証) を提供します。 資格情報プロバイダーは、これらの資格情報をパッケージし、Winlogon に返します。 Winlogon は、収集された資格情報を lsass に渡します。 Lsass は、収集された資格情報を Kerberos セキュリティ サポート プロバイダーに渡します。 Kerberos プロバイダーは、ドメインに参加しているワークステーションからドメイン ヒントを取得して、ユーザーのドメイン コントローラーを見つけます。 |
| B | Kerberos プロバイダーは、署名された事前認証データと、公開キーを含むユーザーの証明書を、ドメイン コントローラーで実行されているキー配布センター (KDC) サービスにKERB_AS_REQの形式で送信します。 ドメイン コントローラーは、証明書が自己署名証明書ではないと判断します。 ドメイン コントローラーは、信頼されたルート証明書への証明書チェーンが、その有効期間内にあり、認証に使用でき、取り消されていないことを確認します。 KERB_AS_REQに含まれる証明書から公開キーと UPN を取得し、Active Directory で UPN を検索します。 証明書の公開キーを使用して、署名された事前認証データを検証します。 成功すると、KDC は証明書をKERB_AS_REPに含む TGT をクライアントに返します。 |
| C | Kerberos プロバイダーは、ドメイン コントローラーからの応答を信頼できることを確認します。 まず、KDC 証明書が、デバイスによって信頼されているルート証明書にチェーンされます。 次に、証明書が有効期間内にあり、失効していないことを確認します。 次に、Kerberos プロバイダーは、証明書に KDC 認証が存在し、KDC の証明書に一覧表示されているサブジェクト代替名が、ユーザーが認証するドメイン名と一致することを確認します。 |
| D | この条件に合格すると、Kerberos は TGT を lsass に返します。ここで、TGT はキャッシュされ、後続のサービス チケット要求に使用されます。 |
| E | Lsass は、成功認証について Winlogon に通知します。 Winlogon はログオン セッションを作成し、ユーザーのプロファイルを読み込み、explorer.exe を開始します。 |
| F | Windows がユーザーのデスクトップを読み込む間、lsass は収集した資格情報をクラウド認証セキュリティ サポート プロバイダー (クラウド AP プロバイダーと呼ばれます) に渡します。 クラウド AP プロバイダーは、Microsoft Entra IDから nonce を要求します。 Microsoft Entra IDは nonce を返します。 |
| G | クラウド AP プロバイダーは、ユーザーの秘密キーを使用して nonce に署名し、署名された nonce をMicrosoft Entra IDに返します。 Microsoft Entra IDは、ユーザーの安全に登録された公開キーを使用して、署名された nonce を nonce 署名に対して検証します。 署名を検証した後、Microsoft Entra ID返された署名付き nonce を検証します。 nonce を検証した後、Microsoft Entra IDは、デバイスのトランスポート キーに暗号化されたセッション キーを持つ PRT を作成し、それをクラウド AP プロバイダーに返します。 クラウド AP プロバイダーは、セッション キーを使用して暗号化された PRT を受け取ります。 デバイスのプライベート トランスポート キーを使用して、クラウド AP プロバイダーはセッション キーを復号化し、デバイスの TPM を使用してセッション キーを保護します。 クラウド AP プロバイダーは、lsass に正常な認証応答を返します。 Lsass は PRT をキャッシュします。 |
重要
上記のデプロイ モデルでは、新しくプロビジョニングされたユーザーは、デバイスがドメイン コントローラーに対して視線を持っていない限り、Windows Hello for Businessを使用してサインインできません。