Microsoft SecurityAdvent Calendar 2024

NTTデータ先端技術

FIDO2 で Windows にサインインする（ADドメイン編）

Last updated at 2025-01-06Posted at 2024-12-02

はじめに

本記事では、FIDO2 セキュリティキーを使用して Active Directory ドメインアカウントで Windows にサインインする方法を紹介します。

本件を検証する前に、色々と下調べしたのですが、ローカルアカウントしかサポートしていない等の情報が多く引っ掛かって、成功例は見当たらず、そもそも無理なんじゃないかと諦めかけていました。

ですが、以下の公開情報を見つけて、頑張ればなんとかできるんじゃないかと思い、トライしてみました。

公開情報：FIDO2 セキュリティキーを使用して Microsoft Entra ID による Windows 10 および 11 デバイスへのサインインを有効にする
https://learn.microsoft.com/ja-jp/entra/identity/authentication/howto-authentication-passwordless-security-key-windows?wt.mc_id=mvp_407731

本記事のターゲット

「FIDO2 セキュリティキーを使用して Windows にサインイン」を有効化する方法は、いくつか用意されていますが、本記事では ④ のグループポリシーを使った手順を紹介します。
① Microsoft Intune で有効にする
② ターゲットとなる Microsoft Intune のデプロイ
③ プロビジョニングパッケージを使用して有効にする
④ グループポリシーで有効にする (Microsoft Entra ハイブリッド参加済みデバイスのみ)

公開情報：Windows サインインのセキュリティキーを有効にする
https://learn.microsoft.com/ja-jp/entra/identity/authentication/howto-authentication-passwordless-security-key-windows?wt.mc_id=mvp_407731#enable-security-keys-for-windows-sign-in

お知らせ
① のパターンは、別途記事を投稿してありますので、併せて参照ください。
FIDO2 で Windows にサインインする（Entra Join 編）
https://qiita.com/carol0226/private/3933199bfd512e31f060

本構成の注意事項

以下の公開情報に書かれている通り、FIDO2 でサインインした場合にサポートされていない操作があります。

① Windows Server Active Directory Domain Services (AD DS) 参加済みの (オンプレミス専用デバイスの) デプロイ。
② セキュリティキーを使用した リモートデスクトッププロトコル (RDP)、仮想デスクトップインフラストラクチャ (VDI)、Citrix のシナリオ。
③ セキュリティキーを使用した S/MIME。
④ セキュリティキーを使用した [別のユーザーとして実行] 。
⑤ セキュリティキーを使用したサーバーへのログイン。

公開情報：サポートされていないシナリオ
https://learn.microsoft.com/ja-jp/entra/identity/authentication/howto-authentication-passwordless-security-key-on-premises?wt.mc_id=mvp_407731#unsupported-scenarios

② の問題の回避策
上記のうち、② の RDP については、Webauthn リダイレクトを使う事で対処することができます。
構成方法は、以下の記事にまとめてあります。

前提事項

Active Directory ドメインに参加した PC を、FIDO2 対応にするには、Microsoft Entra Hybrid 参加済みにする必要があります。そのほか、いくつかの要件を満たす必要があります。
以下の公開情報の要件の表で、右側の列が該当します。

公開情報：要件
https://learn.microsoft.com/ja-jp/entra/identity/authentication/howto-authentication-passwordless-security-key-windows?wt.mc_id=mvp_407731#requirements

上記の公開情報の要件を元にした結果、実施すべき内容を以下の ①～④ としてまとめました。

① ドメインコントローラー

要件の欄には、以下の記載があります。
完全にパッチが適用された Windows Server 2016/2019 ドメインコントローラー

具体的には FAQ に以下の情報があるので、これら KB のインストールが必要なようです。
なお、私は Windows Server 2022 で検証して動作しているので、それ以降の最新 OS であればサポートしていそうです。

