Hoe los je AADSTS50020 Gebruikersaccount niet gevonden in tenant op

By Mirko Peters · 2026-04-21

Als je ooit bent tegengehouden door de foutmelding “AADSTS50020: User account not found in tenant” bij het inloggen op Microsoft 365, Azure of een andere app…

Automatically translated with AI from the original post. Read the English original

Als je ooit bent tegengehouden door de foutmelding “AADSTS50020: User account not found in tenant” bij het inloggen op Microsoft 365, Azure of een app die gebruikmaakt van Microsoft Entra ID (voorheen Azure AD), dan sta je er niet alleen voor. Deze vervelende fout is een veelvoorkomend probleem voor beheerders, ontwikkelaars en gewone gebruikers die tegen problemen aanlopen bij het aanmelden of het verlenen van toegang.

In deze gids lees je wat AADSTS50020 precies betekent, waar de fout optreedt, hoe je hem snel oplost en hoe je hem in de toekomst voorkomt. We behandelen de hoofdoorzaken, lastige situaties en stap-voor-stapoplossingen, zodat je, of je nu een hele organisatie beheert of als ontwikkelaar problemen oplost, precies weet hoe je dit identiteitsprobleem aanpakt.

Klaar om die verwarrende tenantmeldingen te ontwarren en weer aan het werk te gaan? Laten we beginnen en uitzoeken wat er echt aan de hand is, zodat je het definitief kunt oplossen en misschien zelfs kunt voorkomen dat het opnieuw optreedt!

De AADSTS50020-fout voor identiteitsproviders begrijpen

Wanneer je de fout AADSTS50020 tegenkomt, zegt Microsoft eigenlijk: “Sorry, deze gebruikersaccount bestaat niet in deze tenant.” Maar achter die saaie waarschuwing speelt zich iets meer technisch drama af. Deze fout hangt rechtstreeks samen met problemen bij de identiteitsprovider in omgevingen van Microsoft Entra ID (Azure AD). In gewone taal: de service probeert je aanmeldaccount te koppelen aan een specifieke tenant (de directory van je organisatie), maar vindt daar niets.

Deze mismatch kan om verschillende grote redenen ontstaan, maar het betekent altijd dat de authenticatieservice je account niet kan terugvinden in de directory waarin hij zoekt. Misschien gebruik je een persoonlijk account in plaats van een werkaccount, misschien ben je in de verkeerde tenant terechtgekomen, of misschien is er een technische storing in de manier waarop accounts of domeinen op de achtergrond zijn ingesteld.

Vanuit het perspectief van Microsoft wordt elke aanmeldpoging doorgestuurd naar een “identiteitsprovider” die controleert wie je bent en tot welke tenant je behoort. Als je met de verkeerde sleutels aan de deur komt, of met sleutels die ze nog nooit hebben gezien, wordt je geweigerd, en de code AADSTS50020 is Microsoft’s versie van “toegang geweigerd: gebruiker hier niet gevonden”.

Begrijpen hoe en waarom deze fout optreedt, geeft je de mogelijkheid om hem te diagnosticeren. In de komende secties lees je welke precieze symptomen je moet herkennen en gaan we dieper in op de meest voorkomende technische fouten die de authenticatie in Microsoft-cloudomgevingen verstoren.

Veelvoorkomende symptomen en vervelende gebruikerservaringen

• Je krijgt een aanmeldscherm voor Office 365, de Azure-portal of een app die met Microsoft is geïntegreerd, voert je e-mailadres in en krijgt een foutmelding met de tekst “User account from identity provider does not exist in tenant”. Soms verwijst het bericht naar je account en de naam van de tenant, waardoor je je afvraagt wat er aan de hand is.
• In plaats van het dashboard of de app van je bedrijf te zien, krijg je geen toegang of wordt je verteld dat je account niet bestaat in de organisatie, terwijl je zeker weet dat je een account hebt of onlangs een uitnodiging hebt ontvangen.
• Als je als gast of externe gebruiker probeert toegang te krijgen, merk je misschien dat je de benodigde resources gewoon niet kunt bereiken, hoe vaak je ook probeert in te loggen en welke browser je ook gebruikt.
• Ontwikkelaars en beheerders zien mogelijk patronen van mislukte aanmeldingen of mislukte tokenaanvragen in logboeken en rapportages, gerelateerd aan specifieke app-registraties, eindpunten of gebruikerstypen.

Hoofdoorzaken van AADSTS50020-aanmeldfouten

De fout AADSTS50020 is geen willekeurige storing. Het is de manier van Microsoft Entra om aan te geven dat er iets misgaat bij het koppelen van accounts, de keuze van de tenant of de instellingen van de identiteitsprovider. In de kern draait het probleem om een mismatch tussen de gebruiker die probeert in te loggen en de plek waar Microsoft naar die gebruikersgegevens zoekt.

Dit kan om verschillende redenen gebeuren, van een persoonlijk e-mailadres gebruiken in plaats van een organisatieaccount, tot het kiezen van het verkeerde aanmeldeindpunt, slordige app-configuraties of gebruikerstoewijzingen die uit de hand lopen. Soms is het een simpele misstap, zoals het klikken op de verkeerde uitnodigingslink. In andere gevallen zit de oorzaak dieper in de infrastructuur, zoals problemen met de synchronisatie van de back-enddirectory of ontbrekende domeinverificaties.

