Welche Microsoft-Entra-ID-Fehlercodes bedeuten was – und wo liegt die Ursache bei Anmelde-, MFA- und Token-Problemen?

Technische Grundlagen zur Fehlereinordnung: Identitäten, Anmeldepfade, Tokenflüsse, Richtlinien und Vertrauensstellungen in Entra ID

Identitätsobjekte und Mandanten-Grenzen als erste Fehlerquelle

Fast jede Entra-ID-Fehlermeldung lässt sich auf ein konkretes Objekt und dessen Beziehung zu einem Tenant zurückführen. Technisch zentral sind Benutzer- und Dienstprinzipale (Service Principals), Applikationsobjekte (Application Registrations), Gruppen, Geräteobjekte sowie deren Verknüpfungen (z. B. App-Zuweisungen, Rollen, Geräte-Registrierungsstatus). Viele scheinbar „anwendungsbezogene“ Fehler entstehen, weil ein Token für den falschen Tenant ausgestellt werden soll, weil das Zielobjekt im Tenant nicht existiert oder weil eine Identität nur als Gast (B2B) vorliegt und daher andere Anmeldepfade, Claims und Richtlinien greift.

Für die Fehlereinordnung ist entscheidend, ob eine Identität als Cloud-only, synchronisiert (Entra Connect) oder föderiert (z. B. AD FS, Drittanbieter-IdP) geführt wird. Diese Entscheidung bestimmt, wo Kennwortprüfung, MFA-Auslösung, Gerätezustand und Blockierungslogik durchgesetzt werden. Daraus folgt: Derselbe sichtbare Anmeldefehler in einer Anwendung kann auf einen lokalen AD-Kennwortstatus, eine Cloud-Sperre, eine CA-Richtlinie oder eine Token-Audience-Mismatch-Situation zurückgehen.

Anmeldepfade: interaktiv, nicht-interaktiv, Legacy und Workload-Identitäten

Entra ID unterscheidet technisch zwischen interaktiven Benutzeranmeldungen (Browser, moderne Authentifizierung), nicht-interaktiven Tokenabrufen (z. B. Refresh-Token-Flows), Legacy-Authentifizierung (Basic/SMTP/IMAP, wo noch zugelassen) sowie Workload-Identitäten (Client Credentials, Federated Credentials). Fehlercodes und Statusmeldungen variieren je nach Pfad, weil andere Gateways beteiligt sind: Bei interaktiven Anmeldungen dominiert die Richtlinienauswertung (Conditional Access, MFA), bei Workloads die Konfiguration der App (Credentials, Zertifikate, Federated Credentials, Token-Audience) und bei Legacy der Protokollblock (Security Defaults/CA).

Für die Praxis bedeutet das: Eine Fehlermeldung in Exchange Online, SharePoint, Teams oder einer Drittanwendung ist oft nur die Oberfläche eines fehlgeschlagenen OAuth/OpenID-Connect-Vorgangs. Der relevante technische Kern steht dann in den Sign-in-Logs (interactive oder non-interactive) sowie in den Token-Fehlerdetails (z. B. fehlende Claims, abgelehnte Grant Types). Ohne diese Zuordnung werden CA-Blocks, Consent-Probleme oder Credential-Fehler häufig fälschlich als „App down“ klassifiziert.

• Interaktive Benutzeranmeldung: führt typischerweise über /oauth2/v2.0/authorize bzw. OpenID Connect und endet mit Token-Ausstellung an /oauth2/v2.0/token; hier erscheinen CA- und MFA-Entscheidungen prominent.
• Non-interactive Sign-in: umfasst Token Refresh, On-Behalf-Of und Hintergrundabrufe; Fehler wirken wie „plötzliche App-Abmeldung“, obwohl die Ursache oft ein widerrufenes Refresh-Token oder geänderte CA-Bedingungen ist.
• Workload (Client Credentials): Tokenabruf über grant_type=client_credentials an /oauth2/v2.0/token; Fehlereinordnung fokussiert auf client_id, Credential-Typ (Secret/Zertifikat/Federated) und Zielressource (scope bzw. /.default).
• Legacy Authentication: tritt als Protokollanmeldung ohne moderne Tokenflüsse auf; Blockierungen erscheinen als CA- oder Security-Defaults-Effekt, obwohl der eigentliche Auslöser die Protokollklasse ist.

