Hoe los je foutcode AADSTS50034 op: gebruiker bestaat niet in Microsoft Azure AD

By Mirko Peters · 2026-04-21

Foutcode AADSTS50034 in Microsoft Azure AD betekent simpelweg: “gebruiker bestaat niet.” Wanneer iemand probeert aan te melden bij Microsoft 365, Azure of verwante clouddiensten en deze code krijgt, kan Azure Active Directory geen account vinden dat overeenkomt met de gebruikersnaam die is ingevoerd. Dit bericht komt vaak voor, vooral nadat een gebruiker het bedrijf heeft verlaten, is verwijderd,

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

Foutcode AADSTS50034 in Microsoft Azure AD betekent simpelweg: “gebruiker bestaat niet.” Wanneer iemand probeert aan te melden bij Microsoft 365, Azure of verwante clouddiensten en deze code krijgt, kan Azure Active Directory geen account vinden dat overeenkomt met de gebruikersnaam die is ingevoerd. Dit bericht komt vaak voor, vooral nadat een gebruiker het bedrijf heeft verlaten, is verwijderd, of wanneer er een typfout of een vergissing is gemaakt tijdens het aanmelden of het synchroniseren van accounts.

Deze fout oplossen is niet alleen het wegnemen van een vervelende melding. Het is cruciaal voor naadloze toegang tot de cloud, de productiviteit van gebruikers en een sterke beveiliging. AADSTS50034 kan ervoor zorgen dat legitieme gebruikers hun werk niet kunnen doen, en wijst op diepere problemen met de levenscyclus van accounts, de directoryconfiguratie of de tenanttoegang. Deze gids legt uit waarom deze fout optreedt, hoe deze zich verhoudt tot vergelijkbare problemen, en welke stappen je kunt nemen om deze op te lossen of, beter nog, om toekomstige AADSTS-problemen in Microsoft-omgevingen te voorkomen.

AADSTS50034 en gerelateerde Azure AD-authenticatiefouten begrijpen

AADSTS50034 zit midden in het hart van het gebruikersopzoekproces van Azure Active Directory. Wanneer mensen de melding “gebruiker bestaat niet” zien, gebeurt er eigenlijk het volgende: Azure AD heeft geprobeerd hun gebruikersnaam of inloggegevens te koppelen aan de directory, maar vond niets. Dit kan betekenen dat de gebruiker nooit heeft bestaan, is verwijderd, of nooit is gesynchroniseerd of ingericht.

Maar authenticatie in de cloud van Microsoft is zelden eenvoudig, en er kunnen veel foutcodes tegelijk optreden, wat eerder verwarring dan duidelijkheid oplevert. Naast AADSTS50034 krijgen beheerders vaak te maken met andere aanmeldfouten, zoals AADSTS50020 en AADSTS50126. Deze draaien allemaal om het bestaan en de identiteit van een gebruiker, maar elk heeft een eigen, subtiele betekenis. Het gevolg is dat probleemoplossing aanvoelt als een detectiveverhaal, waarbij elke fout naar een andere oorzaak wijst: een niet-overeenkomende tenant, wachtwoordproblemen of ontbrekende gebruikersobjecten.

Deze codes begrijpen is essentieel voor iedereen die verantwoordelijk is voor de ondersteuning van Microsoft 365 of Azure. De grens tussen een ontbrekende gebruiker, een ongeldig wachtwoord en een verkeerde tenant is dun, en door de verschillen te kennen los je problemen sneller en met meer zekerheid op. Voordat je aan technische oplossingen begint, is het belangrijk om het grotere geheel te zien: hoe Azure AD identiteiten controleert, fouten interpreteert en deze codes in het verhaal van veilige, betrouwbare toegang samenbrengt. Laten we uitzoeken wat AADSTS50034 veroorzaakt en hoe deze zich verhoudt tot andere veelvoorkomende aanmeldfouten.

Oorzaken van foutcode AADSTS50034 en hoe je deze oplost in Microsoft Azure

Foutcode AADSTS50034 verschijnt wanneer Azure AD tijdens het aanmelden geen overeenkomend gebruikersobject kan vinden. Het is ongeveer zo eenvoudig als het klinkt: als de gebruiker niet in de directory bestaat, wordt de toegang geweigerd. De oorzaken variëren echter van eenvoudig, zoals een typfout in een e-mailadres, tot verborgen problemen, zoals verwijderingen, mislukte synchronisatie of tenantconflicten.

