Fehler AADSTS50034 beheben: Benutzer ist nicht vorhanden in Microsoft Azure AD

Von Mirko Peters · 2026-04-21

Fehler AADSTS50034 in Microsoft Azure AD bedeutet schlicht: „Benutzer ist nicht vorhanden.“ Wenn sich jemand bei Microsoft 365, Azure oder verwandten Cloud-Diensten anmeldet und diesen Code erhält, kann Azure Active Directory kein Konto finden, das zum eingegebenen Benutzernamen passt. Diese Meldung tritt häufig auf, besonders nachdem ein Benutzer das Unternehmen verlassen hat, sein Konto gelöscht

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Cover: Fix Azure Governance Before Your Next Cloud Audit

Die Behebung dieses Fehlers ist mehr als das Entfernen einer lästigen Meldung. Sie ist entscheidend für einen reibungslosen Cloud-Zugriff, die Produktivität der Benutzer und eine starke Sicherheit. AADSTS50034 kann verhindern, dass berechtigte Benutzer ihre Arbeit erledigen, und deutet auf tiefer liegende Probleme beim Lebenszyklus von Konten, bei der Verzeichniskonfiguration oder beim Mandantenzugriff hin. Dieser Leitfaden erläutert, warum dieser Fehler auftritt, wie er mit ähnlichen Problemen zusammenhängt und welche Schritte Sie unternehmen sollten, um ihn zu beheben oder – noch besser – künftige AADSTS-Probleme in Microsoft-Umgebungen zu verhindern.

AADSTS50034 und verwandte Azure-AD-Authentifizierungsfehler verstehen

AADSTS50034 steht im Zentrum der Benutzersuche in Azure Active Directory. Wenn die Meldung „Benutzer ist nicht vorhanden“ erscheint, hat Azure AD versucht, den Benutzernamen oder die Anmeldedaten mit dem Verzeichnis abzugleichen, und dabei keinen Treffer erzielt. Das kann bedeuten, dass der Benutzer nie existiert hat, gelöscht wurde oder im Vorfeld nie synchronisiert oder bereitgestellt wurde.

Authentifizierung in der Microsoft-Cloud ist jedoch selten einfach, und mehrere Fehlercodes können sich häufen und mehr Verwirrung als Klarheit stiften. Neben AADSTS50034 stoßen Administratoren oft auf weitere Anmeldefehler wie AADSTS50020 und AADSTS50126. Alle drehen sich um die Existenz und Identität von Benutzern, doch jeder hat eine eigene, subtile Bedeutung. Dadurch wird die Fehlersuche zu einem Krimi, bei dem jeder Fehler auf eine andere Wendung hinweist, sei es ein nicht passender Mandant, ein Kennwortproblem oder ein fehlendes Benutzerobjekt.

Diese Codes zu verstehen, ist für alle unverzichtbar, die Microsoft 365 oder Azure betreuen. Die Grenzen zwischen einem fehlenden Benutzer, einem ungültigen Kennwort und einem falschen Mandanten sind schmal. Wer die Unterschiede kennt, löst Probleme schneller und sicherer. Bevor Sie zu technischen Lösungen übergehen, sollten Sie das Gesamtbild im Blick behalten: wie Azure AD Identitäten prüft, Fehler interpretiert und diese Codes in den Zusammenhang sicherer und zuverlässiger Zugriffe einordnet. Schauen wir uns an, was AADSTS50034 verursacht und wie sich der Fehler von anderen gängigen Anmeldefehlern unterscheidet.

Ursachen für Fehler AADSTS50034 und wie Sie den Code AADSTS50034 in Microsoft Azure beheben

Fehler AADSTS50034 tritt auf, wenn Azure AD während der Anmeldung kein passendes Benutzerobjekt finden kann. Der Name ist ziemlich eindeutig: Existiert der Benutzer nicht im Verzeichnis, wird der Zugriff verweigert. Die Ursachen reichen allerdings von einfachen Dingen wie einem Tippfehler in einer E-Mail-Adresse bis hin zu versteckteren Problemen wie Löschvorgängen, fehlgeschlagenen Synchronisierungen oder Mandantenkonflikten.