Tokenflüsse, Claims und warum Fehler als „Zugriffsproblem“ in Anwendungen erscheinen

Entra ID stellt Identität gegenüber Anwendungen primär über Tokens dar. ID Token (OIDC) transportiert Authentifizierungsereignisse, Access Token autorisiert den Zugriff auf eine Ressource (API), Refresh Token ermöglicht Folgeausstellungen. Viele Fehlbilder entstehen, weil Anwendungen nicht die Anmeldung, sondern die Autorisierung auswerten: Ein Login kann erfolgreich sein, während der Zugriff auf eine API wegen falscher Audience, fehlender Scopes, abgelehnter Consent-Basis oder CA-Claims-Challenge scheitert.

Claims fungieren als technische Schnittstelle zwischen Identitätszustand und Policy-Entscheidung. Conditional Access kann eine „Claims Challenge“ erzwingen, sodass eine Ressource ein Token mit zusätzlichen Anforderungen verlangt (z. B. MFA, compliant device). Anwendungen, die diese Challenge nicht sauber weiterreichen, zeigen dann generische Fehler wie „unauthorized“ oder „need admin approval“, obwohl die Ursache eine CA-Richtlinienentscheidung oder ein fehlender Claims-Parameter ist. Auch Token-Lebensdauern und Session Controls wirken indirekt: Token werden weiterhin akzeptiert, bis die Ressource oder der Client eine neue Bewertung erzwingt, was Fehler oft zeitversetzt auftreten lässt.

Richtlinienauswertung: Conditional Access, MFA, Session Controls und Risiko-Signale

Conditional Access bewertet eine Anmeldung kontextbezogen anhand von Signalen (Benutzer, Gruppe, App, Standort, Gerät, Clienttyp, Risiko, Authentifizierungsstärke) und setzt ein Ergebnis durch: erlauben, blockieren oder Anforderungen stellen. Diese Anforderungen können MFA, bestimmte Authentifizierungsmethoden (Authentication Strength), Gerätekonformität oder zugelassene Apps (App Protection/Client App) umfassen. MFA selbst ist dabei nicht „die“ Ursache, sondern häufig nur die geforderte Kontrollmaßnahme; die eigentliche Ursache liegt in der Richtlinienbedingung, die die Kontrolle auslöst.

Session Controls (z. B. Sign-in-Frequenz, persistent browser session) erzeugen Fehlbilder, die wie Tokenprobleme wirken: Clients müssen häufiger neu authentifizieren, Refresh Tokens verlieren ihre Nutzbarkeit oder werden durch Reauth-Anforderungen ergänzt. Risiko-basierte Entscheidungen (Identity Protection, sofern lizenziert und aktiv) fügen eine weitere Ebene hinzu: Eine Anmeldung kann bei erhöhtem Risiko blockiert oder zur Kennwortänderung gezwungen werden, was sich in Apps als „Access denied“ ohne sichtbaren Risikohinweis ausdrücken kann.

• Policy-Entscheidung „Block“: erscheint in Anwendungen oft nur als generisches „Zugriff verweigert“, technisch ausgelöst durch CA-Resultat und in Sign-in-Logs über „Conditional Access“ nachvollziehbar.
• Policy-Entscheidung „Require MFA“: führt zu zusätzlichem Authentifizierungsschritt; bei fehlender Registrierung oder Methodenrestriktion entsteht ein MFA-/Methodenfehler, obwohl der Trigger die CA-Bedingung ist.
• Authentication Strength: erzwingt eine Methodenklasse (z. B. phishing-resistant); Fehlermeldungen wirken wie „MFA schlägt fehl“, technisch handelt es sich um eine Nichterfüllung der geforderten Stärke.
• Sign-in Frequency / Reauthentication: verursacht wiederkehrende Login-Prompts; Fehler treten häufig beim Token-Refresh auf und erscheinen in Clients als „Session expired“.

Vertrauensstellungen: Föderation, externe Identitäten und Schlüsselmaterial

