federatedTokenValidationPolicy ab August 2026 Pflicht!
Federierte Authentifizierung ist einer der ältesten Vertrauensanker in Microsoft-Umgebungen und gleichzeitig einer der gefährlichsten. Wer AD FS oder einen Dritt-IdP an Entra ID anbindet, sagt dem Tenant: Vertraue jedem Token, das dieser Identity Provider signiert. Genau dieses Vertrauen schränkt Microsoft jetzt ein.
Federierte Authentifizierung ist einer der ältesten Vertrauensanker in Microsoft-Umgebungen und gleichzeitig einer der gefährlichsten. Wer AD FS oder einen Dritt-IdP an Entra ID anbindet, sagt dem Tenant: Vertraue jedem Token, das dieser Identity Provider signiert.
Genau dieses Vertrauen schränkt Microsoft jetzt ein. Ab Mitte August 2026 ändert sich das Default-Verhalten der federatedTokenValidationPolicy: Entra ID blockiert dann federierte Anmeldungen, bei denen die internalDomainFederation nicht zur UPN-Domain des anmeldenden Benutzers passt.
Bisher musstest du dieses Verhalten aktiv konfigurieren. Künftig ist es der Standard für alle Tenants, angekündigt über Message Center MC1303719 und Roadmap-ID 566869 (GA August CY2026, gleichzeitig für Worldwide, GCC, GCC High und DoD).
Warum Microsoft den Default verschärft
Der Hintergrund ist ein bekanntes Angriffsmuster. Kompromittiert ein Angreifer das Token-Signing-Zertifikat eines AD FS oder eines anderen federierten IdP, kann er gültige Tokens für beliebige Benutzer ausstellen (Golden-SAML-Klasse). Solange Entra ID Tokens eines Federation-Trusts auch für Benutzer akzeptiert, deren UPN-Domain gar nicht zu diesem Trust gehört, weitet ein einziger kompromittierter oder falsch konfigurierter Trust den Schaden auf den kompletten Tenant aus.
Die Validierung gegen die UPN-Domain begrenzt den Blast Radius: Ein Trust darf nur noch für die Domains sprechen, für die er eingerichtet wurde. Diese Härtung empfehlen Security-Researcher seit Jahren, unter anderem über die Einstellung validatingDomains = all. Microsoft zieht sie jetzt im Rahmen der Secure Future Initiative als Default durch, wie zuvor schon App Instance Lock und die Admin-Consent-Defaults für Exchange-Graph-Permissions.
Wie Entra ID federierte Anmeldungen technisch prüft
Um zu verstehen, wo der neue Default zuschlägt, hilft der Blick auf das Token-Matching. Wenn der Client nach der Anmeldung am IdP mit dem signierten SAML-Token zu login.microsoftonline.com zurückkehrt, sucht Entra ID das passende Benutzerobjekt nach drei Kriterien.
Das Objekt muss per Verzeichnisabgleich oder manuell mit einem SourceAnchor versehen sein, denn Cloud-only-Konten ohne OnPremisesImmutableId können sich nicht per Federation anmelden. Das NameID-Feld im Token muss die Base64-codierte ImmutableID des Benutzers enthalten, denn über dieses Feld findet Entra ID das Objekt im Tenant. Und der UPN des gefundenen Objekts muss zu einer federierten Domain gehören.
Genau am dritten Kriterium setzt die Verschärfung an. Findet Entra ID das Objekt zwar über die ImmutableID, aber die UPN-Domain passt nicht zum Federation-Trust, der das Token ausgestellt hat, endet die Anmeldung mit dem Fehler 5000820 („Sign-in blocked by Federated Token Validation policy", ausgeschrieben AADSTS5000820).
Frank Carius hat diese Matching-Kette auf der MSXFAQ ausführlich dokumentiert, inklusive der Konsequenz: Die schnellste Korrektur auf Objektebene ist ein UPN, der zur federierten Domain passt.
Die Praxis zeigt: Für manche gilt der Block schon heute
Der August-Rollout ist formal die Umstellung für Bestandsdomains. Real greift die strikte Validierung aber schon länger. Für Domains, die seit Dezember 2025 neu federiert wurden, ist das Verhalten bereits aktiv. Und in der Microsoft Q&A Community melden IdP-Anbieter und Kunden seit Ende 2024, dass Cross-Domain-Konstrukte per Backend-Änderung blockiert wurden, damals noch ohne Message-Center-Ankündigung. Der Fall des Anbieters Circle Security ist lehrreich: Deren FIDO2-Anmeldung federierte eine eigene Domain im Kunden-Tenant und mappte Benutzer per OnPremisesImmutableId, auch wenn deren UPN auf einer anderen, managed Domain lag. Genau dieses Muster liefert seither 5000820.
Aus dem Thread lassen sich drei Punkte für deine Planung ableiten. Erstens: Proxy-Adressen, Subdomain-Varianten oder ein korrektes ImmutableId-Mapping über Domaingrenzen hinweg lösen den Fehler nicht, nur der passende UPN oder eine saubere Federation je Domain. Zweitens: Ein UPN-Wechsel ist in gewachsenen Tenants kein Klick, sondern ein Change-Projekt, weil der UPN als Identifier in Exchange Online, Teams, SharePoint, Intune und in per Entra-SSO angebundenen SaaS-Apps hängt. Drittens: Die Primär-Domain nachträglich zu federieren ist als Ausweichweg riskant, weil Entra ID mit der Aktivierung sofort keine Passwörter mehr für diese Domain akzeptiert.
Ein Pilotbetrieb für eine Teilmenge der Benutzer ist im Domain-Federation-Modell nicht vorgesehen. Wer Dritt-IdPs nur für die MFA-Stufe braucht, sollte deshalb External Authentication Methods (EAM) als moderneren Integrationspfad prüfen, statt eine Domain zu federieren.
Wer jetzt prüfen muss
Kritisch wird es überall dort, wo Benutzer einer Domain über den Federation-Trust einer anderen Domain authentifizieren. Typische Kandidaten: Multi-Domain-Forests mit einem zentralen AD FS, dessen IssuerUri nur auf eine der Domains zeigt. Übernahme-Szenarien, in denen Benutzer der gekauften Firma noch über den alten Trust der Muttergesellschaft laufen. Dritt-IdPs wie Ping, Okta oder Shibboleth, bei denen mehrere UPN-Suffixe auf eine einzige Federation-Konfiguration gemappt wurden. Und verwaiste Trusts, die nach Migrationen zu Managed Authentication nie sauber abgeräumt wurden.
Die Policy liegt im Beta-Endpoint unter GET /policies/federatedTokenValidationPolicy, als Berechtigung reicht lesend Policy.Read.All, schreibend brauchst du Policy.ReadWrite.FedTokenValidation. Als Rollen unterstützt Microsoft Security Administrator, Hybrid Identity Administrator und External Identity Provider Administrator:
Connect-MgGraph -Scopes "Policy.Read.All","Domain.Read.All"
# Alle federierten Domains im Tenant auflisten
Get-MgBetaDomain | Where-Object { $_.AuthenticationType -eq "Federated" } |
Select-Object Id, AuthenticationType
# Federation-Konfiguration je Domain einsehen (IssuerUri, PassiveSignInUri)
Get-MgBetaDomainFederationConfiguration -DomainId "contoso.com"
# Aktuelle federatedTokenValidationPolicy mit validatingDomains abrufen
Get-MgBetaPolicyFederatedTokenValidationPolicyDas entscheidende Property der Policy heißt validatingDomains: Es legt fest, für welche verifizierten Domains Entra ID den Abgleich zwischen federiertem Konto und Root-Domain des gemappten Entra-Kontos erzwingt. Gleiche die IssuerUri-Werte der Federation-Konfigurationen mit den UPN-Suffixen deiner Benutzer ab. Wo ein Suffix auf einen Trust zeigt, der formal zu einer anderen Domain gehört, hast du einen Treffer. Beachte dabei, dass jede IssuerUri weltweit eindeutig sein muss; der Versuch, denselben Wert für eine zweite Domain zu verwenden, scheitert mit „Request_MultipleObjectsWithSameKeyValue".
Ergänzend lohnt der Blick in die Entra-Sign-in-Logs: Filtere auf federierte Anmeldungen und prüfe, ob die authentifizierende Domain vom UPN-Suffix abweicht.
Ein Betriebshinweis aus der Praxis, der bei jeder Arbeit an Federation-Konfigurationen gilt: Halte ein Cloud-only-Admin-Konto mit einem UPN auf der onmicrosoft.com-Domain bereit. Wenn eine federierte Domain klemmt, ist das dein einziger garantierter Weg zurück in den Tenant.
Deine zwei Optionen vor dem Stichtag
Option eins, und das ist die richtige: Federation-Konfiguration korrigieren. Jede federierte Domain bekommt einen sauberen, eigenen Trust mit passender IssuerUri und korrekten UPNs, oder die betroffenen Benutzer wandern gleich zu Managed Authentication mit Password Hash Sync oder Phishing-resistenten Cloud-Methoden. Wer AD FS ohnehin nur noch aus Gewohnheit betreibt, hat hier den passenden Anlass für den Ausstieg.
Option zwei existiert, aber Microsoft rät ausdrücklich davon ab: Per Update auf /policies/federatedTokenValidationPolicy lässt sich eine Custom Policy mit rootDomains = none anlegen, die Cross-Domain-Anmeldungen weiter erlaubt. Das ist als Notfallschalter für Business Continuity gedacht, nicht als Dauerzustand, weil du damit exakt die Schutzwirkung deaktivierst, die der neue Default liefern soll. Wenn du diesen Weg gehst, dokumentiere ihn als bewusste Risikoübernahme mit Ablaufdatum.
Abgrenzung: Workload Identity Federation ist nicht betroffen
Der Begriff Federation taucht in Entra ID an zwei sehr unterschiedlichen Stellen auf, und nur eine davon ist hier Thema. Die federatedTokenValidationPolicy betrifft ausschließlich die Domain Federation für Benutzeranmeldungen über AD FS oder Dritt-IdPs.
Federated Identity Credentials (FICs) für App Registrations und Managed Identities, also das, was deine GitHub-Actions-Pipelines, Kubernetes-Workloads oder Terraform-Deployments ohne Secrets an Entra anbindet, arbeiten mit einem anderen Vertrauensmodell: Dort validiert Entra die Kombination aus issuer und subject des externen OIDC-Tokens gegen die hinterlegte Credential-Definition (maximal 20 FICs pro App, Audience api://AzureADTokenExchange, RS256-signierte Tokens). Diese Workload-Szenarien laufen nach dem August-Rollout unverändert weiter.
Wenn dein Monitoring also AADSTS70021 meldet, ist das ein Federated Identity Credential (FIC) Problem und hat mit dieser Policy nichts zu tun.
Stolperfallen
Zwei Nebenwirkungen solltest du einplanen. Conditional Access bewertet federierte Anmeldungen nach der Umstellung unter veränderten Bedingungen, blockierte Sign-ins können also auch dort als unerwartete Zugriffsverweigerungen auftauchen.
Und der Helpdesk braucht ein Briefing: AADSTS5000820 wird nach Mitte August der Fehlercode sein, hinter dem sich vergessene Cross-Domain-Konstrukte melden. Wer die Analyse erst nach dem Rollout startet, debuggt unter Zeitdruck mit Anwendern in der Leitung.
Fazit
Die Umstellung der federatedTokenValidationPolicy ist die Sorte Breaking Change, die man sich als Admin eigentlich wünscht: Microsoft schließt eine seit Jahren dokumentierte Schwachstelle im Federation-Modell, und für sauber konfigurierte Umgebungen passiert schlicht gar nichts. Das Risiko liegt ausschließlich bei gewachsenen Setups, in denen Federation-Trusts über Domaingrenzen hinweg mitbenutzt werden, und genau diese Konstrukte waren schon immer ein Sicherheitsproblem, kein Feature. Insofern trifft die Härtung die Richtigen.
Kritikwürdig ist die Kommunikationshistorie. Die Q&A-Threads belegen, dass Teile der Enforcement schon Ende 2024 ohne Deprecation Notice im Backend scharf geschaltet wurden und Anbieter wie Kunden monatelang ohne offizielle Dokumentation debuggten. Die jetzt erfolgte Ankündigung per Message Center und Roadmap ist der richtige Schritt, kommt für einige Betroffene aber nachträglich. Dazu bleibt das enge Rollout-Fenster im August ohne Übergangsphase für Bestandsdomains, und die Prüfung läuft über einen Beta-Endpoint der Graph API, was in produktiven Automatisierungen Zusatzaufwand bedeutet.
Mein Rat deshalb: Führe die Bestandsaufnahme jetzt durch, nicht im Sommer. Federierte Domains inventarisieren, IssuerUri gegen UPN-Suffixe abgleichen, Sign-in-Logs auf Cross-Domain-Muster prüfen, Cloud-only-Break-Glass-Konto verifizieren. Findet sich nichts, bist du in einer Stunde durch und kannst den Message-Center-Eintrag abhaken. Findet sich etwas, hast du bis Mitte August Zeit für die saubere Lösung (UPN-Korrektur, eigener Trust je Domain oder Wechsel zu EAM beziehungsweise Managed Authentication) statt für den ausdrücklich unerwünschten Opt-out. Und strategisch bleibt die Kernbotschaft dieselbe wie bei jeder SFI-Änderung der letzten Monate: Domain Federation ist ein Auslaufmodell. Jede Stunde, die du jetzt in die Analyse alter Trusts steckst, ist ein Argument mehr, sie ganz abzuschalten.
PowerShell Script
Bevor Du das Skript ausführst, installiere einmalig die benötigten Module. Kopiere die folgenden Befehle einzeln in die PowerShell und führe sie der Reihe nach aus.
# 1) Microsoft Graph Authentication (fuer Connect-MgGraph)
Install-Module Microsoft.Graph.Authentication -Scope CurrentUser
# 2) Microsoft Graph Beta - Domain/Federation-Cmdlets
Install-Module Microsoft.Graph.Beta.Identity.DirectoryManagement -Scope CurrentUserDamit das Skript auf die Federation-Konfiguration Deines Tenants zugreifen kann, verbinde Dich vorher einmalig mit Microsoft Graph. Führe den folgenden Befehl vor dem Skript aus und trenne die Verbindung nach Abschluss wieder.
# 3) Verbindung zu Microsoft Graph herstellen (vor dem Script noetig)
Connect-MgGraph -Scopes "Domain.Read.All"
# 4) Script ausführen!
# 5) Verbindung nach Abschluss wieder trennen
Disconnect-MgGraph
Mit dem folgenden Skript gleichst Du alle Benutzer des lokalen Active Directory gegen die tatsächliche Federation-Konfiguration Deines Entra-ID-Tenants ab und siehst auf einen Blick, bei welchen Konten der Token korrekt gesetzt ist und bei welchen nicht oder fehlt.
Kopiere das Skript in einen Editor und speichere es als .ps1-Datei ab. Führe es mit der PowerShell-Session aus, mit der Du Dich auch connected hast!
# ============================================================
# federatedTokenValidationPolicy - Abgleich lokales AD <-> Entra Federation-Konfiguration
#
# Prueft nicht nur, ob die UPN-Domain eines Benutzers ueberhaupt federiert ist,
# sondern gleicht sie gegen die tatsaechliche Federation-Konfiguration
# (IssuerUri je Domain) aus Entra ID ab - das ist der Wert, den Entra beim
# Sign-in mit dem Issuer des SAML-Tokens vergleicht (AADSTS5000820 bei Mismatch).
# Zusaetzlich werden Domains erkannt, deren IssuerUri von mehr als einer
# Domain genutzt wird (Cross-Domain-Risiko, siehe Circle-Security-Beispiel
# im Artikel).
#
# Voraussetzung: VOR diesem Script bereits ausgefuehrt:
# Connect-MgGraph -Scopes "Domain.Read.All"
#
# Grenze dieses Scripts: Welcher Issuer bei der Anmeldung eines konkreten
# Benutzers tatsaechlich verwendet wird, entscheidet die AD-FS-seitige
# Relying-Party-Konfiguration zur Laufzeit und ist aus AD/Graph allein nicht
# auslesbar. Dieses Script bildet den bestmoeglichen statischen Proxy nach.
#
# Fuer die endgueltige Bestaetigung zusaetzlich die Entra Sign-in-Logs
# pruefen (federierte Anmeldungen: authentifizierende Domain vs. UPN-Suffix).
# ============================================================
$ExportPath = "C:\Temp\FederatedTokenValidation_Audit_$(Get-Date -Format 'yyyyMMdd_HHmmss').txt"
$IncludeDisabledUsers = $false
Import-Module ActiveDirectory
Import-Module Microsoft.Graph.Beta.Identity.DirectoryManagement
if (-not (Get-MgContext)) {
throw "Keine aktive Microsoft-Graph-Verbindung. Vorher ausfuehren: Connect-MgGraph -Scopes 'Domain.Read.All'"
}
# --- Schritt 1: Alle Domains + Federation-Konfiguration aus Entra lesen ---
$allDomains = Get-MgBetaDomain -All
$federatedDomains = $allDomains | Where-Object { $_.AuthenticationType -eq 'Federated' }
$domainIssuerMap = @{} # Domain -> IssuerUri
$issuerDomainMap = @{} # IssuerUri -> Liste von Domains (fuer Kollisionserkennung)
foreach ($fd in $federatedDomains) {
$issuerUri = $null
try {
$fedConfig = Get-MgBetaDomainFederationConfiguration -DomainId $fd.Id -ErrorAction Stop
if ($fedConfig -and $fedConfig.Count -gt 0) {
$issuerUri = $fedConfig[0].IssuerUri
}
} catch {
$issuerUri = $null
}
$domainIssuerMap[$fd.Id] = $issuerUri
if ($issuerUri) {
if (-not $issuerDomainMap.ContainsKey($issuerUri)) {
$issuerDomainMap[$issuerUri] = @()
}
$issuerDomainMap[$issuerUri] += $fd.Id
}
}
# Domains, deren IssuerUri von mehr als einer Domain genutzt wird -> Cross-Domain-Risiko
$collidingDomains = @()
foreach ($issuer in $issuerDomainMap.Keys) {
if ($issuerDomainMap[$issuer].Count -gt 1) {
$collidingDomains += $issuerDomainMap[$issuer]
}
}
# --- Schritt 2: Lokale AD-Benutzer einlesen ---
$users = Get-ADUser -Filter * -Properties UserPrincipalName, Enabled
if (-not $IncludeDisabledUsers) {
$users = $users | Where-Object { $_.Enabled -eq $true }
}
# --- Schritt 3: Klassifizieren ---
$correct = @()
$incorrect = @()
foreach ($u in $users) {
$upn = $u.UserPrincipalName
if ([string]::IsNullOrWhiteSpace($upn) -or -not $upn.Contains('@')) {
$incorrect += [pscustomobject]@{
SamAccountName = $u.SamAccountName
UserPrincipalName = $upn
Grund = "UPN fehlt oder ist ungueltig"
}
continue
}
$domain = $upn.Substring($upn.IndexOf('@') + 1)
if ($domain -notin $federatedDomains.Id) {
$incorrect += [pscustomobject]@{
SamAccountName = $u.SamAccountName
UserPrincipalName = $upn
Grund = "UPN-Domain '$domain' ist in Entra nicht als federiert registriert"
}
continue
}
if (-not $domainIssuerMap[$domain]) {
$incorrect += [pscustomobject]@{
SamAccountName = $u.SamAccountName
UserPrincipalName = $upn
Grund = "Federation-Konfiguration fuer '$domain' hat keine IssuerUri (fehlkonfiguriert)"
}
continue
}
if ($domain -in $collidingDomains) {
$incorrect += [pscustomobject]@{
SamAccountName = $u.SamAccountName
UserPrincipalName = $upn
Grund = "IssuerUri von '$domain' wird auch von einer anderen Domain verwendet (Cross-Domain-Risiko, AADSTS5000820)"
}
continue
}
$correct += [pscustomobject]@{
SamAccountName = $u.SamAccountName
UserPrincipalName = $upn
Domain = $domain
IssuerUri = $domainIssuerMap[$domain]
}
}
# --- Schritt 4: Export ---
$lines = @()
$lines += "federatedTokenValidationPolicy - UPN/Federation-Audit"
$lines += "Erstellt: $(Get-Date -Format 'yyyy-MM-dd HH:mm:ss')"
$lines += "Federierte Domains in Entra: $($federatedDomains.Id -join ', ')"
if ($collidingDomains.Count -gt 0) {
$lines += "ACHTUNG - Domains mit kollidierender IssuerUri: $($collidingDomains -join ', ')"
}
$lines += "Einbezogene Benutzer: $($users.Count) (deaktivierte einbezogen: $IncludeDisabledUsers)"
$lines += ""
$lines += "=== Benutzer mit KORREKT gesetztem UPN/Federation-Bezug ($($correct.Count)) ==="
foreach ($c in $correct) {
$lines += "$($c.SamAccountName)`t$($c.UserPrincipalName)`t$($c.IssuerUri)"
}
$lines += ""
$lines += "=== Benutzer mit FEHLERHAFTEM oder FEHLENDEM Federation-Bezug ($($incorrect.Count)) ==="
foreach ($i in $incorrect) {
$lines += "$($i.SamAccountName)`t$($i.UserPrincipalName)`t$($i.Grund)"
}
$lines | Out-File -FilePath $ExportPath -Encoding UTF8
Write-Host "Export abgeschlossen: $ExportPath"
Write-Host "Korrekt: $($correct.Count) | Fehlerhaft/Fehlend: $($incorrect.Count)"
if ($collidingDomains.Count -gt 0) {
Write-Host "WARNUNG: Kollidierende IssuerUri gefunden bei: $($collidingDomains -join ', ')" -ForegroundColor Yellow
}
Sei der Erste und starte die Diskussion mit einem hilfreichen Beitrag.
Kommentar hinterlassen
Dein Beitrag wird vor der Veröffentlichung kurz geprüft — fachlich, respektvoll und auf den Punkt ist hier genau richtig.