De meest voorkomende oorzaken zijn verkeerd getypte gebruikersnamen, gebruikers die recent zijn verwijderd maar nog steeds proberen aan te melden, of accounts die nooit zijn gesynchroniseerd vanuit on-premises Active Directory. Een andere boosdoener is dat de gebruiker probeert toegang te krijgen tot de verkeerde tenant. Misschien heeft die toegang tot meerdere organisaties, of is de gastuitnodiging nooit volledig verwerkt. Nog verwarrender: als er vertraging zit in het aanmaken van B2B-gebruikers of als er een afwijking is tussen e-mail en UPN tijdens federatie, verschijnt AADSTS50034 eveneens.

Om deze fout op te lossen, controleer je eerst de gebruikersnaam op typfouten. Controleer in het Azure-portaal onder Gebruikers of de gebruiker bestaat in de beoogde tenant. Als de gebruiker is verwijderd, moet je deze mogelijk herstellen, of bij gastentoegang opnieuw uitnodigen. Controleer in hybride omgevingen of het on-premises account actief is en succesvol synchroniseert met Azure AD. Bevestig ten slotte altijd dat de aanmelding wordt geprobeerd in de juiste tenant en dat het gebruikerstype (‘Member’ of ‘Guest’) overeenkomt met de rol van het account. Door deze onderliggende problemen aan te pakken, verdwijnt AADSTS50034 en wordt de algehele betrouwbaarheid van identiteiten in je omgeving versterkt.

Azure AD-gebruikersfouten vergelijken: AADSTS50020 versus AADSTS50126

De fouten AADSTS50020 en AADSTS50126 worden vaak verward met AADSTS50034, maar wijzen op iets andere aanmeldproblemen. AADSTS50020 betekent dat de gebruiker wel bestaat in Azure AD, maar niet in de tenant waar hij of zij naartoe wil. Dit gebeurt vaak wanneer iemand met de juiste inloggegevens inlogt bij de verkeerde organisatie of tenant.

AADSTS50126 wijst daarentegen op onjuiste inloggegevens, zoals een geldige gebruikersnaam met het verkeerde wachtwoord. AADSTS50034 zegt eigenlijk: “Wie ben jij?”, terwijl deze andere codes zeggen: “Niet hier!” (50020) of “Dat is niet jouw wachtwoord!” (50126). Als je deze nuances snel herkent, kunnen beheerders veel sneller bepalen of de oplossing in de inloggegevens, de tenant of de directoryconfiguratie zelf zit.

Problemen met tenants en directory's oplossen om toegangsproblemen in Azure AD te verhelpen

Veel toegangsproblemen in Azure AD komen neer op de keuze van de tenant, de directoryconfiguratie of de handhaving van beleid. In omgevingen van grote organisaties, zeker die met meerdere Azure-tenants of business-to-business (B2B)-opzetten, lopen gebruikers vaak tegen fouten aan simpelweg omdat ze op het verkeerde moment in de verkeerde omgeving zitten. Het komt regelmatig voor dat een gebruiker per ongeluk inlogt op een andere tenant, of dat beleid een verder geldige aanmelding blokkeert.

De tenant- en directorystructuur van Azure AD fungeert als een beveiligingsgrens. Toegang van gebruikers, app-registraties en machtigingen voor resources zijn allemaal gekoppeld aan de context van de huidige tenant. Als een gebruiker of gast vanuit de verkeerde context probeert in te loggen, is het systeem niet lastig: het kan die gebruiker simpelweg niet vinden of autoriseren. Dat leidt tot fouten zoals AADSTS50034, AADSTS50105 of AADSTS53003.

Bij het oplossen van dit soort problemen let je goed op hoe gebruikers tussen tenants worden doorgestuurd, of het om leden of gasten gaat en of er sprake is van een mismatch in de directory. Bij organisaties met complexe voorwaardelijke toegang of sterk afgeschermde tenants kan het beheerbeleid ook in de weg zitten en toegang weigeren, ook als alles volgens de bedoeling is ingericht. Meer over hoe governance en beleid toegang kunnen bepalen, vind je in deze bron over Azure enterprise governance. Grip krijgen op de grenzen van directory en tenant is essentieel voordat je je verdiept in de steeds terugkerende vraag “waarom wordt deze gebruiker niet gevonden?”.

