MENU

Microsoft Entraでゲスト切替時の「Resend notification」エラーを根治する手順｜Microsoft Authenticator・MFA・ProxyAddress競合まで完全解説

Azure

Microsoft Entra（旧 Azure AD）のディレクトリを既存テナントからゲスト招待された別テナントへ切り替える際、Microsoft Authenticator の番号一致で承認した直後に「We’re sorry, we ran into a problem. Please choose “Resend notification” to try again.」と表示され、相関 ID（Correlation ID）付きで失敗する――この“切替不能”を、原因の切り分けから即効ワークアラウンド、恒久対策、運用設計まで実務視点でまとめました。

目次

現象の概要（再掲と補足）

  • 状況：ホーム テナントのアカウントでサインイン済み。
    ポータルのアカウント メニューからゲスト先テナントへ切替（Switch directory）すると、Authenticator の番号一致（Number matching）で承認は通るものの、その直後のトークン発行／セッション確立で失敗し、上記メッセージとともに切替がキャンセルされる。
  • 影響：テナントに入れないため、管理タスク・運用・開発が停止。サポート プラン契約がある場合でも、対象テナント側のポータルに入れないと有償チケット起票すら困難。
  • 再現性：特定ユーザーや特定デバイスのみ／全ユーザー共通など様々。発生直後の相関 ID とタイムスタンプを控えると原因追跡が速い。

裏で何が起きているのか（仕組みの要点）

ディレクトリ切替は、ホーム テナントでの本人確認（MFA 含む）と、ゲスト先テナントでの条件付きアクセスや認証方式ポリシーの満たし込み（claims challenge）が連続して起こる処理です。Authenticator の“承認”はホーム側の MFA 要件を満たしたことを示しますが、ゲスト先が「当テナントで登録された方法」や「特定の認証強度（例：フィッシング耐性）」を要求した場合、MFA 自体は通っているのに最終トークン発行が否認され、結果として同じエラーメッセージに見えることがあります。

また、ディレクトリ内でユーザー識別子の競合（例：ProxyAddress 重複）があると、アカウント解決フェーズで矛盾が生じ、MFA が“通ったように見えて”次段階で破綻するケースもあります。

主な原因と考えられる要因

項目内容補足
MFA 登録情報の競合ゲスト アカウントの Authenticator 登録が不完全・重複・古いデバイスに紐づき続けている等で、ホーム側では“承認”されるがゲスト先では整合が取れず失敗扱い。ゲスト特有の断続的な報告がある。登録強制のやり直しで解消することが多い。
SMTP/ProxyAddress の重複同じ SMTP アドレス（ProxyAddresses）を別のユーザー／連絡先／共有メールボックス／ソフトデリート オブジェクトが保持し、サインイン時の識別に競合。Exchange Online に波及。ディレクトリ切替やアプリ トークン発行で影響しうる。
デバイス／ブラウザ依存キャッシュ、拡張機能、TLS インスペクション、VPN/プロキシ、時刻同期などにより追加認証フローが阻害。同じメッセージでも内部要因が異なる。環境差分の切り分けが有効。
条件付きアクセスの強度要件ゲスト先テナントで「フィッシング耐性 MFA（例：FIDO2）」など特定の認証強度を必須にしており、Authenticator の“承認”だけでは不足。認証強度（Authentication strength）やセッション制御設定の見直しで改善。
クロステナント アクセス設定外部ユーザーに対し「他社テナントの MFA を信頼する/しない」等のトラスト設定で不一致があり、チャレンジ充足が二重化して失敗。External Identities > Cross-tenant access の既定/組織別設定を確認。
登録状態のメタデータ不整合ユーザーの登録詳細（userRegistrationDetails 等）が古い・部分的に壊れており、UI 上は承認でもバックエンドで失敗。再登録の強制と併用で解消するパターンが多い。

最優先の対処（実証済ワークアラウンド）

別のグローバル管理者による SMS 認証の追加は、短時間で復旧可能な再現性の高い回避策です。これにより問題ユーザーが Authenticator に依存せずにゲスト先へ入れるようになり、業務を即時再開できます。