Vertrauen ist in Entra ID technisch entweder implizit (verwaltete Domäne) oder explizit (föderierte Domäne, externe IdPs, B2B/B2C-ähnliche Flows im Entra External ID Kontext). Bei Föderation verlagert sich die Primärauthentifizierung an den Identity Provider; Entra ID nimmt Assertions entgegen und transformiert sie in Token für Zielressourcen. Fehlerbilder spalten sich dadurch: Der Client sieht möglicherweise einen Entra-ID-Dialog, die Ursache liegt jedoch in der Signaturprüfung, der UPN-Routing-Logik, einer abgelaufenen Token-Signing-Konfiguration des IdP oder in einer nicht mehr passenden Domänenkonfiguration.

Schlüsselmaterial und Metadaten sind dabei ein häufiger Engpass. Token-Signierung (OpenID-Configuration/JWKS), Zertifikatswechsel und Metadaten-Caching entscheiden, ob Ressourcen Tokens validieren können. Parallel existiert Vertrauenslogik für Workloads: Zertifikatsbasierte Clientauthentifizierung, federierte Workload-Credentials (z. B. OIDC von CI/CD) und deren Audience/Issuer-Bindung. Bereits kleine Abweichungen bei issuer, subject oder erlaubter Audience führen zu Tokenablehnung, die in Logs als OAuth-Fehler erscheint, obwohl „die Anmeldung“ im engeren Sinne nie stattgefunden hat.

Referenz der Anmelde- und Zugriffsfehler: AADSTS-/MSAL-Codes, Conditional-Access-Meldungen, MFA/OTP-Probleme und typische Originaltexte

Anmelde- und Zugriffsfehler in Microsoft Entra ID erscheinen je nach Client und Protokoll als AADSTS-Fehlercode (vom Security Token Service), als MSAL-Exception/Browser-Fehler oder als Conditional-Access-Blockmeldung. Technisch lassen sich diese Meldungen auf wenige Schichten zurückführen: Client-Anforderung (OAuth2/OIDC/SAML), Benutzer- und Mandantenkontext, Richtlinienauswertung (Conditional Access, MFA, Geräte- und Standortbedingungen) sowie Token-Ausstellung (Claims, Signaturschlüssel, Ressourcen-/Scope-Validierung). Die folgenden Referenzen ordnen typische Originaltexte und Codes diesen Schichten zu und machen sichtbar, warum identische Ursachen in Anwendungen als „Login fehlgeschlagen“, „Zugriff verweigert“ oder „App-Fehler“ erscheinen.

AADSTS-Codes bei OAuth2/OpenID Connect: Ursache, Komponente, typische Auslöser

AADSTS-Codes stammen aus dem Entra-ID-Tokenendpunkt und werden häufig als Query-Parameter (error, error_description) an Redirect-URIs zurückgegeben oder von Bibliotheken wie MSAL in Exceptions übersetzt. Die semantische Einordnung gelingt über die Stelle, an der die Anfrage scheitert: Mandantenfindung (Issuer/Tenant), Client-Validierung (App-Registrierung, Redirect URI), Benutzerzustand (Account, Kennwort, Sperre), Richtlinien (CA/MFA) und Token-Engine (Scopes/Ressourcen/Consent/Claims).

Für die Praxis ist relevant, dass viele Anwendungen AADSTS-Codes nicht anzeigen, sondern in generische Fehler übersetzen. Bei OIDC-Redirects bleibt der Code jedoch typischerweise in error_description erhalten. In Server-zu-Server-Szenarien (Client Credentials) erscheinen dieselben Codes als HTTP-Fehler vom Tokenendpunkt, häufig zusammen mit einem trace_id und correlation_id, die für die Serverprotokolle und Entra-ID-Sign-In-Logs entscheidend sind.

MSAL- und Client-seitige Fehlerbilder: Wenn AADSTS nicht sichtbar ist

MSAL kapselt Protokollfehler und ergänzt Clientdiagnostik (Cache, Broker, Netzwerk). Ein Teil der „Login-Probleme“ entsteht vor dem eigentlichen Tokenaufruf: fehlerhafte Authority, blockierte Browserfenster, fehlende System-WebView-Komponenten oder Broker-Registrierung. Andere Fehler sind AADSTS-Fehler, die als MSAL-spezifische Exceptioncodes weitergereicht werden, etwa bei interaktiver Anmeldung, Silent Token Acquisition oder Device Code Flow.

