Windows Hello for Business をハイブリッド Azure AD 参加 + Intune で使っていると、「顔/指紋は成功するのに毎回 PIN も要求される」現象に悩まされがちです。本記事では、その原因となるマルチファクター解除ポリシーの仕組みと、狙いどおり「生体成功だけで解除」に近づける具体的な設定・確認ポイントを、ハイブリッド特有の注意点も交えながら詳しく解説します。
現象の整理：生体認証は成功しているのに毎回 PIN が必要
まずは、よくある相談パターンを整理します。次のような構成・要件で運用しているケースを想定します。
- 端末は ハイブリッド Azure AD 参加（Hybrid Azure AD Join / Hybrid AADJ）
- 端末構成や Windows Hello for Business（WHfB）は Intune の「エンドポイント セキュリティ > アカウント保護」で管理
- WHfB の構成では PIN + 指紋 + 顔 を有効にしている
- 要件は「普段は顔認証または指紋認証だけで解除し、生体が失敗したときだけ PIN を入力させたい」
しかし実際には、次のような挙動になります。
- 顔/指紋をタッチ・覗き込むと、まず生体認証は 成功しているように見える
- その直後に「組織のポリシーにより、もう一段階の確認が必要です」と表示される
- 結局、生体認証 + PIN の二段階を毎回要求される
- イベント ログでは Event ID 3520（multi-factor unlock を試行） などが記録される
- クライアント レジストリの
DeviceUnlockFactorsは7（PIN=1, 指紋=2, 顔=4 の合計値）になっている
一見すると「生体認証の設定をオンにしたのに期待どおり動いていない」ように感じられますが、実はこれは Intune の Windows Hello for Business ポリシーの仕様どおりに動いているケースがほとんどです。
原因：マルチファクター解除ポリシーが有効になっている
この現象の本質は、マルチファクター解除（multi-factor unlock） のポリシーが有効になっていることです。ここを理解すると、なぜ「毎回 生体 + PIN」になってしまうのかがストンと腑に落ちます。
「デバイスのロック解除要素」は「並列の選択肢」ではない
Intune の WHfB ポリシー（エンドポイント セキュリティ > アカウント保護）には、次のような設定項目があります。
- Windows Hello for Business を構成するか
- 生体認証を使用するか
- デバイスのロック解除要素（マルチファクター解除） を構成するか
多くの管理者が誤解しがちなのは、「デバイスのロック解除要素（PIN・指紋・顔）」に複数チェックを入れると、それぞれが「どれか1つを選べるサインイン方法」として並列に許可されると考えてしまう点です。
しかし実際には、この項目は次のような意味を持ちます。
- マルチファクター解除モードを構成する ための設定
- ここに列挙した要素のうち、常に 2 つ以上の要素を要求する ことを意味する
- 典型的には「生体認証 + PIN」のセットを毎回求める動作になる
つまり、「解除要素を全部オン」＝「どれか1つで解除」ではなく、「2要素以上を必須にする」 という構成になっているのです。
イベントログとレジストリに現れるサイン
マルチファクター解除が有効になっているかどうかは、イベントログやレジストリからも確認できます。
| 確認箇所 | 内容 | 意味 |
|---|---|---|
| イベント ログ | Event ID 3520（multi-factor unlock を試行） | マルチファクター解除のフローが動いているサイン |
| レジストリ | DeviceUnlockFactors = 7 | PIN=1, 指紋=2, 顔=4 の合計値。 複数要素を使うマルチファクター解除が有効 |
このような状態の端末では、「顔認証・指紋認証が成功しても、常に PIN を追加で要求する」という挙動が仕様として発生します。
狙いの動作：「生体成功だけで解除、失敗時のみ PIN」にするには
要件は次のようなものだったはずです。
- 通常は、顔認証または指紋認証だけでロック解除させたい
- ただし、生体認証が連続して失敗した場合は PIN を入力させたい（フォールバック）
この挙動に近づけるには、マルチファクター解除ポリシーを無効（または未構成） にし、「生体認証を使用」を有効にするだけで十分なケースが多くなります。
ざっくり整理すると、次のようなイメージです。
| 構成 | 挙動のイメージ |
|---|---|
| 生体認証 有効 マルチファクター解除 無効/未構成 | 生体認証で即解除。 生体失敗時に PIN をフォールバック要求 |
| 生体認証 有効 マルチファクター解除 有効（PIN + 指紋 + 顔） | 生体が成功しても毎回 PIN も要求される。 常時 2 要素が必要 |
では、Intune では具体的にどのように設定すればよいのでしょうか。
Intune（エンドポイント セキュリティ）での具体的な設定例
以下は、Intune で Windows Hello for Business を構成している一般的な例をベースにした設定イメージです。実際のポリシー名や項目名はテナントやポータルの更新によって若干異なる場合がありますが、考え方は変わりません。
Windows Hello for Business ポリシーの推奨値
Intune 管理センターから次のように辿ります。
- エンドポイント セキュリティ > アカウント保護 > 対象の Windows Hello for Business ポリシー
主な設定項目と推奨例は次のとおりです。
| 設定項目 | 推奨値（例） | 補足 |
|---|---|---|
| Windows Hello for Business | 有効 | WHfB 自体を有効化 |
| 生体認証を使用する | 有効 | 顔認証・指紋認証を許可する |
| デバイスのロック解除要素（マルチファクター解除） | 未構成または無効 | ここに PIN/指紋/顔を列挙しないことがポイント |
| PIN の最小長 | 組織のセキュリティ基準に合わせて設定 | 長さ・複雑さはセキュリティ ポリシーとバランス |
| PIN の回復 | 必要に応じて有効 | サポート観点で有効化が多い |
特に重要なのは、「デバイスのロック解除要素」には何も設定しないことです。ここを未構成または無効にしておくことで、「常時 2 要素を要求するモード」に入ることを避けられます。
プロファイル種別の混在に注意
同一端末に対して、次のような複数のプロファイルが混在していると、意図しない結果を生むことがあります。
- エンドポイント セキュリティ > アカウント保護 による WHfB ポリシー
- 構成プロファイル（テンプレートや設定カタログ） での WHfB 関連設定
- オンプレミスの グループ ポリシー（GPO） による Hello 関連設定
一見同じ意味の設定項目でも、適用優先度や「有効/無効/未構成」の組み合わせによって結果は変わります。トラブルシュート時には、どのレイヤーが最終的に有効になっているかを必ず確認しましょう。
オンプレミス GPO / 旧設定との競合チェック
ハイブリッド Azure AD 参加環境では、オンプレミスの GPO と Intune のポリシーが同じ端末に適用されます。そのため、GPO 側で古いポリシーが残っていると、意図しないサインイン挙動を引き起こすことがあります。
確認しておきたい主な GPO 設定
代表的な確認項目を整理すると、次のようになります。
| GPO の例 | 推奨状態 | ポイント |
|---|---|---|
| 生体認証を許可する | 有効 | 生体認証機能自体の ON/OFF |
| 生体認証でのサインインを許可する | 有効 | サインイン/解除に生体を使うことを許可 |
| Windows Hello for Business またはスマートカードのサインインを必須にする | 未構成または無効 （要件に応じて検討） | 不要な二要素要求やスマートカード必須を避ける |
| PIN サインインを無効化（Convenience PIN を禁止） | 未構成または無効 | 古い Convenience PIN 禁止設定が WHfB に悪影響を与えることがある |
特に、過去に「Convenience PIN を禁止」するための GPO を展開していた環境では、その GPO が今も生きていないかを確認しておくことが重要です。Windows Hello for Business の PIN は旧来の Convenience PIN とは別物ですが、設定の組み合わせによっては思わぬ挙動につながる場合があります。
ハイブリッド構成特有の制約：Key trust / 証明書トラスト / Cloud Kerberos Trust
Windows Hello for Business は、ハイブリッド環境では大きく分けて次のような構成方式があります。
- 証明書トラスト（Certificate Trust）
- Key trust（キー トラスト）
- Cloud Kerberos Trust（Cloud Kerberos Trust / CKT）
これらの方式は、ユーザーの Hello 資格情報をどのようにオンプレミス AD の Kerberos 認証と結びつけるか、という点で異なります。詳細な構成はここでは割愛しますが、生体認証のみで安定して解除できるかどうかという観点で、次のようなことが言えます。
- 証明書トラスト の構成では、証明書のライフサイクルや同期の状態など、より多くの前提条件に依存するため、特定の環境条件で生体単独解除が不安定になるケースが報告されることがあります。
- Key trust や Cloud Kerberos Trust は構成が比較的シンプルで、クラウド側の Azure AD / Entra ID との連携を前提としたモダンな方式です。要件が許すなら、こちらへ移行することで期待どおりの挙動に近づきやすくなります。
- オンプレミスへの依存を減らせる場合は、いっそ Azure AD Join（クラウドのみ） 端末として運用したほうが、「生体成功で即解除」という挙動は安定していることが多いです。
つまり、「生体成功だけで解除」という体験を重視するなら、認証アーキテクチャ自体を見直すことも選択肢に入れるべきということです。Intune/WHfB のポリシー調整だけでは限界がある場合、Key trust / Cloud Kerberos Trust への移行や、Azure AD Join 端末の採用を検討しましょう。
端末側での確認ポイントとトラブルシュート
ポリシーを修正・再配布した後は、端末側で実際に設定が反映されたかを確認する必要があります。代表的な確認ポイントを整理します。
レジストリの DeviceUnlockFactors を確認
マルチファクター解除が無効化されていれば、DeviceUnlockFactors の値は次のいずれかの状態になっているはずです。
- 値が存在しない、または 0 に近い状態：マルチファクター解除が構成されていない
- 7（PIN + 指紋 + 顔） などの合算値ではない：特定の要素が組み合わされた状態ではない
値が 7 のままであれば、まだどこかからマルチファクター解除ポリシーが適用されている可能性が高いと考えられます。
イベント ログ：Event ID 3520 が出ていないか
サインイン/ロック解除のタイミングで次の点を確認します。
- ロック解除操作時に Event ID 3520（multi-factor unlock） がログに出ていないか
- 代わりに通常の Hello 認証イベントのみが記録されているか
Event ID 3520 が記録され続ける場合、どこかでマルチファクター解除が有効のままになっていると判断できます。
それでも毎回 PIN を求められる場合の追加対応
ポリシーや GPO を見直しても挙動が改善しない場合、次のようなローカル要因が疑われます。
- 生体認証デバイスのドライバー不具合
- Windows Hello コンテナ（NGC フォルダー）の破損
- 過去のテスト構成が中途半端に残っている
この場合の対処として、例えば次のようなステップが考えられます。
- 指紋センサーやカメラ ドライバーを最新に更新する
- 既存の指紋・顔の登録を一度削除し、再登録する
- それでも改善しない場合は、管理者主導で Windows Hello の再セットアップ（NGC コンテナのリセット） を検討する
NGC コンテナのリセットは、ユーザーの PIN/生体情報を再登録させる必要があるため、事前の周知や手順書の準備など、運用面の配慮が欠かせません。
よくある誤解と設計のポイント
Windows Hello for Business と Intune を組み合わせるとき、設計・運用の現場でよく見かける誤解や落とし穴をまとめておきます。
「解除要素を全部オン = どれか1つで解除できる」は誤解
最も多い誤解が、次のような考え方です。
- 「PIN・指紋・顔は全部オンにしておけば、ユーザーが好きな方法を選べる」
実際には、これは 「マルチファクター解除を有効化し、複数要素を同時に要求する構成」 です。結果として、ユーザーは毎回 生体 + PIN を入力する必要が出てきてしまいます。
ユーザー体験とセキュリティのバランスを取るには、次のような設計方針を明確にすることが重要です。
- 普段は 1 要素（生体）でよいのか
- 常に 2 要素（生体 + PIN）を要求したいのか
- 2 要素にしたい場合は、その理由（リスク シナリオ）が明確か
そのうえで「普段は 1 要素（生体）でよく、失敗時にだけ PIN を使わせたい」のであれば、マルチファクター解除は使わないという判断になります。
ハイブリッド環境では「構成のシンプルさ」が重要
オンプレミス AD と Azure AD（Entra ID）、さらに Intune と GPO が絡むハイブリッド構成では、設定が複雑になるほどトラブルシュートも難しくなります。Windows Hello for Business の設計でも、次のような方針が現実的です。
- できるだけ Key trust / Cloud Kerberos Trust など構成がシンプルな方式を選択する
- 端末側ポリシーの 主役を Intune にまとめる（GPO は必要最小限）
- テスト用のポリシーを追加するときは、適用範囲や優先度が本番と競合しないように設計する
特に、証明書トラスト構成でさまざまな要件を満たそうとすると、予期しないサインイン挙動に遭遇しやすくなります。「なぜか毎回 PIN が要求される」といった現象の裏には、設計が複雑化しすぎているという背景があることも少なくありません。
シナリオ別のおすすめ構成イメージ
最後に、「生体認証でロック解除したい」という要件を前提とした場合に、どのような構成が現実的かをシナリオ別に整理します。
| シナリオ | おすすめ構成の例 | ポイント |
|---|---|---|
| オンプレミス AD 中心 クラウドは徐々に移行中 | ハイブリッド Azure AD 参加 + Intune 管理 WHfB は Key trust または CKT を優先 | 証明書トラストより構成がシンプルで、生体単独解除の安定性も期待しやすい |
| クラウド ファースト オンプレ AD は最小限 | Azure AD Join + Intune 管理 オンプレ依存を極力減らす | WHfB のシンプルな構成が可能で、「生体成功 = 解除」の体験を実現しやすい |
| 高いセキュリティ要件 常時 2 要素での解除を徹底したい | マルチファクター解除（デバイスのロック解除要素）を敢えて有効化 生体 + PIN を常時要求 | ユーザー負荷は増えるが、リスクの高い端末や部門では現実的な選択肢 |
同じ Windows Hello for Business でも、「求めるユーザー体験」と「許容できるリスク レベル」によって、最適な構成は変わってきます。マルチファクター解除は強力な機能ですが、使いどころを明確にしないまま有効化してしまうと、「毎回 PIN が必要で不便」という不満につながってしまう点に注意が必要です。
運用時にチェックしておきたい項目まとめ
最後に、「生体成功だけでロック解除、失敗時のみ PIN」という運用を目指すうえで、最低限チェックしておきたいポイントをチェックリスト形式でまとめます。
- Intune の WHfB ポリシーで、マルチファクター解除（デバイスのロック解除要素）が未構成または無効になっているか
- 生体認証の使用 = 有効 になっているか
- PIN の長さや複雑さなど、組織基準に沿ったポリシーが設定されているか
- オンプレミス GPO による 生体認証禁止 や Convenience PIN 禁止 など、競合しうる設定が残っていないか
- 端末レジストリの DeviceUnlockFactors が 7 などの合算値になっていないか
- ロック解除時のイベント ログに Event ID 3520（multi-factor unlock） が出ていないか
- 環境全体として、Key trust / Cloud Kerberos Trust / Azure AD Join など、構成のシンプルさを優先した設計になっているか
これらのポイントを押さえることで、「なぜか毎回 PIN を求められる」というよくあるトラブルから一歩抜け出し、ユーザー体験とセキュリティを両立した Windows Hello for Business の運用に近づけることができます。
まとめると、今回の現象はバグや不具合というよりも、マルチファクター解除ポリシーが仕様どおり動いた結果であることがほとんどです。Intune 側のポリシー設計を見直し、必要に応じてハイブリッド構成の方式（Key trust / Cloud Kerberos Trust / Azure AD Join）自体も検討することで、狙いどおりの「生体成功だけで解除、失敗時のみ PIN」という運用を実現していきましょう。
コメント