Freigeben über

Fehler AADSTS50020 : Das Benutzerkonto des Identitätsanbieters ist im Mandanten nicht vorhanden.

Dieser Artikel hilft Ihnen bei der Problembehandlung von Fehlercode AADSTS50020 , der zurückgegeben wird, wenn sich ein Gastbenutzer von einem Identitätsanbieter (IdP) nicht bei einem Ressourcenmandanten in microsoft Entra ID anmelden kann.

Symptome

Wenn ein Gastbenutzer versucht, auf eine Anwendung oder Ressource im Ressourcenmandanten zuzugreifen, schlägt die Anmeldung fehl, und die folgende Fehlermeldung wird angezeigt:

AADSTS50020: Das Benutzerkonto 'user@domain.com' vom Identitätsanbieter '{IdentityProviderURL}' ist im Mandanten '{ResourceTenantName}' nicht vorhanden.

Wenn ein Administrator die Anmeldung beim Heimmandanten überprüft, gibt ein Fehlercodeeintrag "90072" einen Anmeldefehler an. Die Fehlermeldung gibt folgendes an:

Das Benutzerkonto "{email}" vom Identitätsanbieter "{idp}" ist im Mandanten "{tenant}" nicht vorhanden und kann nicht auf die Anwendung {appId}({appName}) in diesem Mandanten zugreifen. Das Konto muss zuerst als externer Benutzer im Tenant hinzugefügt werden. Melden Sie sich ab und anschließend mit einem anderen Microsoft Entra-Benutzerkonto erneut an.

Ursache: Benutzer melden sich mit persönlichen Microsoft-Konten beim Microsoft Entra Admin Center an

Wenn Sie versuchen, sich mit Ihren persönlichen Microsoft-Konten (Outlook, Hotmail oder OneDrive) beim Microsoft Entra Admin Center anzumelden, sind Sie standardmäßig mit dem Microsoft Services-Mandanten verbunden. Innerhalb des Standardmandanten gibt es kein verknüpftes Verzeichnis, um Aktionen auszuführen. Dies ist das erwartete Verhalten.

In der vorherigen Erfahrung wird ein Verzeichnis (z. B. UserNamehotmail735.onmicrosoft.com) erstellt und mit dem persönliches Konto verknüpft, und Sie können Aktionen wie das Erstellen von Benutzerkonten im Verzeichnis ausführen. Das Verhalten wurde nun geändert.

Lösung: Erstellen eines Azure-Kontos mit einem neuen Mandanten

Wenn Sie über ein Verzeichnis verfügen möchten, müssen Sie ein Azure-Konto und einen neuen Mandanten erstellen:

  1. Navigieren Sie zu https://azure.microsoft.com/en-us/free/, und wählen Sie dann "Kostenlos starten" aus.
  2. Befolgen Sie die Anweisungen zum Erstellen eines Azure-Kontos.
  3. Ein Mandant wird zusammen mit dem Azure-Konto generiert, und Sie werden automatisch als globaler Administrator festgelegt. Dadurch erhalten Sie vollen Zugriff auf alle Optionen in diesem Mandanten.

Ursache 2: Verwendung eines nicht unterstützten Kontotyps (mandantenfähige und persönliche Konten)

Wenn die App-Registrierung auf einen Single-Tenant-Kontotyp festgelegt ist, können sich Benutzer aus anderen Verzeichnissen oder Identity-Anbietern nicht bei dieser Anwendung anmelden.

Lösung: Ändern der Anmeldegruppeneinstellung im App-Registrierungsmanifest

Führen Sie die folgenden Schritte aus, um sicherzustellen, dass die App-Registrierung kein Einzelmandantenkontotyp ist:

  1. Suchen und wählen Sie im Azure-PortalApp-Registrierungen aus.

  2. Wählen Sie den Namen Ihrer App-Registrierung aus.

  3. Wählen Sie in der Randleiste "Manifest" aus.

  4. Suchen Sie im JSON-Code die Einstellung "signInAudience" .

  5. Überprüfen Sie, ob die Einstellung einen der folgenden Werte enthält:

    • Azure AD und persönliches Microsoft-Konto
    • AzureADMultipleOrgs
    • PersönlichesMicrosoftKonto

    Wenn die Einstellung "signInAudience " keinen dieser Werte enthält, erstellen Sie die App-Registrierung erneut, indem Sie den richtigen Kontotyp ausgewählt haben. Sie können signInAudience derzeit im Manifest nicht ändern.

Weitere Informationen zum Registrieren von Anwendungen finden Sie in der Schnellstartanleitung: Registrieren einer Anwendung bei der Microsoft Identity Platform.

Ursache 3: Verwenden des falschen Endpunkts (persönliche und Organisationskonten)

