Microsoft Entra IDでMFAを全社適用しつつ、サービスアカウントは条件付きアクセスで除外しているのに「セキュリティ情報の登録（MFA登録）」が毎回出る…。その原因はMFAではなくSSPR設定にあることが多いです。登録画面を完全に出さないための実践手順と確認ポイントをまとめます。
事象の整理：MFAの“除外”をしているのに登録画面が毎回出る
組織全体で多要素認証（MFA）を有効化し、特定のサービスアカウント（システム連携・RPA・監視・バッチ処理など）だけは例外として運用していると、次のような状況になりがちです。
- 条件付きアクセス（Conditional Access / CA）ポリシーで、当該アカウント（またはグループ）をMFA必須の対象から除外している
- Microsoft 365 管理センターの「アクティブなユーザー > 多要素認証（ユーザーごとのMFA）」でも、当該ユーザーの状態を無効にしている
それにもかかわらず、サインインのたびに以下のような画面が表示され、毎回「スキップ」を押す必要が出てしまうことがあります。
- 「詳細情報が必要です」
- 「アカウントのセキュリティ保護」
- 「セキュリティ情報（認証方法）の追加」
- 「Microsoft Authenticator の設定」
ここで押さえておきたいのは、“MFAが要求されている”のではなく、“セキュリティ情報の登録が要求されている”という点です。見た目がMFA登録と同じでも、要求している主体がMFA（CA）とは限りません。
よくある誤解：MFAを除外すれば登録画面も消える
Microsoft Entra ID（旧 Azure AD）では、MFAとSSPR（セルフサービス パスワード リセット）と「セキュリティ情報（Authentication methods）」が強く結び付いています。特に“MFA用の登録”と“SSPR用の登録”が同じ登録フロー（統合登録）で表示されるため、原因がMFAなのかSSPRなのか見分けづらくなります。
| 区分 | 画面の特徴 | 主なトリガー | 管理者が最初に見るべき場所 |
|---|---|---|---|
| MFA（追加認証の強制） | サインインを進めるのに承認/コードが必須（スキップ不可） | 条件付きアクセス、ユーザーごとのMFA、Identity Protection 等 | 条件付きアクセスのポリシー評価、ユーザーごとのMFA状態 |
| 登録要求（セキュリティ情報の登録） | 「登録してください」「詳細情報が必要」だがスキップ可能な場合がある | SSPRの登録要求、登録キャンペーン、統合登録の設定 等 | SSPRの対象範囲、認証方法ポリシー、キャンペーン対象 |
| SSPR（パスワードリセットの準備） | “パスワードのリセットに備えて”と書かれるが、画面はMFA登録と同じ | SSPRが全ユーザー対象、サインイン時の登録要求 | SSPRの「対象（All/Selected）」と「登録要求」の設定 |
本記事の主題はこのうち「登録要求（セキュリティ情報の登録）」を完全に出さない方法です。結論から言うと、サービスアカウントを“登録要求のスコープ外”にするのが最も確実です。
原因：SSPR（セルフサービス パスワード リセット）が「すべてのユーザー」対象になっている
実際に解決したケースでは、原因はSSPR の有効化対象でした。
SSPR が「すべてのユーザー」に対して有効になっていると、たとえ以下が成立していても…
- 条件付きアクセスでMFA必須ポリシーから除外している
- ユーザーごとのMFAも無効化している
「パスワードリセット用のセキュリティ情報を登録してください」という目的で、登録画面が出続けることがあります。ユーザーから見るとMFA登録と同じ画面なので、混乱が起きます。
なぜSSPRが登録画面を出すのか
SSPRは「本人であることの確認（認証）」が前提です。登録がないユーザーにパスワードリセットを許すと、なりすましでパスワードを乗っ取られる危険があるため、管理者がSSPRを有効化すると、対象ユーザーに対して“事前登録”を求める動線が生まれます。
また、統合登録（MFAとSSPRで同じ登録画面を使う）を有効にしている環境では、SSPR目的でも「Microsoft Authenticatorを追加」などMFAっぽい表現が表示されます。ここが一番の落とし穴です。
重要：SSPRは個別ユーザーを除外できない
SSPRの有効化対象は基本的に「すべてのユーザー」か「選択したグループ」の2択です。つまり、SSPRをAll usersで有効にしている限り、“この1ユーザーだけSSPR対象外”という除外はできません。
したがってサービスアカウントだけを確実に外したい場合は、SSPRの対象を「選択したグループ」に切り替え、SSPRを使わせたいユーザーだけをグループに入れる構成へ変更するのが正攻法になります。
解決策：SSPR対象を動的グループへ変更し、サービスアカウントをスコープ外にする
実際に解決した構成は次の通りです。
- 社員アカウント：SSPR対象（＝登録画面が必要なら出る）
- サービスアカウント／システムアカウント：SSPR対象外（＝登録画面を出さない）
作業：SSPRを使わせたいユーザーだけを含む動的グループを作成する
Microsoft Entra 管理センターで、SSPR対象のグループを作成します。運用面では動的グループが特におすすめです（入退社・異動があっても自動追従しやすいため）。
グループ設計の考え方はシンプルです。
- SSPRを許可したいユーザーを「含める条件」を決める
- サービスアカウントやブレークグラスなど、SSPRを許可したくないユーザーは「含めない条件」にする
実務で採用しやすい判別パターンを表にまとめます。
| 判別方法 | 条件の例 | メリット | 注意点 |
|---|---|---|---|
| 命名規則（UPN/表示名） | svc- / rpa- / system- で始まるアカウントは除外 | 導入が最速。既存環境でも即対応しやすい | 命名が崩れると漏れる。例外が増えると管理が辛い |
| 人事属性（employeeType/department等） | employeeType=Employee を対象、Service を除外 | 運用が堅い。命名に依存しない | 属性が正しく同期されていることが前提 |
| 拡張属性（extensionAttribute等） | extensionAttribute15=SSPR_Enabled を対象 | 例外が多くても柔軟に制御できる | 属性を更新する運用フローが必要 |
| 専用OU/同期範囲 | オンプレAD同期で、社員OUのみを対象にする | 根本的に住み分けしやすい | OU設計や同期ルールに影響。既存運用の見直しが必要 |
動的グループ ルール例（命名規則でサービスアカウントを除外するパターン）
(user.userType -eq "Member") and (user.accountEnabled -eq true) and (user.userPrincipalName -notStartsWith "svc-") and (user.userPrincipalName -notStartsWith "rpa-") and (user.userPrincipalName -notStartsWith "system-")動的グループ ルール例（拡張属性で「SSPR対象」を明示するパターン）
(user.userType -eq "Member") and (user.accountEnabled -eq true) and (user.extensionAttribute15 -eq "SSPR_Enabled")どのパターンを採るにしても、「サービスアカウント判別に使えるルールを持つ」ことが重要です。SSPRだけでなく、条件付きアクセスの例外や監査でも同じルールが使えます。
作業：SSPRの対象を「すべてのユーザー」から「選択したグループ」へ変更する
次に、SSPRの有効化対象をグループに切り替えます。ポータルの表示は更新で変わることがありますが、概ね次の流れで設定できます。
- Microsoft Entra 管理センター（Entra）で「パスワード リセット（SSPR）」の設定画面へ移動する
- SSPRの有効化対象を「すべてのユーザー」から「選択したグループ」へ変更する
- 先ほど作成した動的グループを指定して保存する
これにより、SSPR対象ユーザー（社員アカウント）のみに登録要求が出るようになり、サービスアカウントではMFA登録画面（に見える登録画面）が出なくなります。
副作用として理解しておくべきこと
サービスアカウントをSSPR対象外にすると、そのアカウントはセルフサービスでパスワードリセットできなくなります。サービスアカウントはそもそも人が使う前提ではないことが多いため、運用としては自然です。
- サービスアカウントのパスワード変更は、管理者管理（手順・申請・監査）に寄せる
- 可能なら、ユーザー型サービスアカウントを減らし、アプリ登録やマネージドIDへ移行する
反映確認とテストのコツ
- 動的グループの評価には時間がかかる場合があります。設定変更直後に結果が変わらない場合は、少し時間を置いてから再テストします。
- テストはInPrivate/シークレットで実施し、セッションやキャッシュの影響を避けます。
- 「一度出ない」ではなく、同一アカウントで複数回サインインし、毎回出ていた画面が出なくなったことを確認します。
同様の事象が起きたときに総ざらいで確認するポイント
登録画面が出る仕組みはSSPR以外にも複数あります。原因を取り違えると、CAの例外を増やしてしまったり、不要な設定を触ってしまうので、次の観点で一度棚卸しするのがおすすめです。
条件付きアクセス（CA）
- 「すべてのクラウドアプリ」対象のMFA必須ポリシーが存在し、サービスアカウントが除外漏れしていないか
- ユーザーとグループのスコープが“直接指定”と“グループ経由”で二重に掛かっていないか
- 除外を増やす前に、サービスアカウントを専用グループへ集約し、例外を一括管理できる形になっているか
ユーザーごとのMFA（クラシックMFA設定）
- Microsoft 365 管理センターの「アクティブなユーザー > 多要素認証」で、状態が「有効」「強制」になっていないか
- 過去の検証で一時的に有効化したままのアカウントが残っていないか
CA運用に寄せる場合、ユーザーごとのMFAは“なるべく使わない/混在させない”のが運用のコツです。
Microsoft Entra ID 保護（Identity Protection）
- サインインリスク/ユーザーリスクに応じてMFAを必須化するポリシーがあり、対象に入っていないか
- サービスアカウントはそもそもリスク判定と相性が悪い（想定外の場所・アプリから動く）ため、運用要件と合わせて設計し直す余地がないか
SSPR（セルフサービス パスワード リセット）
- SSPRの対象が「すべてのユーザー」になっていないか
- SSPR対象を「選択したグループ」にし、必要なユーザーだけを含むグループ（静的/動的）に切り替えられないか
セキュリティの既定値（Security defaults）
条件付きアクセスでMFAを運用しているテナントでは、セキュリティの既定値が有効のままだと、意図しない登録要求や追加要件が出ることがあります。運用方針として、CA運用に統一するなら既定値は無効化して整理するのが一般的です。
認証方法の登録キャンペーン（登録促進）
ユーザーにMicrosoft Authenticatorなどの登録を促す「登録キャンペーン」を有効にしている場合、対象ユーザーに登録の促しが出ることがあります。サービスアカウントは基本的に対象に入れる必要がないため、キャンペーンのスコープをグループで管理できているかを確認します。
切り分けを早める実務テクニック
サインインログで“適用されたポリシー”を確認する
「誰が何を要求したか」は、サインインログを見るのが近道です。条件付きアクセスの評価結果（どのポリシーが適用/未適用だったか）を確認すると、MFA強制がCA由来なのか、登録要求がSSPRや別機能由来なのか、判断しやすくなります。
サービスアカウントの利用実態を合わせて点検する
登録画面が出るタイミングで、サービスアカウントが以下のような想定外の使われ方をしていないかも見直すと、事故を減らせます。
- 人がブラウザでログインして操作していないか（本来は非対話型のはず）
- 実行元のIPや国がぶれていないか（漏えい・誤設定の兆候）
- 失敗回数が増えていないか（パスワード不一致・攻撃の兆候）
サービスアカウントをMFA除外で運用する場合の防御線
今回のように「登録画面を出さない」は達成できても、MFA除外の運用はリスクを伴います。どうしてもユーザー型サービスアカウントが必要な場合は、次の補強策を組み合わせると現実的です。
- 条件付きアクセスでサインイン場所（IP/ネットワーク）を制限する
- 利用するクラウドアプリを最小化し、「すべてのクラウドアプリ」対象を避ける
- レガシー認証をブロックする（可能なら全面停止）
- 長期運用のパスワードはローテーションと監査ログの監視を仕組み化する
さらに可能であれば、ユーザー型サービスアカウントを減らし、アプリ登録（証明書）やマネージドIDなど対話型サインインを必要としない方式へ寄せると、登録画面の問題だけでなく運用全体が安定します。
まとめ：MFA除外なのに登録画面が出るなら、まずSSPRの対象範囲を疑う
- CAで除外し、ユーザーごとのMFAも無効なのに登録画面が出る場合、MFAではなくSSPRなどが登録を要求しているケースが多い
- SSPRを「すべてのユーザー」で有効にしていると、サービスアカウントだけを個別に除外できず、登録画面が残りやすい
- 解決の近道は、SSPR対象を「選択したグループ」に切り替え、SSPRを使わせたいユーザーだけを含む（動的）グループでスコープ管理すること
サービスアカウントは例外が増えやすい領域です。今回のように「全体設定だと逃げ道がない」ポイントを押さえ、スコープをグループで制御する設計に寄せることで、設定漏れと運用負荷を同時に減らせます。
コメント