Zu den häufigsten Auslösern gehören falsch geschriebene Benutzernamen, kürzlich gelöschte Benutzer, die sich dennoch anzumelden versuchen, oder Konten, die nie aus dem lokalen Active Directory synchronisiert wurden. Ein weiterer Auslöser ist der Versuch, auf den falschen Mandanten zuzugreifen, etwa wenn jemand Zugriff auf mehrere Organisationen hat oder seine Gasteinladung nie vollständig bereitgestellt wurde. Besonders verwirrend ist: Verzögerungen bei der Erstellung von B2B-Benutzern oder eine Abweichung zwischen E-Mail-Adresse und UPN bei der Föderation führen ebenfalls zu AADSTS50034.

Um diesen Fehler zu beheben, prüfen Sie zunächst den Benutzernamen auf Tippfehler. Stellen Sie im Azure-Portal unter „Benutzer“ im vorgesehenen Mandanten sicher, dass der Benutzer vorhanden ist. Wurde der Benutzer gelöscht, müssen Sie ihn gegebenenfalls wiederherstellen oder bei Gastzugriffen erneut einladen. In Hybridumgebungen prüfen Sie, ob das lokale Konto aktiv ist und erfolgreich mit Azure AD synchronisiert wird. Achten Sie schließlich darauf, dass die Anmeldung im richtigen Mandanten versucht wird und der Benutzertyp („Mitglied“ oder „Gast“) zur Rolle des Kontos passt. Wenn Sie diese zugrunde liegenden Probleme beseitigen, verschwindet AADSTS50034, und die Zuverlässigkeit der Identitäten in Ihrer Umgebung steigt insgesamt.

Azure-AD-Benutzerfehler im Vergleich: AADSTS50020 vs. AADSTS50126

Die Fehler AADSTS50020 und AADSTS50126 werden häufig mit AADSTS50034 verwechselt, bezeichnen aber leicht andere Anmeldeprobleme. AADSTS50020 bedeutet, dass der Benutzer zwar in Azure AD existiert, aber nicht im Mandanten, auf den er zugreifen will. Das passiert oft, wenn sich jemand mit den richtigen Anmeldedaten bei der falschen Organisation oder dem falschen Mandanten anmeldet.

AADSTS50126 dagegen weist auf falsche Anmeldedaten hin, etwa einen gültigen Benutzernamen mit dem falschen Kennwort. Während AADSTS50034 fragt: „Wer sind Sie?“, sagen die anderen Codes: „Nicht hier!“ (50020) oder „Das ist nicht Ihr Kennwort!“ (50126). Wer diese Unterschiede schnell erkennt, kann besser eingrenzen, ob der Fehler in den Anmeldedaten, im Mandanten oder in der Verzeichniskonfiguration liegt.

Fehlerbehebung bei Mandanten- und Verzeichnisproblemen für Zugriffsprobleme in Azure AD

Viele Zugriffsprobleme in Azure AD lassen sich auf die Mandantenauswahl, die Verzeichniskonfiguration oder die Durchsetzung von Richtlinien zurückführen. In Unternehmensumgebungen, besonders bei mehreren Azure-Mandanten oder B2B-Setups (Business-to-Business), stoßen Benutzer häufig auf Fehler, weil sie schlicht am falschen Ort zur falschen Zeit sind. Es kommt nicht selten vor, dass sich ein Benutzer versehentlich bei einem anderen Mandanten anmeldet oder dass eine Richtlinie eine eigentlich gültige Anmeldung blockiert.

Die Mandanten- und Verzeichnisstruktur von Azure AD wirkt als Sicherheitsgrenze. Benutzerzugriff, App-Registrierung und Berechtigungen für Ressourcen sind alle an den Kontext des aktuellen Mandanten gebunden. Versucht ein Benutzer oder Gast, sich aus dem falschen Kontext heraus anzumelden, ist das System nicht einfach nur launisch. Es kann ihn schlicht nicht finden und nicht autorisieren. Das führt zu Fehlern wie AADSTS50034, AADSTS50105 oder AADSTS53003.