手順

  1. グローバル管理者で Microsoft Entra 管理センターにサインイン。
  2. ID（Microsoft Entra ID） > ユーザーから対象ユーザーを開く。
  3. 認証方法（Authentication methods）を開き、+ 認証方法の追加を選択。
  4. 電話（SMS）を選び、携帯番号を E.164 形式（例：+81xxxxxxxxxx）で登録。
  5. 対象ユーザーはサインイン時に SMS コードを選択し、成功後にディレクトリ切替を実行。
  6. ゲスト先のポータルに到達できることを確認。

この回避策は恒久対策ではありませんが、「まず業務を再開する」という観点で最も効果的です。以降の恒久対策と合わせて実装してください。

恒久対策（優先度順に実施）

1. MFA の再登録を強制（Require re‑register MFA）

Authenticator の登録が壊れている／競合している場合、再登録の強制が効きます。対象ユーザーに一時的な代替方法（SMS や FIDO2）を用意した上で実行してください。

  1. 管理センターで ID > ユーザー > 対象ユーザーを開く。
  2. 認証方法またはユーザーの操作メニューから、Require re-register multifactor authentication（名称は UI 更新により前後）を実行。
  3. 次回サインイン時、Authenticator の再ペアリングまたは SMS/FIDO2 での再設定が促される。

注意：再登録の強制は現在有効なプッシュ通知や番号一致が使えなくなるため、少なくとも 1 つの代替要素（SMS、音声通話、FIDO2、Temporary Access Pass など）を先に付与してください。

2. Authenticator／電話など認証方法の整合性を Graph で点検・修復

Microsoft Graph PowerShell を使うと、対象ユーザーに紐づく認証方法を一覧・削除・追加できます。例を示します。

# Graph PowerShell の接続（管理者）
Connect-MgGraph -Scopes "User.Read.All","UserAuthenticationMethod.ReadWrite.All"
Select-MgProfile -Name "beta"   # レポートや一部 API は beta に先行

# ユーザーの認証方法を一覧
$u = "[email protected]"
Get-MgUserAuthenticationMethod -UserId $u

# Microsoft Authenticator のみ抽出
Get-MgUserAuthenticationMicrosoftAuthenticatorMethod -UserId $u

# 不要/壊れた Authenticator エントリを削除（Id は上の一覧結果から）
Remove-MgUserAuthenticationMicrosoftAuthenticatorMethod -UserId $u -MicrosoftAuthenticatorAuthenticationMethodId <Id>

# SMS（電話）要素を追加
New-MgUserAuthenticationPhoneMethod -UserId $u -PhoneType "mobile" -PhoneNumber "+81xxxxxxxxxx"

# ユーザー登録状況の健全性（レポート）を確認
Get-MgReportAuthenticationMethodsUserRegistrationDetail | Where-Object {$_.UserPrincipalName -eq $u}

REST を直接叩く場合の例（読み取りのみ）：

GET https://graph.microsoft.com/beta/reports/authenticationMethods/userRegistrationDetails?$filter=userPrincipalName%20eq%20'[email protected]'
GET https://graph.microsoft.com/v1.0/users/{id}/authentication/methods

ポイント：

  • 削除は慎重に。事前に SMS か FIDO2 を追加してから行うと安全です。
  • スマホ機種変更やアプリ再インストールで古い Authenticator エントリが残っている場合、古いものを削除して再登録すると安定することが多いです。

3. ProxyAddress（SMTP）競合の解消

アドレス衝突は“見えない”原因になりがちです。Exchange Online とディレクトリの両側からチェックしましょう。

# Exchange Online（新モジュール）での接続
Connect-ExchangeOnline

# 競合するメールアドレスを横断検索
$addr = "[email protected]"
Get-EXORecipient -ResultSize Unlimited -Filter "EmailAddresses -like 'SMTP:$addr'"

# 対象ユーザーの ProxyAddresses を確認
Get-EXOMailbox -Identity [email protected] | Select-Object -ExpandProperty EmailAddresses

# Graph 側（ユーザー/連絡先/グループの残骸を含めて検索）
Connect-MgGraph -Scopes "Directory.Read.All"

# ユーザーの ProxyAddresses に対象アドレスが存在するか
Get-MgUser -Filter "proxyAddresses/any(p:p eq 'SMTP:[email protected]')" -All