Zo los je op: controleer of je de juiste tenant gebruikt in Azure AD

• Controleer de tenantcontext: controleer altijd de tenant die je ziet in je Azure- of Microsoft 365-portal. De weergavenaam rechtsboven geeft je actieve organisatie aan.
• Wissel van directory: als je lid bent van meerdere tenants, gebruik dan de directory-wisselaar in de portal om tussen organisaties te schakelen voordat je opnieuw probeert in te loggen.
• Controleer je lid- of gaststatus: bevestig of je als lid of als gast bent opgenomen in de organisatie waartoe je toegang zoekt. Een onjuiste rol blokkeert de toegang vaak.
• Controleer uitnodigingen: zorg bij gastgebruikers dat de uitnodiging is geaccepteerd en dat het gastaccount is aangemaakt in de juiste Azure AD-directory.

AADSTS50105 en AADSTS53003 oplossen: directorytoegang geblokkeerd of geweigerd

1. Beleid of toegang geblokkeerd (AADSTS50105): Beheerders kunnen toegangsbeleid, groepen of beperkingen hebben ingesteld die bepaalde gebruikers de toegang tot resources ontzeggen. Controleer de groepstoewijzingen en de rolgeschiktheid in het beheercentrum.
2. Voorwaardelijke toegang of beperkingen voor externe gebruikers (AADSTS53003): Aanmelding kan worden geblokkeerd als beleid voor apparaatcompliance, locatie of risico wordt afgedwongen. Controleer alle voorwaardelijke toegangsbeleidsregels in Microsoft Entra ID en zorg dat aan de eisen voor apparaatregistratie en beveiliging wordt voldaan.
3. Verlopen gastaccount of toegangsreview: Gasten of externe gebruikers kunnen hun toegang verliezen na een toegangsreview of automatische verlooping. Voer regelmatig audits van gastaccounts en levenscyclusreviews uit om onverwachte weigeringen te beheersen en tot een minimum te beperken.
4. Beheerdersinterventie: Vermoed je een bredere blokkade, neem dan contact op met je beheerder om beperkingen op te heffen of de toegang opnieuw in te richten, volgens de best practices uit de gids over governance van de levenscyclus van gastaccounts.

On-premises AD synchroniseren en accounttypen controleren om AADSTS50034 te voorkomen

Organisaties met een hybride identiteitsopstelling trappen vaak in AADSTS50034-valkuilen door problemen met synchronisatie en de classificatie van accounts. Wanneer je on-premises Active Directory is gekoppeld aan Azure AD, kunnen storingen bij het synchroniseren van gebruikersaccounts ervoor zorgen dat mensen worden buitengesloten, ook al lijkt hun account lokaal wel te bestaan.

Een grote oorzaak is dat gebruikers niet goed synchroniseren tussen on-premises AD en Azure AD. Misschien is het synchronisatieproces mislukt, is het gebruikersobject uitgeschakeld, of zijn wijzigingen nog niet naar de cloud gerepliceerd. Deze problemen komen vaak pas aan het licht wanneer een gebruiker probeert in te loggen en de melding ‘user does not exist’ ziet.

Het wordt lastiger wanneer gebruikers verkeerd geclassificeerd zijn: als ‘Guest’ terwijl ze ‘Member’ moeten zijn, of andersom. Microsoft Entra ID (voorheen Azure AD) controleert deze status tijdens de authenticatie. Als een externe gast verkeerd is geconfigureerd, of een gesynchroniseerde membergebruiker als gast is gemarkeerd, weet Azure AD niet waar het moet zoeken en krijg je AADSTS50034. Voor beheerders van hybride, multi-cloud of omgevingen met veel gastgebruikers is het belangrijk deze nuances goed te begrijpen. Laten we vervolgens kijken naar praktische manieren om een goede synchronisatie en de juiste accounttypen in de clouddirectory van Microsoft te waarborgen.

Synchronisatie van on-premises AD met Azure AD repareren om problemen met directorysynchronisatie te voorkomen