Bei der Fehlersuche sollten Sie deshalb genau darauf achten, wie Benutzer zwischen Mandanten weitergeleitet werden, ob es sich um Mitglieder oder Gäste handelt und ob eine Abweichung im Verzeichnis vorliegt. In Organisationen mit komplexem bedingtem Zugriff oder streng abgesicherten Mandanten können Administratorrichtlinien den Zugriff auch dann verweigern, wenn alles korrekt eingerichtet scheint. Wie Governance und Richtlinien den Zugriff prägen, erklärt dieser Beitrag zur Azure-Unternehmens-Governance. Bevor Sie sich mit der Frage „Warum wird dieser Benutzer nicht gefunden?“ befassen, die sich immer wieder stellt, sollten Sie die Grenzen von Verzeichnis und Mandant verstanden haben.

So beheben Sie es: Zugriff auf den richtigen Mandanten in Azure AD prüfen

Mandantenkontext prüfen: Überprüfen Sie immer den Mandanten, der im Azure- oder Microsoft 365-Portal angezeigt wird. Der Anzeigename oben rechts zeigt Ihre aktive Organisation an.
Verzeichnis wechseln: Wenn Sie mehreren Mandanten angehören, wechseln Sie über die Verzeichnisauswahl des Portals zur gewünschten Organisation, bevor Sie die Anmeldung erneut versuchen.
Gast- bzw. Mitgliedsstatus prüfen: Stellen Sie sicher, ob Sie in der Organisation, auf die Sie zugreifen, als Mitglied oder als Gast geführt werden. Falsche Rollen blockieren den Zugriff häufig.
Einladungen prüfen: Bei Gastbenutzern sollten Sie sicherstellen, dass die Einladung angenommen wurde und das Gastkonto im richtigen Azure AD-Verzeichnis bereitgestellt ist.

Fehler AADSTS50105 und AADSTS53003 beheben: Verzeichniszugriff blockiert oder verweigert

Richtlinie oder blockierter Zugriff (AADSTS50105): Administratoren haben unter Umständen Zugriffsrichtlinien, Gruppen oder Einschränkungen festgelegt, die bestimmten Benutzern den Zugriff auf Ressourcen verwehren. Prüfen Sie im Admin Center die Gruppenzuweisungen und die Berechtigung der Rollen.
Bedingter Zugriff oder Einschränkungen für externe Benutzer (AADSTS53003): Die Anmeldung kann blockiert werden, wenn Richtlinien zu Gerätekonformität, Standort oder Risiko greifen. Prüfen Sie alle Richtlinien für bedingten Zugriff in Microsoft Entra ID und stellen Sie sicher, dass die Geräteregistrierung und die Sicherheitsanforderungen erfüllt sind.
Ablauf von Gastzugängen oder Zugriffsüberprüfung: Gäste oder externe Benutzer können ihren Zugriff nach Zugriffsüberprüfungen oder automatischem Ablauf verlieren. Führen Sie regelmäßige Audits der Gastkonten und Überprüfungen des Lebenszyklus durch, um unerwartete Zugriffsverweigerungen zu verwalten und zu minimieren.
Eingreifen des Administrators: Wenn Sie eine umfassendere Sperre vermuten, wenden Sie sich an Ihren Administrator, damit dieser Einschränkungen aufhebt oder den Zugriff neu bereitstellt. Halten Sie sich dabei an die bewährten Methoden aus dem Leitfaden zur Governance des Gastkonten-Lebenszyklus.

Synchronisierung von lokalem AD und Überprüfung der Kontotypen zur Vermeidung von AADSTS50034

Organisationen mit hybrider Identitätsinfrastruktur tappen wegen Problemen bei der Synchronisierung und der Klassifizierung von Konten häufig in die Falle AADSTS50034. Wenn Ihr lokales Active Directory mit Azure AD verbunden ist, können Fehler bei der Synchronisierung von Benutzerkonten dazu führen, dass Personen ausgesperrt werden, obwohl ihr Konto lokal scheinbar existiert.