Inzicht in elk van deze grondoorzaken is de sleutel om voorbij die “user not found”-muur te komen. Of je nu te maken hebt met persoonlijke Microsoft Entra-accounts, niet-ondersteunde accounttypen, verwarrende endpointkeuzes of problemen rond gastuitnodigingen en app-toewijzingen, we lopen hierna de meest voorkomende scenario’s door. Zo weet je waar je moet kijken, wat je moet vragen en, het belangrijkste, hoe je het één keer en voor altijd oplost.

En als je wilt zien hoe niet-beheerde gastaccounts nog meer complicaties kunnen veroorzaken, bekijk dan deze gids over de verborgen gevaren van blijvende Microsoft 365-gastaccounts voor tips om alles overzichtelijk en veilig te houden.

Problemen met persoonlijke Microsoft Entra-accounts en niet-ondersteunde accounttypen

• Aanmelden met een persoonlijk account: Als je probeert in te loggen op het Microsoft Entra-beheercentrum met een persoonlijk Microsoft-account (zoals @outlook.com of @hotmail.com), krijg je meestal AADSTS50020, omdat dat beheercentrum alleen organisatieaccounts (werk- of schoolaccounts) accepteert.
• Niet-ondersteunde accounttypen in app-registraties: Stel dat een app is ingesteld als “single tenant”, maar je probeert er toegang toe te krijgen met een account van een andere organisatie of met een persoonlijk Microsoft-account. Die mismatch geeft ook deze fout.
• Multitenant- en persoonlijke accounts door elkaar: Ontwikkelaars configureren apps soms zo dat ze meerdere organisatiemappen accepteren, maar vergeten persoonlijke accounts toe te staan, of andersom. Dit soort foutieve configuraties leidt tot mislukte authenticatie voor gebruikers van een type dat niet is toegestaan.

Problemen met endpoints, tenantselectie en uitnodigingen voor gastgebruikers

• Het verkeerde authenticatie-endpoint gebruiken: Microsoft-aanmeldingen ondersteunen meerdere endpoints, zoals /common, /organizations, /consumers en tenantspecifieke endpoints. Als je probeert aan te melden bij een tenantspecifieke app via het endpoint /common of /consumers met een werkaccount, kan Azure AD je account niet matchen, wat AADSTS50020 veroorzaakt.
• Aanmelden bij de verkeerde tenant: Het is verrassend makkelijk om in de verkeerde organisatiemap terecht te komen, vooral als je lid bent van meerdere organisaties. Als je je authenticeert bij een tenant waar je account niet bestaat, krijg je de fout. Dit is een klassiek geval van “je staat bij de verkeerde voordeur”.
• Gastuitnodiging niet verstuurd of niet correct ingewisseld: Organisaties die externe medewerkers uitnodigen, vergeten soms gastuitnodigingen te versturen of correct in te stellen. Als het gastaccount niet goed is geregistreerd of geactiveerd, is de gebruiker onzichtbaar voor de directory en krijgt hij een botte weigering wanneer hij apps of bestanden probeert te openen.
• De app vereist gebruikerstoewijzing, maar je hebt geen toegang: Sommige apps in Microsoft Entra zijn afgeschermd voor specifieke gebruikers of groepen. Als “gebruikerstoewijzing vereist” is ingesteld en jij staat niet op de lijst, wordt je toegang geweigerd, met een foutmelding die op AADSTS50020 kan lijken, ook al is je account geldig.
• Verwijderde en opnieuw aangemaakte gebruikers: Als een gebruiker is verwijderd en daarna opnieuw is aangemaakt in de thuistenant met hetzelfde e-mailadres, herkent Azure AD de “nieuwe” gebruiker misschien niet als hetzelfde object, zeker niet over meerdere tenants heen. Dit kan zeker onopgeloste aanmeldingen veroorzaken en die beruchte foutcode.
• Domein- en DNS-misconfiguraties: Als je organisatie aangepaste domeinen gebruikt (voor gebruikersnamen of app-registraties) en die domeinen niet zijn geverifieerd of verkeerd zijn geconfigureerd in Azure AD, kan het herkennen van gebruikers mislukken met AADSTS50020. Zelfs lokale DNS-fouten of blokkades naar authenticatie-endpoints kunnen het aanmelden verstoren, dus infrastructuur doet ertoe!
• Problemen met directorysynchronisatie (hybride identiteit): In sommige hybride enterpriseomgevingen, waarin accounts vanuit on-premises AD worden gesynchroniseerd met tools zoals Azure AD Connect, kunnen ontbrekende of niet-gesynchroniseerde gebruikers in de doeltenant ook foutmeldingen over niet-gevonden accounts geven. Controleer de synchronisatiestatus telkens wanneer hybride identiteit in het spel is.
• Shadow IT of niet-beheerde apps: Niet-goedgekeurde applicaties of toestemming voor apps van derden (klassiek Shadow IT) kunnen conflicterende toegangsroutes voor gebruikers creëren, en soms bijdragen aan hardnekkige aanmeldfouten. Voor meer grip op de risico’s van Shadow IT, zie deze gids over het beheren van Shadow IT binnen je M365-tenant.