• Controleer de synchronisatiestatus: bekijk in het dashboard van Azure AD Connect de laatste synchronisatietijd en eventuele foutrapporten. Als er fouten staan, los deze op voordat je verder gaat.
• Controleer de gebruiker in de cloud: gebruik het Azure AD-portaal om te bevestigen dat de gebruiker aanwezig is en overeenkomt met de gegevens in je on-premises directory.
• Los synchronisatiefouten op: pak veelvoorkomende problemen aan, zoals dubbele proxyadressen, conflicten in gebruikersobjecten of verkeerd geconfigureerde kenmerken die directorysynchronisatie blokkeren.
• Start een handmatige synchronisatie: als een gebruiker net is aangemaakt of gewijzigd, voer dan een handmatige synchronisatie uit om de on-premises en cloud-directory handmatig bij te werken.

Controleer het accounttype en los AADSTS50034 op voor leden en gasten van Microsoft

• Controleer het gebruikerstype: controleer in Microsoft Entra ID of de gebruiker als ‘Member’ of ‘Guest’ is aangemerkt. Een verkeerd type blokkeert de aanmelding bij tenantresources.
• Corrigeer verkeerde classificaties: zet verkeerd geregistreerde gasten om naar leden (of andersom) met de beheertools voor gebruikers in Azure AD.
• Valideer UPN’s en e-mailadressen: controleer of de User Principal Name overeenkomt met het beoogde account en of er geen niet-overeenkomende e-mailaliassen zijn die conflicten veroorzaken.
• Controleer externe identiteiten: controleer bij B2B- en hybride gebruikers of uitnodigingen en organisatorische relaties correct zijn ingesteld en actief zijn.

Wanneer authenticatie van services en apps AADSTS-fouten veroorzaakt in Microsoft 365

AADSTS-fouten komen niet alleen voor bij reguliere gebruikersaanmeldingen. Ze verschijnen ook wanneer apps en services verbinding maken met Microsoft 365. Soms is de service zelf het probleem: app-registraties werken niet goed, clientsecrets verlopen of een registratie is verwijderd. Exchange Online, SharePoint en honderden integraties van derden zijn afhankelijk van een correcte configuratie in Azure AD, dus zelfs een kleine wijziging kan alles blokkeren.

De app-registratie moet overeenkomen met de authenticatie-instellingen van de client. Elke afwijking, zoals een ontbrekend of ingetrokken secret, een verkeerde app-ID, een uitgeschakelde app of een niet-overeenkomende redirect-URI, kan fouten veroorzaken zoals AADSTS700016 (‘app not found’) of AADSTS7000218 (‘invalid client secret’). Deze problemen geven IT-beheerders vaak hoofdbrekens, vooral tijdens tenantmigraties, PowerShell-automatisering of wanneer nieuwe apps snel worden opgezet.

Daarnaast kunnen strikte voorwaardelijke toegangsbeleidsregels en strenge tenantbeperkingen apps blokkeren, ook als de authenticatiegegevens juist lijken. Weten hoe je deze fouten interpreteert en het probleem traceert, of het nu gaat om een app-instelling, een toestemmingsverlening of een OAuth-lek, is cruciaal om bedrijfsonderbrekingen te voorkomen. Maak je zorgen over OAuth-toestemming of beveiligingslekken in apps? Bekijk dan hoe je consent-aanvallen kunt voorkomen met Entra ID OAuth-toestemming.

AADSTS700016 en AADSTS7000218 oplossen: applicatie niet gevonden of ongeldige client

• Controleer de app-registratie: zorg dat de applicatie is geregistreerd in de Azure AD-tenant. Vergelijk de client-ID's en app-ID's in de authenticatieaanvragen met de geregistreerde waarden.
• Controleer het clientsecret of certificaat: zorg voor vertrouwde clients dat het secret of certificaat geldig en actief is en overeenkomt met de instellingen van de app-registratie.
• Valideer de redirect-URI's: het antwoord moet een redirect-URI gebruiken die in de app-registratie staat vermeld. Elke afwijking leidt tot een mislukte aanmelding.
• Controleer tenant en machtigingen: apps moeten zijn ingeschakeld in de juiste tenant, met gedelegeerde of app-only machtigingen die passen bij de use case.

Oplossen van AADSTS90002 en AADSTS900144 in Microsoft 365-services