Eine wesentliche Ursache ist, dass Benutzer nicht richtig zwischen dem lokalen AD und Azure AD synchronisiert werden. Vielleicht ist der Synchronisierungsprozess fehlgeschlagen, das Benutzerobjekt wurde deaktiviert, oder Änderungen wurden noch nicht in die Cloud repliziert. Diese Probleme fallen oft erst auf, wenn sich ein Benutzer anmeldet und die Meldung „Benutzer nicht vorhanden“ erhält.

Schwieriger wird es, wenn Benutzer falsch klassifiziert sind, etwa als „Gast“, obwohl sie „Mitglied“ sein sollten, oder umgekehrt. Microsoft Entra ID (früher Azure AD) prüft diesen Status während der Authentifizierung. Ist ein externer Gast falsch konfiguriert oder wird ein synchronisierter Mitgliedsbenutzer als Gast markiert, kann Azure AD nicht finden, wonach es suchen soll, und Sie erhalten AADSTS50034. Diese Zusammenhänge sind für Administratoren in hybriden, Multi-Cloud- oder gastlastigen Umgebungen essenziell. Schauen wir uns nun praktische Wege an, um eine korrekte Synchronisierung und die richtigen Kontotypen im Cloud-Verzeichnis von Microsoft sicherzustellen.

Lokales AD mit Azure AD synchronisieren, um Verzeichnissynchronisierungsprobleme zu vermeiden

Synchronisierungsstatus prüfen: Sehen Sie sich im Azure AD Connect-Dashboard die letzte Synchronisierungszeit und etwaige Fehlermeldungen an. Beheben Sie Fehler, bevor Sie fortfahren.
Benutzer in der Cloud prüfen: Verwenden Sie das Azure AD-Portal, um zu bestätigen, dass der Benutzer vorhanden ist und seine Daten mit dem lokalen Verzeichnis übereinstimmen.
Synchronisierungsfehler beheben: Lösen Sie häufige Probleme wie doppelte Proxy-Adressen, Konflikte bei Benutzerobjekten oder fehlerhaft konfigurierte Attribute, die die Verzeichnissynchronisierung blockieren.
Manuelle Synchronisierung auslösen: Wurde ein Benutzer gerade erstellt oder geändert, starten Sie eine manuelle Synchronisierung, um eine Aktualisierung zwischen lokalem Verzeichnis und Cloud zu erzwingen.

Kontotyp prüfen und Fehler AADSTS50034 für Mitglieder und Gäste beheben

Benutzertyp prüfen: Sehen Sie in Microsoft Entra ID nach, ob der Benutzer als „Mitglied“ oder „Gast“ geführt wird. Ein falscher Typ blockiert die Anmeldung an Ressourcen des Mandanten.
Falsche Klassifizierungen korrigieren: Wandeln Sie fälschlich registrierte Gäste in Mitglieder um (oder umgekehrt) – über die Benutzerverwaltung in Azure AD.
UPNs und E-Mail-Adressen validieren: Stellen Sie sicher, dass der User Principal Name zum vorgesehenen Konto passt und keine abweichenden E-Mail-Aliase Konflikte verursachen.
Externe Identitäten prüfen: Kontrollieren Sie bei B2B- und hybriden Benutzern, dass Einladungen und Organisationsbeziehungen korrekt eingerichtet und aktiv sind.

Wenn Dienst- und App-Authentifizierung AADSTS-Fehler in Microsoft 365 auslösen

AADSTS-Fehler treten nicht nur bei regulären Benutzeranmeldungen auf, sondern auch dann, wenn sich Apps und Dienste mit Microsoft 365 verbinden. Manchmal ist der Dienst selbst das Problem: App-Registrierungen funktionieren fehlerhaft, Clientgeheimnisse laufen ab oder die Registrierung wurde gelöscht. Exchange Online, SharePoint und Hunderte Drittanbieter-Integrationen hängen von der korrekten Konfiguration in Azure AD ab, daher kann selbst eine kleine Änderung alles blockieren.

