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

  • Artikel
  • 7 Minuten Lesedauer

Dieser Artikel hilft Ihnen bei der Problembehandlung von Fehlercode AADSTS50020 , der zurückgegeben wird, wenn sich ein Gastbenutzer eines Identitätsanbieters (IdP) nicht bei einem Ressourcenmandanten in Azure Active Directory (Azure AD) 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" 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 Azure Active Directory-Benutzerkonto an.

Ursache 1: 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 nur einem 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 nach der 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 2: Verwendet den falschen Endpunkt (persönliche Konten und Organisationskonten)

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 Azure AD-Verzeichnis – mehrinstanzenfähig)

  • Konten in einem beliebigen Organisationsverzeichnis (Beliebiges Azure AD-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 Optionen für die Anwendungskonfiguration.

Ursache 3: 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 Fällen 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 ein anderes persönliches Konto verwendet als das, das verwendet werden soll. Oder sie haben eine Sitzung, die ihr Organisationskonto verwendet, obwohl sie ein persönliches Gastkonto verwenden wollten (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 Organisationskonto bei Ihrem Mandanten statt mit dem Basismandanten angemeldet? Oder hat sich ein Benutzer mit einem anderen persönlichen Konto als dem live.com bereits eingeladenen konto beim Identitätsanbieter angemeldet?

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 4: 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 5: 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 6: 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 von Azure AD-Mandanten, nicht in persönlichen Konten.

Lösung: Verwenden Sie einen Endpunkt, 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 Azure AD-Mandanten eingeladen wurden, können kein ROPC verwenden. Weitere Informationen finden Sie unter Kennwortanmeldeinformationen für Microsoft Identity Platform und OAuth 2.0-Ressourcenbesitzer.

Ursache 7: Ein zuvor gelöschter Benutzername wurde vom Administrator des Basismandanten 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.

Ü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: 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 neu 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 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 den Azure-Communitysupport übermitteln.