Freigeben über

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

  • Artikel

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 Mandanten hinzugefügt werden. Melden Sie sich ab und anschließend mit einem anderen Microsoft Entra-Benutzerkonto erneut an.

Ursache 1: 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 zum Ausführen von Aktionen. 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 vollzugriff auf alle Optionen innerhalb dieses Mandanten.

Ursache 2: Verwendeter nicht unterstützter Kontotyp (Multitenant und persönliches Konto s)

Wenn die App-Registrierung auf einen Kontotyp mit einem Mandanten festgelegt ist, können sich Benutzer aus anderen Verzeichnissen oder Identitätsanbietern 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 Sie im Azure-Portal nach App-Registrierungen, und wählen Sie den Eintrag 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:

    • AzureADandPersonalMicrosoftAccount
    • AzureADMultipleOrgs
    • PersonalMicrosoftAccount

    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 (beliebiges 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 nach den User account Werten Identity provider in der Fehlermeldung. Stimmen diese Werte mit der erwarteten Kombination überein oder nicht? Hat sich beispielsweise ein Benutzer mit dem Organisationskonto bei Ihrem Mandanten anstelle seines Privaten Mandanten angemeldet? Oder hat sich ein Benutzer bei dem live.com Identitätsanbieter angemeldet, indem er einen anderen persönliches Konto verwendet als den, der 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 in private Browsersitzung zu öffnen, oder der Benutzer versucht, 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 5: Gastbenutzer wurde nicht eingeladen

Der Gastbenutzer, der versucht hat, 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, einen Kennwortanmeldeinformationsfluss für Ressourcenbesitzer für persönliches Konto zu verwenden

Wenn ein Benutzer versucht, den RoPC-Fluss (Resource Owner Password Credentials) für persönliches Konto zu verwenden, tritt ein Fehler AADSTS50020 auf. Die Microsoft Identity Platform unterstützt ROPC nur innerhalb von Microsoft Entra-Mandanten, nicht persönliches Konto s.

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üfungsoption 1: Überprüfen, ob der Gastbenutzer des Ressourcenmandanten älter als das Benutzerkonto des Privaten Mandanten ist

Bei der ersten Überprüfungsoption wird das Alter des Gastbenutzers des Ressourcenmandanten mit dem Benutzerkonto des Heimmandanten verglichen. 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 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.

PowerShell-Modul „MSOnline“

Notiz

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 Heimmandanten. Das Szenario wird bestätigt, wenn der Gastbenutzer erstellt wurde, bevor das Benutzerkonto des Heimmandanten erstellt wurde.

Notiz

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

Es wird empfohlen, für die Interaktion mit Microsoft Entra ID (früher Azure AD) zu Microsoft Graph PowerShell zu migrieren. Informationen zu allgemeinen Migrationsfragen finden Sie in den häufig gestellten Fragen zur Migration. Hinweis: Bei der Version 1.0.x von MSOnline können nach dem 30. Juni 2024 Unterbrechungen auftreten.

Überprüfungsoption 2: Überprüfen Sie, ob sich die alternative Sicherheits-ID des Ressourcenmandanten von der Benutzer-NET-ID des Heimmandanten unterscheidet.

Notiz

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 Benutzers LiveID (die eindeutige Anmelde-ID des Benutzers) im AlternativeSecurityIds key Attribut gespeichert. Da das Benutzerkonto gelöscht und im Heimmandanten 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 Heimmandanten mit dem Schlüsselwert, der im AlternativeSecurityIds Gastkonto im Ressourcenmandanten gespeichert ist, wie folgt:

  1. Rufen Sie im Heimmandanten 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 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 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 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.