Entra federatedTokenValidationPolicy: de stille standaardwijziging die federated aanmeldingen blokkeert

Midden in augustus 2026 activeert Microsoft een nieuwe standaard in Microsoft Entra die federated aanmeldingen kan blokkeren voor organisaties met een oudere federation-inrichting. Gebruikers krijgen foutcode AADSTS5000820. Wat er precies verandert, wie er last van heeft en hoe u het oplost voordat het uw helpdesk overspoelt.

Midden augustus 2026 activeert Microsoft een standaardwijziging in Microsoft Entra ID die voor sommige organisaties onverwacht aanmeldfouten veroorzaakt. De wijziging betreft de federatedTokenValidationPolicy, een instelling die bepaalt hoe Entra omgaat met federated sign-ins waarbij het authentication token afkomstig is van een domein dat niet overeenkomt met het UPN-domein van de gebruiker.

De verandering is geen nieuwe feature, maar een veiligheidsmaatregel die al eerder werd aangekondigd via Message Center-bericht MC1303719. Voor tenants waarvan federated domeinen zijn geconfigureerd vóór december 2025 wordt de strengere validatie nu automatisch ingeschakeld. Voor wie sindsdien een federated domein heeft aangemaakt, gold de strengere regel al. De uitrol verloopt gefaseerd en was halverwege augustus 2026 voor de meeste tenants wereldwijd van kracht.

Wat is de federatedTokenValidationPolicy?

Microsoft Entra ondersteunt federated authenticatie, waarbij een externe Identity Provider (IdP) een token uitgeeft dat Entra vervolgens accepteert om de gebruiker aan te melden. Dit wordt veel gebruikt in hybride omgevingen met Active Directory Federation Services (AD FS), maar ook bij integraties met derde partijen zoals Ping Identity, Okta of andere SAML-gebaseerde systemen.

De federatedTokenValidationPolicy bepaalt hoe Entra omgaat met een specifiek scenario: een token dat door een federated IdP is uitgegeven voor een domein dat niet overeenkomt met het UPN-domein van de gebruiker. Dit wordt cross-domain federation genoemd en is in de meeste gevallen een configuratiefout of een nalatenschap van een fusie of overname waarbij domeinen en gebruikers niet volledig zijn samengevoegd.

In de oude standaard accepteerde Entra zulke tokens en liet de gebruiker gewoon inloggen. In de nieuwe standaard wordt de aanmelding geblokkeerd en krijgt de gebruiker foutcode AADSTS5000820 te zien: 'Sign-in blocked by Federated Token Validation policy'.

Wie heeft last van de wijziging?

Voor de meeste organisaties verandert er niets. De wijziging raakt uitsluitend tenants waar gebruikers zich aanmelden via een federated IdP en waarbij het token wordt uitgegeven voor een ander domein dan het UPN-domein van de gebruiker. Concreet gaat het om drie scenario's.

Ten eerste organisaties die zijn gefuseerd of overgenomen en waarbij gebruikers van het ene domein zich via de federation-inrichting van het andere domein aanmelden zonder dat de UPN-domeinen zijn samengevoegd. Ten tweede omgevingen met een centrale AD FS-server die meerdere domeinen afhandelt maar waarbij de internalDomainFederation-objecten in Entra niet precies overeenkomen met alle gebruikers-UPN-domeinen. Ten derde integraties met externe IdP's waarbij het IdP tokens uitgeeft voor een subdomein of een alias-domein dat niet als federated domein in Entra is geregistreerd.

Organisaties op een cloud-only inrichting, met Microsoft Entra Password Hash Sync of met Pass-through Authentication (PTA) hebben geen last van deze wijziging. Hetzelfde geldt voor hybride omgevingen waar de UPN-domeinen in AD en Entra exact overeenkomen en consistent zijn geconfigureerd.

Hoe diagnosticeer je of jouw omgeving kwetsbaar is?

De eerste stap is controleren of er überhaupt federated domeinen zijn geconfigureerd in jouw tenant. Dat doe je via Microsoft Graph met de opdracht die de internalDomainFederation-objecten ophaalt. Voor elke federated domeinobject kun je zien welke IdP is geconfigureerd en welk domein daarin is opgenomen.