Die Anwendungsregistrierung muss mit den Authentifizierungseinstellungen des Clients übereinstimmen. Jede Abweichung, etwa ein fehlendes oder widerrufenes Geheimnis, eine falsche App-ID, eine deaktivierte App oder ein nicht passender Redirect-URI, kann Fehler wie AADSTS700016 („App nicht gefunden“) oder AADSTS7000218 („ungültiges Clientgeheimnis“) auslösen. Diese Probleme bringen IT-Administratoren vor allem bei Mandantenmigrationen, bei PowerShell-Automatisierung oder beim schnellen Bereitstellen neuer Apps aus dem Takt.

Hinzu kommt, dass strenge Richtlinien für bedingten Zugriff und restriktive Mandanteneinschränkungen Apps blockieren können, selbst wenn die Authentifizierungsdaten korrekt erscheinen. Um Unterbrechungen im Geschäftsbetrieb zu vermeiden, müssen Sie diese Fehler richtig deuten und die Ursache verfolgen, sei es eine App-Einstellung, eine Zustimmung oder eine OAuth-Lücke. Falls Sie sich Sorgen über OAuth-Zustimmung oder App-basierte Sicherheitslücken machen, lesen Sie, wie Sie Zustimmungsangriffe auf Entra ID OAuth consent verhindern.

Fehler AADSTS700016 und AADSTS7000218 beheben: Anwendung nicht gefunden oder ungültiger Client

App-Registrierung prüfen: Stellen Sie sicher, dass die Anwendung im Azure AD-Mandanten registriert ist. Vergleichen Sie die Client-IDs bzw. App-IDs in den Authentifizierungsanfragen mit den registrierten Werten.
Clientgeheimnis oder Zertifikat überprüfen: Bei vertraulichen Clients muss das Geheimnis bzw. das Zertifikat gültig und aktiv sein und zu den Einstellungen der App-Registrierung passen.
Redirect-URIs validieren: Die Antwort muss einen Redirect-URI verwenden, der in der App-Registrierung aufgeführt ist. Jede Abweichung führt zum Fehlschlagen der Anmeldung.
Mandant und Berechtigungen prüfen: Die Apps müssen im richtigen Mandanten aktiviert sein, und die delegierten oder App-only-Berechtigungen müssen zum Anwendungsfall passen.

AADSTS90002 und AADSTS900144 in Microsoft 365-Diensten beheben

Mandant nicht gefunden (AADSTS90002): Das bedeutet meist, dass der Zielmandant nicht existiert oder gelöscht wurde. Prüfen Sie den Domänennamen in Ihrer Anmeldung oder Ihrem Verbindungszeichenfolge der App noch einmal und stellen Sie sicher, dass der Mandant aktiv ist.
Richtlinien- oder Verzeichnisverstoß (AADSTS900144): Bedingter Zugriff oder mandantenweite Richtlinien erzwingen möglicherweise strengere Kontrollen. Überprüfen und passen Sie die Richtlinien an, wobei Sie eine umfassende Abdeckung priorisieren und Ad-hoc-Ausnahmen für mehr Zuverlässigkeit möglichst minimieren. Weitere Informationen zu einem optimalen Richtliniendesign finden Sie in diesem Leitfaden zu Best Practices für bedingten Zugriff.
Probleme bei delegiertem Zugriff: Abgelaufene OAuth-Zustimmungen oder fehlende Berechtigungen in App-Registrierungen können den Anmeldevorgang blockieren. Überprüfen Sie daher regelmäßig die erteilten Zustimmungen und deren Ablaufdaten.
Löschen von Dienst oder Benutzer: Stellen Sie sicher, dass der erforderliche Dienstprinzipal und der Benutzer im richtigen Mandanten vorhanden sind. Wurden sie kürzlich gelöscht, stellen Sie sie wieder her oder registrieren Sie sie bei Bedarf neu.

Anforderungen an die Multi-Faktor-Authentifizierung und Richtlinien für bedingten Zugriff

Auch wenn Benutzer das richtige Konto und die richtigen Anmeldedaten haben, kann Azure AD den Zugriff blockieren, wenn Sicherheitsrichtlinien nicht erfüllt sind. Die Multi-Faktor-Authentifizierung (MFA) und Anforderungen an die Gerätekonformität spielen dabei eine große Rolle. Organisationen nutzen sie, um Risiken zu reduzieren, indem sie vor Abschluss einer Anmeldung eine zusätzliche Überprüfung oder eine Prüfung des Gerätezustands verlangen.