Effectieve oplossingen voor AADSTS50020-fouten 'Account niet gevonden'

Het oplossen van de AADSTS50020-fout begint altijd met het precies vaststellen waar de mismatch zit: accounttype, directory, endpoint of toegangsmachtigingen. Zodra je de hoofdoorzaak kent, kun je gerichte oplossingen per scenario toepassen en voorkomen dat de fout opnieuw opduikt.

Gaat het om een persoonlijk versus een organisatieaccount? Gebruik dan het juiste type login. Heeft het probleem te maken met de app-registratie? Controleer dan de instellingen voor het doelgroep van aanmelding (sign-in audience) en pas die aan zodat de accounts die je wilt ondersteunen erbij horen: single tenant, multitenant of zelfs persoonlijke Microsoft-accounts, indien nodig. Voor gastgebruikers geldt: zorg dat uitnodigingen correct zijn verzonden en ingewisseld. Soms lost een nieuwe uitnodiging het probleem meteen op.

Vergeet de gebruikerstoewijzing niet! Als je app die vereist, wijs dan de juiste personen of groepen toe in Microsoft Entra om de blokkade op te heffen. Blijft de verwarring bestaan door browsercaching of blijvende sessies, probeer dan uit te loggen en de inlogpagina opnieuw te openen in een privé- of incognitovenster. Soms moet je een nieuwe directory aanmaken of toegang op een hoger niveau toewijzen, vooral bij het opzetten van nieuwe tenants of het migreren van gebruikers.

Een volledige enterprise-oplossing vraagt ook om de juiste governance. Lees hoe beleid en afwijkingen in toewijzingen (assignment drift) in grote omgevingen voor chaos kunnen zorgen, en waarom regelmatige reviews en RBAC essentieel zijn, in deze gids over de Azure enterprise governance-strategie. Met de juiste technische oplossing en wat proactieve planning houd je AADSTS50020 uit je inlogpagina's.

Bewezen best practices om toekomstige AADSTS50020-fouten te voorkomen

• Kies het juiste aanmeldeindpunt: Stem altijd de aanmeldingsdoelgroep van je app (single tenant, multitenant of persoonlijk) af op het juiste aanmeldeindpunt. Verkeerde combinaties van endpoints en doelgroepen zijn de meest voorkomende bron van verwarring.
• Beheer gastgebruikers zorgvuldig: Nodig gasten niet alleen uit en vergeet ze daarna. Houd de levenscyclus van gastgebruikers strak in de gaten: regelmatige reviews, toegang met een beperkte looptijd en een duidelijk offboardingproces. Zo verklein je het aanvalsoppervlak. Lees meer over dit onderwerp in de gids over het beheer van Microsoft 365-gastaccounts.
• Dwing gestructureerde toegang en toewijzingen af: Zorg dat apps die gebruikerstoewijzing vereisen zijn ingericht met duidelijke, actuele lijsten van wie wat mag openen. Laat toewijzingen niet verouderen: controleer en actualiseer ze regelmatig.
• Controleer en beheer app-machtigingen: Beperk consent sprawl en shadow IT door app-registraties en externe delingen te controleren. Voor diepgaander identiteitsbeveiliging en risicobeperking kun je lessen halen uit deze aflevering over de Entra ID conditional access security loop, en houd je voorwaardelijke toegangsbeleidsregels helder en afdwingbaar.
• Verifieer domeinen en houd DNS in de gaten: Controleer altijd dubbel of de verificatie van aangepaste domeinen in Azure AD klopt, en let op lokale DNS- of firewallregels die Microsoft-inlogendpoints kunnen blokkeren.
• Houd hybride identiteitssynchronisatie goed in de gaten: Als je synchroniseert vanuit on-premises AD, let dan op problemen met Azure AD Connect en zorg dat gebruikersobjecten naar alle juiste tenants worden gesynchroniseerd.

Samenvatting van AADSTS50020-oorzaken, symptomen en oplossingen

• Veelvoorkomende symptomen: Toegang geweigerd, foutmeldingen dat de gebruiker niet in de tenant is gevonden, of mislukte inlogpogingen bij Microsoft 365- en Azure-apps.
• Belangrijkste oorzaken: Verkeerd accounttype (persoonlijk versus werk), verkeerde tenant of endpoint, onvolledige gastuitnodigingen, niet-toegewezen gebruikers, domein- of DNS-fouten, of mislukte directorysynchronisatie.
• Oplossingen: Gebruik de juiste login voor je accounttype, kies het juiste endpoint en de juiste tenant, verstuur gastuitnodigingen opnieuw, wijs gebruikers toe aan apps, verifieer je domeinen, los synchronisatieproblemen op en houd je browsers vrij van cache.
• Preventietips: Voer toegangsreviews uit, houd de levenscyclus van gasten en gebruikers onder controle en zorg voor sterke governance op apps en endpoints.