Erreur AADSTS50020 - Le compte d’utilisateur du fournisseur d’identité n’existe pas dans le locataire

2025-04-09

Cet article vous aide à résoudre les problèmes de code d’erreur AADSTS50020 retourné si un utilisateur invité d’un fournisseur d’identité (IdP) ne peut pas se connecter à un locataire de ressource dans Microsoft Entra ID.

Symptômes

Lorsqu’un utilisateur invité tente d’accéder à une application ou une ressource dans le locataire de ressource, la connexion échoue et le message d’erreur suivant s’affiche :

AADSTS50020 : le compte d’utilisateur «user@domain.com » provenant du fournisseur d’identité {IdentityProviderURL} n’existe pas dans le client {ResourceTenantName}.

Lorsqu’un administrateur examine les journaux de connexion sur le locataire domestique, une entrée de code d’erreur « 90072 » indique un échec de connexion. Le message d’erreur indique :

Le compte d’utilisateur {email} du fournisseur d’identité {idp} n’existe pas dans le locataire {tenant} et ne peut pas accéder à l’application {appId}({appName}) dans ce locataire. Le compte doit d'abord être ajouté en tant qu'utilisateur externe dans le tenant. Déconnectez-vous et reconnectez-vous avec un autre compte d’utilisateur Microsoft Entra.

Cause 1 : Les utilisateurs se connectent au Centre d’administration Microsoft Entra à l’aide de comptes Microsoft personnels

Lorsque vous essayez de vous connecter au Centre d’administration Microsoft Entra à l’aide de vos comptes Microsoft personnels (Outlook, Hotmail ou OneDrive), vous êtes connecté au locataire des services Microsoft par défaut. Dans le tenant par défaut, il n’existe aucun répertoire lié pour effectuer des actions. Il s’agit du comportement attendu.

Dans l’expérience précédente, un répertoire (par exemple, UserNamehotmail735.onmicrosoft.com) est créé et lié au compte personnel, et vous pouvez effectuer des actions telles que la création de comptes d’utilisateur dans l’annuaire. Le comportement a maintenant été modifié.

Solution : Créer un compte Azure avec un nouveau locataire

Si vous souhaitez disposer d’un annuaire, vous devez créer un compte Azure et un nouveau locataire :

Accédez à https://azure.microsoft.com/en-us/free/, puis sélectionnez Démarrer gratuitement .
Suivez les instructions pour créer un compte Azure.
Un locataire sera généré en même temps que le compte Azure, et vous serez automatiquement désigné en tant qu’administrateur général. Cela vous permet d’accéder entièrement à toutes les options de ce locataire.

Cause 2 : Type de compte non pris en charge (multilocataire et compte personnel)

Si l’inscription de votre application est définie sur un type de compte à locataire unique, les utilisateurs d’autres répertoires ou fournisseurs d’identité ne peuvent pas s'authentifier à cette application.

Pour vous assurer que l’inscription de votre application n’est pas un type de compte à locataire unique, procédez comme suit :

Dans le portail Azure, recherchez et sélectionnez Inscriptions d’applications.
Sélectionnez le nom de votre inscription d’application.
Dans la barre latérale, sélectionnez Manifeste.
Dans le code JSON, recherchez le paramètre signInAudience .
Vérifiez si le paramètre contient l’une des valeurs suivantes :
- Azure AD et compte Microsoft personnel
- AzureADMultipleOrgs
- PersonnelMicrosoftAccount
Si le paramètre signInAudience ne contient pas l’une de ces valeurs, recréez l’inscription de l’application en utilisant le type de compte correct sélectionné. Vous ne pouvez actuellement pas modifier signInAudience dans le manifeste.

Pour plus d’informations sur l’inscription d’applications, consultez Démarrage rapide : Inscrire une application auprès de la plateforme d’identités Microsoft.

Cause 3 : Utilisé le point de terminaison incorrect (comptes personnels et d’organisation)

Votre appel d’authentification doit cibler une URL qui correspond à votre sélection si le type de compte pris en charge par votre inscription d’application a été défini sur l’une des valeurs suivantes :