見つかった重複を解消（不要なアドレスを削除／別オブジェクトへ移設）した上で、再度ディレクトリ切替を試します。ソフトデリート（ごみ箱）内のオブジェクトが原因の場合もあるため、削除済みオブジェクトの確認・完全削除を検討してください。

4. 基本的なトラブルシューティングで環境依存を除外

  • プライベート/シークレット ウィンドウで https://portal.azure.com/<TenantID> に直接アクセス。
  • ブラウザのキャッシュ・Cookie をクリアし、拡張機能を全無効化。
  • VPN・プロキシ・TLS インスペクションを停止して再試行（企業ネットワーク由来の干渉を除外）。
  • 別ブラウザ／別デバイス（PC・スマホ）で同操作を実施して差分を確認。

5. 条件付きアクセスとクロステナント設定の見直し

ゲストが満たせない認証強度やデバイス準拠を要求していないかを確認します。

  • 条件付きアクセス（Conditional Access）：
    対象アプリ（例：Azure ポータル）に対するポリシーで、認証強度（Authentication strength）が「フィッシング耐性」など高すぎないか、準拠端末必須や厳しいセッション制御（サインイン頻度、永続ブラウザ cookie 無効）が設定されていないかを点検。
  • クロステナント アクセス：
    External Identities > Cross-tenant access の既定設定／組織別設定で、外部 MFA 信頼の取り扱いが適切かを確認。ホーム側 MFA を信頼しない構成だと、ゲスト先で追加要件を満たせず失敗することがあります。

発生直後に行う“診断ファーストエイド”

相関 ID とログが鍵です。次のいずれかで失敗理由を特定します。

  • サインイン ログ（Sign-in logs）で対象ユーザー＋時刻で検索し、Status details / Failure reason / Conditional Access statusを確認。
  • Log Analytics にアーカイブしている場合は KQL で深掘り：
SigninLogs
| where CorrelationId == "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
| project TimeGenerated, AppDisplayName, ResourceDisplayName,
          ResultType, ResultDescription, FailureReason,
          AuthenticationRequirement, ConditionalAccessStatus,
          ConditionalAccessPolicies, DeviceDetail, LocationDetails
| order by TimeGenerated desc
  • Graph API で相関 ID から参照：
GET https://graph.microsoft.com/v1.0/auditLogs/signIns?$filter=correlationId%20eq%20'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'

ここで ResultType/FailureReason が「MFA 要件未充足」「Authentication method not satisfied」「CA によりブロック」等を示していれば、ポリシー側の見直しが必要です。Invalid or missing claim / policy evaluation error のような場合は登録情報の再構成（前述の再登録・削除/追加）を優先します。

迅速復旧を最優先するオペレーション手順（実務テンプレート）

  1. 影響範囲を確認：他ユーザーでも再現するか、同端末のみか。
  2. 回避策を即時適用：別管理者で SMS を追加。必要なら Temporary Access Pass（時間限定）で救済。
  3. ログ採取：相関 ID・タイムスタンプ・サインイン ログを保全。
  4. 登録情報の健全化：Authenticator の古いエントリ削除 → 再登録強制 → 代替要素の追加。
  5. アドレス競合の解決：Exchange/Graph で ProxyAddress を横断確認し、重複を解消。
  6. ポリシー整合：条件付きアクセスの認証強度、クロステナント トラストをゲスト利用の現実解に合わせて調整。
  7. 再発防止：バックアップ要素（SMS/FIDO2）を標準化。運用チェックリストに組み込み。

よくある質問（FAQ）

Q. Authenticator の“番号一致”で承認したのに、なぜ切替で失敗するの？
A. その承認はあくまでホーム テナントの要求を満たしたに過ぎません。ゲスト先が追加の認証強度や端末状態を要求すると、「承認後に」失敗します。登録情報が壊れている場合も同様に後段で失敗します。

Q. SMS で入れてしまうのはセキュリティ的に弱くない？
A. ワークアラウンドとしての SMS は“業務再開”のための暫定策です。恒久対策では FIDO2 などのフィッシング耐性 MFAを追加し、Authenticator との二系統化を推奨します。