公開情報：パッチを適用すべき DC の数に関する推奨事項はありますか
https://learn.microsoft.com/ja-jp/entra/identity/authentication/howto-authentication-passwordless-faqs?wt.mc_id=mvp_407731#whats-the-recommendation-on-the-number-of-dcs-that-should-be-patched
（公開情報より抜粋）
Windows Server 2016 または 2019 ドメインコントローラーで、次のパッチが適用されていることを確認します。必要に応じて、Windows Update を実行してインストールします。
Windows Server 2016 - KB4534307
Windows Server 2019 - KB4534321

② Microsoft Entra Hybrid 参加済みデバイス

以下の記事を参考に Microsoft Entra Hybrid 参加済み（Microsoft Entra Hybrid Joined）となったデバイスがあれば、要件が満たされます。

Microsoft Entra ハイブリッド参加（旧HAADJ）を構成してみた
https://qiita.com/carol0226/items/7c16c4813e2b54a76789
※Windows 10 バージョン 2004 以降が必要です。

Microsoft Entra Hybrid Join とは
オンプレミスの AD ドメインを、Microsoft Entra Connect で同期を構成します。
さらに、Hybrid Join の構成を行うことでコンピューターオブジェクトもテナントに同期されるようになります。Hybrid Join が構成された環境でクライアント PC は、"AD ドメイン" と "Microsoft Entra ID" に同時に参加（Join）した状態になります。これを Hybrid Join と言います。

Hybrid Join で構成された PC へのサインインは、引き続きオンプレミスドメインのユーザーアカウントでサインインしますが、 FIDO2 セキュリティキーの紐づけは、テナント側で行う必要があります。

そのため、FIDO2 サインインが可能になるのは、テナント側に同期されたハイブリッドユーザーのみとなります。

③ Microsoft Entra ハイブリッド認証管理モジュール

初めて構成する際に公開情報を読んだだけだと、この要件を満たす方法が判りづらいかもしれません。
具体的には、Microsoft Entra Kerberos 認証の構成を行うことで対応できます。

以下の私の記事で解説していますので、この作業を行ってください。

Microsoft Entra Kerberos 認証を構成しオンプレミスへ SSO する
https://qiita.com/carol0226/items/a52a54ff63c19fa957e6

公開情報：オンプレミスのリソースへの SSO
https://learn.microsoft.com/ja-jp/entra/identity/authentication/howto-authentication-passwordless-security-key-on-premises?wt.mc_id=mvp_407731

④ テナントで FIDO2 セキュリティーキーを有効化

以下の記事で紹介している内容でテナントで FIDO2 セキュリティーキーが利用できるように構成され、オンプレミスから同期されたハイブリッドユーザーに FIDO2 セキュリティキーが割り当てられている必要があります。

Microsoft Entra ID の認証を FIDO2 で出来るようにする
https://qiita.com/carol0226/private/8586291079d941f62f7b

構成手順

前提条件を満たしていれば、① GPO または ② Intune の構成によって、FIDO2 での OS サインインがサポートされるようになります。

どちらで構成するのか、判断材料
クライアントがオンプレミスのみであったり、Intune を採用していない場合は、① GPO で構成します。
すでに Microsoft Entra Join デバイスも併用しており、Intune が利用可能な環境の場合は、② Intune で構成が良さそうです。

① GPO で構成する

FIDO2 サインインを行いたいコンピューターオブジェクトが含まれた OU が用意されている前提です。
※本記事では、Client-PC という OU を想定した手順となっています。

ドメインコントローラーで グループポリシーの管理 を開きます。
　
任意の OU に対して このドメインに GPO を作成し、このコンテナーにリンクする を選択します。

　
任意の GPO 名を指定して OK を押します。（今回は、FIDO2 を命名）

　
作成された GPO を右クリックして編集を選択します。

　
以下の設定を開きます。
コンピューターの構成 － ポリシー － 管理用テンプレート － システム－ログオン
　セキュリティキーでのサインインを有効にする

　
設定を有効にして OK を押します。

　
以下のように表示されれば OK です。

