パスワードレス認証、憧れますよね。
最近ではIPAの資料に取り入れられていて、ますます大衆的な存在になってきています。
パスワードレスの細かい話は置いといて、この記事では、 Microsoft 365環境で、Entra joinをした端末のWindows Hello for Businessの認証プロセスでは何が起きてるの？ という話です。
基本的にMicrosoft Learnを少し砕くだけです。 Learnの和訳読むよりかは得るものが多いとイイナと思います。
先に参考資料です。
learn.microsoft.com jpazureid.github.io
サインインについて
さて、ここからが本題です。 本記事では前述したとおり下記状況のサインインの認証プロセスについて記載します。 この話では、どのタイミングでPRTトークンを取得しているのか？ また、PRTトークンを取得するためには何のキーで認証していて、何が担保されているのか・ ということを明らかにしていきます。 一部、自分の知識や想像での補完を行います。わかるように書きますので、ご自身で検証しながら読み、間違いがあれば訂正いただけると助かります。
Entra Joinは、Windows端末のサポートされているデバイス登録方法3種のうち、Entra のみにデバイスを登録する手法です。 （他に、オンプレADのみ、オンプレAD + EntraIDのHybridEntraIDJoinが有ります） ですので、この場合には認証ではEntra IDとの通信が主となります。
サインインフェーズについて
フェーズA.認証の実施～PRT取得開始まで
本フェーズでは認証を開始するところから始まり、PRTトークンの取得要求を行うところまでが表現されています。
①ユーザーはロック画面（時間が表示されたり、サインインに関する情報が無いページ）にて、何かしらのシグナルを送信し、クレデンシャルプロバイダを表示させます。 ※ちなみに、このクレデンシャルプロバイダ(資格情報プロバイダー)やログオンUI(LogonUI.exe)はWinlogonが呼び出してくれているみたいです。Winlogonはログオン・ログオフのもろもろの調整をしてクレみたいデス。タクトを振ってくれてるイメージですかね。
②「パスワード」ではなく、顔や指紋、PINなどでログインを行います。 ★認証ポイント：本人の特徴を持っていること
③クレデンシャルプロバイダは認証に関連する資格情報をまとめて、Winlogonに渡します。
④Winlogonは受け取った資格情報のまとめをLsassに渡します。 ※Lsassは「ローカルセキュリティ機関サブシステムサービス」と呼ばれるWindowsのセキュリティシステムコンポーネントです。実際に認証を通す際に利用されていた利、その後のユーザーのポリシーや認可範囲などの制御でも利用されます。
⑤Lsassは資格情報まとめをクラウドAPプロバイダーに渡します。
一旦ここまで。
フェーズB
①資格情報まとめを受け取ったクラウドAPプロバイダーはEntraIDに対してnonceを要求します。 nonceは、認証セッションを識別するランダムな文字列です。以降このnonceを用いて「正しいデバイスであることの証明」を行います。
②Entra IDはnonceを返します。
③CloudAPプロバイダーは秘密キーを用いてnonceに署名します。
ここでの署名は恐らくデバイスキーが利用されており、これからPRT取得リクエストを送るデバイスが正しいデバイスであることを事前に認証していることと思います。
ここでの認証はユーザーIDキーによる認証でした。
ユーザー ID キーは、サービスに対するユーザーの認証に使用されます。 たとえば、nonce に署名して秘密キーを所有していることを証明します。これは、登録済みの公開キーに対応します。 Active Directory、Microsoft Entra ID、または Microsoft アカウントを持つユーザーには、自分のアカウントにキーが関連付けられています。 このキーを使用して、ドメイン コントローラー (Active Directory シナリオ)、またはクラウド (Microsoft Entra ID および MSA シナリオ) に認証することで、Windows デバイスにサインインできます。
★認証ポイント：認識されたデバイスを所持していること
③署名されたnonceをEntra IDに渡します。
フェーズC
①Entra ID は受け取ったnonceの秘密鍵が正しい物か確かめるため、対になる公開鍵で検証します。これはデバイス登録時にEntra ID上に登録されています。
②真正デバイスである確認が取れたら、PRTを発行し、クラウドAPプロバイダーに渡します。
※PRTはこの②の処理時にセッションキーを作成し、デバイス登録時に作成されていたトランスポートキーの公開鍵で暗号化されます。
なお、トランスポートキーの秘密鍵はデバイスが所持しています。
フェーズD
①クラウドAPプロバイダーがPRTを受け取る
②クラウドAPプロバイダーはトランスポートキーの秘密鍵を利用して、セッションキーを復号し、デバイスのTPMを使用して、セッションキーを保護します。
セッションキーは、TPMで保護されたため、これを復号できるということが、正しいデバイスを持っているという証明になってますね
フェーズE
①クラウドAPプロバイダーはLsassに正常な認証応答を返します。
②LsassはPRTをキャッシュし、認証が成功した旨をWinlogonに通知します
③WinLogonはログオンセッションを作成し、ユーザーのプロファイルを読み込み、explorer.exeを開始します。
おわり
フェーズEでようやく認証プロセスが終わりました。
ここまでの処理をきわめて短い処理で終わらせるの、本当にいいですよね。
これがローカルでパスワードでの認証だと時間当たりの認証強度で見ちゃうと段違いですわ。
うーん、Windows Hello for Business 広めたい。
また、この一連の流れで、「デバイスキー」「トランスポートキー」「セッションキー」「TPMで保護」「PRT」などなど、Entra IDの世界観が出ました。それだけ覚えてもらえたらそれでもう幸せです。
Windosw Hello for Businessでは各認証プロファイル（顔・指紋・PIN）ごとにも別のキーがあり、それを暗号化するキーが有り・・など少しややこしいので、また別の機会にまとめます。
何かご相談などあればコメントやXまで！