Comptes dans n’importe quel annuaire organisationnel (n’importe quel annuaire Microsoft Entra - multi-locataires)
Comptes dans n’importe quel annuaire organisationnel (n’importe quel répertoire Microsoft Entra - Multilocataire) et comptes Microsoft personnels (par exemple, Skype, Xbox)
Comptes Microsoft personnels uniquement

Si vous utilisez https://login.microsoftonline.com/<YourTenantNameOrID>, les utilisateurs d’autres organisations ne peuvent pas accéder à l’application. Vous devez ajouter ces utilisateurs en tant qu’invités dans le locataire spécifié dans la demande. Dans ce cas, l’authentification doit être exécutée uniquement sur votre locataire. Ce scénario provoque l’erreur de connexion si vous vous attendez à ce que les utilisateurs se connectent à l’aide de la fédération avec un autre client ou fournisseur d’identité.

Utilisez l’URL de connexion correspondante pour le type d’application spécifique, comme indiqué dans le tableau suivant :

Type d’application	URL de connexion
Applications mutualisées	`https://login.microsoftonline.com/organizations`
Multilocataire et compte personnel s	`https://login.microsoftonline.com/common`
Comptes personnels uniquement	`https://login.microsoftonline.com/consumers`

Dans votre code d’application, appliquez cette valeur d’URL dans le Authority paramètre. Pour plus d’informations sur Authority, consultez les options de configuration des applications de la plateforme d’identités Microsoft.

Cause 4 : Connecté au locataire incorrect

Lorsque les utilisateurs essaient d’accéder à votre application, soit ils sont envoyés un lien direct à l’application, soit ils essaient d’accéder via https://myapps.microsoft.com. Dans les deux cas, les utilisateurs sont redirigés pour se connecter à l’application. Dans certains cas, l’utilisateur peut déjà avoir une session active qui utilise une autre compte personnel que celle destinée à être utilisée. Ou ils ont une session qui utilise leur compte d’organisation bien qu’ils aient l’intention d’utiliser un compte invité personnel (ou inversement).

Pour vous assurer que ce scénario est bien la cause, recherchez les valeurs User account et Identity provider dans le message d’erreur. Ces valeurs correspondent-elles à la combinaison attendue ou non ? Par exemple, un utilisateur s’est-il connecté à l’aide de son compte d’organisation à votre locataire au lieu de son locataire domestique ? Ou un utilisateur s’est-il connecté au fournisseur d’identité à live.com l’aide d’une compte personnel différente de celle qui a déjà été invitée ?

Demandez à l’utilisateur d’ouvrir une nouvelle session de navigateur privée ou d’essayer d’accéder à partir d’un autre navigateur. Dans ce cas, les utilisateurs doivent se déconnecter de leur session active, puis essayer de se reconnecter.

Cause 5 : L’utilisateur invité n’a pas été invité

L’utilisateur invité qui a essayé de se connecter n’a pas été invité au locataire.

Solution : Inviter l’utilisateur invité

Veillez à suivre les étapes de démarrage rapide : ajoutez des utilisateurs invités à votre annuaire dans le portail Azure pour inviter l’utilisateur invité.

Cause 6 : L’application nécessite une attribution d’utilisateur

Si votre application est une application d’entreprise qui nécessite une attribution d’utilisateur, une erreur AADSTS50020 se produit si l’utilisateur n’est pas dans la liste des utilisateurs autorisés qui ont accès à l’application. Pour vérifier si votre application d’entreprise nécessite une attribution d’utilisateur :

Dans le portail Azure, recherchez et sélectionnez Applications d’entreprise.
Sélectionnez votre application d’entreprise.
Dans la barre latérale, sélectionnez Propriétés.
Vérifiez si l’option Affectation requise est définie sur Oui.

Solution : Attribuer l’accès aux utilisateurs individuellement ou dans le cadre d’un groupe

Utilisez l’une des options suivantes pour attribuer l’accès aux utilisateurs :