公開情報：グループポリシーを使用して有効にする
https://learn.microsoft.com/ja-jp/entra/identity/authentication/howto-authentication-passwordless-security-key-windows?wt.mc_id=mvp_407731#enable-with-group-policy

② Microsoft Intune で有効にする

なお、公開情報の要件を読む限りは、GPO の代わりに Intune で構成することも可能なようです。

公開情報：Microsoft Intune で有効にする
https://learn.microsoft.com/ja-jp/entra/identity/authentication/howto-authentication-passwordless-security-key-windows?wt.mc_id=mvp_407731#enable-with-microsoft-intune

以下の記事では、Microsoft Entra ID を使って Windows にサインインする方法を記載した記事です。
すでに、この構成を行っている場合は、Intune で設定が行われているため、GPO の設定は割愛できると思われます。

FIDO2 で Windows にサインインする（Entra ID 編）
https://qiita.com/carol0226/items/3933199bfd512e31f060

動作確認

FIDO2 セキュリティキーを使用してサインインする

前章で GPO または Intune の構成を変更したあと、AD ドメインに参加したデバイスを再起動します。
　
ポリシー設定が PC にうまく反映されると、緑下線の サインインオプション を押した際に、以下の通り赤枠（セキュリティキー）のアイコンが追加されます。
※設定の反映にタイムラグがありえますが、私は 10 分後くらいに反映されてました。セキュリティキーのアイコンが出ない場合は、再起動してください。

いくらやっても、FIDO2 セキュリティキーのアイコンが出ない場合
前提条件が満たせていないと、アイコンは出ません。
手順の見直しと、以下の方法でも、構成をチェックしてください。
dsregcmd /status のコマンドを実行して、Hybrid Joined の構成になっているのか？
gpresult /h を使って、ポリシーがクライアントに適用されているか？
このほか、最終章にトラブルシューティングへのリンクを掲載しているので、そちらも確認してください。

以下の記事でも紹介されていますが、VPN 接続してから、ドメインコントローラーに接続するようなケースでは、利用中にセキュリティキーのアイコンが消えることもあります。dsregcmd /join で再度 Join することで復活できます。
https://jpazureid.github.io/blog/azure-active-directory/fq-device-based-ca-for-remote-work/#質問-4-ハイブリッド-Azure-AD-参加のデバイス登録処理はどのような流れで行われますか？-VPN-経由でも動作しますか？

3．以下の画面が FIDO2 で OS にサインインできる画面です。
ここで、FIDO2 セキュリティキーを挿入して PIN を入力します。
※アカウント名を入力しなくても良いんですね・・・（キー内に ID も保存されている）

4．正しい PIN が入力されたら、以下の画面が表示されます。

5．FIDO2 セキュリティキーに指タッチします。
下図は、私が検証した YubiKey です。この時にランプが点灯しています。

6．これで以下の画面に遷移されてドメインログオンが完了します。

以上のように、あらかじめ FIDO2 セキュリティキーにハイブリッドユーザーのアカウントが登録されていれば、パスワードレスでサインインすることが可能になります。

公開情報：FIDO2 セキュリティキーを使用してサインインする
https://learn.microsoft.com/ja-jp/entra/identity/authentication/howto-authentication-passwordless-security-key-windows?wt.mc_id=mvp_407731#sign-in-with-fido2-security-key

サインイン直後の状態確認

dsregcmd /status コマンドを実行して、以下の値を確認できれば良いと思います。
こうなっていれば、テナントからチケットを正常に取得できています。

項目名	ステータス
AzureAdJoined	YES
DomainJoined	YES
AzureAdPrt	YES
OnPremTgt	YES
CloudTgt	YES

dsregcmd /status の実行結果を見るにはココをクリック

PS C:\Users\testnogu> dsregcmd /status

+----------------------------------------------------------------------+
| Device State                                                         |
+----------------------------------------------------------------------+

             AzureAdJoined : YES
          EnterpriseJoined : NO
              DomainJoined : YES
                DomainName : AVD
           Virtual Desktop : NOT SET
               Device Name : SurfacePro6.avd.server-on.net

