Cloud Kerberos 信頼デプロイ ガイド
この記事では、次Windows Hello for Business適用される機能またはシナリオについて説明します。
- 展開の種類:
- 信頼の種類:
- 結合の種類:Microsoft Entra参加、ハイブリッド参加ハイブリッド参加の両方にシングル サインオンしますMicrosoft Entra
要件
デプロイを開始する前に、「Windows Hello for Businessデプロイの計画」の記事で説明されている要件を確認してください。
開始する前に、次の要件が満たされていることを確認してください。
重要
クラウド Kerberos 信頼デプロイ モデルを実装する場合は、ユーザーがWindows Hello for Businessで認証する各 Active Directory サイトに適切な数の読み取り/書き込みドメイン コントローラーがあることを確認する必要があります。 詳細については、「 Active Directory の容量計画」を参照してください。
展開の手順
前提条件が満たされたら、Windows Hello for Businessのデプロイは次の手順で構成されます。
Kerberos Microsoft Entra展開する
パスワードレス セキュリティ キー サインイン用のオンプレミス SSO を既にデプロイしている場合は、Microsoft Entra Kerberos は既にorganizationにデプロイされています。 Windows Hello for Businessをサポートするために既存のMicrosoft Entra Kerberos デプロイを再デプロイまたは変更する必要はありません。また、「Windows Hello for Business ポリシー設定の構成」セクションに進むことができます。
Kerberos Microsoft Entra展開していない場合は、パスワードレス セキュリティ キーのサインインを有効にするに関するドキュメントの手順に従ってください。 このページには、Microsoft Entra Kerberos PowerShell モジュールをインストールして使用する方法に関する情報が含まれています。 モジュールを使用して、クラウド Kerberos 信頼を使用するドメインのMicrosoft Entra Kerberos サーバー オブジェクトWindows Hello for Business作成します。
Microsoft Entra Kerberos とクラウド Kerberos の信頼認証
Microsoft Entra Kerberos が Active Directory ドメインで有効になっている場合、AzureADKerberos コンピューター オブジェクトがドメインに作成されます。 このオブジェクト:
読み取り専用ドメイン コントローラー (RODC) オブジェクトとして表示されますが、物理サーバーには関連付けられません
Active Directory ドメインの TGT を生成するためにのみ、Microsoft Entra IDによって使用されます
注
RODC に使用される同様の規則と制限は、AzureADKerberos コンピューター オブジェクトに適用されます。 たとえば、民営化された組み込みセキュリティ グループの直接または間接的なメンバーであるユーザーは、クラウド Kerberos 信頼を使用できません。
Kerberos Microsoft Entra がクラウド Kerberos 信頼Windows Hello for Business使用する方法の詳細については、「Windows Hello for Business認証の技術的な詳細」を参照してください。
注
AzureADKerberos コンピューター オブジェクトに構成されている既定の パスワード レプリケーション ポリシー では、クラウド Kerberos 信頼キーまたは FIDO2 セキュリティ キーを使用してオンプレミス リソースに高い特権アカウントを署名することはできません。
Microsoft Entra IDから Active Directory への攻撃ベクトルの可能性があるため、コンピューター オブジェクトCN=AzureADKerberos,OU=Domain Controllers,<domain-DN>のパスワード レプリケーション ポリシーを緩和して、これらのアカウントのブロックを解除することはお勧めしません。
Windows Hello for Business のポリシー設定の構成
Microsoft Entra Kerberos オブジェクトを設定した後、Windows Hello for business を有効にして、クラウド Kerberos 信頼を使用するように構成する必要があります。 クラウド Kerberos 信頼モデルでWindows Hello for Businessを構成するには、次の 2 つのポリシー設定が必要です。
もう 1 つのオプションですが、推奨されるポリシー設定は次のとおりです。
重要
[オンプレミス認証に証明書を使用する] ポリシーが有効になっている場合、証明書の信頼はクラウド Kerberos 信頼よりも優先されます。 クラウド Kerberos 信頼を有効にするマシンに、このポリシーが 構成されていないことを確認します。
次の手順では、Microsoft Intuneまたはグループ ポリシー (GPO) を使用してデバイスを構成する方法について説明します。
Intune/CSP
Gpo注
Windows Hello for Businessを構成するためにMicrosoft Intuneによって提供されるさまざまなオプションについては、「Microsoft Intuneを使用してWindows Hello for Businessを構成する」の記事を参照してください。
Intuneテナント全体のポリシーが有効になっていて、ニーズに合わせて構成されている場合は、[Prem 認証でクラウド信頼を使用する] ポリシー設定を有効にする必要があります。それ以外の場合は、両方の設定を構成する必要があります。
Microsoft Intuneを使用してデバイスを構成するには、設定カタログ ポリシーを作成し、次の設定を使用します。
| カテゴリ | 設定名 | 値 |
|---|---|---|
| Windows Hello for Business | 仕事にパスポートを使用する | true |
| Windows Hello for Business | オンプレミス認証にクラウド信頼を使用する | 有効 |
| Windows Hello for Business | セキュリティ デバイスが必要 | true |
構成するデバイスまたはユーザーをメンバーとして含むグループにポリシーを割り当てます。
または、PassportForWork CSP でカスタム ポリシーを使用してデバイスを構成することもできます。
| 設定 |
|---|
- OMA-URI:./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/UsePassportForWork- データ型: bool- 値： True |
- OMA-URI:./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/UseCloudTrustForOnPremAuth- データ型: bool- 値： True |
- OMA-URI:./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/RequireSecurityDevice- データ型: bool- 値： True |
グループ ポリシーとIntuneの両方を使用して構成Windows Hello for Business展開する場合、グループ ポリシー設定が優先され、Intune設定は無視されます。 ポリシーの競合の詳細については、「複数の ポリシー ソースからのポリシーの競合」を参照してください。
その他のポリシー設定を構成して、Windows Hello for Businessの動作を制御できます。 詳細については、「ポリシー設定のWindows Hello for Business」を参照してください。
Windows Hello for Businessに登録する
Windows Hello for Businessプロビジョニング プロセスは、前提条件のチェックに合格した場合、ユーザーがサインインした直後に開始されます。 クラウド Kerberos 信頼Windows Hello for Business、クラウド Kerberos 信頼がポリシーによって有効になっている場合Microsoft Entraハイブリッド参加済みデバイスの前提条件のチェックが追加されます。
前提条件のチェックの状態を確認するには、[アプリケーションとサービス ログ>] Microsoft>Windows の [ユーザー デバイス登録] 管理者ログを表示します。
この情報は、コンソールの コマンドを dsregcmd.exe /status 使用して入手することもできます。 詳細については、「 dsregcmd」を参照してください。
クラウド Kerberos 信頼の前提条件チェックは、プロビジョニングの開始を許可する前に、ユーザーが部分的な TGT を持っているかどうかを検出します。 このチェックの目的は、ユーザーのドメインとテナントMicrosoft Entra Kerberos が設定されているかどうかを検証することです。 Kerberos Microsoft Entra設定されている場合、ユーザーはサインイン中に部分的な TGT を受け取り、他のロック解除方法の 1 つを使用します。 このチェックには、Yes、No、Not Tested の 3 つの状態があります。 [テストされていない] 状態は、クラウド Kerberos 信頼がポリシーによって強制されていない場合、またはデバイスが参加Microsoft Entra場合に報告されます。
注
クラウド Kerberos 信頼の前提条件チェックは、参加しているデバイスMicrosoft Entra行われません。 Microsoft Entra Kerberos がプロビジョニングされていない場合、Microsoft Entra参加済みデバイスのユーザーはサインインできますが、Active Directory によってセキュリティ保護されたオンプレミス リソースへの SSO は使用されません。
ユーザー エクスペリエンス
ユーザーがサインインすると、Windows Hello for Business登録プロセスが開始されます。
- デバイスが生体認証をサポートしている場合、ユーザーは生体認証ジェスチャを設定するように求められます。 このジェスチャを使用して、デバイスのロックを解除し、Windows Hello for Businessを必要とするリソースに対する認証を行うことができます。 ユーザーが生体認証ジェスチャを設定したくない場合は、この手順をスキップできます
- ユーザーは、organization アカウントでWindows Helloを使用するように求められます。 ユーザーが [OK] を選択する
- プロビジョニング フローは、登録の多要素認証部分に進みます。 プロビジョニングは、構成済みの MFA 形式でユーザーに積極的に連絡しようとしていることをユーザーに通知します。 プロビジョニング プロセスは、認証が成功、失敗、またはタイムアウトするまで続行されません。MFA が失敗またはタイムアウトするとエラーが発生し、ユーザーに再試行を求められます
- MFA に成功した場合は、プロビジョニング フローは、ユーザーに PIN の作成と確認を求めます。 この PIN は、デバイスで構成されている PIN の複雑さのポリシーを確認する必要があります
- プロビジョニングの残りの部分では、Windows Hello for Business がユーザーの非対称キー ペアを要求します。TPM の非対称キー ペアをお勧めします (またはポリシーで明示的に設定されている場合は必須です)。 キー ペアが取得されると、Windows は IdP と通信して公開キーを登録します。 キーの登録が完了すると、プロビジョニングWindows Hello for Business、PIN を使用してサインインできることをユーザーに通知します。 ユーザーはプロビジョニング アプリケーションを閉じ、デスクトップにアクセスできます
ユーザーがクラウド Kerberos 信頼で登録を完了すると、Windows Hello ジェスチャをサインインにすぐに使用できます。 Microsoft Entraハイブリッド参加済みデバイスでは、最初に PIN を使用するには DC への視線が必要です。 ユーザーが DC でサインインまたはロック解除すると、キャッシュされたサインインを、視線やネットワーク接続なしで後続のロック解除に使用できます。
登録後、Microsoft Entra Connect はユーザーのキーを Microsoft Entra ID から Active Directory に同期します。
シーケンス図
プロビジョニング フローを理解するには、デバイスの参加と認証の種類に基づいて、次のシーケンス図を確認します。
- マネージド認証を使用したMicrosoft Entra参加済みデバイスのプロビジョニング
- フェデレーション認証を使用したMicrosoft Entra参加済みデバイスのプロビジョニング
- マネージド認証を使用したクラウド Kerberos 信頼デプロイ モデルでのプロビジョニング
認証フローについて理解を深めるために、次のシーケンス図を確認します。
キー信頼デプロイ モデルからクラウド Kerberos 信頼への移行
キー信頼モデルを使用してWindows Hello for Businessをデプロイし、クラウド Kerberos 信頼モデルに移行する場合は、次の手順に従います。
- ハイブリッド環境Microsoft Entra Kerberos を設定する
- グループ ポリシーまたはIntuneを使用してクラウド Kerberos 信頼を有効にする
- 参加済みデバイスMicrosoft Entra場合は、Windows Hello for Businessを使用してサインアウトしてデバイスにサインインします。
注
ハイブリッド参加済みデバイスMicrosoft Entra場合、ユーザーは DC に視線を向けながら、新しい資格情報で最初のサインインを実行する必要があります。
証明書信頼デプロイ モデルからクラウド Kerberos 信頼への移行
重要
証明書信頼のデプロイからクラウド Kerberos 信頼デプロイへの 直接 の移行パスはありません。 Windows Hello コンテナーは、クラウド Kerberos 信頼に移行する前に削除する必要があります。
証明書信頼モデルを使用してWindows Hello for Businessをデプロイし、クラウド Kerberos 信頼モデルを使用する場合は、次の手順に従ってWindows Hello for Businessを再デプロイする必要があります。
- 証明書信頼ポリシーを無効にする
- グループ ポリシーまたはIntuneを使用してクラウド Kerberos 信頼を有効にする
- ユーザー コンテキストから コマンド
certutil.exe -deletehellocontainerを使用して証明書信頼資格情報を削除する - サインアウトしてサインインし直す
- 任意の方法を使用してWindows Hello for Businessをプロビジョニングする
注
ハイブリッド参加済みデバイスMicrosoft Entra場合、ユーザーは DC への視線を持ちながら、新しい資格情報で最初のサインインを実行する必要があります。
よく寄せられる質問
クラウド Kerberos 信頼Windows Hello for Business関してよく寄せられる質問の一覧については、「よく寄せられる質問Windows Hello for Business」を参照してください。
サポートされていないシナリオ
クラウド Kerberos 信頼を使用Windows Hello for Business、次のシナリオはサポートされていません。
- 指定された資格情報を使用した RDP/VDI シナリオ (RDP/VDI はリモート資格情報ガードで使用できます。証明書がWindows Hello for Business コンテナーに登録されている場合)
- 実行にクラウド Kerberos 信頼を使用する
- DC 接続で以前にサインインせずに、Microsoft Entra ハイブリッド参加済みデバイスでクラウド Kerberos 信頼を使用してサインインする
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示