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

Cet article vous aide à résoudre le code AADSTS50020 d’erreur 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 » du fournisseur d’identité {IdentityProviderURL} n’existe pas dans le locataire {ResourceTenantName}.

Lorsqu’un administrateur examine les journaux de connexion sur le locataire d’origine, 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 locataire. Déconnectez-vous et reconnectez-vous avec un autre compte d’utilisateur Microsoft Entra.

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

Lorsque vous essayez de vous connecter à 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 locataire par défaut, il n’existe aucun répertoire lié pour effectuer des actions. Ce comportement est normal.

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 : Create un compte Azure avec un nouveau locataire

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

1. Accédez à https://azure.microsoft.com/en-us/free/, puis sélectionnez Démarrer gratuitement .
2. Suivez les instructions pour créer un compte Azure.
3. Un locataire est généré en même temps que le compte Azure, et vous êtes automatiquement désigné en tant qu’administrateur général. Cela vous donne un accès complet à toutes les options au sein de ce locataire.

Cause 2 : Type de compte non pris en charge utilisé (comptes multilocataires et personnels)

Si l’inscription de votre application est définie sur un type de compte monolocataire, les utilisateurs d’autres annuaires ou fournisseurs d’identité ne peuvent pas se connecter à cette application.

Solution : Modifier le paramètre d’audience de connexion dans le manifeste d’inscription d’application

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

1. Dans le Portail Azure, recherchez et sélectionnez inscriptions d'applications.

2. Sélectionnez le nom de votre inscription d’application.

3. Dans la barre latérale, sélectionnez Manifeste.

4. Dans le code JSON, recherchez le paramètre signInAudience .

5. Vérifiez si le paramètre contient l’une des valeurs suivantes :

   • AzureADandPersonalMicrosoftAccount
   • AzureADMultipleOrgs
   • PersonalMicrosoftAccount

   Si le paramètre signInAudience ne contient pas l’une de ces valeurs, recréez l’inscription de l’application en sélectionnant le type de compte approprié. Actuellement, vous ne pouvez pas modifier signInAudience dans le manifeste.

Pour plus d’informations sur l’inscription d’applications, consultez Démarrage rapide : Inscrire une application avec le Plateforme d'identités Microsoft.

Cause 3 : Utilisation d’un point de terminaison incorrect (comptes personnels et organization)

Votre appel d’authentification doit cibler une URL qui correspond à votre sélection si le type de compte pris en charge de 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 - Multilocataire)