+----------------------------------------------------------------------+
| Device Details                                                       |
+----------------------------------------------------------------------+

                  DeviceId : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
                Thumbprint : XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 DeviceCertificateValidity : [ 2024-12-17 22:32:46.000 UTC -- 2034-12-17 23:02:46.000 UTC ]
            KeyContainerId : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
               KeyProvider : Microsoft Platform Crypto Provider
              TpmProtected : YES
          DeviceAuthStatus : SUCCESS

+----------------------------------------------------------------------+
| Tenant Details                                                       |
+----------------------------------------------------------------------+

                TenantName : Qiita
+----------------------------------------------------------------------+
| User State                                                           |
+----------------------------------------------------------------------+

                    NgcSet : YES
                  NgcKeyId : {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}
                  CanReset : DestructiveOnly
           WorkplaceJoined : NO
             WamDefaultSet : YES
       WamDefaultAuthority : organizations
              WamDefaultId : https://login.microsoft.com
            WamDefaultGUID : {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx} (AzureAd)

+----------------------------------------------------------------------+
| SSO State                                                            |
+----------------------------------------------------------------------+

                AzureAdPrt : YES
      AzureAdPrtUpdateTime : 2024-12-29 05:10:28.000 UTC
      AzureAdPrtExpiryTime : 2025-01-12 05:10:34.000 UTC
       AzureAdPrtAuthority : https://login.microsoftonline.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
             EnterprisePrt : NO
    EnterprisePrtAuthority :
                 OnPremTgt : YES
                  CloudTgt : YES
         KerbTopLevelNames : .windows.net,.windows.net:1433,.windows.net:3342,.azure.net,.azure.net:1433,.azure.net:3342

+----------------------------------------------------------------------+
| Diagnostic Data                                                      |
+----------------------------------------------------------------------+

        AadRecoveryEnabled : NO
    Executing Account Name : AVD\testnogu, testnogu@carol226.com
               KeySignTest : PASSED

        DisplayNameUpdated : YES
          OsVersionUpdated : YES
           HostNameUpdated : NO

      Last HostName Update : FAIL
          Client ErrorCode : 0x801c0083
               Client Time : 2024-12-28 19:00:50.000 UTC
                Request ID : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
               Server Time : 2024-12-28T19:00:51.7897386Z
               HTTP Status : 400
          Server ErrorCode : directory_error
       Server ErrorSubcode : error_hostname_duplicate
            Server Message : Value of unique property 'HostNames' is already in use by 'Device' with ObjectId 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'.

+----------------------------------------------------------------------+
| IE Proxy Config for Current User                                     |
+----------------------------------------------------------------------+

      Auto Detect Settings : YES
    Auto-Configuration URL :
         Proxy Server List :
         Proxy Bypass List :

+----------------------------------------------------------------------+
| WinHttp Default Proxy Config                                         |
+----------------------------------------------------------------------+

               Access Type : DIRECT

参考：サインイン直後の Kerberos チケットの状態は？
サインイン直後は、以下のように Kerberos チケットは取得出来ていないように見えますが、これで問題ありません。キャッシュログオンすれば、初めはこうなります。

それでも、そのあと GPO 更新やファイルサーバーへのアクセスがおこなわれれば、以下のように取得されたチケットが表示されます。

※klist コマンドは PC で取得された kerberos チケットの状態を確認するコマンドです。

ドメインリソースへの SSO でのアクセス確認

正しく構成されていれば、サインインしたあとに、ドメイン環境のファイルサーバー（ドメコンの SYSVOL も可）にアクセスしたり、gpupdate コマンドでポリシーを更新したりすると、正常に動作していることを確認できます。

正常な場合の振る舞い
ドメイン内のファイル共有にアクセスした場合に、認証なしで表示されます。

GPO も正常に更新できます。

構成に問題があった場合の振る舞い
ドメイン内のファイル共有にアクセスした際に、以下のように認証窓が開いてしまいます。

