Microsoft Entra（旧 Azure AD）のグローバル管理者がサインイン時にエラーコード「399287」で止まり、SMS 認証しか使えない――そんな“詰み”のように見える状況でも、正しい手順を踏めば確実に復旧できます。本記事は、実務で使えるバックエンド解除の進め方から、再ログイン後のベストプラクティス、再発防止の設計までを一気通貫でまとめた実践ガイドです。
状況整理：どんな問題が起きているのか
主訴は次のとおりです。
- グローバル管理者がサインインできず、エラーコード 399287 が表示される。
- SMS 以外の多要素認証（MFA）が使えず、Microsoft Authenticator アプリにも入れない。
- テナント側で何らかの判定により MFA がブロックされ、管理ポータルへ到達できない。
この現象の多くは、Entra ID のリスク評価や電話番号のレピュテーション（評判）に起因する自動ブロック、またはサポート／エンジニアリング側での安全装置が働いた結果として発生します。特に SMS/音声通話は電話網の悪用（IRSF: International Revenue Share Fraud）や SIM スワップ等のリスクの影響を受けやすく、正当なユーザーでもブロックされることがあります。
結論：最短で復旧するための手順（バックエンド解除）
もっとも再現性の高い復旧ルートは、Microsoft サポート経由でエンジニアリングチームに解除を依頼することです。現場では「悪性レピュテーションのクリア」「MFA ブロック解除」といった表現が使われます。解除が完了すると、まずは SMS 認証での再ログインが可能になります（復旧直後は最小限の到達を優先）。
サポート依頼前に準備すべき情報
手戻りを防ぐため、以下の情報を整理してから連絡しましょう。
| 項目 | 内容例 | 備考 |
|---|---|---|
| テナント名／テナント ID | contoso.onmicrosoft.com / xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | 両方提示できるとスムーズ |
| 対象管理者の UPN（メール） | [email protected] | エイリアスがあれば併記 |
| 登録電話番号と国名 | +81-90-xxxx-xxxx / 日本 | 国際表記で正確に |
| 発生日時とタイムゾーン | 2025-11-01 09:30 JST | ログ突合に必須 |
| エラー情報 | エラーコード 399287 のスクリーンショット | メッセージ本文も記録 |
| 接続元情報 | グローバル IP / 位置情報 | 異常検知回避の補助 |
| 代替連絡先 | 固定電話、別の管理者の連絡先 | 本人確認のため |
サポート依頼の進め方（現場テンプレート）
【件名】Entra ID グローバル管理者の MFA ブロック解除依頼（Error 399287）
【概要】
グローバル管理者（UPN: [[email protected]](mailto:[email protected])）がサインイン時にエラー 399287 で停止。
SMS 以外の MFA が利用できずポータルに到達できない。バックエンド側でのブロック解除（悪性レピュテーションのクリア）を希望。
【テナント】
* テナント名 / テナント ID: contoso.onmicrosoft.com / xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
【ユーザー情報】
* UPN: [[email protected]](mailto:[email protected])
* 電話番号（国際表記）: +81-90-xxxx-xxxx（国: 日本）
【事象】
* 発生日時: 2025-11-01 09:30 JST
* 画面エラー: 399287（スクリーンショット添付）
* 接続元 IP: xxx.xxx.xxx.xxx（日本国内）
【希望対応】
* 対象ユーザーの MFA ブロック解除（悪性レピュテーションのクリア）
* 必要であれば一時的に SMS を許可して再ログインを実施
【補足】
* 緊急アクセス手段の整備・SMS 廃止方針に移行予定やってはいけないこと
- 焦って多数の失敗サインインを繰り返す（ロックアウト延長の原因）。
- 不明な VPN／プロキシからの再試行（別のリスク判定を誘発）。
- 未承認の電話番号や共用端末での検証（なりすまし疑義を増幅）。
復旧後に必ず実施する 3 つの設定
SMS による再ログインが通ったら、そのセッションが有効なうちに次の設定を即日完了させます。目的は「フィッシング耐性の高い方法へ主軸を移し、かつ多系統化する」ことです。
1) Microsoft Authenticator アプリを主要手段にする
- プッシュ通知 + 番号マッチングを有効化し、承認画面に表示される番号を入力させる方式に切り替える。
- オフライン時に備えて アプリ内の「ワンタイムコード」（30秒更新）も登録する。
- 電話番号はバックアップ用途に限定し、承認優先順位を下げる。
2) フィッシング耐性 MFA（FIDO2 セキュリティキー／パスキー）を追加
- 業務端末に紐づく FIDO2 セキュリティキー（PIN + 生体）を 2 本以上登録。
- 端末の TPM／プラットフォーム認証器を使ったパスキー（Windows Hello 等）も登録して冗長化。
3) 認証方法を 2 系統以上に多重化
少なくとも「Authenticator アプリ + FIDO2（またはパスキー）」の 2 系統にします。電話網依存と端末内生体／秘密鍵系をミックスすると可用性が上がります。
認証方法の比較表
| 方法 | フィッシング耐性 | オフライン可 | 要デバイス | 運用ポイント |
|---|---|---|---|---|
| SMS / 音声通話 | 低 | 可 | 不要（電話網依存） | IRSF・SIM スワップに弱く、原則バックアップ用途 |
| Authenticator（プッシュ + 番号マッチング） | 中〜高 | 一部可（TOTP） | スマートフォン | 通知承認ルール・生体利用で効果向上 |
| FIDO2 セキュリティキー | 高 | 可 | 鍵デバイス | 2 本以上を登録し、保管ルールを定義 |
| パスキー（Windows Hello 等） | 高 | 可 | 当該端末 | 端末更新時の移行計画を用意 |
ブレークグラス（緊急用）アカウントの作り方
管理者のロックアウトはビジネス継続リスクです。MFA 無効のクラウド専用アカウントを 1〜2 つ用意し、条件付きアクセスから明示的に除外します。平常時はログイン禁止・サインインアラートのみ有効、緊急時だけ使える鍵として設計します。
設計ガイドライン
- アカウント名例：
[email protected]/[email protected] - パスワードは 32 文字以上・ランダム・使い回し禁止。紙封筒（耐火金庫）とオフライン金庫型パスワード管理の二重保管。
- 条件付きアクセス：全ポリシーから明示除外し、サインイン時にはただちにセキュリティ担当へ通知。
- ロール割り当ては最小限（必要時に PIM で昇格）。
- 四半期に一度、封印解除手順のリハーサル（監査ログを残し、終了後は必ずパスワード更新）。
運用時の監視ルール（例）
- ブレークグラスのサインイン成功・失敗を即時通知（メール＋Teams）。
- 対象アカウントのサインイン発生時は自動でインシデント起票。
- 非業務時間帯の使用を自動ブロック（就業規則に合わせた運用）。
再発防止：条件付きアクセスとポリシー設計
「SMS が唯一の救い」にならないよう、Authentication strengths（認証強度）と 条件付きアクセス（CA）で設計を見直します。
管理者向け CA ポリシー設計例
| 観点 | 推奨設定 | ねらい |
|---|---|---|
| 対象 | 特権ロール（全管理者ロール）を動的グループ化 | 管理対象を確実に包含 |
| クラウドアプリ | Azure ポータル、Microsoft Graph、管理者用アプリ全般 | 特権操作の入口を網羅 |
| アクセス制御 | フィッシング耐性 MFA を必須（FIDO2／パスキー等） | プッシュ疲れ・中間者攻撃を排除 |
| セッション | サインイン頻度 12 時間・永続化無効 | 奪取セッションの寿命短縮 |
| 場所 | 信頼済み場所（固定グローバル IP）以外は制限 | 地理・ネットワークのリスク低減 |
| 例外 | ブレークグラスのみ除外（監視は強化） | 非常時の可用性確保 |
SMS の利用を戦略的に縮小する
- 一般ユーザー向けは「Authenticator かパスキー」を既定にし、SMS は再登録時や旅行時のバックアップに限定。
- 管理者は SMS を完全禁止、または認証強度ポリシーで満たさない方法として拒否。
Identity Protection のリスクポリシー最適化
- サインインリスクが高いときにアクセスをブロックしつつ、管理者だけは信頼済み場所での追加検証に緩和。
- 旅行や突発的な移動に備えて「名前付きの場所」を適切に整備し、誤検知でのロックアウトを回避。
運用：ログ監視・アラート・定期点検
「MFA blocked」「リスク付きサインイン」を早期に検知し、エスカレーションを自動化します。
毎日見るべきダッシュボード項目
| 指標 | 見方 | 対応の目安 |
|---|---|---|
| MFA 挑戦の結果 | 成功／失敗比率の急変、特に管理者 | 急増時は接続元とメソッドを即時調査 |
| リスクの高いユーザー | 新規検出・継続者の推移 | 継続 24h 超は強制パスワードリセット等 |
| サインインリスクの場所分布 | 国・ASN・匿名系 ASN の比率 | 匿名プロキシ比率の上昇は CA 強化 |
| ブレークグラス使用 | 成功/失敗の全件アラート | 直ちに事象レビューと是正 |
四半期の健康診断
- 登録済み認証方法の棚卸し（単一方法のみ＝改善対象）。
- FIDO2 鍵の所在確認・予備鍵の実在チェック。
- 条件付きアクセスのシミュレーション（What-if）でルール逸脱が無いか検証。
- ブレークグラスの封印点検・パスワード更新・手順リハーサル。
トラブルシューティング：よくある詰まりどころと対処
SMS が届かない／遅延する
- キャリア側の一時ブロック・フィルタを疑う。短時間に多数のコードを要求するとスパム扱いされることがある。
- ローミング中は遅延が発生しやすい。Wi-Fi 通信での Authenticator（TOTP）へ切り替える設計に。
Authenticator の再登録ができない
- 既存の端末紐づけが残っている場合は、管理センターのユーザープロファイルから古い認証方法を削除したうえで「再登録を要求」。
- 再登録後は必ず「番号マッチング」「場所・アプリ名表示」を有効化。
FIDO2 セキュリティキーの PIN を忘れた
- PIN リセットは鍵デバイス側の機能。初期化すると鍵内の登録が消えるため、予備鍵で運用継続し、初期化後に再登録。
管理者が複数いるが、全員がブロックされた
- ブレークグラスでログインし、条件付きアクセスの誤設定（循環的に全員ブロック）を解除。変更前に必ずエクスポート・バックアップを取得。
- それでも入れない場合は、サポートにバックエンド解除を再度要請。テナント全体のレピュテーションが関与しているケースもある。
実務 Tips：安全と迅速を両立する運用ディテール
- ロール分離：日常運用者は限定ロール、特権昇格は PIM で時間制。昇格時のみ強力な認証強度を要求。
- 出張モード：一時的に信頼できる国／場所を登録し、帰任時に予約解除。時間制限付きの CA フィルターを活用。
- 端末紛失を想定：Authenticator 端末紛失時の代替手段（FIDO2 予備鍵 + ブレークグラス）を手順化。
- 人の手順訓練：管理者には年 2 回の模擬フィッシング訓練と、番号マッチングの習熟トレーニングを実施。
- 監査可能性：MFA 設定変更・CA 変更・PIM 昇格は監査ログにひも付けてチケット番号を記録。
エラー 399287 を見たときの意思決定フロー（カード）
| フェーズ | 判定 | アクション | ゴール |
|---|---|---|---|
| 初動 | 管理者が誰も入れない／入れる人がいる | 入れる人がいれば CA/リスク設定の緩和と再登録を実施。誰も入れないならサポートへ直行。 | 管理平面への到達 |
| 復旧 | SMS で一時的に入れる | 即時で Authenticator + FIDO2 を追加、電話はバックアップに格下げ。 | 強い MFA に移行 |
| 恒久化 | CA と認証強度の不足がないか | 管理者はフィッシング耐性 MFA のみ許可。ブレークグラス整備。監視とアラートを自動化。 | 再発の芽を摘む |
現場で効くチェックリスト
- ☑ サポートへ提出する情報（テナント ID・UPN・電話・国・発生日時・IP・エラー画面）を揃えた。
- ☑ 解除後すぐに Authenticator の番号マッチングを有効化した。
- ☑ FIDO2 鍵を 2 本以上登録し、保管場所を分離した。
- ☑ 認証方法は 2 系統以上（電話網依存と端末内秘密鍵の併用）。
- ☑ 管理者用 CA はフィッシング耐性 MFA を必須にした。
- ☑ ブレークグラスは 1〜2 アカウント、CA 除外＋厳格な監視を実装した。
- ☑ Identity Protection とサインインログの監視・アラートを整備した。
- ☑ 四半期の健康診断（棚卸し・シミュレーション・封印点検）を日程化した。
補足：なぜ SMS は推奨しないのか
2025 年現在、Microsoft は SMS/音声 MFA を「突然の電波障害・SIM 交換・フィッシングに弱いレガシー手段」と位置づけています。特に IRSF（国際料金詐取）は被害額が大きく、正当ユーザーのトラフィックまで抑止される事例が後を絶ちません。復旧の取っ掛かりとして SMS を使うこと自体は現実解ですが、恒久手段としては排除し、Authenticator（番号マッチング）とパスキー／FIDO2 に移行するのが最善です。
まとめ
エラー 399287 と SMS しか使えない状況は、適切な情報を揃えてサポートに依頼すればバックエンドで解除できます。復旧の直後こそが設計の見直しチャンスです。Authenticator を主軸化し、FIDO2／パスキーを追加、条件付きアクセスでフィッシング耐性 MFA を必須に。さらにブレークグラスを整備し、ログ監視とアラートを日常運用に織り込めば、同種のロックアウトは「起きにくく、起きても復旧が速い」状態にできます。
コメント