こんにちは。
前回の投稿から少し時間が空いてしまいました。。。
最近、Windows Hello for Business を構成したいというお声を時々耳にするため、 タイトルにもある通り、Windows Hello for Businessのハイブリッドキー信頼の構成について学習もかねて検証環境で構成してみた結果をまとめてみました。
記載の内容はあくまで自身の検証結果及び公式ページの情報をもとに記載している内容になりますので、ご参考までにご愛読いただけますようお願いいたします。
なお、誤っている点や更新があったものがありましたら、ご教示いただけますと幸いです。
Windows Hello for Businessの展開の種類
Windows Hello for Businessの展開モデルは以下の３通りがあります。
ハイブリッドモデルはいずれにしてもAzureAD参加が必要となります。
最近では、端末をAzureAD参加している企業も多くなってきているので、一般的には、クラウドまたはハイブリッドでの構成が一般的ではないかと思っています。
2022/5：追記
クラウドトラストという展開モデルがプレビューされましたのでこちらで試しています。よろしければご参照ください。
パスワードレス認証によるSSO② Windows Hello for Business Cloud Trust (クラウド信頼)を試してみた
ずいぶんと更新期間が空いてしまいましたが、タイトルの通り、現時点(2022/05)でプレビュー中となっているWindows Hello for Businessのクラウド信頼について試してみました。
現在、パスワードレス認証の導入を積極的に導入することを検討されている企業様も増えてきていることもあって今回の本機能については、まさに期待に応えられる機能なのではないかなと思っています。
信頼の種類
上述で記載した通り、信頼の方式には2種類あります。
要は、認証サーバーが認証処理を行う際、認証用キー(厳密には自己証明書)を利用するのか、証明書認証を行うのかの違いになるかと存じます。
以下Microsoft社のサポートブログにもわかりやすい説明が公開されているのでこちらを参考にしていただければと思います。
Windows Hello for Businessの構成解説
ここからは信頼の種類についてです。
信頼の種類には、キー信頼と証明書信頼の二種類があります。
キー信頼
キー信頼はその名前の通り、認証用キーを使って認証処理を行うものになります。
厳密にいうと、生体認証やPINコード入力にて端末にサインインした後、ADにAS(Authentication Service)リクエストするわけですが、その際に自己証明書も一緒に送付します。
送付された自己証明書に対し、ADは公開鍵で署名を検証します。
署名して問題がなければ、チケットを発行することになります。
少しばかり整理すると以下のようになります。
■ADへの認証
① AS(Authentication Service)リクエスト
⇒TPMなどに保存された秘密キーを使ってKerberos事前認証データに署名します。この署名済み認証データと公開キー(自己証明書)を送信します。
※事前認証データとはKerberos認証の仕組みとしてあるものでASリクエストを初回にすると、ADはタイムスタンプをクライアントに送付します。クライアントはアカウント名とパスワードHASHで暗号化したタイムスタンプを送付することで事前に対象のアカウントが正当なものかを確認するものです。
②事前認証データを検証し、TGT(Ticket Granting Ticket)発行
⇒2016以降のドメインコントローラーが 署名済み認証データと公開キー(自己証明書) を受け取ると、この証明書が自己証明書であることが判別されます。
この証明書から公開キーを取得し、AD内で公開キーを検索します。
公開キーと認証要求のUPNがADに登録されているUPNと一致し、検証に成功するとTGTを発行します。
※この公開キーがADのどこに登録されているのか、後ほど解説します。
③サービスチケットの要求
⇒以降、サービスチケットの要求を行うわけですが、ここでも細かな確認動作を行っています。
証明書に記載されているサブジェクト代替名がユーザーの認証先のドメイン名と一致していることやADでKDC認証が対応しているかなどを確認していると思われます。
一方でAzureADへの認証は以下の通りとなります。
■AzureADへの認証
①トークン（Nonce)の要求
⇒nonceとは、number used onceの略。ワンタイムトークンと呼ばれます。
②署名したNonceをAzureADに送付
⇒ TPMなどに保存された秘密キーを使ってnonceに署名し、 AzureADに返します。
③公開鍵でリクエストの中身を確認
⇒AzureADに保存されている公開鍵を使って署名されたリクエストを検証します。
④PRTを発行
⇒ 公開鍵で検証した結果、問題ないことを確認後、 PRT(Primary Refresh Token) を発行します。
証明書信頼
一方で証明書信頼とは、認証用キーを使ったキー信頼とは反対に、証明書を使って認証を行う仕組みです。
ADFSを利用している環境であったり、DCが2016以降のものが用意できない場合は、この証明書信頼を利用することになるかと存じます。
本ブログでは、今後脱ADFSが推奨されていることもあり、ハイブリッドキー信頼によるWindows Hello for Businessを使って展開及び解説していきたいと思います。
ハイブリッドキー信頼の前提条件
ざっと前提条件を確認してみましょう。
- ドメイン/フォレスト機能レベル：Win2008R2以上
- ドメインコントローラー：2016以降
- PKI(CA基盤)2012以降
- AzureADとADが存在すること
- パススルーORパスワードハッシュ同期が必要
- 多要素認証の設定が必要
- AzureADへのデバイスの登録が必要(AzureADPremiumP1)
ここからは上記洗い出した前提条件で特に注意すべきものを説明します。
ドメインコントローラー：2016以降
公開鍵のマッピング及びキーによるAD認証を利用するためには、2016以降のDCでないといけません。その場合、大企業様の場合ですと、ユーザー数もかなり多いため、複数のDCを用意されているかと思います。ですが、もしDC2016以降のDCが少数しか用意されていない環境で上記のハイブリッドキー信頼の展開を行ってしまうとどういうことが起きるか、以下MS社にもシナリオが公開されておりますが、結論、DC2016にかなりの負荷がかかることになります。
Windows Server 2016 以降のドメインコントローラー (Windows Hello for Business の展開用) の適切な数の計画
Windows Server 2016 以降のドメインコントローラーが、すべての公開キー信頼認証の100% を処理しています。 ただし、パスワード認証の10% も処理しています。 どうしてでしょうか? この動作が発生するのは、ドメインコントローラー 2-10 はパスワードと証明書の信頼認証のみをサポートしているためです。Windows Server 2016 以上のドメインコントローラーのみが、公開キーの信頼認証をサポートしています。 Windows Server 2016 以上のドメインコントローラーでも、パスワードと証明書の信頼認証を認証する方法が理解されています。また、これらのクライアントの認証の負荷はそのまま共有されます。
上記を簡単にまとめてみると、DCが2016以前のバージョンのものを利用している環境において、以下のように 例えば500人のクライアントがAD認証を行っている場合に、ハイブリッドキー信頼を展開する際をシナリオに検討してみます。
※なお、認証要求は均等に各ADへ分散できることを前提として考えてみます。
通常は、パスワードを使って認証を行いますが、 この時、前提条件より認証要求は均等に各ADに割り振られており、負荷が分散されているかと存じます。
では、次に、ハイブリッドキー信頼を展開し、キーによる認証を利用した場合、どうなるのか。
前提条件に述べた通り、キーによる認証は2016以降のDCでしか利用できません。したがって、キー認証がDC2016に集中してしまいます。
さらにキー認証しているからと言って、従来のパスワード認証の負荷が減るというわけではありません。
認証要求を負荷分散する前提条件ではありますが、キー信頼はDC2016でしかできないため、DC2016ですべて処理し、かつパスワード認証は前提条件に基づいた場合、すべてのDCで分散するため、パスワード認証も処理しなければなりません。
上記から、ハイブリッドキー信頼を展開する場合は、まず現環境のDCを一度見直す必要もあるということがわかります。
Windows Server 2019 キー信頼認証の問題
※Windows Server 2019 既知の問題※
これまでDC2016以降とは述べてきましたが、実は2019には既知の問題があり、通常ではキーによる認証処理を行うことができません。こちらはMicrosoft社の公開情報にも記載がある通りです。
Windows Server 2019 のキー信頼認証に問題がありました。 問題を解決するには、「 KB4487044」を参照してください。
https://docs.microsoft.com/ja-jp/windows/security/identity-protection/hello-for-business/hello-adequate-domain-controllers
どういうことかというと、実際に上記リンクに飛んでみてもらえばわかりますが、修正パッチを適用しないとキーによる認証処理ができないことに加え、以下のようなエラーが表示される可能性があります。
Addresses an issue that causes the Windows Hello for Business Hybrid Key Trust deployment sign-in to fail if Windows 2019 Server domain controllers (DC) are used for authentication. The error is, "That option is temporarily unavailable. For now, please use a different method to sign in”. If Active Directory (AD) activity tracing is enabled, a Local Security Authority Subsystem Service (LSASS) exception may occur in the Windows 2019 DC when processing a user’s sign in.
https://support.microsoft.com/en-us/topic/february-12-2019-kb4487044-os-build-17763-316-6502eb5d-dde8-6902-e149-27ef359ed616
これは、端末にサインインする際、Windows Hello for Businessによるサインインが失敗することが書かれています。
実際にエラー画面が表示されることを確認したのですが、以下のようにサインインができないエラーが表示されます。
また、ファイルサーバーなどのリソースにもアクセスができません。
ですので、上記修正パッチを適用しておく必要があるので注意がいります。
PKI(CA基盤)2012以降
キー信頼の場合、デバイスに証明書を配布する必要はないですが、より高性能なKerberosKDCテンプレートを構成するために証明機関から証明書を構成する必要があります。
ドメイン コントローラー証明書テンプレート
クライアントはドメイン コントローラーを信頼する必要があります。このためには、各ドメイン コントローラーに Kerberos 認証の証明書があることを確実にするのが最適です。 ドメイン コントローラーに証明書をインストールすることでキー配布センター (KDC) が有効になり、ドメインの他のメンバーに身元が証明されます。 これにより、ドメイン外部の信頼のルート、つまりエンタープライズ証明機関がクライアントに提供されます。
デバイスの登録が必要
ハイブリッドキー信頼のシナリオにおいては、デバイスをAzureADとオンプレミスADどちらも参加(登録)する必要があります。つまり、ハイブリッドAzureAD参加を行う必要があります。
やってみる
準備環境
以下環境を準備し、構成してみました。
こちらは既にインストール済みであることとし、次の設定作業に移ります。
※Windows Server 2019には修正パッチも適用済み。
- Windows Server 2019 (ActiveDirectory/AADC/ADCAインストール)
- Windows10 1908 2台
- AzureADテナント(AzureADPremium P1ライセンス必要)
設定作業
では、手始めにハイブリッドAzureAD参加を完了させます。
ちなみに、今回はGPOによるハイブリッドAzureAD参加を行いますが、SCCMまたはMECMを保有されている場合は、共同管理という方法でハイブリッドAzureAD参加を行う必要があるので、以下ご参照まで。
SCCM共同管理によるHybrid Azure AD Joinedの構成
今後、 Intune と Configuration Manager を組み合わせた Microsoft Endpoint Manager としてサポートしてくれるそうです。
なのでここではSCCMを利用している環境で正しくハイブリッドAzureADJoin構成を行う手順を記載します。※間違っているところがあれば、ご指摘ください。
では、AADCの構成ウィザードを起動し、「デバイスオプションの構成」を選択します。
「次へ」を選択し、「ハイブリッドAzureAD参加の構成」にチェックを入れ、次へをクリックします。
「Windows10以降のドメインに参加しているデバイス」にチェックを入れ、「次へ」をクリックします。
「追加」をクリックし、エンタープライズ管理者の権限を持つアカウントの認証情報を入力します。
入力後、「次へ」をクリックして構成を完了させます。
SCPが構成されていることを確認します。
ハイブリッドAzureAD参加を構成するためのGPOを作成します。
これでハイブリッドAzureAD参加の構成は完了です。
一旦、AADCを同期し、ハイブリッドAzureAD参加として端末をセットアップしておきましょう。
上記が完了したら、続いてAADCディレクトリ同期の設定を引き続き行います。
以下キーのマッピングを行うためにAADCのサービスアカウントを[KeyAdmins]のメンバーに追加します。
Windows Hello for Businessの公開鍵をAzureADに同期するために、msDS-KeyCredentialLink 属性の読み取り、書き込み権限を付与するためです。
これでAADCの設定は完了です。
では次に新しいKerberos認証の証明書テンプレートを作成し、DCに展開します。
「証明書テンプレート」-「新規作成」を選択し、テンプレートを作成します。
「結果的な変更を表示」のチェックボックスをオフにし、証明機関、証明書の受信者を以下のように変更します。
テンプレート名と有効期間、更新期間を入力します。
エンタープライズCAの要件を満たす期間を指定する必要があるため、以下の公開情報を参考に期間を任意で設定します。
証明書の有効期限を変更する - Windows Server | Microsoft Docs
「サブジェクト名」タブで以下のように構成します。
「暗号化」タブを選択し、プロバイダーのカテゴリは「キー格納プロバイダー」、アルゴリズムは「RSA」、最小キーサイズは「2048」を選択します。
これで新しい証明書テンプレートの作成は完了です。
次に、作成した証明書の優先設定と公開設定を行うかつ、旧証明書は削除(無効化）を行います。これはMicrosoft社としても推奨されています。
先ほど作成したテンプレートを右クリックし、「優先するテンプレート」タブから「追加」をクリックします。
以下のテンプレートを追加し、「OK」をクリックします。
次にこの証明書テンプレートを公開します。
「証明書テンプレート」を右クリックし「新規作成」-「発行する証明書テンプレート」をクリックします。
対象のテンプレートを選択し、OKをクリックします。
テンプレートの発行ができれば、以下不要となった旧テンプレートを削除します。
以下の公開情報からと「ドメインコントローラの認証」と「Kerberos認証」のテンプレートも削除するように記載がされているため、削除します。
ハイブリッド Windows Hello for Business の構成 - 公開キー基盤 (PKI) - Microsoft 365 Security | Microsoft Docs
旧テンプレートの削除が完了後、新しく作成し、公開した証明書テンプレートをADに配布します。以下記載の通り、新しく作成したテンプレートは自動的には認識しないため、GPOによる自動登録構成もしくは、手動による証明書の要求が必要となります。
証明書の自動登録に対するドメイン コントローラーの構成
ドメイン コントローラーは、ドメイン コントローラー証明書テンプレートから自動的に証明書を要求します。 ただし、新しい証明書テンプレートや、証明書テンプレートの優先する構成を認識しません。 新しい証明書テンプレートと証明書テンプレートの優先する構成を認識するドメイン コントローラー証明書の自動登録と更新を続行するには、証明書の自動登録のグループ ポリシー オブジェクトを作成および構成し、ドメイン コントローラー OU にリンクします
手順に記載の通り、[Domain Controlles]OUにリンクさせる形で以下GPOを作成します。
規定では、「ドメインコントローラー」という旧テンプレートが配布されています。
Windows Hello for Businessのセットアップ
では、構成が一通り完了したところで、Windows Hello for Businessのセットアップをします。
Windows Hello for Businessをプロビジョニングするためには端末にサインイン後にセットアップを要求するようにポリシーを適用しておく必要があります。
実はこれ、少し以前本ブログでも触れましたが、AzureAD参加したデバイスであれば、規定でWindows Hello for Businessのセットアップを要求するポリシーになります。
AzureAD参加デバイスへサインインしたときに表示されるWindows Hello for Business設定を無効化する
これを表示させる、させないの設定は、MEM(Intune)から行うことができ、大きく2通りの手順があります。
①組織全体にWindows Hello for Businessを適用する
⇒前提としてAzureAD参加とIntuneの自動登録構成が必要です
組織全体に適用されるため、全ユーザーに対して適用されます。
②Intuneデバイス構成プロファイルでWindows Hello for Businessを適用する
⇒Intune登録が必要です。こちらもAzureAD参加またはハイブリッドAzureAD参加する端末に適用するには、Intuneの自動登録構成を設定しておきましょう。
この方法はグループ単位で適用先を制御できることがメリットになります。
以前は Windows Hello for Businessの セットアップが不要であったため、強制的に無効化しましたが、今回は逆で有効化する必要があります。
加えて、本シナリオではIntuneへデバイスを登録していないハイブリッドAzureAD参加環境を想定していましたので、Intuneにデバイスが登録されていない以上、Intuneによるポリシーが適用できません。
ではどうするかというと、グループポリシー(GPO)で設定します。
以下画面の通り、Windows Hello for BusinessのGPOを適用することでサインイン時にセットアップを要求することが可能となります。
上記GPOを設定後、ハイブリッドAzureAD参加している端末にサインインしてみます。すると、下記のようにセットアップが求められたので画面に従って設定を進めます。
※もし、下記の画面が何度試しても要求されない場合は、まずはGPOが適用されていることを確認してください。
次にハイブリッドAzureAD参加できているかを確認してください。
ハイブリッドキー信頼におけるWindows Hello for Businessの セットアップはAzureADにデバイスが参加していることが前提条件となっております。
後におまけとして、確認すべきポイントを記載しておりますのでご参照ください。
こちら2段階認証が必要となるので認証媒体を用意する必要があります。
多要素認証がセットアップできればPINコードを入力します。
※検証環境のためPINコードになってますが、生体認証のセットアップも可能かと思います。
セットアップが完了したら端末にサインインします。
これでWindows Hello for Businessのセットアップは終了です。
公開鍵のライトバック
Windows Hello for Business のセットアップが無事に終わり、利用ができるようになったと思いますが、そうではありません。実際は本項目の確認をすることが一番重要となってきます。
Windows Hello for Business のセットアップが完了すると、AzureADに公開鍵が登録されます。 この時、ユーザーの「個人」ストアに 以下自己証明書が生成されます。
実は、ADにはこの自己証明書を認証時に認証キーと合わせて送付していることになります。
では、AzureADには公開鍵が登録されましたが、ADにはどうやって登録されるのかというと、AADCのライトバック機能にて公開鍵がAzureADからADの「msDS-KeyCredentialLink」属性に格納されます。
この公開鍵を使ってADは認証要求に対し、署名することで成り立っているのだと思います。
結果
上記の構成を行うことでADへの認証もエラーが表示されず、サインインおよび、リソース(共有ファイルなど)への接続も問題ないことが確認できました。
これで、パスワードいらずのサインインでAzureADとADどちらのリソースにもSSOできる構成ととなりました。
おまけ
Windows Hello for Businessのセットアップが要求されない場合
Windows Hello for Businessのプロビジョニングはイベントログの「User Device Registration」という項目に記録されます。
以下画面にわかる通り、前提条件があることがわかります。
これを満たす必要があるので参考にしてもらえればと思います。
※例えばリモートデスクトップ経由でアクセスしていないか等
多要素認証によるAzureAD 条件付きアクセスの適用
少し、以前のブログでお話したのですが、Windows Hello for Businessでは多要素認証による要件を満たしているため、AzureADの条件付きアクセスのアクセス許可設定にある「多要素認証を要求する」を適用していても、ユーザーから見るとシームレスにアクセス許可されている動作となります。
これはすでに対象の端末にPRTトークンが発行されており、このトークンの中にユーザー情報に加えて多要素認証の情報も格納されており、サインイン時にこのPRTトークンを提示しているため、アクセスが許可されているのです。
過去の参考ブログです。
Windows Hello for Businessを設定した端末で AzureAD 条件付きアクセスの多要素認証(AzureMFA)によるアクセス許可を適用する
操作上、多要素認証によるログイン操作をスキップできました。
ただ、実際はWindows Hello for Businessにより、多要素認証としてログインしているから、しっかりアクセス許可を付与されているのです。
AzureADのサインインログにも出力されています。
Defender for Identity のタイムラインでも証明書によるログインと表示されている？
今回準備したADにはDefender for Identity(旧称：Azure ATP)のセンサーをインストールして監視を行っているのですが、タイムラインを確認したところ、以下のように証明書でログオンしたと記載がありました。これは自己証明書のことを指しているのかはわかっておらずです。
最後に
一応、Windows Hello for Businessはパスワードいらずの認証といわれておりますが、 あくまでWindows Hello for Businessはセキュリティ向上とパスワード入力機会を削減するというメリットがあるだけで、パスワード自体がなくなったわけではありません。
オンプレミスADやAzureADへの認証(条件付きアクセスなどの認証制御が適用されていない環境)はパスワードでもログインできるため、万が一、パスワード情報が盗まれた場合は誰でもログインできてしまいます。
なのでこれまで通り、継続して定期的にパスワード変更はやっていかないといけません。
AADCパスワードライトバック＋パスワードセルフサービスパスワードリセット（SSPR）機能であれば、仮に不正なアクセスなどが発覚した場合でもユーザー自身がパスワードをリセット（変更）できるため、有効化しておく方が良いかもしれません。
※ありがたいことに上記はTwitterでアドバイスをいただき、記載をさせていただきました。大変参考になりました。。。
なお、以下は端末のメモリ内に記憶されている資格情報を悪意のあるツールで取得した場合の参考画面です。これは端末内に残ってしまったログオン情報から搾取したNTMLハッシュ値になります。
さらに、Overpass-the-Hash と呼ばれる一般的な手法を使用すれば、収集された NTLM ハッシュを使用して、TGTを取得することができてしまいます。このことからもWindows Hello for Businessを設定したからといって完全に安全・安心・セキュリティ対策OKということにはならないことがわかります。
※このような対策は別のソリューションの導入（Defender for Identityでの検知/Windows Defender Credential Guard）などであったり、現行システムの運用の見直し（ローカルAdministratorsに所属させないなど）が必要になるのではないかなと思います。
上記は今後勉強していきたいと思います。。。
それではまた。