チケットの状態をみても、いつまで経っても Kerberos チケットが取得されません。

GPO の更新も失敗します。

原因
私も、この状況に陥ってハマっていたことがあるのですが、テストに使ったユーザーが Domain Admins に所属していることが原因でした。

上記 FAQ の URL
https://learn.microsoft.com/ja-jp/entra/identity/authentication/howto-authentication-passwordless-faqs?wt.mc_id=mvp_407731#fido2-security-key-sign-in-isnt-working-for-my-domain-admin-or-other-high-privilege-accounts-why

対処策①
テストに使うユーザーから、Domain Admins の権限を剥奪して、再度テストを行ったら、問題なく SSO でアクセスできるようになります。

対処策②
Domain Admins でも SSO でアクセスできるようにするための方法が、FAQ に対策が記載されているのですが、これが非常に判りづらくて、どう対処したら良いのか判りませんでしたが、以下に紹介する対処手順を参考に作業してもらえれば OK です。

色々調査してみましたが、以下の構成を行うことを示唆しているようです。
誤) Microsoft Entra Kerberos Computer オブジェクト
正) AzureADKerberos コンピューターオブジェクト

対処策②の手順

Active Direcotry ユーザーとコンピューター(ADUC) を開き 拡張機能 を有効にしておきます。（黄枠の箇所がチェック ON )
※これで、属性エディターのタブが表示されるようになります。

　
Domain Controllers コンテナーを開き、AzureADKerberos というコンピューターオブジェクトを右クリックして プロパティ を開きます。

　
属性エディター タブを選択して msDS-NeverRevealGroup という項目を選択して編集を押します。

　
この属性はこのグループに所属しているユーザーは、Microsoft Entra Kerberos の対象外となってしまいます。今回は、Domain Admins と Administrators を削除します（再度追加すれば元に戻ります）

　
削除したら OK を押して終了します。

私の環境では、上記の属性編集を行ったあと、該当のユーザー環境からファイル共有へアクセスしてみたら、すぐに参照できるように改善しました。

さいごに

今回の検証は、結構達成感がありました。
実際に動作させてみるまでは、どうやってオンプレドメインの資格情報を FIDO2 内に入れるんだろう・・と疑問に思っていたのですが、結果クラウド経由で仕込んでおいて、Microsoft Entra Kerberos 認証を使ってドメインログオンしてるんだな・・・ということが判った気がします。

これをやりたいと思っても、巷の情報で、中々成功事例を見つけられなかったのですが、本記事を参考にチャレンジしてみていただければ幸いです。

Next Step

注意事項の欄にも書きましたが、FIDO2 でログオンした場合、RDP 接続には SSO できないため、パスワードを使用する必要があります。

RDP 接続もパスワードレス化するには、以下の記事を参考に構成してみてください。

この構成は、本記事（FIDO2 ドメインログオン）との相性抜群ですので是非セットで構成しましょう。

参考

以下の公開情報で、FAQ やトラブルシューティングが掲載されています。
これは、構築後に動作確認した後のタイミングで良いので、目を通しておくとその後の運用時に無駄にハマらずに済むかもしれません。

参考情報
上記の FAQ のうち、以下の件について、コマンド実行時の結果を掲載しておきます。

私の正常動作している環境で取得したキャプチャですので、これと比べて相違がないかどうかの判断に利用できるかもしれません。

公開情報：FIDO2 セキュリティキーを使用してサインインし、資格情報のプロンプトを受け取った後、ユーザーが my NTLM ネットワークリソースへの SSO を取得できない

nltest /dsgetdc:[dc name] /keylist /kdc
https://learn.microsoft.com/ja-jp/entra/identity/authentication/howto-authentication-passwordless-troubleshoot?wt.mc_id=mvp_407731#users-are-unable-to-get-sso-to-my-ntlm-network-resource-after-signing-in-with-a-fido2-security-key-and-receiving-a-credential-prompt

※上記の緑枠は、ドメイン名に置き換えてください。