Fehler AADSTS50020 – Benutzerkonto vom Identitätsanbieter ist im Mandanten nicht vorhanden

  • Artikel
  • 7 Minuten Lesedauer

Dieser Artikel hilft Ihnen bei der Problembehandlung von FehlercodeAADSTS50020, der zurückgegeben wird, wenn sich ein Gastbenutzer von einem Identitätsanbieter (IdP) nicht bei einem Ressourcenmandanten in Azure Active Directory (Azure AD) 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' vom Identitätsanbieter {IdentityProviderURL} ist im Mandanten {ResourceTenantName} nicht vorhanden.

Wenn ein Administrator die Anmeldeprotokolle im Home-Mandanten überprüft, weist der Fehlercodeeintrag "90072" auf einen Anmeldefehler hin. Die Fehlermeldung besagt Folgendes:

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 Mandanten hinzugefügt werden. Melden Sie sich ab und erneut mit einem anderen Azure Active Directory Benutzerkonto an.

Ursache 1: Verwendeter nicht unterstützter Kontotyp (mehrinstanzenfähige und persönliche Konten)

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

Lösung: Ändern der Benutzergruppeneinstellung für die Anmeldung im App-Registrierungsmanifest

Führen Sie die folgenden Schritte aus, um sicherzustellen, dass ihre App-Registrierung kein Kontotyp mit einem einzigen 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 in der Randleiste " Manifest" aus.

  4. Suchen Sie im JSON-Code die SignInAudience-Einstellung .

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

    • AzureADandPersonalMicrosoftAccount
    • AzureADMultipleOrgs
    • PersonalMicrosoftAccount

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

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

Ursache 2: Verwendet den falschen Endpunkt (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 (beliebiges Azure AD-Verzeichnis – mehrinstanzenfähig)

  • Konten in einem beliebigen Organisationsverzeichnis (beliebiges Azure AD-Verzeichnis – Multitenant) und persönliche Microsoft-Konten (z. B. Skype, Xbox)

  • Nur persönliche Microsoft-Konten

Wenn Sie die Anwendung 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 für Ihren Mandanten ausgeführt wird. Dieses Szenario verursacht den Anmeldefehler, wenn Sie erwarten, dass sich Benutzer über einen Partnerverbund 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
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 finden AuthoritySie unter Microsoft Identity Platform Anwendungskonfigurationsoptionen.

Ursache 3: Beim falschen Mandanten angemeldet

Wenn Benutzer versuchen, auf Ihre Anwendung zuzugreifen, wird entweder ein direkter Link zur Anwendung gesendet, oder sie versuchen, über https://myapps.microsoft.comzugriff zu erhalten. 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 nach den User account Werten in Identity provider der Fehlermeldung. Stimmen diese Werte mit der erwarteten Kombination überein oder nicht? Hat sich ein Benutzer beispielsweise mithilfe seines Organisationskontos bei Ihrem Mandanten und nicht mit dem privaten Mandanten angemeldet? Oder hat sich ein Benutzer mit einem anderen persönlichen Konto als dem live.com bereits eingeladenen 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 lassen Sie den Benutzer versuchen, von einem anderen Browser aus 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 sich anmelden wollte, wurde nicht zum Mandanten eingeladen.

Lösung: Einladen des Gastbenutzers

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

Ursache 5: App erfordert Benutzerzuweisung

Wenn Ihre Anwendung eine Unternehmensanwendung ist, die eine Benutzerzuweisung erfordert, tritt ein Fehler AADSTS50020 auf, wenn der Benutzer nicht in der Liste der zulässigen Benutzer aufgeführt ist, denen Der Zugriff auf die Anwendung zugewiesen ist. So überprüfen Sie, ob Ihre Unternehmensanwendung eine Benutzerzuweisung erfordert:

  1. Suchen Sie im Azure-Portal nach Enterprise Anwendungen, 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 6: Es wurde versucht, den Kennwort-Anmeldeinformationsfluss eines 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 Azure AD Mandanten, nicht in 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 Azure AD-Mandanten eingeladen wurden, können kein ROPC verwenden. Weitere Informationen finden Sie unter Microsoft Identity Platform- und OAuth 2.0-Ressourcenbesitzer-Kennwortanmeldeinformationen.

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

Fehler AADSTS50020 kann 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 keinem Benutzerkonto im Home-Mandanten zugeordnet ist:

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

Die erste Überprüfungsoption besteht darin, das Alter des Gastbenutzers des Ressourcenmandanten mit dem Benutzerkonto des Heimmandanten zu vergleichen. Sie können diese Überprüfung mithilfe von Microsoft Graph oder MSOnline PowerShell vornehmen.

Microsoft Graph

Stellen Sie eine Anforderung an die MS Graph-API, 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 mit dem Erstellungsdatum des Benutzerkontos im Startmandanten. Das Szenario wird bestätigt, wenn der Gastbenutzer erstellt wurde, bevor das Benutzerkonto des Heimmandanten 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 mit dem Erstellungsdatum des Benutzerkontos im Startmandanten. Das Szenario wird bestätigt, wenn der Gastbenutzer erstellt wurde, bevor das Benutzerkonto des Heimmandanten erstellt wurde.

Überprüfungsoption 2: Überprüfen Sie, ob sich die alternative Sicherheits-ID des Gastmandanten von der Benutzer-Net-ID des Heimmandanten 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 annimmt, wird das Attribut des Benutzers (die eindeutige Anmelde-ID des Benutzers LiveID ) im AlternativeSecurityIds key Attribut gespeichert. Da das Benutzerkonto im Startmandanten gelöscht und erstellt wurde, hat sich der NetID Wert für das Konto für den Benutzer im Heimmandanten geändert. Vergleichen Sie den NetID Wert des Benutzerkontos im Startmandanten mit dem Schlüsselwert, der im AlternativeSecurityIds Gastkonto im Ressourcenmandanten gespeichert ist, wie folgt:

  1. Rufen Sie im Home-Mandanten 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 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 unterschiedlich sind. Das NetID Benutzerkonto im Heimmandanten hat sich geändert, als das Konto gelöscht und neu erstellt wurde.

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

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