Q. エラーの英語メッセージは同じだが、別原因の可能性は？
A. あります。だからこそ相関 ID とログで実際に何が要求され否認されたのかを読み解くことが重要です。

設計上のベストプラクティス（再発防止）

  • 認証方法の多様化：Authenticator に加え、SMS/音声やFIDO2 セキュリティ キーを最低 1 つは併用。端末紛失時の復旧が速い。
  • ゲスト受け入れの標準ポリシー：条件付きアクセスの認証強度を段階化（通常は MFA、権限高は FIDO2 必須など）し、クロステナントでの MFA トラスト方針をドキュメント化。
  • 登録ライフサイクル管理：入社・異動・機種変更時の Authenticator 更新手順を明文化。Require re-register MFA の運用手順書を用意。
  • 監査ログの即時保全：発生直後にサインイン ログを保存し、相関 ID と時刻を台帳化。サポート連携が容易になる。
  • アドレス一意性の保証：メール アドレス付与フローに重複検査を組み込み、Exchange と Entra の双方で阻止。

“この症状”に強いチェックリスト

確認観点具体的な確認手順合格基準 / 典型 NG
SMS 追加で入れるか別管理者が SMS を追加して即サインイン入れる＝登録不整合の可能性高。入れない＝CA/ネットワークも疑う
Authenticator エントリGraph で一覧し重複/古い端末を削除1 つに正規化＋再登録後に安定
ProxyAddress 競合EXO/Graph で横断検索、ソフトデリート含む重複ゼロが合格。競合ありは解消必須
条件付きアクセス対象アプリの CA と認証強度を棚卸し実現可能な強度設定（過剰要求を避ける）
クロステナント トラストDefault/組織別設定の MFA 信頼を精査ホーム側 MFA を適切に扱えている
環境依存別端末・別ブラウザ・無通信制御で再試行再現しないならネットワーク/端末起因

付録：運用で使えるコマンド集

Graph PowerShell（認証方法と登録状況）

# 接続
Connect-MgGraph -Scopes "User.Read.All","UserAuthenticationMethod.ReadWrite.All"
Select-MgProfile -Name "beta"

# ユーザー認証方法の列挙

Get-MgUserAuthenticationMethod -UserId [[email protected]](mailto:[email protected])

# Authenticator の特定と削除

Get-MgUserAuthenticationMicrosoftAuthenticatorMethod -UserId [[email protected]](mailto:[email protected])
Remove-MgUserAuthenticationMicrosoftAuthenticatorMethod -UserId [[email protected]](mailto:[email protected]) -MicrosoftAuthenticatorAuthenticationMethodId 

# SMS の追加

New-MgUserAuthenticationPhoneMethod -UserId [[email protected]](mailto:[email protected]) -PhoneType "mobile" -PhoneNumber "+81xxxxxxxxxx"

# ユーザー登録状態レポート

Get-MgReportAuthenticationMethodsUserRegistrationDetail | Where-Object {$_.UserPrincipalName -eq "[[email protected]](mailto:[email protected])"}

Exchange Online（アドレス競合の発見）

Connect-ExchangeOnline
Get-EXORecipient -ResultSize Unlimited -Filter "EmailAddresses -like 'SMTP:[email protected]'"
Get-EXOMailbox -Identity [email protected] | Select-Object -ExpandProperty EmailAddresses

サインイン ログ（Graph REST）

GET https://graph.microsoft.com/v1.0/auditLogs/signIns?$filter=correlationId%20eq%20'&lt;CorrelationId&gt;'

ケーススタディ：実際の復旧ストーリー

ある開発チームでは、管理者アカウントがゲスト先に入れず開発停止。Authenticator の番号一致は通るが前掲のエラーで切替失敗という典型パターンでした。別のグローバル管理者が SMS を追加して入室を回復。その後、Graph で古い Authenticator エントリを削除し、Require re‑register MFAを実行。さらに Exchange/Graph で ProxyAddress の衝突がないかを点検し、不要なセカンダリ アドレスを整理。24 時間以内に恒久安定し、以後は FIDO2 を標準要素として配布。以降同種の事故は発生していません。