Pour affecter individuellement l’accès utilisateur à l’application, consultez Affecter un compte d’utilisateur à une application d’entreprise.
Pour affecter des utilisateurs s’ils sont membres d’un groupe affecté ou d’un groupe dynamique, consultez Gérer l’accès à une application.

Cause 7 : Tentative d'utilisation d'un flux de mot de passe de propriétaire de la ressource pour les comptes personnels

Si un utilisateur tente d’utiliser le flux d’informations d’identification de mot de passe du propriétaire de la ressource (ROPC) pour les compte personnel s, une erreur AADSTS50020 se produit. La plateforme d’identités Microsoft prend en charge ROPC uniquement pour les locataires Microsoft Entra, et non pas pour les comptes personnels.

Solution : Utiliser un point de terminaison spécifique au locataire ou à l’organisation

Utilisez un point de terminaison spécifique au locataire (https://login.microsoftonline.com/<TenantIDOrName>) ou le point de terminaison de l’organisation. Les comptes personnels qui sont invités sur un locataire Microsoft Entra ne peuvent pas utiliser ROPC. Pour plus d’informations, consultez la plateforme d’identités Microsoft et les informations d’identification du mot de passe du propriétaire de la ressource OAuth 2.0.

Cause 8 : Un nom d’utilisateur précédemment supprimé a été recréé par l’administrateur du locataire d’accueil

Une erreur AADSTS50020 peut se produire si le nom d’un utilisateur invité qui a été supprimé dans un locataire de ressource est recréé par l’administrateur du locataire domestique. Pour vérifier que le compte d’utilisateur invité dans le locataire de ressource n’est pas associé à un compte d’utilisateur dans le locataire domestique, utilisez l’une des options suivantes :

Vérification : vérifiez si l’utilisateur invité du locataire de ressource est plus ancien que le compte d’utilisateur du locataire de base

Pour vérifier la date de création du compte d’utilisateur invité, vous pouvez utiliser Microsoft Graph, Microsoft Entra PowerShell ou le Kit de développement logiciel (SDK) Microsoft Graph PowerShell.

Microsoft Graph

Émettez une demande à l’API MS Graph pour passer en revue la date de création de l’utilisateur, comme suit :

GET https://graph.microsoft.com/v1.0/users/{id | userPrincipalName}/createdDateTime

Ensuite, vérifiez la date de création de l’utilisateur invité dans le locataire de ressource par rapport à la date de création du compte d’utilisateur dans le locataire domestique. Le scénario est confirmé si l’utilisateur invité a été créé avant la création du compte d’utilisateur du locataire d’accueil.

Microsoft Entra PowerShell

Exécutez l’applet de commande Get-EntraUser PowerShell pour passer en revue la date de création de l’utilisateur, comme suit :

Get-EntraUser -UserId {id | userPrincipalName} | Select-Object id, userPrincipalName, createdDateTime

Microsoft Graph - SDK PowerShell

Exécutez l’applet de commande Get-MgUser PowerShell pour passer en revue la date de création de l’utilisateur, comme suit :

$p = @('Id', 'UserPrincipalName', 'CreatedDateTime')
Get-MgUser -UserId {id | userPrincipalName} -Property $p| Select-Object $p

Solution : réinitialiser l’état d’échange du compte d’utilisateur invité

Réinitialisez l’état de récupération du compte d’utilisateur invité dans le locataire de ressources. Ensuite, vous pouvez conserver l’objet utilisateur invité sans avoir à supprimer, puis recréer le compte invité. Vous pouvez réinitialiser l’état de l’échange à l’aide des Portail Azure, d’Azure PowerShell ou de l’API Microsoft Graph. Pour obtenir des instructions, consultez Réinitialiser le statut d'utilisation pour un utilisateur invité.

Contactez-nous pour obtenir de l’aide

Si vous avez des questions ou avez besoin d’aide, créez une demande de support ou demandez le support de la communauté Azure. Vous pouvez également envoyer des commentaires sur le produit à la communauté de commentaires Azure.