Citrix のログインを RADIUS + NPS Extension for Azure MFA で保護していると、Entra ID の「認証方法ポリシー」で TOTP を特定グループのみに許可したつもりでも、グループ外ユーザーが Microsoft Authenticator の確認コード（TOTP）で通ってしまうことがあります。本記事では、この挙動の理由を「どこで何が判定されているのか」という視点で分解し、短期対処と中長期の移行判断まで整理します。
NPS Extension for Azure MFA と Entra ID 認証方法ポリシーは、そもそも“守備範囲”が違う
最初に押さえるべきは、Citrix + RADIUS + NPS Extension の構成は、SAML/OIDC のような「Entra ID がサインイン全体を主導する構成」ではない、という点です。RADIUS は古典的なプロトコルで、NPS は Windows Server 上の認証基盤、NPS Extension は「NPS が“二段階目”を実施できるようにするアダプター」です。結果として、Entra ID の認証方法ポリシー（Authentication Methods Policy）が提供する“きめ細かい許可/除外”と、NPS 経由の MFA で実際に行われる“二段階目の成立条件”が一致しないケースが発生します。
| 要素 | 役割 | 何を根拠に判定するか | 今回の論点との関係 |
|---|---|---|---|
| Citrix（Gateway/ADC/StoreFront 等） | ログイン受付・RADIUS クライアント | RADIUS 応答（Accept/Reject） | 「TOTP を許可する/しない」を直接は判断しない |
| NPS（Windows Server） | 一次認証（AD DS）と RADIUS ポリシー | AD の資格情報 + NPS ポリシー条件 | MFA を“必要にするか”は決められても、MFA 手段の細かい制御は難しい |
| NPS Extension for Azure MFA | 二次認証（MFA）をクラウドに委譲 | ユーザーに「登録済み」の強固な方法があるか等 | 認証方法ポリシーのスコープを強制しない挙動が問題になる |
| Entra ID 認証方法ポリシー | ユーザー/グループごとに利用可能な方法を管理 | ポリシー（含める/除外/設定） | “本来ここで制御したい”のに、NPS 経由にはそのまま効かないことがある |
つまり今回の事象は、「ポリシーが壊れている」というより“評価している場所が違う”ことに起因します。以降は、その評価ポイントを、Microsoft の説明に沿って明確化します。
結論：NPS Extension は「認証方法ポリシー」のスコープを評価・強制しない
Microsoft Learn の Q&A（Citrix を RADIUS + NPS Extension で保護している、ほぼ同一の前提の質問）では、次の趣旨が明確に回答されています。
- NPS Extension は現時点で Authentication Methods Policy のスコープ（含める/除外するグループ等）を強制しない
- 参照しているのは、ユーザーに保存されている従来の MFA 登録情報（Security Info に相当する登録データ）
- よって、ポリシー上は TOTP を許可していないユーザーでも、すでに TOTP が登録されていれば、その TOTP で通ってしまう
- さらに、将来的に NPS Extension が認証方法ポリシーを尊重するという確定ロードマップは公開されていない
この回答が重要なのは、現場で起きている「グループ外ユーザーでも TOTP が通る」を、“仕様として説明できる形”に落とし込める点です。運用ドキュメントに残すなら、「NPS Extension は認証方法ポリシーではなく登録済み方法（Security Info）を根拠に二次認証を成立させる」という一文が核になります。
実際に何を見ているのか：NPS Extension がチェックするのは「登録済み MFA 方法」
NPS Extension の基本動作は、公式ドキュメント上も「既存の認証フローに電話/SMS/アプリなどの追加認証を足す」「RADIUS とクラウド MFA のアダプター」という位置づけで説明されています。MFA の二段目はクラウド側で実施されますが、そこで使われるのは“ユーザーに構成されている（登録されている）検証方法”です。
特に押さえておきたいのが、NPS Extension の最近の挙動です。Microsoft のドキュメントでは、一定バージョン以降の NPS Extension では、RADIUS 接続時に TOTP を優先する（TOTP に寄せる）動きが明記されています。
- NPS は number matching をサポートしない
- 一方で、最新の NPS Extension は Microsoft Authenticator の TOTP など、TOTP 方式をサポートする
- そして「RADIUS 接続 + 一定バージョン以降」では、ユーザーに TOTP が登録されていれば TOTP でのサインインが促される
ここで重要なのは、“ユーザーが TOTP を登録しているか”が分岐条件になっている点です。認証方法ポリシーのスコープではなく、「登録済みかどうか」が前に出てきます。
なぜ「許可していないはずのユーザー」が TOTP を使えてしまうのか
現象だけを見ると混乱しがちですが、認証フローに沿って分解するとシンプルです。
| ステップ | 処理の主体 | 実際に起きていること | “ポリシーが効かない”と見える理由 |
|---|---|---|---|
| 一次認証 | NPS（AD DS） | ユーザー名/パスワードの妥当性確認 | ここでは MFA 手段の可否は判断しない |
| 二次認証要求 | NPS Extension | クラウド MFA を呼び出して追加認証を要求 | 認証方法ポリシーのスコープを参照しない |
| 二次認証の成立 | クラウド MFA | ユーザーに紐づく登録済み方法（TOTP 等）で検証 | 「登録済み」が残っている限り、グループ外でも成立しうる |
Microsoft Learn Q&A の説明もこの筋道に沿っています。NPS Extension は Authentication Methods Policy を強制せず、ユーザーに登録されている強固な方法があるか（Registered）を確認してプロンプトを出す、という整理です。
つまり、現場で起きる“すり抜け”は次のどちらか、または複合です。
- 過去に登録した TOTP が Security Info 側に残っている（ポリシーで後から絞っても、NPS 経由では参照されない）
- 「どの TOTP を制御しているのか」が想定とズレている（Authenticator OTP と、第三者ソフトウェア OATH などの区分）
「Microsoft Authenticator の確認コード」と「ソフトウェア OATH トークン」は、設定上の区分がズレやすい
Entra ID の認証方法ポリシーは、いわゆる “OTP/TOTP” を 1 つの塊として扱うのではなく、種類ごとにコントロールが分かれています。Microsoft の移行ガイドでも、OATH トークンについて「Microsoft Authenticator の OTP」「第三者ソフトウェア」「ハードウェア」などが分割管理であることが説明されています。
ここで起きがちな誤解は、「ソフトウェア OATH トークンを特定グループだけ許可」にしたつもりでも、実際には“Microsoft Authenticator の OTP を別枠で許可していた”、あるいは“旧来登録（Security Info）を NPS が参照しているため、そもそもポリシーの許可/不許可と関係なく通る”という二重構造です。
社内向けに説明するときは、次のように言い換えると伝わりやすいです。
- 認証方法ポリシーは「クラウドサインイン時に、そのユーザーに何を使わせるか」を管理するための仕組み
- NPS Extension は「オンプレ RADIUS の二段目を成立させる」ために、ユーザーの“登録済み”情報を見にいく仕組み
- このため、ポリシーを絞っても、登録が残っていると NPS 側では TOTP が使えてしまうことがある
切り分けチェックリスト：原因を最短で特定する
「グループ外ユーザーでも TOTP が使える」を調査するときは、闇雲にポリシーをいじるより、次の順で“事実確認”をすると収束が速いです。
| 確認ポイント | 見る場所 | 分かること | 次のアクション |
|---|---|---|---|
| ユーザーに TOTP が登録されているか | Entra 管理センターのユーザー認証方法/登録情報 | 「登録済み」なら NPS 経由で通る余地が高い | 不要なら登録情報の棚卸・削除を検討 |
| NPS Extension の挙動が TOTP 優先になっていないか | NPS Extension のバージョン/設計 | 条件により TOTP を促す仕様がある | “想定したユーザー体験”を見直す（Approve/Deny 前提は危険） |
| 認証方法ポリシーで何を制御しているつもりか | Authentication methods policy | Authenticator OTP と OATH の区分・対象グループ | 意図した方法のみ許可/除外を再設計 |
| Conditional Access で制御できていると思い込んでいないか | CA ポリシー設計 | NPS 経由は CA の評価対象になりにくい | “NPS 側で制御”するか、“ネイティブ連携へ寄せる” |
特に 4 行目は盲点になりやすいポイントです。Microsoft Learn Q&A でも「NPS Extension は Conditional Access ポリシーを見ない（相互作用しない）」旨が明示されています。NPS を通す時点で、CA の“場所/デバイス/リスク”などの文脈評価は期待しづらく、「NPS が二段階目をやったかどうか」だけが結果として扱われる、という整理になります。
短期の対処：RADIUS + NPS Extension を維持したまま、事故を減らす現実解
「すぐに SAML/OIDC へ移行できない」ことは珍しくありません。短期は、割り切りと運用統制で被害を抑えるのが現実的です。
登録情報（Security Info）を“棚卸して消す”という発想を持つ
NPS Extension が参照するのが認証方法ポリシーではなく登録情報である以上、「許可されていないのに登録が残っている」状態が最大のリスクです。運用としては次の 2 点がセットになります。
- 許可対象外ユーザーの登録情報（TOTP 等）を棚卸し、不要なら削除する
- 同時に、認証方法ポリシー側も整備し、対象外ユーザーが再登録できない状態を作る（ただし NPS 経由では強制材料になりにくい点は理解した上で）
“登録情報の棚卸”をやらないままポリシーだけ絞ると、「ポリシー上は許可していないのに使える」という矛盾が温存され、監査・説明コストが増えます。
「TOTP を禁止したい」よりも「どういう第二要素を標準にするか」を先に決める
RADIUS/NPS の世界では、SAML/OIDC のように “認証強度” を細かく揃えるのが難しくなります。さらに NPS Extension は、状況によって TOTP を促す仕様が記載されています。したがって、短期の落としどころは次のどちらかになりがちです。
- TOTP を標準（推奨）として受け入れ、登録・配布・紛失時の再登録手順を固める
- どうしても TOTP を使わせたくない事情があるなら、“NPS Extension で何ができて何ができないか”を前提に要件を調整する（例：RADIUS 経由では方法制御を諦め、利用者層や接続元の統制に寄せる）
どちらを選ぶにしても、「認証方法ポリシーで TOTP を絞れば RADIUS でも同じように絞れるはず」という期待を捨てるのが重要です。
“やれる制御”は NPS 側に寄る（例：誰に MFA を要求するか）
Microsoft Learn の回答でも「NPS Extension 経由で利用される認証方法の制御は Entra 側ではなく NPS 側」という趣旨が示されています。裏を返すと、RADIUS の世界で現実的にできるのは、次のようなネットワークポリシー/到達経路の設計です。
- 特定の RADIUS クライアント（Citrix Gateway など）だけ MFA を必須にする
- 管理者/特権ユーザーの接続経路と一般ユーザーの接続経路を分ける
- 必要なら、MFA を要求する NPS と要求しない NPS を分ける（構成分離で制御）
“認証方法そのものの粒度”は難しくても、「誰が」「どこから」「どの経路で」は、RADIUS/NPS の得意領域として設計できます。
中長期の推奨：認証方法ポリシーや CA を活かすなら、Citrix を Entra ネイティブ連携へ寄せる
認証方法ポリシーで「グループ単位の許可/除外」「優先順位」「新しい認証（パスキー等）」まで活かしたい場合、RADIUS + NPS Extension は構造的に不利です。Microsoft Learn Q&A でも、NPS Extension が Conditional Access を見ない設計であることが明言されており、クラウド主導の統制に寄せるには限界が出ます。
そのため中長期では、Citrix 側を次のいずれか（または組み合わせ）に寄せる判断が現実的です。
- Citrix と Entra ID を SAML で連携し、Entra 側で MFA・条件付きアクセス・認証方法の制御を完結させる
- OIDC などのモダン認証に寄せる（Citrix の提供形態や要件による）
- 「社外からのアクセスだけ厳格に」などの要件は、条件付きアクセスの設計に寄せて運用を単純化する
| 観点 | RADIUS + NPS Extension | SAML/OIDC + 条件付きアクセス |
|---|---|---|
| 認証方法ポリシー（グループスコープ） | 期待どおりに効かないことがある（登録情報ベース） | Entra サインインの文脈で適用しやすい |
| Conditional Access | 「見ない」設計のため統制が難しい | 場所/デバイス/リスクなどの制御が可能 |
| 監査・説明 | “なぜ許可外で通るのか”の説明が必要になりがち | ポリシー＝挙動になりやすく説明が簡単 |
| 移行コスト | 現状維持は容易 | 設計・検証・切替のプロジェクトが必要 |
ポイントは、「今すぐ NPS を捨てる」ではなく、将来やりたい統制（方法制御/認証強度/リスクベース）に対して、RADIUS 方式がどこまで追随できるかを軸に意思決定することです。NPS Extension が認証方法ポリシーを尊重するようになる確定情報がない以上、“いつか改善される前提”で待つのはリスクになります。
社内ドキュメントにそのまま書ける要点
- NPS Extension for Azure MFA は、Entra ID の Authentication Methods Policy（認証方法ポリシー）のスコープを現時点で強制しない。
- NPS 経由の MFA で参照されるのは、ユーザーの登録済み MFA 方法（Security Info 相当）であり、登録が残っている限り TOTP が成立しうる。
- そのため「認証方法ポリシーでグループ外を除外したのに TOTP が通る」は仕様として説明可能。
- 認証方法ポリシー/Conditional Access による厳密な方法制御を実現したい場合は、Citrix 側を SAML/OIDC など Entra ネイティブ連携へ移行する検討が必要。
この要点を前提に、短期は「登録情報の棚卸と運用統制」、中長期は「モダン認証への寄せ」を計画すると、監査・障害対応・利用者体験のいずれも破綻しにくくなります。
よくある質問
認証方法ポリシーで TOTP を許可していないのに、Citrix（NPS）では使えてしまうのはバグ？
同様の事象に対し、Microsoft Learn の Q&A では「NPS Extension は認証方法ポリシーのスコープを強制せず、登録済みの方法（Security Info）を参照する」趣旨が回答されています。したがって、少なくとも現時点では“設計上起こりうる挙動”として整理するのが安全です。
「ユーザーの Security Info に登録がある限り通る」なら、ポリシーでの制御は無意味？
無意味ではありません。SAML/OIDC など Entra が主導するサインインでは、認証方法ポリシーでの制御が効く場面が増えます。また、再登録を抑止する目的でもポリシー整備は重要です。ただし RADIUS + NPS Extension という経路に限っては、挙動が一致しない前提で説明・運用する必要があります。
将来的に NPS Extension は認証方法ポリシーを尊重するようになる？
Microsoft Learn の Q&A では「確定したロードマップはない」趣旨が回答されています。よって、ロードマップ待ちを前提に設計するのではなく、必要な統制がある場合は SAML/OIDC + 条件付きアクセスへの寄せを中長期計画に含めるのが現実的です。
コメント