• Authority-/Tenant-Fehladressierung: Falscher Mandantenkontext oder falscher Cloud-Host führt zu Anmeldeumleitungen und „App nicht gefunden“-Meldungen; typische Parameter sind https://login.microsoftonline.com/{tenant} und in nationalen Clouds abweichende Hosts wie https://login.microsoftonline.de/.
• Token-Cache-/Silent-Flow-Probleme: acquireTokenSilent scheitert häufig nicht „wegen Passwort“, sondern wegen fehlendem passenden Cache-Eintrag, geänderter Claims-Anforderungen oder abgelaufener Session; Clients fallen dann auf interaktiv zurück oder melden „interaction required“ (konzeptionell häufig durch AADSTS wie AADSTS50076/AADSTS50079 ausgelöst).
• Redirect-/Loop-Fehler im Client: Bei Desktop-/Mobile-Apps verursachen falsche Redirect-Schemata oder nicht registrierte App-Links typische „loop“-/„cannot open page“-Effekte; technisch liegt oft derselbe Kern wie bei AADSTS50011 vor, nur früher im Client sichtbar.
• Broker-/Gerätebindung: Auf verwalteten Geräten erzwingt CA häufig gerätegebundene Tokens; wenn der Broker (z. B. Microsoft Authenticator/Company Portal) nicht verfügbar oder nicht korrekt eingebunden ist, schlägt der Nachweis fehl und äußert sich als generischer Anmeldefehler trotz korrekter Credentials.

Conditional-Access-Meldungen: Block, Unterbrechung, Claims Challenge

Conditional Access (CA) greift in die Tokenausstellung ein. Technisch erzeugt CA entweder einen harten Block (kein Token), eine Unterbrechung mit zusätzlicher Benutzerinteraktion (z. B. MFA) oder eine „Claims Challenge“, die der Client an nachgelagerte Ressourcen (typisch Microsoft Graph/SharePoint/Exchange Online) zurückspielen muss. Viele Anwendungen zeigen dann nicht den ursprünglichen CA-Grund, sondern nur „Zugriff verweigert“ oder „Weitere Informationen erforderlich“.

• „You can’t get there from here“: Klassische CA-Blockseite, wenn Bedingungen (Standort, Gerät, Risiko, Client-App) nicht erfüllt sind; Zuordnung: Richtlinienauswertung vor Token-Ausgabe, häufig mit Verweis auf „blocked by Conditional Access“ in den Sign-In-Logs.
• „AADSTS53003“ – „Access has been blocked by Conditional Access policies“: Harte CA-Blockade; Komponente: CA-Engine. Typische Auslöser sind ausgeschlossene Legacy-Authentifizierung, nicht konformes Gerät oder nicht vertrauenswürdiger Standort.
• „AADSTS53000“ – „Device is not in required state“: Gerätebedingung nicht erfüllt (z. B. „compliant“ oder „hybrid Azure AD joined“ gefordert). Fehler wirkt oft wie ein App-Problem, tatsächlich fehlt der Geräte-Claim bzw. das Gerät erfüllt die Intune/Join-Anforderungen nicht.
• „Claims challenge required“ (ressourcenseitig): Ressourcen antworten mit WWW-Authenticate und einer Claims-Anforderung; der Client muss den Tokenaufruf mit zusätzlichem claims-Parameter wiederholen. Fehlt diese Unterstützung, erscheint ein generischer 401/403 in der Anwendung.

MFA/OTP-Probleme: Methoden, Zeitfenster, Status und Originaltexte

MFA-Fehler unterscheiden sich danach, ob die primäre Anmeldung erfolgreich war und die zweite Stufe scheitert (Challenge/Verification), oder ob die Policy die Anmeldung bereits vor Erreichen der Challenge blockiert (z. B. fehlende Registrierung). OTP-Fehler wirken oft wie „falscher Code“, können aber auch aus abweichender Uhrzeit, mehrfacher Verwendung, falschem Kanal (SMS vs. TOTP) oder methodenbasierten Anforderungen stammen.