1. Tenant niet gevonden (AADSTS90002): Dit betekent meestal dat de doeltenant niet bestaat of is verwijderd. Controleer de domeinnaam in je aanmelding of de verbindingsreeks van de app en zorg dat de tenant actief is.
2. Beleids- of maprichtlijnschending (AADSTS900144): Voorwaardelijke toegang of tenantbrede beleidsregels kunnen strengere controles afdwingen. Bekijk en pas het beleid aan, waarbij je prioriteit geeft aan brede dekking en ad-hocuitzonderingen tot een minimum beperkt voor betrouwbaarheid. Meer weten over een goed beleidsontwerp? Lees deze best practices voor voorwaardelijke toegang.
3. Problemen met gedelegeerde toegang: Verlopen OAuth-toestemmingen of ontbrekende machtigingen in app-registraties kunnen de aanmeldstroom blokkeren. Controleer daarom regelmatig de toestemmingen en hun vervaldatums.
4. Verwijderde service of gebruiker: Zorg dat de vereiste service-principal en gebruiker bestaan in de juiste tenant. Zijn ze recent verwijderd, herstel ze dan of registreer ze opnieuw.

Vereisten voor multifactorauthenticatie en voorwaardelijke toegangsbeleidsregels

Ook als gebruikers het juiste account en de juiste inloggegevens hebben, kan Azure AD de toegang nog steeds blokkeren als aan de beveiligingsbeleidsregels niet wordt voldaan. Multifactorauthenticatie (MFA) en vereisten voor apparaatcompliance spelen hierbij een grote rol. Organisaties gebruiken ze om risico’s te beperken: er wordt extra verificatie gevraagd of de status van het apparaat gecontroleerd voordat een aanmelding wordt voltooid.

Fouten als AADSTS50076 en AADSTS50079 verschijnen wanneer een gebruiker MFA overslaat of probeert in te loggen vanaf een niet-beheerd of niet-compliant apparaat. Deze fouten kunnen gebruikers verrassen, zeker als het beleid recent is gewijzigd of ze voor het eerst een nieuw apparaat gebruiken. Vaak is vooraf niet duidelijk dat een nieuwe voorwaarde wordt afgedwongen, totdat Azure AD de verbinding volledig weigert.

Voor beheerders is het configureren en onderhouden van effectieve voorwaardelijke toegang een doorlopend proces en geen klus die je eenmalig afrondt. Afwijkingen ontstaan vanzelf: gebruikers zoeken omwegen, beleidsregels worden aangepast en apparaten worden vervangen. Wil je dieper ingaan op schaalbare en afdwingbare identiteitsbeveiliging? In deze podcast over governance van voorwaardelijke toegang lees je hoe je beveiligingsmaatregelen sterk houdt en tegelijk de wrijving beperkt. Hierna volgen de praktische stappen voor het oplossen van veelvoorkomende aanmeldblokkades door MFA en compliance.

AADSTS50076 en AADSTS50079 oplossen: MFA en apparaatcompliance vereist

• MFA instellen: Als je hierom wordt gevraagd, zorg dan dat MFA is ingeschakeld en ingesteld. Gebruik de mobiele app, een telefoontje of sms, afhankelijk van de configuratie van je organisatie.
• Apparaten registreren: Voor compliance van het apparaat zorg je dat je apparaat is ingeschreven in het apparaatbeheersysteem van je organisatie, zoals Intune of Endpoint Manager.
• Beleid controleren: Controleer de toewijzing en scope van de beleidsregels voor voorwaardelijke toegang. Pas ze aan als legitieme gebruikers worden geblokkeerd door regels die te streng zijn.
• Contact opnemen met beheerder: Als de configuratie klopt maar de fouten blijven optreden, vraag dan je beheerder om de compliance van het apparaat of de sessie te controleren en de beleidslogboeken op recente wijzigingen na te lezen.

Expert-tips: fouten ‘User does not exist’ voorkomen in Microsoft Entra B2B-scenario’s

Het oplossen van de fout ‘user does not exist’ is één ding, maar voorkomen is een heel ander verhaal, zeker in Microsoft Entra B2B- en cross-tenantsituaties. Naarmate organisaties vaker over bedrijfsgrenzen heen samenwerken, neemt de kans op AADSTS50034 toe door vertragingen bij gebruikersprovisioning, spookgastaccounts en niet-overeenkomende gebruikerseigenschappen. Het proces voor het aanmaken van gastgebruikers, het verwijderen van accounts en de synchronisatie van hybride identiteiten verloopt niet altijd direct of volledig betrouwbaar.

