Windows Hello for Business ハイブリッド キー信頼構成で実現する、Azure AD Join端末からオンプレADへのシングルサインオン

2018年10月19日

このエントリではTechSummit 2017で実施した展示の技術解説を行おうと思います。といっても展示するシステム自体、テクサミ1週間前くらいから急ピッチで構築して「とりあえず動いた…。もう触らんとこ…」であり仕組みまで深堀出来てません。そんな浅い理解ですが、ナレッジはナレッジなので展開し共有します。

目次

  • Windows Helloとは?
  • Windows Hello for Businessとは?
  • (余談)PIN・パスワード・生体認証の安全度考察
  • Windows Hello for Business ハイブリッド構成のパターン
  • Windows Hello for Business ハイブリッド キー信頼構成の構築手順
  • なぜWindows Hello for Business ハイブリッドでAzure AD Join端末からオンプレADにSSOできるのか

Windows Helloとは?

パスワードの代わりに、PIN/生体認証でWindows端末にログインする仕組みです。

f:id:teraco:20171229143302j:plain
f:id:teraco:20171229143304j:plain

Windows Hello for Businessとは?

ざっくりいうと、ポリシーを利用してPIN/生体認証でのログインを"強制する事が出来る"機能です。"強制する事が出来る"というのがポイント。

“ユーザーの希望に応じてPIN/生体認証でWindowsログインできるようにする"という要件を満たすだけならWindows Helloでよいのですが、Windows Helloの欠点はユーザー自身が設定しないとPIN/生体認証でログインできない事です。

情シス視点で

  • ポリシーを強化し、パスワードを複雑にしたい
  • それだけだとパスワードをメモして付箋で貼り付けるユーザーが続出する
  • なので、PIN/生体認証を利用してパスワードを利用せずWindowsログインできるようにしたい

という狙いの場合、単純にWindows Hello環境を整えてユーザーに設定手順書を渡しても「あ～、情シスから設定してくれってメールきたんだけど、よく分からないし指紋登録とかヤだから、今まで通りパスワードでログインしてるよ」となるのは容易に想像できます。

Windows Hello for Businessなら、グループポリシーでパスワードの複雑性を定義するのと同じ感覚で、ドメイン参加後にPIN/生体認証の登録画面に飛ばす事が出来ます。

具体的には以下の動画をご覧ください。

Windows Hello for Business: What’s New in 2017 – BRK2076 – YouTube

実はこのPIN/生体認証登録はスキップする事が出来ますが、登録しない場合、PCにログインするたびにこの画面が表示されるので、半強制的にPIN/生体情報を登録させることができます。

Windows Hello for Businsssのセキュリティ

もう一つのメリットとして、Windows Hello for Businessではクライアント⇔サーバー間の通信がPKI(公開鍵基盤)のロジックに変わります。

説明しますと、普通のWindows Helloでは、PCログイン時にPIN/生体認証を使用してログインするものの、その後は、PC内に保存されているパスワードハッシュをADに向かって投げつけるので、ログオンの瞬間以外は普通のパスワードログインと変わりません。

f:id:teraco:20171229143304j:plain

一方、Windows Hello for BusinessはクライアントPC ⇔ ドメインコントローラー(あるいはAzureAD)間の認証が、公開鍵基盤認証の仕組みで認証されるようになります。クライアントPC視点でドメインコントローラー(あるいはAzureAD)が認証局として動作します(するようです)。よって途中のパケットをキャプチャされても、もちろんパスワードは分かりませんし、公開鍵基盤認証の仕組み上、成りすましログインも出来ません。

f:id:teraco:20171229152247j:plain

すごい！！！！！！！

…しかし、この説明を聞いて「うお～すげ～！Windows Hello for Business導入するしかね～！」と思った人はどれくらいいるでしょうか?

MS側は"Windows Hello for Businessの一番のメリットはセキュリティだ！"とか言ってるのですが「パスワードハッシュが社内ネットワークを流れてるの、前々から問題だと思ってたんだよね～」という意識高い情シス担当者は少ないので、実際にこの点をメリットとして宣伝するのは、かえって混乱を招くんじゃないかな…と思います。現場の情シスさん、そんな高度な問題より、付箋にパスワードを書くようなユーザーに悩んでると思うんですよね。しかも、Windows Hello for Businessを構成後も、PCの内部にNTLMハッシュを持つので、Pass-the-Hash攻撃などは普通にやられるようです。

f:id:teraco:20171229144336j:plain

ひとまず、このエントリに限っては、パスワードハッシュがネットワークを流れずセキュア、というのは忘れてもらってよいかなと思います。一方Windows Hello for Businessは公開鍵基盤認証であるというのは、覚えておいてください。

Windows Hello for Businsss：よくありそうな質問

  • Q：Windows Hello for Businessを展開すればユーザーにパスワードを教えなくてもいい?
    • A：×誤りです。初回セットアップ時にADのユーザー名/パスワードが必要です。
  • Q：Windows Hello for Businessを展開すればPass the Hash攻撃されても大丈夫?
    • A：×誤りです。端末にパスワード情報が保存されるので、盗まれます。
  • Q：Windows Hello for Businessを展開すればネットワークにパスワードハッシュが流れない?
    • A：×誤りです。サーバーにNTLM認証を求められた場合、キャッシュされたパスワードハッシュを提供します。
  • Q：PINでのログインを禁止して、生体情報だけを許可する事は出来ないの?
    • A：×出来ないようです。システム的にはPINも生体情報も同じくらいセキュアと扱われています。

Windows Hello for Business ハイブリッド構成のパターン

さて、Windows Hello for Business ハイブリッドを構成するわけですが、4つの構成方法が提示されています。