• Comptes dans n’importe quel annuaire organisationnel (n’importe quel annuaire 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 requête. Dans ce cas, l’authentification est censée ê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 locataire ou fournisseur d’identité.

Solution : Utiliser l’URL de connexion correcte

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

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

Cause 4 : Connexion au locataire incorrect

Lorsque les utilisateurs essaient d’accéder à votre application, ils sont soit envoyés à un lien direct vers l’application, soit ils essaient d’y 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à disposer d’une session active qui utilise une autre compte personnel que celle qui est destinée à être utilisée. Ou ils ont une session qui utilise leur compte organization bien qu’ils aient prévu d’utiliser un compte invité personnel (ou vice versa).

Pour vous assurer que ce scénario est le problème, recherchez les User account valeurs et Identity provider dans le message d’erreur. Ces valeurs correspondent-elles ou non à la combinaison attendue ? Par exemple, un utilisateur s’est-il connecté en utilisant son compte organization à votre locataire au lieu de son locataire d’origine ? Ou un utilisateur s’est-il connecté au fournisseur d’identité à l’aide live.com d’une autre compte personnel que celle qui était déjà invitée ?

Solution : Déconnectez-vous, puis reconnectez-vous à partir d’un autre navigateur ou d’une session de navigateur privé

Demandez à l’utilisateur d’ouvrir une nouvelle session de navigateur privé ou d’essayer d’y 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 tenté de se connecter n’a pas été invité au locataire.

Solution : Inviter l’utilisateur invité

Veillez à suivre les étapes décrites dans Démarrage rapide : Ajouter des utilisateurs invités à votre annuaire dans le Portail Azure pour inviter l’utilisateur invité.

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

Si votre application est une application d’entreprise qui nécessite une affectation d’utilisateur, une erreur AADSTS50020 se produit si l’utilisateur ne figure pas dans la liste des utilisateurs autorisés auxquels l’accès à l’application est attribué. Pour case activée si votre application d’entreprise nécessite une affectation d’utilisateur :

1. Dans la Portail Azure, recherchez et sélectionnez Applications d’entreprise.

2. Sélectionnez votre application d’entreprise.

3. Dans la barre latérale, sélectionnez Propriétés.

4. 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 attribuer individuellement l’accès utilisateur à l’application, consultez Attribuer un compte d’utilisateur à une application d’entreprise.

• Pour affecter des utilisateurs s’ils sont membres d’un groupe attribué ou d’un groupe dynamique, consultez Gérer l’accès à une application.

Cause 7 : Tentative d’utilisation d’un flux d’informations d’identification de mot de passe du 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 comptes personnels, une erreur AADSTS50020 se produit. Le Plateforme d'identités Microsoft prend en charge ROPC uniquement au sein des locataires Microsoft Entra, et non dans les comptes personnels.

Solution : utilisez un point de terminaison spécifique au locataire ou au organization

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

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

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 d’origine. 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 d’origine, utilisez l’une des options suivantes :

Option de vérification 1 : vérifier si l’utilisateur invité du locataire de ressource est antérieur au compte d’utilisateur du locataire d’origine

La première option de vérification consiste à comparer l’âge de l’utilisateur invité du locataire de ressource au compte d’utilisateur du locataire d’origine. Vous pouvez effectuer cette vérification à l’aide de Microsoft Graph ou de MSOnline PowerShell.

Microsoft Graph

Émettez une demande à ms API 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, case activée 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 d’origine. Le scénario est confirmé si l’utilisateur invité a été créé avant la création du compte d’utilisateur du locataire d’origine.

MSOnline PowerShell

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

Get-MsolUser -SearchString user@contoso.com | Format-List whenCreated

Ensuite, case activée 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 d’origine. Le scénario est confirmé si l’utilisateur invité a été créé avant la création du compte d’utilisateur du locataire d’origine.

Option de vérification 2 : vérifier si l’ID de sécurité alternatif invité du locataire de ressource diffère de l’ID de réseau utilisateur du locataire d’origine

Lorsqu’un utilisateur invité accepte une invitation, l’attribut de LiveID l’utilisateur (l’ID de connexion unique de l’utilisateur) est stocké dans AlternativeSecurityIds l’attribut key . Étant donné que le compte d’utilisateur a été supprimé et créé dans le locataire d’origine, la NetID valeur du compte a changé pour l’utilisateur dans le locataire d’origine. Comparez la NetID valeur du compte d’utilisateur dans le locataire d’origine à la valeur de clé stockée dans AlternativeSecurityIds le compte invité dans le locataire de ressource, comme suit :

1. Dans le locataire d’origine, récupérez la valeur de l’attribut à l’aide LiveID de l’applet de Get-MsolUser commande PowerShell :

   Get-MsolUser -SearchString tuser1 | Select-Object -ExpandProperty LiveID
   

2. Dans le locataire de ressource, convertissez la valeur de l’attribut key dans AlternativeSecurityIds en une chaîne encodée en base64 :

   [convert]::ToBase64String((Get-MsolUser -ObjectId 01234567-89ab-cdef-0123-456789abcdef
          ).AlternativeSecurityIds.key)
   

3. Convertissez la chaîne encodée en base64 en valeur hexadécimale à l’aide d’un convertisseur en ligne (tel que base64.guru).

4. Comparez les valeurs des étapes 1 et 3 pour vérifier qu’elles sont différentes. Le NetID du compte d’utilisateur dans le locataire d’origine a changé lorsque le compte a été supprimé et recréé.

Solution : Réinitialiser le status d’échange du compte d’utilisateur invité

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

Contactez-nous pour obtenir de l’aide

Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.