Fehler wie AADSTS50076 und AADSTS50079 treten auf, wenn Benutzer die MFA umgehen oder sich von einem nicht verwalteten oder nicht konformen Gerät aus anmelden möchten. Diese Fehler können Benutzer überraschen, besonders wenn Richtlinien kürzlich geändert wurden oder sie zum ersten Mal ein neues Gerät verwenden. Oft wird erst dann deutlich, dass eine neue Bedingung erzwungen wird, wenn Azure AD die Verbindung vollständig ablehnt.

Für Administratoren ist die Konfiguration und Pflege eines wirksamen bedingten Zugriffs ein fortlaufender Kreislauf und keine Aufgabe, die man einmal einrichtet und dann vergisst. Abweichungen entstehen von selbst: Benutzer finden Umgehungswege, Richtlinien werden angepasst, Geräte werden ersetzt. Wenn Sie sich eingehend mit skalierbarer, durchsetzbarer Identitätssicherheit befassen möchten, zeigt dieser Podcast zur Governance des bedingten Zugriffs, wie Sie Kontrollen wirksam halten und zugleich Reibungsverluste minimieren. Im Anschluss folgen die praktischen Schritte zur Fehlerbehebung bei häufigen Anmeldeblockaden durch MFA und Gerätekonformität.

AADSTS50076 und AADSTS50079 beheben: MFA und Gerätekonformität erforderlich

MFA einrichten: Falls Sie dazu aufgefordert werden, stellen Sie sicher, dass die MFA aktiviert und konfiguriert ist. Je nach Einrichtung Ihrer Organisation verwenden Sie die mobile App, einen Anruf oder SMS.
Geräte registrieren: Für die Gerätekonformität muss Ihr Gerät in der Geräteverwaltungslösung Ihrer Organisation registriert sein, etwa Intune oder Endpoint Manager.
Richtlinien prüfen: Überprüfen Sie die Zuweisung und den Geltungsbereich der Richtlinien für bedingten Zugriff. Passen Sie diese an, wenn berechtigte Benutzer durch zu restriktive Regeln blockiert werden.
Administrator kontaktieren: Wenn die Einrichtung korrekt ist, die Fehler aber weiterhin auftreten, bitten Sie Ihren Administrator, die Gerät- oder Sitzungskonformität zu prüfen und die Richtlinienprotokolle auf kürzliche Änderungen zu untersuchen.

Expertentipps: Fehler „Benutzer existiert nicht“ in Microsoft Entra B2B-Szenarien vermeiden

Den Fehler „Benutzer existiert nicht“ zu beheben ist das eine, ihn zu verhindern ist ein ganz anderes Kaliber, besonders in Microsoft Entra B2B- und mandantenübergreifenden Szenarien. Je stärker Organisationen unternehmensübergreifend zusammenarbeiten, desto häufiger tritt AADSTS50034 auf, etwa durch verzögerte Benutzerbereitstellung, verwaiste Gastkonten und nicht abgestimmte Benutzereigenschaften. Der Prozess zur Erstellung von Gastbenutzern, zum Entfernen von Konten und zur Synchronisierung hybrider Identitäten verläuft nicht immer sofort oder vollkommen zuverlässig.

Das Lebenszyklusmanagement ist entscheidend. Verzögerte Einladungen, fehlgeschlagene externe Synchronisierungen und nicht übereinstimmende E-Mail-Aliase können bei Gastbenutzern AADSTS50034 auslösen, selbst wenn der Onboarding-Prozess abgeschlossen zu sein scheint. Konten, die aufgrund von Inaktivität, Compliance-Vorgaben oder manueller Bereinigung durch Administratoren gelöscht wurden, verbleiben unter Umständen im Status „vorläufig gelöscht“ und verursachen bei der Anmeldung oder bei Mandantenmigrationen Probleme. Wenn Sie diese Fallstricke vermeiden möchten, sind regelmäßige Zugriffsüberprüfungen und strukturierte Lebenszyklusregeln unverzichtbar, wie in diesem ausführlichen Leitfaden zur Gastverwaltung beschrieben.