Grip op het levenscyclusbeheer is essentieel. Vertraagde uitnodigingen, mislukte synchronisaties met externe partijen en afwijkende e-mailaliassen kunnen voor gastgebruikers AADSTS50034 veroorzaken, ook als het onboardingproces af lijkt. Accounts die zijn verwijderd wegens inactiviteit, compliance of handmatig opschonen door een beheerder, kunnen in een zacht verwijderde status blijven staan en zorgen dan voor vreemde situaties bij aanmelding of tenantmigraties. Wil je deze valkuilen vermijden, dan zijn regelmatige toegangsreviews en gestructureerde levenscyclusregels onmisbaar, zoals beschreven in deze uitgebreide gastbeheergids.

Beheerders die apps of services verplaatsen met service principal-authenticatie hebben hun eigen reeks problemen, waarbij ontbrekende gebruikerscontext of verkeerd geconfigureerde machtigingen zorgen dat AADSTS50034 opduikt. In werkelijkheid ligt de oorzaak zelden bij een ontbrekende gebruiker. Wees proactief met B2B-provisioning, mail/UPN-matching en instellingen voor app-migratie, dan geeft je directory de stabiliteit die nodig is voor cross-tenantprojecten en complexe automatiseringsflows. Laten we kijken hoe je deze hardnekkige AADSTS50034-scenario’s monitort, diagnosticeert en voorkomt.

Gastgebruikersprovisioning, accountverwijdering en UPN-afwijkingen die leiden tot AADSTS50034

• Vertragingen bij provisioning: nadat een gast een uitnodiging heeft geaccepteerd, kan het even duren voordat het account volledig in Azure AD verschijnt. Controleer de aanmeldingslogboeken en de aanmaaktijdlijn voordat je verder troubleshoot.
• Automatisch of handmatig verwijderen: gasten en externe gebruikers kunnen automatisch worden verwijderd wegens inactiviteit, of handmatig door beheerders worden verwijderd. Zacht verwijderde accounts kunnen zich niet authenticeren en veroorzaken AADSTS50034. Controleer je levenscyclusbeleid regelmatig, zoals beschreven in deze gids over levenscyclusbeheer.
• E-mail/UPN-afwijking: gebruikers die aanmelden met e-mailaliassen of afwijkende UPN’s (User Principal Names) worden mogelijk niet gevonden door Azure AD. Los dit op door ervoor te zorgen dat UPN en primair e-mailadres overeenkomen met wat in de directory is vastgelegd.
• SMTP-matchingconflicten: dubbele e-mailadressen over tenants heen veroorzaken fouten bij identiteitsresolutie. Gebruik expliciete uitnodigingen en zorg dat e-mailadressen binnen elke tenant uniek zijn om opzoekfouten te voorkomen.

Service principal en app-only authenticatie: misleidende AADSTS50034-fouten bij migraties vermijden

1. Context van app-only authenticatie: migratietools of automatiseringsscripts die service principals gebruiken, kunnen AADSTS50034 krijgen wanneer de app-machtigingen verkeerd zijn geconfigureerd of het script verwijst naar een ontbrekend gebruikersobject, terwijl er bij de authenticatie helemaal geen gebruiker betrokken is. Valideer rollen en app-scopes altijd in het portaal voordat je migraties uitvoert.
2. Gedelegeerde scopes en verlopen toestemming: als gedelegeerde machtigingen vereist zijn maar de toestemming is verlopen of ontbreekt, kunnen tools AADSTS50034 onjuist rapporteren. Ken de toestemming opnieuw toe of controleer deze, vooral na tenantmigraties of goedkeuringscycli van apps.
3. Nauwkeurigheid van UPN en Object-ID: gebruik bij het scripten de juiste, actuele UPN en Object-ID die overeenkomen met de actieve gebruiker of service principal in de tenant, zodat je geen referentiefouten krijgt.
4. Fouten diagnosticeren: zoek niet alleen naar een ontbrekende gebruiker. Controleer de Graph API- of PowerShell-logboeken op fouten in machtigingen en objectreferenties om de werkelijke oorzaak van authenticatiefouten bloot te leggen.