運用設計の要点（ポリシー & 手順）

  • ゲスト受け入れポリシー：外部ユーザーには「既存の MFA を信頼」＋「高リスク操作のみ追加強度」を基本とし、入室自体のハードルを下げる。
  • バックアップ要素の標準化：Authenticator だけに依存しない。SMS か FIDO2 を“必ず 1 つ”備えさせる。
  • 変更管理：機種変更・アプリ再インストール時に必ず登録更新を自己申告させるフローを Service Desk に組み込む。
  • 継続監査：userRegistrationDetails で「登録済みだが利用不可」等をモニタリングし、異常を早期検知。
  • インシデント レスポンス：相関 ID とログ採取、暫定アクセス（SMS/TAP）、恒久修復（再登録と整合化）の 3 段階テンプレートを準備。

トラブルが解消しないときの追加調査ポイント

  • Conditional Access：ブロック系ポリシーが潜んでいないか、認証強度・セッション制御が過剰でないか。
  • Microsoft Graph：/reports/authenticationMethods/userRegistrationDetails で対象ユーザーが registered になっているか。壊れていれば再登録。
  • ネットワーク要因：TLS インスペクションや古い中間証明書により、デバイスがプッシュ通知やトークン エンドポイントに到達できていない可能性。
  • スマホ側の時刻同期：TOTP 使用時に特に重要（番号一致のみであっても同期ずれは副作用を起こしうる）。

まとめ

この現象は「Authenticator の承認が通ったのに、なぜかディレクトリ切替で落とされる」という誤解を招きます。実際には、登録情報の不整合・アドレス競合・ゲスト先のポリシー過剰が主因です。業務継続の観点ではまず SMS の追加で回避し、続けて Require re‑register MFA、ProxyAddress 重複の解消、条件付きアクセス/クロステナントの整合を行えば、多くのケースで安定復旧できます。再発防止の鍵は、認証方法の多様化と登録ライフサイクル運用です。

参考ランブック（貼ってすぐ使える社内手順テンプレ）

  1. （ユーザー）相関 ID と発生時刻を報告。
  2. （管理者）Sign-in logs を取得・保存（相関 ID で抽出）。
  3. （管理者）SMS を追加、ユーザーに SMS で再サインインさせる。
  4. （管理者）Graph で認証方法を点検、古い Authenticator を除去。
  5. （管理者）Require re‑register MFA を実行（事前に代替要素あり）。
  6. （管理者）EXO/Graph で ProxyAddress 競合を検索し、解消。
  7. （管理者）CA/クロステナント設定をレビューし、過剰な要求を是正。
  8. （管理者）FIDO2 を配布し二系統化、登録更新手順をユーザーに周知。

注意事項

  • 作業前に必ず代替要素（SMS、FIDO2、Temporary Access Pass）を用意し、ロックアウトを防止してください。
  • ポリシー変更は最小範囲（テスト グループ）で評価し、監査ログの確認後に本番展開します。
  • 本記事の手順・コマンドは代表例です。テナントのセキュリティ要件やコンプライアンス基準に合わせて調整してください。

実装チェック（導入済みか一目で分かる）

項目実装状態備考
SMS/FIDO2 など代替要素の標準化□ / ■新規ユーザー展開フローに組み込み済みか
Require re‑register MFA の運用手順□ / ■Service Desk から即実行できるか
ProxyAddress 重複チェックの自動化□ / ■配布スクリプトまたは CI で検査
CA の認証強度とゲスト方針の整合□ / ■ゲスト利用に現実的か（過剰要求の是正）
相関 ID の台帳管理□ / ■発生から 15 分以内に収集・保存

最終チェックポイント

  • SMS で入れる → 登録整合性の修復を続行。
  • SMS でも入れない → CA/クロステナント/ネットワークのブロックを最優先で確認。
  • アドレス競合が見つかった → 完全解消後に再試行。ソフトデリートも忘れずに。

以上を順に実施すれば、Microsoft Authenticator 承認直後に発生する「Resend notification」系の切替失敗は、ほぼ確実に原因特定と復旧まで到達できます。復旧後は「二系統の MFA」と「登録更新の運用」によって、次の障害を未然に防ぎましょう。

Azure
MFA Exchange Online Microsoft Graph Microsoft Authenticator Microsoft Entra Conditional Access

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次