Microsoft アカウント（Microsoft Entra ID）で、SMS／音声通話による多要素認証（MFA）が繰り返し失敗しエラーコード 399287が表示される――この症状は、ユーザーや回線の「悪評（Bad reputation）」に起因する電話系MFAのバックエンドブロックが背景にある場合が多く、通常のMFAリセットだけでは解消しません。本記事は、原因の理解から即時復旧、恒久対策（Authenticator優先化と条件付きアクセス）まで、現場でそのまま使える手順と運用ノウハウを体系的にまとめた実践ガイドです。
症状：MFAが通らない／エラーコード 399287
同僚のアカウントでサインインすると、SMSまたは音声通話による追加認証が求められるにもかかわらず、コードが届かない・通話が来ない・または入力しても失敗し、最終的に399287が表示されてログイン不可となります。管理部門には同様の申告が複数寄せられ、特定ユーザーまたは一部の回線・国際帯域に偏って再現することがあります。
現場で観測される典型的な挙動
- 別ユーザーや同一ユーザーでも別の電話番号では成功する。
- ユーザーのMFAをポータルでリセットしても解消しない。
- 数時間～数日ののち、突如成功することがある（自然回復）。
- 複数ユーザーが同一キャリア・同一国番号帯で失敗している。
原因：電話系MFAのバックエンドブロック（Bad reputation）
Microsoft側の不正対策により、特定の電話番号・回線・地域・送受信パターンが「悪評（Bad reputation）」としてマークされると、セキュリティ保護のためにSMS／音声通話ベースのMFAがバックエンドでブロックされることがあります。この状態では、テナント管理者が通常のUIからユーザー設定を初期化しても効果が限定的で、電話・SMSの経路自体が遮断され続けるため、入力の正誤に関わらず失敗が継続します。
このブロックは、Microsoftサポート経由でエンジニアリングチームに解除を依頼し、ブロックと悪評のクリアが完了すると復旧するのが通例です。解除後は、従前の番号でもSMS認証が再度成功するようになります。
すぐに復旧するための実践ステップ（運用ランブック）
一次切り分け（サービスデスク／情シス）
- 影響範囲の把握：同様の申告が他ユーザーでも発生していないか、キャリア・国番号の共通点がないかを整理します。
- サインインログの確認：該当ユーザーの直近の失敗イベントを特定し、日時（UTC）、クライアント種別、結果理由、MFAステータス、コリレーションID（Request ID/Trace ID）があれば控えます。
- ユーザー設定の基本対応：Entra管理センター → ユーザー → 該当ユーザー → Authentication methods でMFAの再登録を促す（必要に応じて「強制再登録」）。同時に Revoke sessions（セッション失効）を実行します。
- 回線側の確認：端末のSMS受信制限、キャリアの国際SMSフィルタ、迷惑SMS自動ブロック、着信拒否設定の有無を確認します。海外ローミングやVoIP番号（使っていれば）も要チェック。
ブロック解除の依頼（管理者／サポート担当）
- サポートケースを起票：カテゴリは認証／MFAの障害。タイトルは「Entra ID MFA（SMS/音声）失敗と Error 399287。Bad reputationによるバックエンドブロック解除要請」など、原因推定を明記。
- 必要情報を添付：下のテンプレート（後述）に従い、UPN／Object ID、失敗タイムスタンプ（UTC）、Request ID、影響ユーザー一覧、電話番号のE.164形式（+国番号）を提供。
- 対処依頼の要点：該当番号・テナントに対する「電話・SMS MFAブロック」と「Bad reputation」の解除、ならびに関連キューのクリア（必要な場合）を要請。
- 暫定措置：解除完了まで、ユーザーの既定サインイン方法をMicrosoft Authenticator通知に切り替え、SMS／音声はバックアップにします。
サポート依頼用テンプレート（コピペ可）
[概要]
Entra IDのMFA(電話/SMS)が連続失敗し、エラーコード399287を返す。
複数ユーザーで再現。Bad reputationによるバックエンドブロック解除を依頼。
[影響範囲]
ユーザー数：XX名／共通キャリア：例）○○
国番号帯：+81（例）／発生日：YYYY-MM-DD HH:MM UTC～
[代表ユーザー]
UPN：[[email protected]](mailto:[email protected])
ObjectID：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
電話番号（E.164）：+81xxxxxxxxxx
最終失敗UTC：YYYY-MM-DD HH:MM
Request ID / Correlation ID：xxxxxxxxxxxxxxxx
[実施済み]
・MFA再登録強制、Revoke sessions
・端末/キャリア側の受信制限確認
・他の認証方法（Authenticator）では成功
[依頼事項]
・電話/SMS系MFAに対するバックエンドのブロック解除
・当該番号/テナントに付与されたBad reputationのクリア
・関連キャッシュのクリア（必要時） より安全な認証方法へ切り替え：Authenticatorを主役に
SMS／音声通話は利便性が高い反面、IRSF（国際通話料金詐取）攻撃やSIMスワップ、スミッシング等の標的になりやすく、フィッシング耐性も限定的です。恒久対策として、Microsoft Authenticatorアプリ（プッシュ通知またはTOTP）をプライマリに据え、電話・SMSはバックアップ手段にとどめる運用へ移行しましょう。
ユーザー体験を損なわない切替ステップ
- 登録キャンペーンの有効化：「Authentication methods Policy」でAuthenticator登録を必須化。未登録ユーザーには登録ウィザードを自動で促します。
- 既定のサインイン方法を更新：ユーザーの「既定のサインイン方法」をAuthenticator通知に設定。プッシュ通知では番号マッチングを必須化し、誤承認・通知爆撃を抑止。
- バックアップの整備：TOTP（アプリ内ワンタイムコード）と回復コードを案内。予備端末やFIDO2セキュリティキーも併用すると復旧性が高まります。
- 最小限のSMS温存：ヘルプデスク向けの最終手段としてSMSを残しつつ、通常のサインインフローでは出番が無いようにポリシーで抑制します。
MFA手段の比較（意思決定用）
| 認証方法 | フィッシング耐性 | IRSF耐性 | オフライン | 運用コスト | ユーザー体験 | 主な用途 |
|---|---|---|---|---|---|---|
| Microsoft Authenticator（プッシュ＋番号マッチ） | 高 | 高 | 不可（データ接続必要） | 低 | 非常に良い | 日常のサインイン、社外利用 |
| Microsoft Authenticator（TOTP） | 中 | 高 | 可 | 低 | 良い | 電波の弱い現場、閉域網 |
| FIDO2 セキュリティキー | 非常に高 | 非常に高 | 可 | 中 | 良い（学習要） | 厳格な業務・共有PC |
| SMS／音声通話 | 低 | 低 | 可 | 中～高（国際SMSコスト） | 普通 | 一時的なバックアップ |
再発防止：ポリシー設計と段階的な無効化
条件付きアクセス（推奨方針）
- 対象：全ユーザー（例外：緊急アクセスアカウント）と全クラウドアプリ。
- 条件：リスクベース（サインインリスク中以上、デバイス準拠未満、信頼できない場所など）。
- アクセス制御：「多要素認証を要求」ではなく、認証の強度で「Authenticator（プッシュ／TOTP）やFIDO2」を満たす強度を必須化。
- 段階的展開：監査→レポート専用モード→限定適用→全社適用の順で実施。
電話・SMSの段階的無効化
- 一部部門でのパイロットから開始し、トラブルを吸い上げながら適用範囲を拡大。
- 「Authentication methods Policy」でSMS／音声通話を非推奨化（あるいは割当グループから除外）。
- 業務上やむを得ない利用には、短期の例外ウィンドウを設け、ログで利用実績を監視。
運用ガードレール
- 緊急アクセス（Break-glass）アカウント：条件付きアクセス対象外・MFA要件外のアカウントを最小限（2つ推奨）用意し、金庫レベルで保管。無人監視のアラートを設定。
- 回復手段の徹底：回復コードの安全保管、Authenticatorのクラウドバックアップ、予備のTOTPやFIDO2キーを周知。
- ユーザー教育：番号マッチング、承認前の地理情報確認、疑わしいプッシュの否認と報告フローを啓発。
IRSF（国際通話料金詐取）対策の観点
攻撃者は音声通話やSMSの配送経路を悪用し、特定の国際番号帯経由で高額な接続を誘発することで、事業者に費用負担やサービス不安定化をもたらします。電話・SMSベースのMFAはこのリスクに直結しやすいため、下記の観点で抑止します。
- 電話・SMSの露出低減：Authenticator／FIDO2へ主軸移行。
- 不可解な配送失敗の監視：国番号・キャリアごとに失敗トレンドを可視化。
- ユーザー案内の標準化：SMSが届かない時のセルフチェック手順を配布（受信拒否・迷惑SMS設定・国際SMS可否・圏外確認など）。
ヘルプデスク用チェックリスト（現場で即使用可）
| 確認項目 | 見る場所 | 期待される状態 | 異常時の例 | 初期アクション |
|---|---|---|---|---|
| MFA要求の有無と理由 | サインインログ | Authenticatorで成功している | 電話/SMSのみ要求で失敗を繰返す | 既定方法をAuthenticatorに変更 |
| 端末の受信設定 | ユーザー端末/キャリア設定 | 国際SMS受信可、迷惑フィルタ適正 | 国際SMS拒否、特番ブロック | 設定変更・テストSMS |
| 同一キャリアでの再現 | インシデント台帳 | 限定的または再現なし | 同キャリア/地域で集中発生 | Bad reputation疑いでエスカレーション |
| UI側のリセット効果 | Authentication methods / Revoke sessions | 通常は改善する | 改善せず399287継続 | サポートにブロック解除依頼 |
管理者向け：ポータル操作の要点
ユーザーのMFA再登録を促す
- Entra管理センター → Users → 対象ユーザー → Authentication methods。
- 不要な電話番号の削除、Authenticatorの再登録を促す。
- Require re-register MFA（強制再登録）を実施。
- Revoke sessionsで既存セッションを失効。
※バックエンドブロック状態では効果が限定的です。サポートへのブロック解除依頼を並行してください。
既定のサインイン方法をAuthenticator通知へ
- ユーザーの既定のサインイン方法を「Microsoft Authenticator 通知」に変更。
- ポリシーで番号マッチング必須を有効化し、誤承認を予防。
条件付きアクセスのベストプラクティス
- すべてのクラウドアプリを対象にしつつ、運用初期はレポート専用モードでドライラン。
- 「認証の強度」でAuthenticator/TOTP/FIDO2等の強度を指定し、SMS/音声のみでは満たせないように設計。
- 高リスクサインインではより強力な手段（FIDO2）を要求。
監視とアラート：失敗の早期検知
ログ分析ワークスペースを使って失敗の兆候を監視しましょう。以下は考え方の例です（環境に合わせてフィールド名は調整）。
// 例：直近24時間で電話/SMS系MFAが連続失敗しているユーザー抽出の考え方
SigninLogs
| where TimeGenerated > ago(24h)
| where AuthenticationRequirement == "multiFactorAuthentication"
| where AdditionalDetails has "Phone" or AdditionalDetails has "SMS"
| summarize Failures=count() by UserPrincipalName
| where Failures >= 3
| order by Failures desc
同一キャリア・国番号帯で集中的に失敗が増えている場合は、Bad reputation疑いとして早期にサポートへ連絡します。
「ユーザー向け」セルフヘルプ：SMSが届かないとき
- 国際SMS受信の許可設定、迷惑SMSフィルタ、着信拒否設定を確認。
- 圏外／機内モード／データ制限を解除し、再起動後に再試行。
- 同一番号でテストSMSを送って受信可否を検証。
- それでも届かない場合は、Authenticatorコード（TOTP）でサインインし、電話・SMSに依存しない運用へ切り替え。
よくある質問（FAQ）
Q. Authenticator端末を紛失した場合の最短復旧は？
回復コードとクラウドバックアップを利用して新端末に復元します。利用できないときは、ヘルプデスクが本人確認のうえ、Require re-register MFAと代替手段の一時有効化で復旧します。
Q. SMSを完全無効にすると現場が困りませんか？
当面はバックアップとして温存し、既定はAuthenticatorにします。条件付きアクセスの認証の強度で、通常はAuthenticator／FIDO2を要求し、例外時のみSMSを使える設計にするとスムーズです。
Q. 海外出張時にSMSが届きにくいのは？
ローミングや国際SMSの事業者間接続、現地キャリアのフィルタリングが影響します。TOTPやFIDO2を併用することで、通信品質に依存しない認証が可能です。
導入・移行のモデルプラン（例）
| 期間 | 主な活動 | 成果物 | 注意点 |
|---|---|---|---|
| 0～2週 | 現状診断、影響ユーザー洗い出し、監視クエリ整備 | 失敗傾向レポート、運用ランブック | Break-glass確認、アラート設定 |
| 3～6週 | Authenticator登録キャンペーン開始、番号マッチ必須化 | 登録率ダッシュボード、教育コンテンツ | VIPサポート体制、問合せテンプレ |
| 7～10週 | 条件付きアクセスの本適用、SMSの段階的無効化 | 本番ポリシー、例外管理台帳 | レポート専用→限定適用→全社適用の段階踏襲 |
| 11～12週 | 残課題解消、最終レビュー、恒久運用へ移行 | 運用SOP、KPI/KRIの定義 | 四半期ごとに見直し |
まとめ：一時復旧＋恒久策の二段構えで「二度と困らない」
399287は、電話・SMS系MFAのバックエンドブロック（Bad reputation）が疑われる代表的な症状です。短期的には、Microsoftサポートまたはテナント管理者からの解除依頼で復旧し、運用の再発防止としてはMicrosoft Authenticatorのプライマリ化と条件付きアクセスによる認証強度の統制が鍵になります。ユーザー教育、回復手段、監視・アラートを一体で設計すれば、IRSFや配送障害に左右されない堅牢なサインイン体験を実現できます。
付録：社内通達のひな形（周知・教育用）
件名：MFAサインイン方式の変更（Authenticator優先化）のお知らせ
本文：
・セキュリティ強化と安定運用のため、SMS/音声通話によるMFAはバックアップ手段へ移行します。
・既定のサインイン方法はMicrosoft Authenticator（通知/番号マッチ）になります。
・初回のみ登録作業が必要です。登録ガイドに沿って5分程度で完了します。
・出張や圏外時もTOTPコードをご利用いただけます。
・お困りの際はヘルプデスク（内線xxxx／メールxxxx）へご連絡ください。
付録：インシデント記録テンプレート（運用品質向上）
| 項目 | 記入例 |
|---|---|
| インシデントID | INC-2025-1101-001 |
| 発生日（UTC） | 2025-11-01 03:12 |
| 影響ユーザー | 10名（営業部、共通キャリアA、+81） |
| エラーコード | 399287 |
| 暫定対処 | 既定サインイン方法をAuthenticator通知に変更、Revoke sessions実施 |
| 恒久対策 | Authenticator登録必須化、SMS段階的無効化、認証強度ポリシー適用 |
| サポート依頼 | Bad reputation解除依頼（Case# 123456） |
| 再発防止KPI | Authenticator登録率95%超、SMS利用率5%未満 |
付録：エスカレーション基準
- 同一キャリア・地域で3名以上が同時に399287を報告。
- UIでのMFA再登録／セッション失効後も失敗が継続。
- Authenticatorでは成功するが、SMS/通話のみ失敗。
- 海外ローミング無しの国内回線で配送不可が継続。
上記に該当する場合は、Bad reputationによるバックエンドブロックを第一仮説とし、サポートケースを即時起票してください。
コメント