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

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

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 » à partir du fournisseur d’identité {IdentityProviderURL} n’existe pas dans le locataire {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 client. 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 locataire 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 :

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 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 s)

Si l’inscription de votre application est définie sur un type de compte monolocataire, les utilisateurs d’autres répertoires 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 de l’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 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 du 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 répertoire Microsoft Entra - Multilocataire)

• 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 attendez 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 votre code d’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 : 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 le problème, recherchez les valeurs et Identity provider les User account valeurs 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 ?

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é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 :

1. Dans le 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 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 d’informations d’identification de mot de passe du propriétaire de la ressource pour les compte personnel s

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. Le Plateforme d’identités Microsoft prend en charge ROPC uniquement dans les locataires Microsoft Entra, et non pas dans les compte personnel s.

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 en savoir plus, consultez Plateforme d’identités Microsoft et 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 :

Option de vérification 1 : Vérifier si l’utilisateur invité du locataire de ressource est plus ancien que le compte d’utilisateur du locataire domestique

La première option de vérification consiste à comparer l’âge de l’utilisateur invité du locataire de ressource par rapport au compte d’utilisateur du locataire domestique. Vous pouvez effectuer cette vérification à l’aide de Microsoft Graph ou MSOnline 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.

MSOnline PowerShell

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

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

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.

Option de vérification 2 : Vérifier si l’ID de sécurité invité du locataire de ressource diffère de l’ID net utilisateur du locataire domestique

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

1. Dans le locataire d’accueil, récupérez la valeur de l’attribut à l’aide LiveID de l’applet Get-MsolUser de 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 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 de l’étape 1 et de l’étape 3 pour vérifier qu’elles sont différentes. Le NetID compte d’utilisateur dans le locataire d’accueil a changé lorsque le compte a été supprimé et recréé.

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

Réinitialisez l’état 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 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 l’état de l’échange 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.