AADSTS50020, Benutzerkonto vom Identitätsanbieter ist im Mandanten nicht vorhanden
In diesem Artikel besprechen wir mögliche Korrekturen zur Behebung des Fehlers AADSTS50020, „Benutzerkonto vom Identitätsanbieter existiert im Mandanten nicht“ . Dieser Fehler tritt normalerweise auf, wenn sich ein Gastbenutzer eines Identitätsanbieters (IdP) nicht bei einem Ressourcenmandanten in Azure Active Directory (Azure AD) anmelden kann. Dieser Fehler kann in verschiedenen Situationen auftreten. Jede Situation erfordert eine andere Art der Fehlerbehebung.
Die vollständige Fehlermeldung, die dem Gastbenutzer angezeigt wird, wenn er versucht, auf eine Anwendung oder Ressource im Ressourcenmandanten zuzugreifen, lautet:
AADSTS50020: Das Benutzerkonto „ [email protected] “ vom Identitätsanbieter {IdentityProviderURL} ist im Mandanten {ResourceTenantName} nicht vorhanden.
Bei der Überprüfung der Protokolle des Home-Mieters wird dem Administrator die folgende Fehlermeldung angezeigt:
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 zunächst als externer Benutzer im Mandanten hinzugefügt werden. Melden Sie sich ab und erneut mit einem anderen Azure Active Directory-Benutzerkonto an.
AADSTS50020, Benutzerkonto vom Identitätsanbieter ist im Mandanten nicht vorhanden
Die folgenden Lösungen helfen Ihnen bei der Behebung des Fehlers AADSTS50020, „Benutzerkonto vom Identitätsanbieter ist im Mandanten nicht vorhanden“.
- Ändern Sie die Einstellung für die Anmeldezielgruppe im App-Registrierungsmanifest
- Verwenden Sie die richtige Anmelde-URL
- Melden Sie sich ab und melden Sie sich dann über einen anderen Browser oder eine private Browsersitzung erneut an
- Laden Sie den Gastbenutzer ein
- Benutzern Zugriff zuweisen (falls zutreffend)
- Verwenden Sie einen Endpunkt, der für den Mandanten oder die Organisation spezifisch ist
- Setzen Sie den Einlösestatus des Gastbenutzerkontos zurück
Sehen wir uns alle diese Korrekturen im Detail an.
1]Ändern Sie die Einstellung für die Anmeldezielgruppe im App-Registrierungsmanifest
Eine mögliche Ursache für diesen Fehler liegt darin, dass ein Mandant einen nicht unterstützten Kontotyp verwendet. Wenn beispielsweise für Ihre App-Registrierung ein Einzelmandantenkontotyp festgelegt ist, kann sich ein Benutzer eines anderen identifizierten Anbieters nicht bei der Anwendung anmelden.
Um den AADSTS50020-Fehler zu beheben, ändern Sie die Anmeldezielgruppeneinstellung im App-Registrierungsmanifest wie folgt:
- Gehen Sie zum Azure-Portal .
- Wählen Sie App-Registrierungen aus .
- Wählen Sie den Namen Ihrer App-Registrierung aus.
- Wählen Sie in der Seitenleiste „Manifest“ aus.
- Suchen Sie im JSON-Code nach der Einstellung signInAudience.
- Überprüfen Sie die Einstellung anhand eines der folgenden Werte:
- AzureADandPersonalMicrosoftAccount
- AzureADMultipleOrgs
- Persönliches Microsoft-Konto
Die SignInAudience sollte einen der oben genannten Werte enthalten. Sollten Sie keinen dieser Werte in der SignInAudience-Einstellung finden, müssen Sie die App-Registrierung erneut erstellen.
2] Verwenden Sie die richtige Anmelde-URL
Eine weitere Ursache für diesen Fehler ist die Verwendung der falschen Anmelde-URL. Wenn Sie beispielsweise die URL https://login.Microsoftonline.com/<YourTenantNameOrID> verwenden, wird erwartet, dass die Authentifizierung nur auf Ihrem Mandanten ausgeführt wird. Aus diesem Grund können Benutzer in anderen Organisationen nicht auf die Anwendung zugreifen. Wenn andere Benutzer dies versuchen, erhalten sie eine Anmeldefehlermeldung.
Um dieses Problem zu beheben, müssen Sie diese Benutzer als Gäste zum in der Anfrage angegebenen Mandanten hinzufügen. Sie können die entsprechende Anmelde-URL für einen bestimmten Anwendungstyp verwenden. Nachfolgend sind einige Beispiele aufgeführt:
Für den Anwendungstyp „Mehrinstanzenfähig“ können Sie die folgende Anmelde-URL verwenden.
Wenn Sie Multitenant und den persönlichen Kontotyp verwenden, können Sie die folgende Anmelde-URL verwenden.
Verwenden Sie diese Anmelde-URL nur für persönliche Konten.
3] Melden Sie sich ab und dann über einen anderen Browser oder eine private Browsersitzung erneut an
Manchmal tritt dieser Fehler auf, wenn sich der Benutzer beim falschen Mandanten angemeldet hat. Zum Beispiel, wenn ein Benutzer bereits eine aktive Sitzung in seinem Webbrowser hat und versucht, auf Ihre Anwendung zuzugreifen, indem er auf den entsprechenden Link klickt oder die erforderliche URL in einem neuen Tab eingibt.
Bitten Sie in dieser Situation den Gastbenutzer, eine der folgenden Aktionen auszuführen:
- Melden Sie sich von dem Konto ab, das bereits in seinem/ihrem Webbrowser eröffnet wurde. Dadurch wird die bereits aktive Sitzung beendet. Jetzt kann er/sie sich mit dem richtigen Link und den richtigen Anmeldeinformationen anmelden.
- Melden Sie sich mit einem anderen Webbrowser an.
- Melden Sie sich im privaten oder Inkognito-Fenster desselben Webbrowsers an.
4] Laden Sie den Gastbenutzer ein
Dieser Fehler tritt auch auf, wenn der Gastbenutzer nicht eingeladen ist. Die Lösung für diese Situation ist einfach. Laden Sie den Gastbenutzer ein.
5] Benutzern Zugriff zuweisen (falls zutreffend)
Wenn es sich bei Ihrer Anwendung um eine Unternehmensanwendung handelt, die eine Benutzerzuweisung erfordert, und der Benutzer nicht in der Liste der zulässigen Benutzer aufgeführt ist, denen Zugriff auf die Anwendung zugewiesen wurde, tritt dieser Fehler auf.
Sie können überprüfen, ob Ihre Unternehmensanwendung eine Benutzerzuweisung erfordert oder nicht, indem Sie die folgenden Schritte ausführen:
- Gehen Sie zum Azure-Portal.
- Wählen Sie die Unternehmensanwendung(en) aus .
- Wählen Sie Ihre Unternehmensanwendung aus.
- Wählen Sie Eigenschaften aus .
- Überprüfen Sie, ob die Option „Zuweisung erforderlich “ auf „Ja“ gesetzt ist . Wenn es auf „Ja“ gesetzt ist, erfordert diese Anwendung die Benutzerzuweisung.
Weisen Sie in dieser Situation den Benutzern einzeln oder als Teil einer Gruppe den Zugriff zu.
6] Verwenden Sie einen Endpunkt, der für den Mandanten oder die Organisation spezifisch ist
Der Fehlercode AADSTS50020 kann auch auftreten, wenn ein Benutzer versucht, den ROPC-Flow (Resource Owner Password Credential) für sein/ihr persönliches Konto/ihre persönlichen Konten zu verwenden. Microsoft Identity Platform unterstützt ROPC nur innerhalb von Azure AD-Mandanten und nicht für persönliche Konten.
In dieser Situation muss der Benutzer den Endpunkt verwenden, der für den Mandanten oder die Organisation spezifisch ist. Beachten Sie, dass persönliche Konten ROPC nicht verwenden können, selbst wenn sie zu einem Azure AD-Mandanten eingeladen werden.
7] Setzen Sie den Einlösestatus des Gastbenutzerkontos zurück
Wenn der Administrator den Benutzernamen des Gastbenutzers im Ressourcenmandanten gelöscht und ihn im Home-Mandanten neu erstellt hat, tritt beim Gastbenutzer dieser Fehler auf. Der Administrator sollte außerdem sicherstellen, dass das Gastbenutzerkonto im Ressourcenmandanten nicht mit dem Gastbenutzerkonto im Home-Mandanten verknüpft ist.
Um den Fehler in dieser Situation zu beheben, setzen Sie den Einlösungsstatus des Gastbenutzerkontos im Ressourcenmandanten zurück.
Das ist es. Ich hoffe das hilft.
Welche Mandanten-ID wird in Azure verwendet?
Die Mandanten-ID in Azure ist eine eindeutige Kennung für einen Azure Active Directory (Azure AD)-Mandanten. Sie wird auch als Office 365-Mandanten-ID bezeichnet. Es gibt verschiedene Möglichkeiten, Ihre Azure-Mandanten-ID zu erhalten.
Wer ist Mieteradministrator?
Ein Mandantenadministrator ist ein Benutzer, der über die höchste Berechtigungsstufe in einem Azure Active Directory (Azure AD)-Mandanten verfügt. Er/sie kann alle Aspekte des Mandanten verwalten, einschließlich Benutzer, Gruppen, Berechtigungen und Einstellungen.
Schreibe einen Kommentar