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

  • Artikel

Dieser Artikel hilft Ihnen bei der Problembehandlung von FehlercodeAADSTS50020, der zurückgegeben wird, wenn sich ein Gastbenutzer eines Identitätsanbieters (IdP) nicht bei einem Ressourcenmandanten in Microsoft Entra ID anmelden kann.

Problembeschreibung

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" des Identitätsanbieters {IdentityProviderURL} ist im Mandanten {ResourceTenantName} nicht vorhanden.

Wenn ein Administrator die Anmeldeprotokolle auf dem Basismandanten überprüft, weist der Fehlercodeeintrag "90072" auf einen Anmeldefehler hin. Die Fehlermeldung gibt folgendes an:

Das Benutzerkonto {email} des Identitätsanbieters {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 Mandanten hinzugefügt werden. Melden Sie sich ab, und melden Sie sich erneut mit einem anderen Microsoft Entra Benutzerkonto an.

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

Wenn Sie versuchen, sich mit Ihren persönlichen Microsoft-Konten (Outlook, Hotmail oder OneDrive) bei Microsoft Entra Admin Center anzumelden, sind Sie standardmäßig mit dem Microsoft Services-Mandanten verbunden. Innerhalb des Standardmandanten gibt es kein verknüpftes Verzeichnis zum Ausführen von Aktionen. Dieses Verhalten wird erwartet.

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 kostenlos starten aus.
  2. Befolgen Sie die Anweisungen zum Erstellen eines Azure-Kontos.
  3. Neben dem Azure-Konto wird ein Mandant generiert, und Sie werden automatisch als globaler Administrator festgelegt. Dadurch erhalten Sie vollzugriff auf alle Optionen innerhalb dieses Mandanten.

Ursache 2: Nicht unterstützte Kontotypen verwendet (mehrinstanzenfähige und persönliche Konten)

Wenn Ihre App-Registrierung auf einen Kontotyp mit nur einem Mandanten festgelegt ist, können sich Benutzer aus anderen Verzeichnissen oder Identitätsanbietern nicht bei dieser Anwendung anmelden.

Lösung: Ändern der Einstellung für die Anmeldezielgruppe im App-Registrierungsmanifest

Führen Sie die folgenden Schritte aus, um sicherzustellen, dass Ihre App-Registrierung kein Kontotyp mit einem einzelnen Mandanten ist:

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

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

  3. Wählen Sie auf 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:

    • AzureADandPersonalMicrosoftAccount
    • AzureADMultipleOrgs
    • PersonalMicrosoftAccount

    Wenn die Einstellung signInAudience keinen dieser Werte enthält, erstellen Sie die App-Registrierung neu, indem Sie den richtigen Kontotyp auswählen. Sie können signInAudience derzeit nicht im Manifest ändern.

Weitere Informationen zum Registrieren von Anwendungen finden Sie unter Schnellstart: Registrieren einer Anwendung beim Microsoft Identity Platform.

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

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

  • Konten in einem beliebigen Organisationsverzeichnis (beliebiges Microsoft Entra Verzeichnis – mehrinstanzenfähig)

  • Konten in einem beliebigen Organisationsverzeichnis (beliebiges Microsoft Entra Verzeichnis – mehrinstanzenfähig) 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 in dem Mandanten hinzufügen, der in der Anforderung angegeben ist. In diesem Fall wird erwartet, dass die Authentifizierung nur auf Ihrem Mandanten ausgeführt wird. Dieses Szenario verursacht den Anmeldefehler, wenn Sie erwarten, dass sich Benutzer über einen Verbund mit einem anderen Mandanten oder Identitätsanbieter anmelden.

Lösung: Verwenden Der richtigen Anmelde-URL

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

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

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

Ursache 4: Beim falschen Mandanten angemeldet

Wenn Benutzer versuchen, auf Ihre Anwendung zuzugreifen, erhalten sie entweder einen direkten Link zur Anwendung, oder sie versuchen, über Zugriff zu https://myapps.microsoft.comerhalten. 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 als die sitzung verwendet, die verwendet werden soll. Oder sie haben eine Sitzung, die ihr organization-Konto 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 Werten und Identity provider . Stimmen diese Werte mit der erwarteten Kombination überein oder nicht? Hat sich ein Benutzer beispielsweise mit dem organization-Konto bei Ihrem Mandanten statt mit dem Basismandanten angemeldet? Oder hat sich ein Benutzer beim Identitätsanbieter mit einem anderen persönliches Konto als dem bereits eingeladenen angemeldetlive.com?

Lösung: Melden Sie sich ab, und melden Sie sich dann erneut über einen anderen Browser oder eine private Browsersitzung an.

Weisen Sie den Benutzer an, eine neue in-private Browsersitzung zu öffnen, oder bitten Sie den Benutzer, über einen 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 versucht hat, sich anzumelden, wurde nicht zum Mandanten eingeladen.

Lösung: Einladen des Gastbenutzers

Führen Sie die Schritte unter Schnellstart: Hinzufügen von Gastbenutzern zu Ihrem Verzeichnis im Azure-Portal aus, um den Gastbenutzer einzuladen.

Ursache 6: App erfordert Benutzerzuweisung

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 ist, denen Zugriff auf die Anwendung zugewiesen ist. So überprüfen Sie, ob Ihre Unternehmensanwendung eine Benutzerzuweisung erfordert:

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

  2. Wählen Sie Ihre Unternehmensanwendung aus.

  3. Wählen Sie auf der Randleiste Eigenschaften aus.

  4. Überprüfen Sie, ob die Option Zuweisung erforderlich auf Ja festgelegt ist.

Lösung: Zuweisen des Zugriffs für Benutzer einzeln oder als Teil einer Gruppe

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

Ursache 7: Es wurde versucht, einen Flow mit Den Kennwortanmeldeinformationen des Ressourcenbesitzers 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 ein Fehler AADSTS50020 auf. Die Microsoft Identity Platform unterstützt ROPC nur innerhalb Microsoft Entra Mandanten, nicht in persönlichen Konten.

Lösung: Verwenden Sie einen Mandanten- oder organization-spezifischen Endpunkt.

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

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

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

Überprüfungsoption 1: Überprüfen Sie, ob der Gastbenutzer des Ressourcenmandanten älter als das Benutzerkonto des Basismandanten ist.

Die erste Überprüfungsoption umfasst den Vergleich des Alters des Gastbenutzers des Ressourcenmandanten mit dem Benutzerkonto des Basismandanten. Sie können diese Überprüfung mithilfe von Microsoft Graph oder MSOnline PowerShell durchführen.

Microsoft Graph

Stellen Sie eine Anforderung an den 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 Basismandanten. Das Szenario wird bestätigt, wenn der Gastbenutzer erstellt wurde, bevor das Benutzerkonto des Basismandanten erstellt wurde.

MSOnline PowerShell

Hinweis

Das MSOnline PowerShell-Modul ist als veraltet festgelegt. Da es auch nicht mit PowerShell Core kompatibel ist, stellen Sie sicher, dass Sie eine kompatible PowerShell-Version verwenden, damit Sie die folgenden Befehle ausführen können.

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

Get-MsolUser -SearchString user@contoso.com | Format-List whenCreated

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

Hinweis

Azure AD- und MSOnline PowerShell-Module sind ab dem 30. März 2024 veraltet. Weitere Informationen finden Sie im Veralteten Update. Nach diesem Datum ist die Unterstützung für diese Module auf Migrationsunterstützung zum Microsoft Graph PowerShell SDK und Sicherheitskorrekturen beschränkt. Die veralteten Module funktionieren weiterhin bis zum 30. März 2025.

Es wird empfohlen, zu Microsoft Graph PowerShell zu migrieren, um mit Microsoft Entra ID (früher Azure AD) zu interagieren. Häufig gestellte Fragen zur Migration finden Sie in den häufig gestellten Fragen zur Migration. Hinweis: Version 1.0.x von MSOnline kann nach dem 30. Juni 2024 unterbrochen werden.

Überprüfungsoption 2: Überprüfen Sie, ob sich die alternative Gastsicherheits-ID des Ressourcenmandanten von der Net-ID des Basismandanten unterscheidet.

Hinweis

Das MSOnline PowerShell-Modul ist als veraltet festgelegt. Da es auch nicht mit PowerShell Core kompatibel ist, stellen Sie sicher, dass Sie eine kompatible PowerShell-Version verwenden, damit Sie die folgenden Befehle ausführen können.

Wenn ein Gastbenutzer eine Einladung akzeptiert, wird das Attribut des LiveID Benutzers (die eindeutige Anmelde-ID des Benutzers) im AlternativeSecurityIdskey -Attribut gespeichert. Da das Benutzerkonto gelöscht und im Basismandanten erstellt wurde, hat sich der NetID Wert für das Konto für den Benutzer im Basismandanten geändert. Vergleichen Sie den NetID Wert des Benutzerkontos im Basismandanten wie folgt mit dem Schlüsselwert, der im AlternativeSecurityIds Gastkonto im Ressourcenmandanten gespeichert ist:

  1. Rufen Sie im Basismandanten den Wert des LiveID Attributs mithilfe des Get-MsolUser PowerShell-Cmdlets ab:

    Get-MsolUser -SearchString tuser1 | Select-Object -ExpandProperty LiveID

  2. Konvertieren Sie im Ressourcenmandanten den Wert des key Attributs in AlternativeSecurityIds in eine base64-codierte Zeichenfolge:

    [convert]::ToBase64String((Get-MsolUser -ObjectId 01234567-89ab-cdef-0123-456789abcdef
       ).AlternativeSecurityIds.key)

  3. Konvertieren Sie die base64-codierte Zeichenfolge mithilfe eines Onlinekonverters (z. B. base64.guru) in einen Hexadezimalwert.

  4. Vergleichen Sie die Werte aus Schritt 1 und Schritt 3, um zu überprüfen, ob sie sich unterscheiden. Die NetID des Benutzerkontos im Basismandanten wurde geändert, als das Konto gelöscht und neu erstellt wurde.

Lösung: Setzen Sie die einlöse status des Gastbenutzerkontos zurück.

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

Kontaktieren Sie uns für Hilfe

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