• „AADSTS50074“ – „User did not pass the multi-factor authentication challenge“: MFA-Challenge fehlgeschlagen oder abgebrochen; Zuordnung: zweite Authentifizierungsstufe. Typisch bei abgelehnter Push-Bestätigung, Zeitüberschreitung oder falschem Einmalcode.
• „AADSTS50072“ – „User strong authentication enrollment required“: Registrierung/Setup einer starken Authentifizierung erforderlich; Ursache ist häufig CA mit MFA-Anforderung oder Security Defaults bei nicht registriertem Benutzer.
• „AADSTS50144“ – „We did not receive a response from the user’s verification device“: Push/Telefon-Erreichbarkeit oder Benachrichtigungszustellung fehlgeschlagen; Komponente: MFA-Service/Benutzergerät. In der Praxis oft Netzwerk-/Push-Token-Thema, nicht Credential-basiert.
• OTP-Zeitdrift/Code-Validierung: TOTP hängt an korrekter Zeit; bei wiederholten Ablehnungen ist die Gerätezeit (NTP) ein häufiger technischer Faktor. Methodisch relevant ist außerdem die Verwechslung zwischen OATH-TOTP und SMS/Voice-OTP, wenn CA eine konkrete Methode erzwingt.
• „Number matching“/phishing-resistente Anforderungen: Wenn CA oder Authentication Strength eine bestimmte Methode fordert, scheitert eine „schwächere“ Methode trotz gültigem Code. Das wirkt wie OTP-Fehler, ist jedoch eine Policy-/Stärkenverletzung, nicht eine falsche Eingabe.

Referenz der Plattform- und Betriebsfehler: OAuth/OIDC- und Token-Fehler, App-Registrierung und Berechtigungen, Verzeichnis- und Hybrid-Synchronisation, Rollen/RBAC sowie dienst- und tenantbezogene Statusmeldungen

Plattform- und Betriebsfehler entstehen häufig nicht im eigentlichen Kennwort- oder MFA-Schritt, sondern in den Schichten darunter: Protokollverarbeitung (OAuth 2.0/OIDC), Token-Ausstellung und -Validierung, App-Objekte und Berechtigungsmodelle, Verzeichnis- und Hybridzustände sowie Rollen- und Dienstgrenzen. Diese Fehler werden in Anwendungen oft als allgemeine „Anmeldeprobleme“ sichtbar, sind technisch jedoch eindeutig einer Entra-ID-Komponente zuzuordnen: Authorization Endpoint, Token Endpoint, Consent/Ressourcenzugriff, Directory Service, Provisioning/Synchronisation oder RBAC/Privileged Identity Management.

OAuth/OIDC- und Token-Fehler: Protokoll, Client, Ressource, Zeit und Signaturen

OAuth/OIDC-Fehler treten typischerweise an zwei Schnittstellen auf: am Authorization Endpoint (Interaktion, Redirects, Parameter, PKCE) und am Token Endpoint (Client-Authentisierung, Grant-Verarbeitung, Token-Ausgabe). Die Fehlersymptome variieren je nach Clienttyp (Public vs. Confidential), Fluss (Authorization Code mit PKCE, Client Credentials, On-Behalf-Of, Refresh Token) und Zielressource (scope/resource). In Logs erscheinen sie als AADSTS-Codes; in HTTP-Antworten zudem als standardisierte Felder (error, error_description).

• AADSTS7000215 – Invalid client secret is provided: Der vertrauliche Client weist sich am Token Endpoint mit einem ungültigen Secret aus (falscher Wert, falscher Secret-Typ, abgelaufen oder Secret wurde in der App gelöscht). Betroffene Komponente: Client-Authentisierung an /oauth2/v2.0/token.
• AADSTS700016 – Application with identifier … was not found in the directory: Der Client verwendet eine client_id, die im Tenant nicht existiert oder im falschen Tenant adressiert wird (z. B. falsche Authority, falscher Mandant im Issuer/Authority-Host). Komponente: App-Objektauflösung im Directory.
• AADSTS50011 – The redirect URI … specified in the request does not match the redirect URIs configured for the application: redirect_uri stimmt nicht exakt mit der App-Registrierung überein (Schema/Host/Port/Pfad/Trailing Slash). Komponente: Redirect-URI-Validierung am Authorization Endpoint.
• AADSTS900144 – The request body must contain the following parameter: …: Ein erforderlicher Parameter fehlt, z. B. grant_type, code, redirect_uri, client_id oder scope. Komponente: Protokollparser/Request-Validierung.
• AADSTS9002313 – Invalid request. Request is malformed or invalid: Generischer Protokollfehler, häufig bei inkonsistenten Parametern (z. B. response_type passt nicht zu response_mode, unerlaubte Zeichen, doppelte Parameter). Komponente: Request-Validierung am Authorization Endpoint.
• AADSTS50148 – The code_verifier does not match the code_challenge: PKCE-Prüfung schlägt fehl (falscher code_verifier, unterschiedliche Sitzung, Code wurde für eine andere Challenge ausgestellt). Komponente: PKCE/Authorization-Code-Bindung.
• AADSTS50013 – Assertion is not within its valid time range: Token/Assertion ist zeitlich ungültig (Clock Skew, abgelaufenes JWT, falsche nbf/exp). Komponente: Token-/Assertion-Validierung und Zeitprüfung.
• AADSTS700082 – The refresh token has expired due to inactivity: Refresh Token wurde durch Inaktivität, Token-Lifetime-Policy bzw. Session-Grenzen ungültig. Komponente: Refresh-Token-Store/Session Management.
• invalid_scope (OAuth-Standardfehler): Angeforderte scope-Kombination ist für den Client oder die Ressource unzulässig (z. B. fehlende Berechtigung, falsches Format, Mischen inkompatibler Ressourcen, nicht unterstützte OIDC-Scopes). Komponente: Scope-/Consent-Auflösung.