Controleer vervolgens in de Entra-aanmeldlogboeken, beschikbaar via het Entra-portaal onder Monitoring, of er al foutmeldingen met de code AADSTS5000820 voorkomen. Als je die code in de logs ziet vóórdat de standaard is geactiveerd, ben je sowieso getroffen en moet je direct handelen.

Een derde controlemaatregel is het vergelijken van de UPN-domeinen van je gebruikers met de geregistreerde federated domeinen in Entra. Als er gebruikers zijn waarvan het UPN-domein niet overeenkomt met het domein dat in de internalDomainFederation-configuratie is opgenomen, loop je risico.

Wat doe je als gebruikers AADSTS5000820 krijgen?

Er zijn twee correcte remediation-paden. Het aanbevolen pad is de federation-configuratie repareren zodat de internalDomainFederation-objecten in Entra precies overeenkomen met de UPN-domeinen van de gebruikers die er gebruik van maken. Dit betekent in de meeste gevallen dat je het federated domein in Entra bijwerkt of extra domeinen toevoegt aan de federation-inrichting.

Als een snelle aanpassing aan de federation-configuratie niet mogelijk is, bijvoorbeeld omdat je afhankelijk bent van een extern IdP waarover je beperkte controle hebt, kun je tijdelijk een aangepaste federatedTokenValidationPolicy aanmaken met de instelling rootDomains = none. Hiermee schakel je de strikte validatie voor jouw tenant uit. Microsoft noemt dit uitdrukkelijk als 'sterk afgeraden' omdat het de beveiligingsmaatregel ongedaan maakt, maar het geeft je tijd om de onderliggende configuratie te corrigeren. Behandel dit als een tijdelijke maatregel, niet als een permanente oplossing.

Welk pad je ook kiest, zet de aanmeldlogboeken actief in de gaten zodra je een wijziging doorvoert. De Entra Sign-in Logs bieden filtermogelijkheden op foutcode, waardoor je binnen enkele minuten kunt bevestigen of de correctie effect heeft gehad.

Waarom maakt Microsoft deze wijziging?

De achtergrond van de maatregel is beveiliging tegen cross-domain sign-in risico's. Als een aanvaller erin slaagt een token te verkrijgen voor een domein dat door jouw federation-inrichting wordt geaccepteerd, maar dat niet overeenkomt met het UPN-domein van de gebruiker, kan dat worden gebruikt voor authenticatie in jouw tenant. De strikte policy sluit dit aanvalspad af.

In de meeste goed-onderhouden Entra-omgevingen bestaat dit risico niet, omdat de federation-configuratie strak is ingericht. Maar in omgevingen die door de jaren heen zijn gegroeid, door overnames, domeinmigraties of ad-hoc integraties, zijn er soms federation-objecten die breder zijn ingesteld dan nodig. De nieuwe standaard dwingt een opschoning af die IT-teams lang hadden moeten doen.

Wat zijn de acties voor vandaag?

Drie stappen die elke IT-beheerder van een hybride of federated Microsoft 365-tenant deze week zou moeten uitvoeren. Ten eerste, controleer in de Entra-portaal welke domeinen als federated zijn geconfigureerd via het tabblad Aangepaste domeinnamen. Ten tweede, bekijk de aanmeldlogboeken van de afgelopen drie weken op foutcode AADSTS5000820. Als je die code ziet, is de wijziging al voor jou van kracht en moeten gebruikers al hinder ondervinden of dat binnenkort doen. Ten derde, vergelijk de UPN-domeinen in jouw gebruikerspopulatie met de geconfigureerde federated domeinen.

Voor organisaties die volledig cloud-native werken of uitsluitend gebruik maken van wachtwoord-hash-synchronisatie of pass-through authenticatie is geen actie vereist. De wijziging raakt alleen omgevingen met een actieve federated IdP-koppeling.

Heeft u een hybride of gefedereerde Microsoft 365-omgeving en wilt u weten of deze wijziging invloed heeft op uw gebruikers? Zarioh helpt IT-teams bij het doorlichten van Entra-configuraties, het opsporen van verborgen federation-risico's en het opstellen van een migratieplan naar een robuustere identity-architectuur. Neem contact op voor een vrijblijvende beoordeling.