Windows Hello for Business (Windows 10) | Microsoft Docs

  • Key trust Group Policy managed
  • Certificate trust Mixed managed
  • Key trust Modern managed
  • Certificate trust Modern managed

判断ポイントは2ポイントで

  • キー信頼モデルか、証明書信頼モデルか
  • グループポリシーでの管理か、Intuneポリシーでの管理か

です。今回はPOCだったので管理手法は別として、キー信頼モデルか、証明書信頼モデルかを検討しました。結論としては、両者に性能的な違いはなく導入する環境や使用予定のコンポーネントによって構成を決定すればよいとドキュメントに書いてあったので、比較的構築が楽なキー信頼モデルを採用しました。

Windows Hello for Business ハイブリッド キー信頼構成の構築手順

以下のマニュアルを見ながら構築しました。11/5時点では全て英語となります。証明書信頼モデルのマニュアルは日本語なのに…。

Hybrid Key Trust Deployment (Windows Hello for Business) | Microsoft Docs

簡単に手順を書きますと

  1. Hybrid Azure AD Join環境の構築
  2. 証明書テンプレートの入れ替え、KeyAdminの同期
  3. 各種ポリシーの設定

の3段階に分かれるかな、と思います。時間がかかるのはHybrid Azure AD Join環境の構築かと思いますが、こちらは割と世の中にナレッジがあるのでいけるんじゃないでしょうか。証明書テンプレートの入れ替え移行は手順通りに進めました。あまりやったことがない手順なのでビビりながら。

なぜWindows Hello for Business ハイブリッドでAzure AD Join端末からオンプレADにSSOできるのか

システム構成図はこんな感じです。

f:id:teraco:20171229153606j:plain

Windows Hello for Business ハイブリッドの手順の一環で、Hybrid Azure AD Join デバイス構成を構築します。

How to configure hybrid Azure Active Directory joined devices | Microsoft Docs

この構成では、Azure AD JoinしたWindowsPCの情報がオンプレミスのActive Directoryにコピーされます。具体的には以下のPC02です。

f:id:teraco:20171229155107j:plain

さて、Windows Hello for Businessは公開鍵証明書基盤の仕組みを利用して認証を行います。PC端末とAzure ADがクライアントと認証局の関係となり公開鍵証明書基盤方式で鍵をやり取り。最終的にクライアントPCが認証局から発行された認証トークン(?)をPC内部に持つと思われます。

仮のこのPCがオンプレミスのADに参加していた場合、Azure AD Joinした場合と同じデバイス情報がオンプレミスのADに作成されると思われます(これ、確認したい)。そしてオンプレミスADと公開鍵証明書基盤方式で鍵をやり取りし、最終的にクライアントPCが認証局から発行された認証トークンは、Azure AD Joinした時に発行されるものと同一となります。

f:id:teraco:20171229155443j:plain

以上より、Azure ADから発行された認証トークンを持ってオンプレADにログインしようとした場合、その認証トークンはオンプレADでも使えるものなので、オンプレADにシングルサインオンが可能となります。オンプレミスのActive DirectoryとクラウドのAzure ADが同一の認証局となることで、クライアントPCがAzureADからもらった認証トークンはオンプレADでも使用できるものとなります。

…という理解です。恥ずかしながら上記動作はあくまで推測です。ネットワークキャプチャして通信暗号化解除して追えばわかると思いますが、そこまでの元気はありませんでした。。。

ただ、公式ドキュメントにAzure AD Joinしたデバイス情報がAADCでオンプレADにコピーされるまで、オンプレADへのSSOは出来ない、と書いてあるので、Hybrid Azure AD Joined構成でコピーされるオブジェクト情報が鍵を握っているのは間違いないと思います。実際、AADCでデバイス情報同期される前にオンプレADにアクセスした場合、シングルサインオンできなかったので。

ここらへん、ほんま自信なくてイベログにもそれっぽいログが出てなかったので、状況証拠からの推測でしかないんですよね…。ドヤったブログタイトルなのにすいません。

そして…課題

課題1. 初回ログイン後、一度サインオンすると、オンプレリソースへのシングルサインオンが出来ない。

なので使い物になりませんwww PCへの初回ログインや、別ユーザーで一度ログイン後、再ログインするとシングルサインオン出来るのですが…。これは僕の構成が間違っていたのか、そもそもバグなのか分かりません。初回ログイン時にシングルサインオン出来ているので、普通に考えると2回目以降もいけそうな気がするんですけどね。

おそらく、初回ログオン時はAzure ADからうまくトークン(?)を取れて、そこでオンプレリソースにSSO出来るのでしょうが、2回目以降のログインでは下手にPCのキャッシュを使ってWindowsにはログインできるが、PKI認証用の情報は消えてしまっている & 取得していないのでSSO出来ないのか、と思います。

課題2. オンプレADへのWindows Hello for Businessポリシーテンプレートが見つからない

本来的にはオンプレADにGPO適用し、オンプレADにデバイス登録されたPCにWindows Hello for businessを強制するようにポリシーを適用したかったのですが、テクサミ時点では管理ポリシーが見つからず、Azure AD Joinした端末にしかWindows Hello for businessを適用できませんでした。ここらへん、最近のyoutubeでは"オンプレもポリシー適用できるぜ！"って言ってるので、今は大丈夫かもしれません。

参考にした情報

docs.microsoft.com
www.youtube.com
channel9.msdn.com

www.slideshare.net

最後に

Windows Hello for Business ハイブリッドはまだ情報も少なく、本番導入時にどこでハマるか分からないので、新しい情報は積極的にキャッチしてアップデートしていけたらと思います。

Posted by tera