App-Registrierung, Berechtigungen und Consent: Ressourcenzugriff vs. Verzeichnisrechte

Fehler rund um App-Registrierungen entstehen häufig durch eine Vermischung von Delegated Permissions (Benutzerkontext) und Application Permissions (App-Kontext) sowie durch unterschiedliche Consent-Anforderungen. Auch die Unterscheidung zwischen Entra-ID-Verzeichnisrollen (z. B. zur Verwaltung von Objekten) und API-Berechtigungen (z. B. Microsoft Graph) ist relevant: Ein Token kann formal korrekt sein, aber an der Ressource wegen fehlender Berechtigungen oder fehlendem Admin-Consent scheitern.

• AADSTS65001 – The user or administrator has not consented to use the application: Für die angeforderte Ressource/Scopes liegt kein gültiger Consent vor oder Admin-Consent ist erforderlich. Komponente: Consent-Service und Berechtigungszuweisung in der App-Registrierung.
• AADSTS7000222 – The provided client secret keys are expired: Secret ist abgelaufen; besonders häufig bei CI/CD-Deployments ohne Secret-Rotation. Komponente: Credentials der App-Registrierung.
• AADSTS50194 – Application … is not configured as a multi-tenant application: Zugriff aus einem fremden Tenant auf eine Single-Tenant-App (oder falsche Authority). Komponente: Supported account types / Tenantgrenzen.
• AADSTS90094 – The grant requires admin permission: Der angeforderte Scope erfordert Administratorzustimmung (z. B. applicationweite Rechte oder besonders privilegierte Delegated Scopes). Komponente: Consent-Policy und Berechtigungsklassifizierung.

Verzeichnis- und Hybrid-Synchronisation: Entra Connect/Cloud Sync, Join- und Objektzustände

Hybridfehler entstehen selten „beim Login“, sondern vorher: Objekte existieren doppelt, sind falsch verknüpft (Immutable ID/Source Anchor), oder Attributregeln erzeugen unzulässige Werte. Entra ID behandelt synchronisierte Objekte als autoritativ aus der lokalen Quelle; Änderungen in der Cloud können dadurch blockiert werden. Zusätzlich beeinflussen Join-Zustände (Hybrid Azure AD join/Entra ID joined) und Gerätestatus den Zugriff, wenn Anwendungen oder Richtlinien Device Claims erwarten.

• Azure AD Connect: „Export Errors“ / „stopped-extension-dll-exception“: Fehler in einer MIM/AD-Connect-Erweiterung oder Regel; tritt in Synchronisationsläufen als Exportfehler auf und blockiert Objektupdates. Komponente: Synchronisationsengine (Connector/Extensions).
• Azure AD Connect: „duplicate attribute“ / „AttributeValueMustBeUnique“: Ein Attributwert (typisch userPrincipalName, proxyAddresses, mail) ist im Tenant bereits vergeben. Komponente: Directory-Constraint im Entra-ID-Verzeichnis.
• Azure AD Connect: „Object is already in use“ (Objektzuordnung/Hard Match): Source Anchor passt nicht zu einem bestehenden Cloudobjekt; harte Zuordnung scheitert, häufig nach Neuaufbau von Connect oder Re-Join von Domänen. Komponente: Objektidentität/Join zwischen Metaverse und Entra-ID-Objekt.
• Cloud Sync Provisioning: „Quarantine“ (Bereitstellungsquarantäne): Wiederholte Fehler (z. B. Namenskonflikte oder ungültige Attribute) führen zur Quarantäne einzelner Objekte. Komponente: Provisioning-Service und Fehlerunterdrückung/Backoff.

