会社の PC で、パスワードの代わりに PIN や顔・指紋でサインインする場面が増えました。これを支えているのが Windows Hello for Business（WHfB）です。「4けたの PIN でサインインして、本当にパスワードより安全なの？」と思ったことがある人も多いのではないでしょうか。
この記事では、Windows Hello for Business のしくみを、PIN がパスワードより安全な理由、登録（プロビジョニング）の流れ、サインインで何を確かめているか、そしてオンプレの AD の資源に入るための「信頼の種類」まで、図とシーケンスで説明します。最後に、設定と確かめ方もまとめます。
- Windows Hello for Business とは何か。Windows Hello との違い
- PIN がパスワードより安全な理由と、TPM の役割
- 登録（プロビジョニング）とサインインの流れで、何を確かめて何を払い出すか
- オンプレ AD に入るための信頼の種類（クラウド Kerberos 信頼・キー信頼・証明書信頼）の違いと選び方
- よくある疑問：ハイブリッド参加で追加の設定は要るか、Entra Kerberos は必須か、「自分の鍵」はどれか
- Intune・グループポリシーでの設定と、dsregcmd での確かめ方
Windows Hello for Business とは
Windows Hello for Business は、パスワードの代わりに、PC の中で作った鍵のペア（公開鍵と秘密鍵）でサインインするしくみです。利用者が入れる PIN や、顔・指紋は、PC の中にある秘密鍵を使えるようにするための「鍵穴」のようなものです。
パスワードのサインインでは、PC とサーバ（DC や Entra ID）が「同じ秘密」を持ち、それを知っていることを確かめ合います（「Windowsの認証は何を確かめている？」の記事で説明しています）。同じ秘密なので、パスワードが知られてしまうと、ほかの PC からでもサインインできてしまいます。
Windows Hello for Business では、サーバが持つのは公開鍵だけです。秘密鍵は PC の TPM（鍵を守るチップ）の中にあり、外に取り出せません。サインインでは、秘密鍵で作った署名だけを送り、サーバは登録しておいた公開鍵で署名を確かめます。公開鍵と秘密鍵のしくみは「暗号の基礎」の記事で説明しています。
2つの要素を1回で済ませる
Windows Hello for Business のサインインは、それだけで2要素の認証になります。
| 要素 | Windows Hello for Business では |
|---|---|
| 持っているもの | その PC（TPM の中にある秘密鍵） |
| 知っているもの・本人の体 | PIN、または顔・指紋 |
そのため、Windows Hello for Business でサインインして Entra ID からもらう PRT には、「MFA を済ませた」しるしが付きます。条件付きアクセスで MFA を求めるアプリでも、もう一度 MFA を聞かれにくくなります。PRT のしくみは「PRT（Primary Refresh Token）とは？」の記事で説明しています。
Windows Hello と Windows Hello for Business の違い
名前がよく似ていますが、指すものが少し違います。
| 項目 | Windows Hello | Windows Hello for Business |
|---|---|---|
| 使うアカウント | 個人の Microsoft アカウントなど | 会社の Entra ID・AD のアカウント |
| しくみ | PIN・顔・指紋でサインインする機能 | 鍵のペア（または証明書）で、Entra ID や AD に認証する |
| 管理 | 利用者が自分で設定する | 会社が Intune やグループポリシーで設定する（PIN の長さ・生体認証の可否など） |
ローカルアカウントで設定した PIN も「Windows Hello」と呼ばれますが、これは鍵のペアを使うしくみではありません。この記事で説明するのは、会社のアカウントで使う Windows Hello for Business です。
PIN がパスワードより安全な理由
PIN は短くて覚えやすいので、パスワードより弱そうに見えます。しかし、PIN とパスワードでは「どこで、何に使うか」が違います。
| 理由 | 説明 |
|---|---|
| 端末に結び付く | PIN は、その PC の TPM の中の鍵を開けるだけです。PIN を知られても、その PC が手元になければ使えません。パスワードは、どの PC からでも使えます |
| サーバに送られない | PIN は PC の中だけで使い、ネットワークには流れません。サーバは PIN を持っていないので、サーバから PIN が漏れることもありません |
| TPM が守る | TPM は、間違いが続くと受け付けなくなるしくみ（アンチハンマリング）を持っています。PIN を何度も試して当てることはできません |
顔・指紋のデータはどこにある
顔や指紋のデータは、PC の中だけに暗号化して置かれます。サーバに送られることも、ほかの PC に移ることもありません。顔・指紋で認証できなかったときのために、PIN は必ず設定します。
コンテナーと鍵
Windows Hello for Business の鍵は、PC の中の「コンテナー」というまとまりに入っています。コンテナーは、ディスクやレジストリのどこかにあるフォルダではなく、関係する鍵をひとまとめにして扱うための考え方です。
| 鍵 | 役割 |
|---|---|
| 保護キー | PIN・顔・指紋のジェスチャーごとにある鍵。どれか1つで認証キーを開けられる |
| 認証キー | コンテナーを開ける鍵 |
| ユーザーの鍵 | Entra ID や AD への認証で、署名に使う鍵のペア。公開鍵だけを登録する |
PIN でも指紋でも、最後に使うのは同じユーザーの鍵です。そのため、指紋を追加しても、サーバ側に登録する鍵は増えません。
Windows Hello for Business の5つの段階
Windows Hello for Business は、いくつかのしくみが順に働いて動きます。Microsoft Learn では、これを5つの段階に分けて説明しています。
| 段階 | すること |
|---|---|
| デバイスの登録 | PC を Entra ID（オンプレだけの構成では AD FS）に登録する。Entra 参加やハイブリッド参加のこと |
| プロビジョニング | MFA を済ませてから PIN を作り、鍵のペアを作って、公開鍵をユーザーに登録する |
| 鍵の同期 | ユーザーの公開鍵を、Entra Connect で Entra ID から AD に同期する（キー信頼などで使う） |
| 証明書の登録 | 同じ鍵でユーザーの証明書を発行する（証明書信頼だけで使う） |
| 認証 | PIN・顔・指紋で秘密鍵を使えるようにし、署名で認証する |
デバイスの登録のしかた（Entra 参加・ハイブリッド参加）は「ドメイン参加・Entra参加・ハイブリッド参加の違い」の記事で説明しています。
登録（プロビジョニング）の流れ
Windows Hello for Business のポリシーが有効な PC にパスワードでサインインすると、デスクトップが開く前に、登録の画面が自動で出てきます。
この記事のシーケンス図では、「○○ が確かめる」「○○ が払い出す」の箱で、だれが何を確かめ、だれが何を渡すのかを示します。箱に書いた名前が、その処理をする人です。
ポイントは次の3つです。
- PIN を作る前に、必ず MFA を済ませます。10分以内に MFA を済ませていれば（PC の初期設定で Entra 参加したときなど）、もう一度は聞かれません
- 鍵のペアは、TPM の中で作ります。秘密鍵は TPM から取り出せません
- Entra ID に送るのは、公開鍵と、TPM で作った鍵であることの証明（構成証明）、端末の情報です。PIN は送りません。Entra ID は、どの端末で作った鍵かも一緒に記録します
登録が始まる条件
次の条件がそろったときだけ、登録の画面が出ます。どれかが欠けていると、何も起きずにデスクトップが開きます。
| 条件 | dsregcmd /status の項目 |
|---|---|
| PC が Entra 参加かハイブリッド参加になっている | IsDeviceJoined |
| サインインしたユーザーが Entra ID にいる | IsUserAzureAD |
| Windows Hello for Business のポリシーが有効 | PolicyEnabled |
| PC がハードウェアの条件を満たす | DeviceEligible |
| リモートデスクトップでサインインしていない | SessionIsNotRemote |
ハイブリッド構成では、ユーザーとデバイスの両方が Entra Connect で同期されている必要があります。同期のしくみは「Entra Connectは何を同期している？」の記事で説明しています。
サインインの流れ（Entra 参加の PC）
登録が終わると、次からは PIN や顔・指紋でサインインできます。Entra 参加の PC では、まず Entra ID に認証して PRT をもらいます。
Entra ID が確かめるのは、「登録した公開鍵で、署名を確かめられるか」と「nonce（1回だけ使う乱数）が正しいか」です。nonce に署名させるので、前に送った署名を使い回すことはできません。ここで PIN そのものは確かめていません。PIN は PC の中で鍵を開けるのに使っただけで、Entra ID には届いていないからです。
どの「信頼の種類」を選んでも、Entra ID へのサインインはこの流れで同じです。違いが出るのは、次に説明するオンプレ AD への入り方です。
オンプレ AD に入るための「信頼の種類」
Entra ID には、鍵のペアだけでサインインできます。しかし、ファイルサーバや社内の Web サイトなど、オンプレの AD で守られた資源に入るには、DC から Kerberos の TGT をもらう必要があります。パスワードを使わずに TGT をもらう方法が、信頼の種類（trust type）です。
| 項目 | クラウド Kerberos 信頼 | キー信頼 | 証明書信頼 |
|---|---|---|---|
| TGT のもらい方 | Entra ID が渡す部分的な TGT を、DC が本物の TGT に替える | 秘密鍵の署名を、DC が AD にある公開鍵で確かめる | ユーザーの証明書で、DC に認証する |
| PKI（証明書の基盤） | いらない | DC の証明書がいる | DC とユーザーの証明書がいる |
| 鍵の同期 | いらない | いる（同期まで待つ） | いらない（証明書ですぐ使える） |
| Entra Kerberos | 必要 | いらない | いらない |
| そのほか | 特権グループのメンバーは使えない | 新しく登録した人は同期まで待つ | AD FS（証明書の登録機関）と Entra ID P1 がいる |
Microsoft は、PKI を用意しなくてよく、登録した直後から使えるクラウド Kerberos 信頼をすすめています。
クラウド Kerberos 信頼
クラウド Kerberos 信頼では、Entra ID が、ユーザーの SID だけを入れた部分的な TGTを PRT と一緒に渡します。PC はこれを DC に持っていき、グループなどの情報を入れた本物の TGT に替えてもらいます。
ハイブリッド参加なのに、なぜ Entra ID を通るのか
「ハイブリッド参加の PC なら、DC から直接 Kerberos のチケットをもらうのでは？」と思うかもしれません。パスワードでサインインするときは、そのとおりです。PC01 はパスワードから作った鍵で AS-REQ を作り、DC01 は AD にある同じ鍵で確かめて、TGT を払い出します。
ところが PIN でサインインするときは、PC01 はパスワードを使いません。手元にあるのは TPM の中の秘密鍵だけで、その公開鍵は Entra ID にしか登録されていません（クラウド Kerberos 信頼では AD に同期しません）。DC01 は PIN の署名を確かめる材料を持っていないので、先に Entra ID に確かめてもらい、その結果である部分的な TGT を受け入れます。
サインインのくわしい流れは次のとおりです。ハイブリッド参加の PC では、クラウド Kerberos 信頼のポリシーが有効だと、Windows は PIN の資格情報を Entra ID 側（CloudAP）に渡し、PRT と部分的な TGT をまとめて受け取ります。
DC01 は、部分的な TGT が Entra Kerberos の作った正しいチケットかを確かめたうえで、AD にある user01 のグループなどの情報を入れて、本物の TGT を払い出します。Entra 参加の PC でも同じしくみを使います。Entra 参加では、サインインのときに受け取った部分的な TGT を、オンプレの資源を使うときに DC に持っていきます。
部分的な TGT を作る Entra Kerberos のしくみ（AD の中の AzureADKerberos というオブジェクトなど）は、「Microsoft Entra Kerberosとは？」の記事で説明しています。FIDO2 セキュリティキーのオンプレ SSO と同じしくみを使うので、すでに設定してあれば、そのまま使えます。
使うための条件は次のとおりです。
| 対象 | 条件 |
|---|---|
| クライアント | Windows 10 21H2 以降（KB5010415 以降）、Windows 11 21H2 以降（KB5010414 以降） |
| DC | Windows Server 2016（KB4534307 以降）、Windows Server 2019（KB4534321 以降）、Windows Server 2022、Windows Server 2025 |
| AD | ドメインとフォレストの機能レベルが Windows Server 2008 R2 以上 |
- AzureADKerberos のオブジェクトは RODC と同じルールで扱われるので、特権グループ（Domain Admins など）のメンバーはクラウド Kerberos 信頼でオンプレの資源に入れません。Microsoft は、この制限をゆるめないようにすすめています
- ハイブリッド参加の PC では、初めて PIN でサインインするときに DC と通信できる必要があります。一度サインインできれば、そのあとは DC に届かない場所でもキャッシュでロックを解除できます
- RDP や VDI で資格情報を渡して使う場面、「別のユーザーとして実行」では使えません（RDP は Remote Credential Guard を使えば使えます）
- ユーザーが認証する AD のサイトごとに、書き込みできる DC を十分な台数置きます
RODC のしくみは「ドメインコントローラの種類とは？」、特権グループは「ADの特権グループとは？」の記事で説明しています。
キー信頼
キー信頼では、PC が秘密鍵で署名した事前認証と公開鍵を DC に送り、DC は AD に登録されている公開鍵と一致するかを確かめます。
送る公開鍵と、AD にある公開鍵は同じもの
鍵のペアは1組だけです。秘密鍵（ここでは「秘密鍵 K」と呼びます）は PC01 の TPM の中にあり、外には出ません。公開鍵 K は、プロビジョニングで Entra ID の user01 に登録され、Entra Connect がそのコピーを AD の user01 に同期します。サインインで DC01 に送るのも、この同じ公開鍵 K です。
わざわざ公開鍵も送るのは、証明書を使う Kerberos の事前認証（PKINIT）が「証明書」と「その秘密鍵で作った署名」をセットで送る決まりになっているからです。キー信頼ではユーザーの証明書がないので、公開鍵 K を自己署名の証明書に包んで送ります。DC01 は、自己署名の証明書だとわかると、証明書そのものは信頼の根拠にせず、中の公開鍵を取り出して AD の中を探します。そして、AD に同期された公開鍵 K と一致するか、その持ち主と要求のユーザー（UPN）が合うか、公開鍵 K で署名が合うかを確かめます。
端末に証明書が入っているわけではない
「自己署名の証明書」と聞くと、PC01 にどこかから証明書が配られているように思えますが、そうではありません。キー信頼では、CA が発行したユーザーの証明書は使いません。公開鍵 K を、証明書という決まった形の入れ物に包んで送っているだけです。入れ物に意味のある中身は公開鍵 K だけで、発行者も自分自身、署名も自分の秘密鍵 K で付けています。
| 証明書の項目 | キー信頼の自己署名の証明書では |
|---|---|
| 公開鍵 | ユーザーの公開鍵 K（AD に同期されたものと同じ） |
| 発行者 | 自分自身（CA ではない） |
| 証明書の署名 | 秘密鍵 K で、自分で付ける |
このとき、秘密鍵 K で作る署名は2つあります。役割がまったく違うので、分けて考えるとわかりやすくなります。
| 署名 | 何に署名するか | 役割 |
|---|---|---|
| 証明書の自己署名 | 公開鍵 K を入れた証明書そのもの | 証明書の形を整えるため。だれでも作れるので、DC01 はこれを信頼の根拠にしない |
| 事前認証の署名 | AS-REQ の中の事前認証のデータ（時刻と nonce） | DC01 が本当に確かめるのはこちら。「秘密鍵 K を持つ PC01 からの、いまの要求だ」とわかる |
信頼の根拠になっているのは、Entra Connect が AD に書き込んだ公開鍵 K のほうです。自己署名の証明書は、その鍵を DC01 まで運ぶための封筒だと考えてください。CA が発行した証明書がユーザーの個人用ストアに入るのは、後で説明する証明書信頼のときです。
PC は、DC から返ってきた DC の証明書も確かめます。信頼するルートにつながっているか、期限内か、失効していないか、KDC 認証の用途があるか、ドメイン名が合っているか、を確かめるので、DC には証明書が必要です。
キー信頼で気をつけたいのは、公開鍵が AD に届くまで、AD の資源に入れないことです。公開鍵は、Entra Connect の次の同期で AD のユーザーに書き込まれます。
証明書信頼
証明書信頼では、プロビジョニングのあとに、同じ鍵でユーザーの証明書を発行します。証明書の要求は AD FS（証明書の登録機関）が受け付け、登録済みの公開鍵と一致するかを確かめてから、登録エージェントの証明書で署名して社内の CA に回します。
サインインでは、この証明書を使って DC に認証します（スマートカードのサインインと同じ考え方です）。キー信頼との違いは、DC01 が AD の公開鍵ではなく、証明書そのものを確かめる点です。CA が発行した証明書なので、信頼する CA につながっているか、期限内か、失効していないかを確かめ、証明書に入っている UPN で AD のユーザーを探します。
証明書がすぐに発行されるので鍵の同期を待ちませんが、PKI と AD FS を用意する必要があり、構成はいちばん重くなります。Entra ID のライセンスについては、証明書信頼だけが Microsoft Entra ID P1 を必要とします。
どれを選ぶか
オンプレ AD がなく Entra ID だけで使う「クラウドのみ」の構成なら、信頼の種類を選ぶ必要はありません。オンプレ AD の資源も使うなら、まずクラウド Kerberos 信頼を選び、使えない場面があるときにキー信頼や証明書信頼を検討します。
よくある疑問
ハイブリッド参加の PC と信頼の種類のまわりは、つまずきやすいところです。よく出る疑問を3つまとめます。
ハイブリッド参加なら、オンプレの資源に入るのに追加の設定は要る？
パスワードでサインインするなら、追加の設定は要りません。ハイブリッド参加の PC は AD のドメインに参加しているので、パスワードでサインインすると、ふつうのドメイン参加の PC と同じく DC から TGT をもらい、そのままファイルサーバなどに Kerberos で入れます。
信頼の種類が必要になるのは、Windows Hello for Business（PIN・顔・指紋）でサインインするときだけです。このとき PC にはパスワードがなく、TPM の中の秘密鍵しかないので、DC がその署名を確かめる方法を、3つの信頼の種類のどれかで用意します。
| サインインのしかた | オンプレの資源に入るために必要なもの |
|---|---|
| パスワード | なし（ふつうのドメイン参加と同じ） |
| Windows Hello for Business | 信頼の種類（クラウド Kerberos 信頼・キー信頼・証明書信頼のどれか） |
Entra Kerberos は必須？
Windows Hello for Business でサインインする前提でも、Entra Kerberos が必要なのは、クラウド Kerberos 信頼を選んだときだけです。キー信頼と証明書信頼では、PC が自分の鍵で署名した AS-REQ を DC に直接送り、DC が AD に同期された公開鍵やユーザーの証明書で確かめます。Entra ID が間に入らないので、Entra Kerberos は使いません。そのかわり、DC の証明書（PKI）や、Entra Connect による公開鍵の同期が必要になります。
反対に、クラウド Kerberos 信頼を選ぶなら Entra Kerberos は欠かせません。特にハイブリッド参加の PC では、影響が大きくなります。
- クラウド Kerberos 信頼のポリシーが有効だと、登録の前に「このユーザーが部分的な TGT をもらえるか」をチェックします。Entra Kerberos がないと、このチェックが通らず、登録が始まりません
- Windows へのサインインそのものが「Entra ID で部分的な TGT をもらう → DC で本物の TGT に替える」流れになるので、Entra Kerberos がないと成り立ちません
Entra 参加の PC では、このチェックはありません。Entra Kerberos がなくても Windows にはサインインでき、オンプレの資源への SSO だけができない、という動きになります。なお、FIDO2 セキュリティキーでオンプレの資源に入るときも、同じ Entra Kerberos を使います。
「自分の鍵で署名する」の鍵はどれ？
PC の中には、名前の似た鍵がいくつもあります。キー信頼・証明書信頼で AS-REQ に署名する「自分の鍵」は、プロビジョニングで TPM が作ったユーザーの秘密鍵（この記事でいう秘密鍵 K）です。セッションキーでも、鍵の ID でもありません。
| 名前 | いつできるか | 何に使うか |
|---|---|---|
| ユーザーの秘密鍵 K | プロビジョニングで、TPM が鍵のペアを作ったとき | AS-REQ の事前認証や、Entra ID の nonce に署名する。TPM から取り出せない |
| ユーザーの公開鍵 K | 同上（ペアのもう片方） | Entra ID（キー信頼では AD にも）に置き、署名を確かめるのに使う |
| 鍵の ID | 公開鍵を登録した最後に、Entra ID が返す | どの公開鍵かを指す番号札。dsregcmd の NgcKeyId で見える。鍵の材料は入っていない |
| セッションキー | PRT をもらったとき | PRT を使う要求に署名する。Entra ID とのやりとり専用で、DC は知らない |
| 端末の鍵・トランスポートの鍵 | デバイスの登録（Entra 参加・ハイブリッド参加）のとき | 端末として Entra ID に名乗る・暗号化されたセッションキーを開ける |
鍵の ID は鍵そのものではなく、「user01 に登録した、PC01 で作った公開鍵」に付けたラベルです。同じ user01 が PC01 と PC02 で Windows Hello を登録すると、公開鍵が2つ登録され、それぞれに別の鍵の ID が付きます。また、Kerberos にも TGT と一緒に渡される「セッションキー」がありますが、これは PRT のセッションキーとは別の鍵です（「Kerberos（ケルベロス）認証とは？」で説明しています）。
キー信頼と証明書信頼で署名に使う秘密鍵は同じです。違うのは、公開鍵の渡し方だけです。
| 信頼の種類 | AS-REQ に入れる公開鍵 | DC01 が確かめるもの |
|---|---|---|
| キー信頼 | 公開鍵 K を、自己署名の証明書に包む | AD に同期された公開鍵 K と一致するか |
| 証明書信頼 | 公開鍵 K を入れて、社内の CA が発行した証明書 | 証明書そのもの（信頼する CA か・期限・失効・UPN） |
秘密鍵 K で署名するのは、AS-REQ の中の事前認証のデータです。証明書を使う事前認証（PKINIT、RFC 4556）では、このデータに時刻と nonce が入っています。DC は公開鍵 K でこの署名を確かめ、「秘密鍵 K を持つ PC01 からの、いまの要求だ」と判断します。PIN は、この秘密鍵 K を TPM の中で使えるようにするだけで、DC には届きません。
デプロイのモデル
Microsoft Learn では、どこにアカウントがあるかで、次の3つのモデルに分けています。
| モデル | アカウントの場所 | PC の参加のしかた・信頼の種類 |
|---|---|---|
| クラウドのみ | Entra ID だけ | Entra 参加。信頼の種類は使わない |
| ハイブリッド | AD と Entra ID（Entra Connect で同期） | Entra 参加またはハイブリッド参加。クラウド Kerberos 信頼・キー信頼・証明書信頼から選ぶ |
| オンプレのみ | AD だけ（AD FS を使う） | ドメイン参加。キー信頼か証明書信頼 |
設定のしかた
Entra 参加の PC では、Windows Hello for Business は既定で有効になっていて、初めてサインインしたときに登録が始まります。止めたいときや、PIN の条件を決めたいときは、Intune かグループポリシーで設定します。
Intune（設定カタログ）
Microsoft Intune 管理センター ›› デバイス ›› 構成 ›› 作成 ›› 設定カタログ で、「Windows Hello for Business」の分類から次を設定します（クラウド Kerberos 信頼の例）。
| 設定 | 値 |
|---|---|
| Use Windows Hello For Business | true |
| Use Cloud Trust For On Prem Auth | Enabled（クラウド Kerberos 信頼のとき） |
| Require Security Device | true（TPM を必須にする。すすめられている） |
Intune には、デバイスを登録するときにだけ当たるテナント全体のポリシー（デバイス ›› Windows ›› Windows の登録 ›› Windows Hello for Business）もあります。こちらは登録したあとのデバイスには反映されないので、ふだんの設定は設定カタログなどのポリシーで行います。
グループポリシー
コンピューターの構成 ›› 管理用テンプレート ›› Windows コンポーネント ›› Windows Hello for Business で設定します。
| 設定 | 値 |
|---|---|
| Windows Hello for Business の使用（Use Windows Hello for Business） | 有効（ユーザーの構成でも設定できる） |
| Use cloud Kerberos trust for on-premises authentication | 有効（クラウド Kerberos 信頼のとき。コンピューターの構成だけ） |
| Use a hardware security device | 有効（TPM を必須にする） |
クラウド Kerberos 信頼の設定が見当たらないときは、対応している Windows から Passport.admx と Passport.adml をセントラルストアにコピーします。グループポリシーと Intune の両方で設定した場合は、グループポリシーが優先され、Intune の設定は無視されます。
パスワードとの関係
Windows Hello for Business は鍵（または証明書）でサインインするので、パスワードを変えても、PIN や顔・指紋のサインインには影響しません。
ただし、パスワードに有効期限がある場合は注意が必要です。Windows Hello でサインインしていると、「パスワードを変更してください」という通知が出ません。気づかないまま期限が切れると、AD で守られた資源への認証に失敗することがあります。Microsoft Learn では、次のような対策を挙げています。
- パスワードの有効期限をなくす
- パスワードの有効期限の代わりに、PIN の有効期限のポリシーを使う
- 有効期限が必要なら、利用者に定期的に（または認証に失敗したときに）
Ctrl + Alt + Del ›› パスワードの変更で変えてもらう
パスワードを変えるときは、PC が DC と通信できる必要があります。
確かめ方
登録できているか、登録が始まらない理由は何か、オンプレ用の TGT があるかは、dsregcmd /status で確かめられます。ユーザーの状態を表示するので、管理者に昇格せず、サインインしたユーザーのままで実行します。
| 項目（セクション） | 意味 |
|---|---|
| NgcSet（User State） | このユーザーの Windows Hello の鍵があれば YES |
| NgcKeyId（User State） | Windows Hello の鍵の ID |
| CanReset（User State） | 利用者が PIN をリセットできるか |
| AzureAdPrt（SSO State） | PRT があれば YES |
| OnPremTgt（SSO State） | クラウド Kerberos 信頼で、オンプレの資源に使うチケットがあれば YES |
| Ngc Prerequisite Check | 登録が始まる条件のチェック。PreReqResult が WillProvision なら、次のサインインで登録が始まる |
登録が終わっていると、Ngc Prerequisite Check のセクションは表示されないことがあります。イベントログでは、イベント ビューアー ›› アプリケーションとサービス ログ ›› Microsoft ›› Windows ›› User Device Registration ›› Admin に、登録の準備ができたこと（イベント ID 358）や、鍵を Entra ID に登録できたこと（イベント ID 300）が記録されます。
オンプレの資源に入れないときは、「Windows認証の調べ方」の記事のように、klist で TGT を持っているか、DC のイベントで認証が失敗していないかを確かめます。
確認に使うコマンド
PC01（コマンドプロンプト・サインインしたユーザー）：参加の状態・Hello の鍵・PRT・登録の条件を表示する
dsregcmd /status
PC01（コマンドプロンプト・サインインしたユーザー）：Hello に関係する行だけを表示する
dsregcmd /status | findstr /i "NgcSet NgcKeyId CanReset AzureAdPrt OnPremTgt PreReqResult"
PC01（コマンドプロンプト・サインインしたユーザー）：持っている Kerberos のチケット（TGT を含む）を表示する
klist
PC01（PowerShell）：User Device Registration のログを新しい順に20件表示する
Get-WinEvent -LogName "Microsoft-Windows-User Device Registration/Admin" -MaxEvents 20 | Format-Table TimeCreated, Id, Message -Wrap
PC01（PowerShell・管理者）：TPM があり、使える状態かを表示する
Get-Tpm
まとめ
| 項目 | ひとことで |
|---|---|
| Windows Hello for Business | PC の中で作った鍵のペアでサインインするしくみ。サーバは公開鍵だけを持つ |
| PIN | PC の TPM の中の鍵を開けるだけ。サーバに送られず、ほかの PC では使えない |
| プロビジョニング | MFA → PIN → TPM で鍵のペア → 公開鍵をユーザーに登録 |
| サインイン | 秘密鍵で nonce に署名し、Entra ID が公開鍵で確かめて PRT（MFA 済み）を払い出す |
| 信頼の種類 | オンプレ AD の TGT のもらい方。おすすめはクラウド Kerberos 信頼 |
| Entra Kerberos | 必要なのはクラウド Kerberos 信頼のときだけ。パスワードのサインインには関係ない |
| 自分の鍵 | プロビジョニングで TPM が作ったユーザーの秘密鍵。セッションキーや鍵の ID とは別 |
| キー信頼の注意 | 公開鍵が Entra Connect で AD に同期されるまで、AD の資源に入れない |
| パスワード | 変えても Hello に影響しないが、期限切れの通知が出ないことに注意 |
| 確かめ方 | dsregcmd /status の NgcSet・OnPremTgt・Ngc Prerequisite Check |
Windows Hello for Business の安全性は、「秘密鍵が PC の TPM から出ない」「PIN はその鍵を開けるだけ」という2つの点で成り立っています。PIN の短さではなく、鍵がどこにあり、何がネットワークに流れるかに目を向けると、しくみがつかみやすくなります。
- Windows Hello for Business overview（Microsoft Learn）
- How Windows Hello for Business works（Microsoft Learn）
- How Windows Hello for Business provisioning works（Microsoft Learn）
- Windows Hello for Business authentication（Microsoft Learn）
- Plan a Windows Hello for Business deployment（Microsoft Learn）
- Cloud Kerberos trust deployment guide（Microsoft Learn）
- Configure Windows Hello for Business（Microsoft Learn）
- Common questions about Windows Hello for Business（Microsoft Learn）
- Troubleshoot devices by using the dsregcmd command（Microsoft Learn）
- Understanding Primary Refresh Token (PRT)（Microsoft Learn）
- RFC 4556: Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
コメント