Ihr Authentifizierungsaufruf muss auf eine URL abzielen, die Ihrer Auswahl entspricht, wenn der unterstützte Kontotyp Ihrer App-Registrierung auf einen der folgenden Werte festgelegt wurde:

  • Konten in einem beliebigen Organisationsverzeichnis (jedes Microsoft Entra-Verzeichnis – Multitenant)

  • Konten in jedem Organisationsverzeichnis (beliebiges Microsoft Entra-Verzeichnis – Multitenant) und persönliche Microsoft-Konten (z. B. Skype, Xbox)

  • Nur persönliche Microsoft-Konten

Wenn Sie verwenden https://login.microsoftonline.com/<YourTenantNameOrID>, können Benutzer aus anderen Organisationen nicht auf die Anwendung zugreifen. Sie müssen diese Benutzer als Gäste im Mandanten hinzufügen, der in der Anforderung angegeben ist. In diesem Fall wird erwartet, dass die Authentifizierung nur auf Ihrem Mandanten ausgeführt wird. In diesem Szenario tritt der Anmeldefehler auf, wenn Sie erwarten, dass sich Benutzer mithilfe des Partnerverbunds mit einem anderen Mandanten- oder Identitätsanbieter anmelden.

Lösung: Verwenden der richtigen Anmelde-URL

Verwenden Sie die entsprechende Anmelde-URL für den jeweiligen Anwendungstyp, wie in der folgenden Tabelle aufgeführt:

Anwendungstyp Anmelde-URL
Mehrinstanzenfähige Anwendungen https://login.microsoftonline.com/organizations
Mehrinstanzen und persönliches Konto https://login.microsoftonline.com/common
Nur persönliche Konten https://login.microsoftonline.com/consumers

Wenden Sie in Ihrem Anwendungscode diesen URL-Wert in der Authority Einstellung an. Weitere Informationen Authorityfinden Sie unter Microsoft Identity Platform-Anwendungskonfigurationsoptionen.

Ursache 4: Beim falschen Mandanten angemeldet

Wenn Benutzer versuchen, auf Ihre Anwendung zuzugreifen, wird entweder ein direkter Link zur Anwendung gesendet, oder sie versuchen, Zugriff über https://myapps.microsoft.comdie Anwendung zu erhalten. In beiden Situationen werden Benutzer umgeleitet, um sich bei der Anwendung anzumelden. In einigen Fällen verfügt der Benutzer möglicherweise bereits über eine aktive Sitzung, die eine andere persönliches Konto verwendet als die, die verwendet werden soll. Oder sie haben eine Sitzung, die ihr Organisationskonto verwendet, obwohl sie ein persönliches Gastkonto verwenden möchten (oder umgekehrt).

Um sicherzustellen, dass dieses Szenario das Problem ist, suchen Sie in der Fehlermeldung nach den User account- und Identity provider-Werten. Stimmen diese Werte mit der erwarteten Kombination überein oder nicht? Hat sich beispielsweise ein Benutzer mit dem Organisationskonto bei Ihrem Mandanten anstelle seines eigenen Mandanten angemeldet? Oder hat sich ein Benutzer bei dem live.com Identitätsanbieter angemeldet, indem er ein anderes persönliches Konto verwendet als dasjenige, das bereits eingeladen wurde?

Lösung: Melden Sie sich ab, und melden Sie sich dann erneut von einem anderen Browser oder einer privaten Browsersitzung an.

Weisen Sie den Benutzer an, eine neue InPrivate-Browsersitzung zu öffnen, oder lassen Sie den Benutzer versuchen, von einem anderen Browser darauf zuzugreifen. In diesem Fall müssen sich Benutzer von ihrer aktiven Sitzung abmelden und dann erneut versuchen, sich anzumelden.

Ursache 5: Gastbenutzer wurde nicht eingeladen

Der Gastbenutzer, der versuchte, sich anzumelden, wurde nicht zum Mandanten eingeladen.

Lösung: Einladen des Gastbenutzers

Stellen Sie sicher, dass Sie die Schritte in der Schnellstartanleitung ausführen: Hinzufügen von Gastbenutzern zu Ihrem Verzeichnis im Azure-Portal, um den Gastbenutzer einzuladen.

Ursache 6: Für die App ist eine Benutzerzuweisung erforderlich

Wenn Es sich bei Ihrer Anwendung um eine Unternehmensanwendung handelt, die eine Benutzerzuweisung erfordert, tritt ein Fehler AADSTS50020 auf, wenn der Benutzer nicht in der Liste der zulässigen Benutzer steht, denen der Zugriff auf die Anwendung zugewiesen ist. So überprüfen Sie, ob Für Ihre Unternehmensanwendung eine Benutzerzuweisung erforderlich ist:

  1. Suchen Sie im Azure-Portal nach Unternehmensanwendungen, und wählen Sie sie aus.

  2. Wählen Sie Ihre Unternehmensanwendung aus.

  3. Wählen Sie in der Randleiste "Eigenschaften" aus.

  4. Überprüfen Sie, ob die option "Zuordnung erforderlich " auf "Ja" festgelegt ist.