Rollen/RBAC und Verwaltungszugriff: Directory Roles, Azure RBAC und PIM-Grenzen

Rollenfehler betreffen entweder Entra-Verzeichnisrollen (Steuerung von Identitäts- und Verzeichnisobjekten) oder Azure RBAC (Steuerung von Azure-Ressourcen). Beide Modelle sind getrennt, können aber in Admin-Portalen gleichzeitig sichtbar werden. Ein häufiger Irrtum besteht darin, dass eine Azure-Rolle automatisch Verzeichnisrechte verleiht oder umgekehrt. Zusätzlich verändern PIM-Aktivierungen die effektiven Rechte zeitlich; daraus ergeben sich situative „Forbidden“-Zustände trotz scheinbar vorhandener Rolle.

• HTTP 403 / „Insufficient privileges to complete the operation“ (Microsoft Graph): Token enthält nicht die erforderlichen Graph-Berechtigungen oder der Benutzer besitzt keine passende Verzeichnisrolle; bei App-Kontext fehlen Application Permissions oder Admin-Consent. Komponente: Ressourcenautorisierung (Graph) und Rollen-/Berechtigungsmodell.
• „The role assignment already exists“ (RBAC): Eine identische Rollenzuweisung ist bereits vorhanden; häufig bei wiederholten IaC-Deployments ohne Idempotenzprüfung. Komponente: Azure RBAC Role Assignments.
• „PrincipalNotFound“ (RBAC): Das Zielobjekt (User/Group/Service Principal) ist im Scope nicht auflösbar, wurde gelöscht oder ist in Cross-Tenant-Szenarien nicht verfügbar. Komponente: RBAC-Resolver und Directory-Objektauflösung.
• „PIM activation required“ / fehlende aktive Rolle: Rolle ist nur „eligible“ und nicht aktiviert; Operationen scheitern bis zur Aktivierung samt ggf. genehmigungspflichtiger Workflows. Komponente: PIM und effektive Rollenberechnung.

Dienst- und tenantbezogene Statusmeldungen: Mandantenzustand, Lizenzen, Einschränkungen

Bestimmte Statusmeldungen sind keine Authentifizierungsfehler im engeren Sinn, sondern resultieren aus Tenantzuständen, Richtlinien auf Mandantenebene oder Dienstverfügbarkeit. Dazu zählen auch Lizenzgrenzen oder Admin-Vorgaben, die einzelne Features (z. B. bestimmte Authentifizierungsverfahren oder App-Typen) einschränken. Im Betrieb sind diese Meldungen relevant, weil sie sich in Clients als „Service nicht erreichbar“ oder „Zugriff verweigert“ äußern, obwohl Anmeldeinformationen korrekt sind.

• AADSTS90002 – Tenant … not found: Der Tenant ist nicht auflösbar (falscher Tenant-Name, falsche Domain, falsche Authority), oder der Request zielt auf einen nicht existierenden Mandanten. Komponente: Mandantenauflösung (Tenant Discovery).
• AADSTS90033 – A transient error has occurred. Please try again: Vorübergehender Dienstfehler (transient), häufig durch kurzzeitige Backendprobleme oder Rate-Limits in Vorstufen; wiederholtes Anfordern mit Backoff ist üblich. Komponente: Dienstverfügbarkeit/Throttling.
• AADSTS50158 – External security challenge was not satisfied: Der Zugriff scheitert an einer externen Sicherheitsbedingung, z. B. fehlgeschlagene Erfüllung eines behaupteten Gerätezustands oder einer externen Challenge/Signalprüfung. Komponente: Risikobewertung/External Claims bzw. Sicherheitsintegration.
• HTTP 429 / Too Many Requests (Graph/Management APIs): Throttling durch Dienstschutzmechanismen; Fehler erscheint als Betriebsstörung in Integrationen, obwohl Authentifizierung korrekt ist. Komponente: API-Gateway/Service Throttling; relevante Header: Retry-After.