Administratoren, die Apps oder Dienste mit Dienstprinzipal-Authentifizierung verschieben, haben oft ihre eigenen Probleme: Fehlender Benutzerkontext oder falsch konfigurierte Berechtigungen lösen AADSTS50034 aus. Tatsächlich liegt die Ursache selten an einem fehlenden Benutzer. Wenn Sie B2B-Bereitstellung, die Zuordnung von E-Mail-Adresse und UPN sowie die Einstellungen für die App-Migration proaktiv konfigurieren, erhält Ihr Verzeichnis die Stabilität, die klientenübergreifende Projekte und komplexe Automatisierungsabläufe benötigen. Im Folgenden zeigen wir, wie Sie diese hartnäckigen AADSTS50034-Szenarien überwachen, diagnostizieren und verhindern.

Bereitstellung von Gastbenutzern, Kontolöschung und UPN-Abweichungen, die zu AADSTS50034 führen

Verzögerungen bei der Bereitstellung: Nachdem ein Gast eine Einladung angenommen hat, kann es eine Weile dauern, bis das Konto vollständig in Azure AD erscheint. Überwachen Sie die Anmeldeprotokolle und prüfen Sie die Zeitabläufe der Kontoerstellung, bevor Sie weitere Fehlerbehebungen durchführen.
Automatische oder manuelle Löschung: Gäste und externe Benutzer können aufgrund von Inaktivität automatisch gelöscht oder von Administratoren manuell entfernt werden. Vorläufig gelöschte Konten können sich nicht authentifizieren und lösen AADSTS50034 aus. Überprüfen Sie Lebenszyklusrichtlinien regelmäßig, wie in diesem Leitfaden zur Lebenszyklusverwaltung beschrieben.
E-Mail-/UPN-Abweichung: Benutzer, die sich mit E-Mail-Aliassen oder abweichenden Benutzerprinzipalnamen anmelden, werden unter Umständen von Azure AD nicht gefunden. Stellen Sie sicher, dass UPN und primäre E-Mail-Adresse mit den Einträgen im Verzeichnis übereinstimmen, um das Problem zu beheben.
Konflikte bei der SMTP-Zuordnung: Doppelte E-Mail-Adressen über Mandanten hinweg führen zu Fehlern bei der Identitätsauflösung. Verwenden Sie explizite Einladungen und stellen Sie sicher, dass E-Mail-Adressen innerhalb jedes Mandanten eindeutig sind, um Suchfehler zu vermeiden.

Dienstprinzipal und App-only-Authentifizierung: Irreführende AADSTS50034-Fehler bei Migrationen vermeiden

Kontext der App-only-Authentifizierung: Migrationstools oder Automatisierungsskripte, die Dienstprinzipale verwenden, können AADSTS50034 erhalten, wenn die App-Berechtigungen falsch konfiguriert sind oder das Skript auf ein fehlendes Benutzerobjekt verweist, obwohl bei der Authentifizierung kein Benutzer beteiligt ist. Überprüfen Sie Rollen und App-Bereiche immer im Portal, bevor Sie Migrationen ausführen.
Delegierte Bereiche und abgelaufene Zustimmung: Wenn delegierte Berechtigungen erforderlich sind, die Zustimmung jedoch abgelaufen oder nicht erteilt ist, können Tools AADSTS50034 falsch melden. Erteilen Sie die Zustimmung erneut oder überprüfen Sie sie, insbesondere nach Mandantenmigrationen oder erneuten App-Genehmigungszyklen.
Genauigkeit von UPN und Objekt-ID: Verwenden Sie beim Scripting die korrekte, aktuelle UPN und Objekt-ID, die dem aktiven Benutzer bzw. Dienstprinzipal im Mandanten entsprechen, um Verweisfehler zu vermeiden.
Fehlerdiagnose: Suchen Sie nicht nur nach einem fehlenden Benutzer. Prüfen Sie die Protokolle von Graph API oder PowerShell auf Berechtigungs- und Objektverweisfehler, um die eigentliche Ursache von Authentifizierungsfehlern zu finden.