Lösung: Zuweisen des Zugriffs auf Benutzer einzeln oder als Teil einer Gruppe

Verwenden Sie eine der folgenden Optionen, um Benutzern Zugriff zuzuweisen:

Ursache 7: Versuch, den Anmeldefluss für das Passwort eines Ressourceninhabers für persönliche Konten zu verwenden

Wenn ein Benutzer versucht, den ROPC-Fluss (Resource Owner Password Credentials) für persönliche Konten zu verwenden, tritt der Fehler AADSTS50020 auf. Die Microsoft Identity Platform unterstützt ROPC nur innerhalb der Microsoft Entra-Mandanten, nicht bei persönlichen Konten.

Lösung: Verwenden eines Endpunkts, der für den Mandanten oder die Organisation spezifisch ist

Verwenden Sie einen mandantenspezifischen Endpunkt (https://login.microsoftonline.com/<TenantIDOrName>) oder den Endpunkt der Organisation. Persönliche Konten, die zu einem Microsoft Entra-Mandanten eingeladen werden, können ROPC nicht verwenden. Weitere Informationen finden Sie unter Microsoft Identity Platform und OAuth 2.0-Kennwortanmeldeinformationen des Ressourcenbesitzers.

Ursache 8: Ein zuvor gelöschter Benutzername wurde vom Heimmandantenadministrator neu erstellt.

Fehler AADSTS50020 können auftreten, wenn der Name eines Gastbenutzers, der in einem Ressourcenmandanten gelöscht wurde, vom Administrator des Heimmandanten neu erstellt wird. Verwenden Sie eine der folgenden Optionen, um zu überprüfen, ob das Gastbenutzerkonto im Ressourcenmandanten nicht einem Benutzerkonto im Heimmandanten zugeordnet ist:

Überprüfung: Überprüfen Sie, ob der Gastbenutzer des Ressourcenmandanten älter als das Benutzerkonto des Heimmandanten ist.

Um das Erstellungsdatum des Gastbenutzerkontos zu überprüfen, können Sie Microsoft Graph, Microsoft Entra PowerShell oder das Microsoft Graph PowerShell SDK verwenden.

Microsoft Graph

Stellen Sie eine Anforderung an die MS Graph-API aus, um das Erstellungsdatum des Benutzers wie folgt zu überprüfen:

GET https://graph.microsoft.com/v1.0/users/{id | userPrincipalName}/createdDateTime

Überprüfen Sie dann das Erstellungsdatum des Gastbenutzers im Ressourcenmandanten anhand des Erstellungsdatums des Benutzerkontos im Heimmandanten. Das Szenario wird bestätigt, wenn der Gastbenutzer erstellt wurde, bevor das Benutzerkonto des Heimmandanten erstellt wurde.

Microsoft Entra PowerShell

Führen Sie das PowerShell-Cmdlet Get-EntraUser aus, um das Erstellungsdatum des Benutzers wie folgt zu überprüfen:

Get-EntraUser -UserId {id | userPrincipalName} | Select-Object id, userPrincipalName, createdDateTime

Überprüfen Sie dann das Erstellungsdatum des Gastbenutzers im Ressourcenmandanten anhand des Erstellungsdatums des Benutzerkontos im Heimmandanten. Das Szenario wird bestätigt, wenn der Gastbenutzer erstellt wurde, bevor das Benutzerkonto des Heimmandanten erstellt wurde.

Microsoft Graph PowerShell SDK

Führen Sie das PowerShell-Cmdlet Get-MgUser aus, um das Erstellungsdatum des Benutzers wie folgt zu überprüfen:

$p = @('Id', 'UserPrincipalName', 'CreatedDateTime')
Get-MgUser -UserId {id | userPrincipalName} -Property $p| Select-Object $p

Überprüfen Sie dann das Erstellungsdatum des Gastbenutzers im Ressourcenmandanten anhand des Erstellungsdatums des Benutzerkontos im Heimmandanten. Das Szenario wird bestätigt, wenn der Gastbenutzer erstellt wurde, bevor das Benutzerkonto des Heimmandanten erstellt wurde.

Lösung: Zurücksetzen des Einlösungsstatus des Gastbenutzerkontos

Setzen Sie den Einlösungsstatus des Gastbenutzerkontos im Ressourcenmandanten zurück. Anschließend können Sie das Gastbenutzerobjekt beibehalten, ohne das Gastkonto löschen und dann erneut erstellen zu müssen. Sie können den Einlösungsstatus mithilfe der Azure-Portal, Azure PowerShell oder der Microsoft Graph-API zurücksetzen. Anweisungen finden Sie unter Zurücksetzen des Einlösungsstatus für einen Gastbenutzer.

Kontaktieren Sie uns für Hilfe

Wenn Sie Fragen haben oder Hilfe benötigen, dann erstellen Sie eine Supportanfrage oder fragen Sie den Azure Community-Support. Sie können auch Produktfeedback an die Azure Feedback Community senden.