Entra ID（旧Azure AD）とオンプレのAD FS（オンプレADのフェデレーション認証基盤）を併用し、子会社・関連会社を含む複数ドメインでフェデレーション認証を組んでいる数千人規模の企業の情シスが、今まさに確認を急ぐべき変更がある。Microsoft Entra IDが、フェデレーション検証ポリシー（federatedTokenValidationPolicy）を既定で強制適用する設定変更を進めており、内部ドメインの設定とUPN（ユーザープリンシパル名。user@example.com形式のサインインID）のドメインが一致しないサインインを遮断するようになる[1][2]。対象はEntra ID側のディレクトリ層で、Graph APIのfederatedTokenValidationPolicyとinternalDomainFederationという2つのオブジェクトの整合性チェックが厳格化される形をとる[5][7]。2025年12月以降に新規追加された連携ドメインにはすでにこの挙動が適用済みで、2026年8月中旬からは既存の連携ドメインにも同じ挙動が広がる[1][2][3]。単体ドメインで完結する企業には影響が乏しい一方、買収・分社を経て複数ドメインが混在するハイブリッド企業ほど、事前の棚卸しを終えているかどうかで結果が大きく変わる。
予備知識
- フェデレーション認証: 自社のID基盤で認証した結果をトークンとして渡し、Entra ID側がそれを信頼してサインインを許可する仕組み
- AD FS: オンプレのActive Directoryと連携し、フェデレーション認証のトークンを発行するMicrosoftの機能（Active Directory Federation Services）
- UPN: ユーザープリンシパル名。サインインに使うuser@example.com形式のID
- internalDomainFederation: ドメインごとのフェデレーション設定を表すEntra ID側のオブジェクト。どのAD FS等と信頼関係にあるかを保持する
フェデレーション設定やオンプレADとの連携画面を実機ベースで確認しながら棚卸し作業の勘所を掴める
federatedTokenValidationPolicyの既定強制で何が起きるのか
federatedTokenValidationPolicyは、オンプレの連携アカウントとEntra ID側のルートドメインが一致するかを検証し、一致しない場合はサインインを拒否するポリシーである[5]。この検証を担うvalidatingDomainsには、none（無検証、非推奨）、all（すべてのユーザーで一致を必須とする）、allFederated（ユーザーのドメインがフェデレーテッドなら検証して遮断し、マネージドなら許可する）といった選択肢があり、既定強制はこの設定を緩い側から厳格側へ寄せる変更にあたる[1][2][6]。遮断時に返るエラーはAADSTS5000820で、メッセージは「フェデレーション検証ポリシーによりサインインがブロックされました。管理者に問い合わせてください」という趣旨になる[2][3]。
実際に遭遇した例も公開されている。Microsoft Q&Aには、SAMLベースの第三者IdPを使う事業者から、UPNのドメインと連携ドメインが一致しない構成でこのエラーに遭遇したという報告が投稿されている[4]。投稿者は2024年後半から2025年初頭にかけてEntra IDがSAMLアサーションを拒否し始めたとしており、別の利用者もUPNを連携ドメインに合わせることで解消したと追認している[4]。ただしこのスレッドにMicrosoftからの回答は付いておらず、挙動の定義そのものはGraph APIのドキュメント[5][6][7]で確認するほうが確実である。
AD FS依存からの脱却も含めたID基盤の中長期設計を、ゼロトラストの文脈で整理できる
なぜAD FS併用のハイブリッド企業でサインイン遮断が起きるのか
遮断が起きる典型例は、internalDomainFederationに登録された連携ドメインと、実際にサインインするユーザーのUPNドメインが食い違うケースである[5][7]。子会社を買収して旧ドメインのUPNを残したまま親会社のAD FSに寄せて認証していたり、alternateID（UPNとは別の属性でのサインイン）を使わずにドメインをまたいでトークンを使い回していたりすると、これに該当しやすい。単一ドメイン・単一AD FSで完結する構成では影響が出にくい一方、次の3パターンは要注意である。
| 構成パターン | UPNドメインとinternalDomainFederationの関係 | 遮断リスク |
|---|---|---|
| 単一ドメイン・単一AD FS | 常に一致 | 低い |
| 子会社ドメインを親会社AD FSに集約 | 子会社UPNと親会社の連携設定が不一致になりやすい | 高い |
| 複数AD FSを混在運用 | ドメインごとに管理者・設定が分かれ棚卸し漏れが起きやすい | 中〜高い |
今回取り上げるのはAD FS（Active Directory Federation Services、Windows Server上でSSO・フェデレーション認証を提供する機能）のDKM（Distributed Key Manager）[…]
棚卸しはいつまでに、何を確認すべきか
2026年8月中旬という既定強制の開始時期はすでに到来しており、段階的な適用が続く前提で、確認は早いほど良い[1][2][3]。確認すべきは、テナント内の全連携ドメイン一覧と、それぞれのUPNサフィックスがinternalDomainFederationの設定と一致しているかの2点である。もし業務継続のため意図的にドメインをまたいだサインインを許可したい場合は、Security Administrator・Hybrid Identity Administrator・External Identity Provider Administratorのいずれかの権限でGraph APIを使い、federatedTokenValidationPolicyのrootDomainsをnoneに設定することで従来どおりの緩い挙動に戻せる[2][3]。ただしこのnone設定はMicrosoft自身が「最も安全性が低く、強く非推奨」と明記しており、恒常的な逃げ道にはできない[6]。
数千人規模でEntra ID（旧Azure AD）とオンプレADを併用し、年次の内部監査があるような日本企業のID基盤担当者は、SMSや音声通話によるMFA（多要素認証）を、まだ主要な認証手段として使い続けている場合が多い。Micr[…]
SIer保守契約とAD FS更改サイクルが棚卸しを遅らせる要因
米国の単一テナント企業であれば、UPN統一やAD FS設定変更を自社IT部門の裁量で即日実行できることが多い。日本のエンタープライズでは事情が異なり、AD FSの保守はSIerとの年間契約に組み込まれ、設定変更そのものが追加見積もりと稟議を要する作業になりやすい。加えて、子会社・関連会社ごとにAD管理者が分かれている場合、internalDomainFederationの棚卸しを本社情シス単独では完結できず、各社への照会と回答待ちで数週間を要する。監査・内部統制の観点でも、認証基盤の設定変更は変更管理プロセスの申請対象になりやすく、rootDomains=noneのような暫定回避策を選ぶ場合は「なぜ推奨されない設定を使うのか」を説明する記録が必要になる。
| 観点 | 米国的な単一テナント企業 | 日本のSIer保守・多社構成企業 |
|---|---|---|
| AD FS設定変更の実行者 | 自社IT部門が即時対応 | SIerへの依頼・見積・稟議を経る |
| 連携ドメインの棚卸し範囲 | 自社1ドメインで完結しやすい | 子会社・関連会社ごとに照会が必要 |
| 変更の記録要件 | 運用ログ程度 | 変更管理・監査証跡としての説明責任 |
IT部門の判断としては、rootDomains=noneに頼る前に、子会社UPNの棚卸しリストを今週中に作成し始めるべきである。決裁側の判断材料としては、AD FS設定変更の稟議を通常の変更管理ルートに乗せるか、サインイン遮断という業務停止リスクを理由に緊急対応枠で処理するかを、今の時点で決めておく必要がある。
数千台規模のWindows端末を、オンプレミスのActive Directory（AD、企業内のユーザー・端末を一元管理するディレクトリサービス）とGPO（グループポリシーオブジェクト、ADで端末設定を一括配布する仕組み）でパッチ運用して[…]
まとめ
情シス担当者の次の一手は、子会社・関連会社を含む全連携ドメインとUPNサフィックスの一覧化を、今週中に着手することである。決裁側は、恒久対応（UPN/AD FS設定修正）と暫定対応（rootDomains=none）のどちらを選ぶ場合でも、SIerへの依頼と変更管理の稟議ルートを先に固めておくべきである。既定強制の開始時期はすでに到来しており、段階的適用の途中にある前提で動くほうが安全である。
よくある質問（FAQ）
Q. 自社は単一ドメインしか使っていないが、それでも影響はあるか。
A. UPNドメインと連携設定が常に一致する単一ドメイン構成であれば、影響は乏しい[1][2]。ただし過去に一時的なドメイン統合や子会社吸収があった場合は、設定が残っていないか確認したほうがよい。
Q. AADSTS5000820が出た場合、まず何をすればよいか。
A. 遮断されたユーザーのUPNドメインと、そのドメインに対応するinternalDomainFederationの設定が一致しているかをGraph API等で確認する[5][7]。応急対応としてrootDomains=noneへの変更もあるが、恒久対応ではない[6]。
Q. AD FSを使っていない、クラウドのみのテナントでも関係あるか。
A. internalDomainFederationはAD FS以外の第三者IdP（SAML/WS-Fedベースの外部IdP）にも適用される概念で、実際に第三者IdPでの遮断報告も出ている[4][7]。AD FS以外のフェデレーション連携を組んでいるテナントも同様に確認が必要である。
出典
[1] M365 Admin (handsontek.net), “Microsoft Entra: Upcoming changes to federatedTokenValidationPolicy default settings” https://m365admin.handsontek.net/microsoft-entra-upcoming-changes-federatedtokenvalidationpolicy-default-settings/[2] Microsoft 365 Message Center Archive (mc.merill.net), “MC1303719 – Microsoft Entra: Upcoming changes to federatedTokenValidationPolicy default settings” https://mc.merill.net/message/MC1303719
[3] Kocho, “Microsoft Entra Federated Sign-In Changes for August 2026” https://kocho.co.uk/news/microsoft-entra-federated-sing-in-changes/
[4] Microsoft Q&A, “Breaking Change: Error 5000820 Federated Token Validation Policy — Third-Party IDP Integration Blocked by UPN Domain Enforcement” https://learn.microsoft.com/en-ca/answers/questions/5855676/breaking-change-error-5000820-federated-token-vali
[5] Microsoft Graph API (beta) ドキュメント, “federatedTokenValidationPolicy resource type” https://learn.microsoft.com/en-us/graph/api/resources/federatedtokenvalidationpolicy?view=graph-rest-beta
[6] Microsoft Graph API (beta) ドキュメント, “validatingDomains resource type”（rootDomainsのnone/all/allFederated等の定義） https://learn.microsoft.com/en-us/graph/api/resources/validatingdomains?view=graph-rest-beta
[7] Microsoft Graph API (beta) ドキュメント, “internalDomainFederation resource type” https://learn.microsoft.com/en-us/graph/api/resources/internaldomainfederation?view=graph-rest-beta
