Microsoft 365 管理センター（レガシー）の MFA から Entra ID（条件付きアクセス＋Authentication methods policy）へ移行し、状態を「Completed」に切り替えた直後から、管理者が管理ポータルへ入れず“アプリ パスワード作成ループ”に陥ることがあります。本記事では AADSTS50072 の読み解き、原因の整理、復旧手順、再発防止と緊急用（break glass）設計の要点を解説します。
起きていること：管理ポータルに入れず「アプリ パスワードを作成せよ」ループになる
まずは現象を言語化しておきます。今回のようなケースでは、移行状態が「In progress」の間は問題なくサインインできていたのに、「Completed」にした瞬間から一部の管理者アカウント（および緊急用の break glass アカウント）だけが詰みます。
- Microsoft 365 管理センター、SharePoint 管理センターなどの管理ポータルに入れない
- Microsoft Authenticator の通知やコード入力まで進まず、「アプリ パスワードを作成する」画面へ誘導される
- アプリ パスワードを作成しても、再び作成画面に戻ってしまい無限ループになる
- サインインログでは AADSTS50072（UserStrongAuthEnrollmentRequiredInterrupt） が出ている
ポイントは、これは「パスワードが間違っている」でも「MFA が壊れている」でもなく、“MFA 登録（第二要素の登録）が必要なのに、登録に使える手段がない（または対象外になっている）”という構造問題であることです。
「In progress」では通るのに「Completed」で破綻する理由
MFA の管理がレガシー（旧 Microsoft 365 管理センターの検証オプション）から Entra 側（Authentication methods policy＋条件付きアクセス）へ移行される過程では、状態によって挙動が変わります。
| 移行状態 | サインイン時に参照されやすい領域 | 起きがちなこと | 運用上の注意 |
|---|---|---|---|
| In progress | レガシー設定とモダン設定が“混在”しやすい | 当面は通る（ただし実態は暫定） | 「通っている＝移行完了」ではない。穴を残したままになりやすい |
| Completed | モダン側（Authentication methods policy／条件付きアクセス）を前提に動く | モダン側が未整備だと一部アカウントが即死する | 切替直後に管理者が入れなくなるリスクが最大 |
つまり「Completed」に切り替えた瞬間、“モダン側の要件が本番として適用される”ため、これまでレガシー側でなんとか成立していた帳尻合わせが一気に崩れます。
AADSTS50072（UserStrongAuthEnrollmentRequiredInterrupt）を現場目線で読み解く
AADSTS50072 は、ざっくり言うと「このユーザーは強力な認証（MFA）登録を完了していないので、登録が必要」という割り込みです。管理者ポリシーの変更、登録情報のリセット、認証方法の移行、セキュリティ要件の強化などで起きやすくなります。
重要なのは、AADSTS50072 が出ているとき、ユーザーに必要なのは “追加の認証” ではなく、まず “認証方法の登録（enroll）”です。ところが次の状態だと詰みます。
- ユーザーが登録に使える方法が 1つも許可されていない
- 許可はされているが、そのユーザーが実際には 対象外グループ（除外）に入っている
- 登録に使えるはずの方法が、運用上の制約で 使えない（端末がない／番号がない／社外で受け取れない）
この“登録できないのに登録が要求される”矛盾が、結果として「アプリ パスワード作成ループ」などの不自然なフロー崩壊として表面化します。
根本原因：Completed 時点で「モダン側の認証方法」が成立していない
結論を先に整理します。
「Completed」にした時点で、モダン側（Authentication methods policy）の設定が正しく移行／有効化されておらず、当該ユーザー（管理者・break glass）が MFA 登録に使える手段を持っていない（または除外されている）ことが原因です。
この状態になると、サインインのシナリオはこうなります。
- 条件付きアクセス等で「MFA が必要」になる
- しかしユーザーは MFA 未登録 → AADSTS50072（登録割り込み）
- 登録に使える方法がない／登録画面へ正しく遷移できない
- 結果として “アプリ パスワード作成” などの不適切な分岐に落ちる
- 作成しても本質（MFA 登録）が解決しないため、ループする
特に管理者だけ、あるいはbreak glass だけが詰まる場合は、方法ポリシーが「全社」ではなくグループ単位で許可／除外されていて、管理者や緊急アカウントが想定外のグループに入っているケースが非常に多いです。
復旧の全体像：最短で直すための「やること」3本柱
対処の要点は、次の3本柱に集約できます。
- レガシー側の検証オプション／旧 SSPR 設定を整理して無効化（または移行ガイドに沿って最小化）
- Authentication methods policy で、管理者と break glass が“登録できる方法”を除外なしで有効化
- 上記を整えてから、移行状態を「Completed」に戻して再テスト
「In progress に戻すと一時的に入れるようになった」という挙動は、Completed で強制されるモダン側の要件が緩むために起きる“暫定復旧”です。根治のためには、Completed 前提で成立する設定に整える必要があります。
手順：ロックアウトを避けながら安全に復旧する
ここからは、WordPress 記事としてそのまま運用に落とし込めるよう、実作業の流れを「事故りにくい順番」でまとめます。
作業前の安全策（最重要）
- 影響を受けていない管理者アカウントを最低1つ確保（可能なら2つ）
- 切替作業は、サポート窓口／復旧手段が使える時間帯に実施
- 「Completed」に切り替える前に、管理者のサインインテストを実施（通常ユーザーではなく管理者で）
- break glass の扱いは、“存在するだけ”では意味がない（実際にサインインでき、必要な操作ができることが条件）
復旧手順（推奨の流れ）
手順A：一時的に「In progress」に戻して復旧用の窓を作る（できる場合）
- すでに管理者が入れない状態なら、まずは管理できるアカウントでサインインし、移行状態を一時的に「In progress」に戻します。
- 目的は“元に戻すこと”ではなく、モダン側の設定を直すための作業窓を確保することです。
手順B：レガシー側の MFA／SSPR 設定を整理する
Completed を前提にするなら、レガシー側の検証オプションが残っていると「いつまでも帳尻合わせが必要な状態」になりがちです。ここは移行ガイドの前提に合わせて、不要な旧設定を外すのが基本です。
- レガシー側に残っている「許可する検証方法」「アプリ パスワード」などの設定が、現在の運用に本当に必要か確認
- 条件付きアクセス＋モダン認証を前提とするなら、アプリ パスワード前提の運用は縮小／廃止を検討
- SSPR の旧設定が残っている場合も、モダン側のポリシーと二重管理にならないよう整理
手順C：Authentication methods policy を「登録できる」観点で見直す
ここが今回の本丸です。多くの事故は「ログインで使う方法」だけ見ていて、「登録（enroll）に使える方法」が抜けています。
見直しの観点は次の2つです。
- 方法が有効化されているか（Microsoft Authenticator / SMS / FIDO2 / CBA / Temporary Access Pass など）
- 対象のスコープに管理者・break glass が含まれているか（除外グループに入っていないか）
| チェック項目 | 見るべきポイント | 合格ライン（目安） | よくある落とし穴 |
|---|---|---|---|
| Authenticator が有効 | 対象ユーザー/グループ | 管理者・break glass が対象に含まれる | 管理者が除外グループに入っていて登録できない |
| SMS 等の代替手段 | 登録・利用の許可 | 少なくとも復旧期間は有効（必要なら） | 「強固にしたい」意識で全て無効化し、詰む |
| Temporary Access Pass | ブートストラップ用途 | 管理者の再登録用に使える | 有効化しておらず、本人が登録できない |
| FIDO2 / Passkey | 高強度・運用設計 | 管理者の標準手段として採用 | 配布・保管・紛失時手順が未整備 |
| 証明書ベース認証（CBA） | 端末・証明書の管理 | 管理者や緊急用の選択肢として設計 | 証明書失効・更新時の運用が弱い |
手順D：対象ユーザーに「登録」を完了させる
ポリシーを直しただけでは、既に AADSTS50072 で割り込まれているユーザーは自動的に直りません。“登録可能な状態”を作った上で、実際に登録を完了させます。
- 対象の管理者に、セキュリティ情報（認証方法）の登録画面から Microsoft Authenticator 等を登録させる
- 可能なら第一手段＋バックアップ手段の2つを登録（例：Authenticator＋FIDO2、Authenticator＋別デバイス）
- 登録後、管理ポータルへのサインインテストを実施（シークレットウィンドウ推奨）
手順E：移行状態を「Completed」に戻し、管理者で再テスト
- 対象の管理者で、Microsoft 365 管理センター／SharePoint 管理センターなど複数の管理ポータルで確認
- 問題が再発しないことを確認してから、同様の管理者へ水平展開
「アプリ パスワード作成ループ」特有のチェックポイント
この現象は“登録フローが成立していない”サインであることが多いですが、現場でハマりやすいポイントを絞っておきます。
アプリ パスワードは「原因」ではなく「誤誘導の結果」になりやすい
管理ポータルのブラウザサインインでアプリ パスワードが必要になる状況は一般的ではありません。にもかかわらず作成を要求される場合、以下を疑います。
- MFA が必須なのに、MFA 登録が完了できない
- レガシー側の設定や移行状態の整合性が崩れ、古い導線に落ちている
- 条件付きアクセスやセキュリティ要件により、登録割り込みが強制されている
「登録に使える方法」が1つでも存在するかを最優先で確認する
復旧に直結する最短チェックはこれです。
| 質問 | YES の場合 | NO の場合 |
|---|---|---|
| 当該ユーザーは、モダン側で登録可能な方法が最低1つ許可されているか？ | 登録画面へ進める可能性が高い | 必ず詰む。まず方法ポリシーのスコープを直す |
| 当該ユーザーは、許可された方法を実際に使える状況か？（端末・番号・トークンなど） | 登録を進められる | Temporary Access Pass や代替手段を検討 |
| 登録を完了した後に、管理ポータルで MFA が正常に求められるか？ | 復旧完了に近い | 条件付きアクセスや対象アプリ、認証強度を再点検 |
Temporary Access Pass（TAP）を“再登録の非常口”として用意する
管理者が外出先で SMS を受け取れない、Authenticator を入れた端末を紛失した、など「登録できるはずの手段が使えない」状況は現実に起こります。こうしたケースに強いのが Temporary Access Pass です。
- 短時間・使い捨てのパスコードとして発行し、ユーザーが認証方法を再登録するための入口にできる
- 「登録が必要だが登録できない」を解消しやすい
- 運用設計（発行権限・有効期限・発行ログ監査）が必須
“管理者が管理ポータルに入れない”系の障害は、発生後に慌てて復旧策を探すより、TAP を含めた復旧導線を先に設計しておくほうが圧倒的に安全です。
break glass（緊急用アカウント）設計の落とし穴と推奨パターン
今回のように break glass まで巻き込まれている場合、設計思想そのものを見直す価値があります。緊急用は「弱くする／外す」ではなく、“詰まない”と“強固”を両立させる設計が必要です。
break glass に求める要件
- 緊急時に確実にサインインできる（ここが満たせないと存在価値がない）
- 平時は使わない（日常運用に混ぜない）
- 侵害された場合のリスクが非常に高いので、保護と監査が強い
設計パターンの比較
| パターン | 考え方 | メリット | デメリット／注意 |
|---|---|---|---|
| 高強度手段で保護（FIDO2/パスキー、CBA 等） | 緊急用でも“強固な第二要素”を持たせる | 侵害耐性が高い。運用ルールを作れば堅牢 | トークン・証明書の保管運用が弱いと逆に詰む |
| アクセス経路の強制管理（保管・手順・監査を極端に強く） | 普段使わない前提で、保管と使用手順で守る | “使えること”を担保しやすい | 人・手順に依存しやすい。定期テストが必須 |
| 除外を多用して可用性優先 | 強い制限を外して“とにかく入れる”を優先 | ロックアウト回避には強い | 侵害時の被害が最大。監視と隔離が弱いと危険 |
現場では「可用性のために除外する」ケースが多い一方、今回のような移行期に除外設計だけが先行すると、別の要因（登録割り込みや移行要件）で break glass が動かず、“緊急用が緊急時に使えない”状態になりがちです。
おすすめは、次のように分解して設計することです。
- break glass のサインイン手段は、パスキー（FIDO2）や CBA など運用設計しやすい強固な方式を優先（次点で Authenticator）
- ただし、方式を強くするほど「保管・紛失・更新」の運用が重要になるため、手順書と定期テストをセットで作る
- “緊急用だから除外して弱くする”ではなく、“使えるが、普段は使わない・厳重に保護する”を徹底する
break glass 運用ルール（実務で効くやつ）
- 緊急用は2アカウント用意（片方が死んでももう片方で入れる）
- 資格情報は金庫（Password Vault）で管理し、参照履歴が残る仕組みにする
- 使用時はチケット起票・承認・二人運用（可能なら）
- サインインが発生したら即時アラート（平時に使わない前提なので検知精度が高い）
- 四半期〜半年に1回、実際にサインインできるかの訓練をする（訓練しないと“存在するだけ”になる）
移行の再発防止：Completed 切替で事故らないための事前チェックリスト
最後に、同じ問題を繰り返さないための「Completed 切替前チェック」を置いておきます。運用ドキュメントにそのまま貼れる形式です。
| チェック | 目的 | OK の条件 | 補足 |
|---|---|---|---|
| 管理者（複数名）がモダン方法で登録済み | 切替後に入れなくなる事故を防ぐ | 管理者が少なくとも2手段を登録している | 「登録済み」は本人の自己申告ではなく実際の確認が安全 |
| Authentication methods policy の対象に管理者が含まれる | 登録割り込みで詰まない | 管理者・break glass が除外されていない | 方法ごとの対象/除外を必ず確認 |
| 復旧用の手段（TAP 等）が準備されている | 端末紛失・出張時の再登録を可能に | 発行権限・手順・監査が整っている | “いざという時だけ”は、いざという時に失敗する |
| レガシー側の設定が整理されている | 二重管理・矛盾を減らす | 旧検証オプション/旧 SSPR の役割が明確 | 必要な例外がある場合は例外設計を文書化 |
| 切替のリハーサル（パイロット）を実施 | 本番一発勝負を避ける | パイロット管理者で Completed 相当をテスト済み | “管理者でのテスト”が重要 |
よくある質問
「In progress」に戻すと直るのですが、戻しっぱなしでもいいですか？
一時的な回避としては有効なことが多いですが、根本的な矛盾（モダン側の方法が成立していない）が残ります。運用が長引くほど、別の変更（ポリシー更新や登録キャンペーン等）で再発しやすくなるため、Completed 前提で成立する設定に直した上で移行を完了させるのが安全です。
アプリ パスワードを作れば解決しますか？
この症状に関しては、解決しないケースが大半です。アプリ パスワードは主にレガシーアプリ向けの措置であり、管理ポータルのサインイン問題の本質（MFA 登録割り込みと登録不能）を解消しません。「登録に使える方法があるか」を最優先で確認してください。
管理者だけが詰むのはなぜですか？
管理者は条件付きアクセスなどで MFA の要求が強くなりやすく、さらに認証方法の対象/除外がグループで制御されていると、一般ユーザーには影響が出なくても管理者だけが対象外になって詰むことがあります。方法ポリシーのスコープ（対象・除外）が最初に疑うべきポイントです。
break glass は「除外」すべきですか？「強い MFA」すべきですか？
“何を除外するか”よりも、“緊急時に確実に入れるか”を先に満たすべきです。その上で、侵害リスクが高いので、パスキー（FIDO2）や CBA 等の強固な方式、厳重な保管、使用時の手順、監査とアラートをセットで設計します。結論としては、「使えるが、普段は使わない・厳重に保護する」が現実的に事故が少ない方針です。
まとめ：Completed 切替の成否は「登録（enroll）設計」で決まる
今回のような「アプリ パスワード作成ループ」は、表面上は奇妙ですが、構造はシンプルです。Completed でモダン側の前提が強制され、AADSTS50072（登録割り込み）が起きたときに、登録に使える方法が当該ユーザーに許可されていない、あるいは運用上使えないためにフローが破綻しています。
レガシー設定の整理、Authentication methods policy のスコープ見直し、管理者・break glass の登録導線確保（必要なら TAP）まで揃えれば、同様のロックアウトは大幅に減らせます。移行は“切り替え作業”ではなく、登録（enroll）を成立させる運用設計だと捉えるのが成功の近道です。
コメント