Error AADSTS50020 – User account from identity provider does not exist in tenant

This article helps you troubleshoot error code AADSTS50020 that’s returned if a guest user from an identity provider (IdP) can’t sign in to a resource tenant in Azure Active Directory (Azure AD).

When a guest user tries to access an application or resource in the resource tenant, the sign-in fails, and the following error message is displayed:

AADSTS50020: User account ‘user@domain.com’ from identity provider {IdentityProviderURL} does not exist in tenant {ResourceTenantName}.

When an administrator reviews the sign-in logs on the home tenant, a “90072” error code entry indicates a sign-in failure. The error message states:

User account {email} from identity provider {idp} does not exist in tenant {tenant} and cannot access the application {appId}({appName}) in that tenant. The account needs to be added as an external user in the tenant first. Sign out and sign in again with a different Azure Active Directory user account.

If your app registration is set to a single-tenant account type, users from other directories or identity providers can’t sign in to that application.

To make sure that your app registration isn’t a single-tenant account type, perform the following steps:

1. In the Azure portal, search for and select App registrations.
2. Select the name of your app registration.
3. In the sidebar, select Manifest.
4. In the JSON code, find the signInAudience setting.
5. Check whether the setting contains one of the following values:
   • AzureADandPersonalMicrosoftAccount
   • AzureADMultipleOrgs
   • PersonalMicrosoftAccount

   If the signInAudience setting doesn’t contain one of these values, re-create the app registration by having the correct account type selected. You currently can’t change signInAudience in the manifest.

Your authentication call must target a URL that matches your selection if your app registration’s supported account type was set to one of the following values:

• Accounts in any organizational directory (Any Azure AD directory – Multitenant)
• Accounts in any organizational directory (Any Azure AD directory – Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox)
• Personal Microsoft accounts only

If you use https://login.microsoftonline.com/<YourTenantNameOrID>, users from other organizations can’t access the application. You have to add these users as guests in the tenant that’s specified in the request. In that case, the authentication is expected to be run on your tenant only. This scenario causes the sign-in error if you expect users to sign in by using federation with another tenant or identity provider.

Use the corresponding sign-in URL for the specific application type, as listed in the following table:

In your application code, apply this URL value in the Authority setting. For more information about Authority.

When users try to access your application, either they’re sent a direct link to the application, or they try to gain access through https://myapps.microsoft.com. In either situation, users are redirected to sign in to the application. In some cases, the user might already have an active session that uses a different personal account than the one that’s intended to be used. Or they have a session that uses their organization account although they intended to use a personal guest account (or vice versa).

To make sure that this scenario is the issue, look for the User account and Identity provider values in the error message. Do those values match the expected combination or not? For example, did a user sign in by using their organization account to your tenant instead of their home tenant? Or did a user sign in to the live.com identity provider by using a different personal account than the one that was already invited?

Instruct the user to open a new in-private browser session or have the user try to access from a different browser. In this case, users must sign out from their active session, and then try to sign in again.

The guest user who tried to sign in was not invited to the tenant.

Make sure that you follow the steps in Quickstart: Add guest users to your directory in the Azure portal to invite the guest user.

If your application is an enterprise application that requires user assignment, error AADSTS50020 occurs if the user isn’t on the list of allowed users who are assigned access to the application. To check whether your enterprise application requires user assignment:

1. In the Azure portal, search for and select Enterprise applications.
2. Select your enterprise application.
3. In the sidebar, select Properties.
4. Check whether the Assignment required option is set to Yes.

Use one of the following options to assign access to users:

• To individually assign the user access to the application, see Assign a user account to an enterprise application.
• To assign users if they’re a member of an assigned group or a dynamic group, see Manage access to an application.

If a user tries to use the resource owner password credentials (ROPC) flow for personal accounts, error AADSTS50020 occurs. The Microsoft identity platform supports ROPC only within Azure AD tenants, not personal accounts.

Use a tenant-specific endpoint (https://login.microsoftonline.com/<TenantIDOrName>) or the organization’s endpoint. Personal accounts that are invited to an Azure AD tenant can’t use ROPC. For more information,see Microsoft identity platform and OAuth 2.0 Resource Owner Password Credentials.

Error AADSTS50020 might occur if the name of a guest user who was deleted in a resource tenant is re-created by the administrator of the home tenant. To verify that the guest user account in the resource tenant isn’t associated with a user account in the home tenant, use one of the following options:

The first verification option involves comparing the age of the resource tenant’s guest user against the home tenant’s user account. You can make this verification by using Microsoft Graph or MSOnline PowerShell.

Issue a request to the MS Graph API to review the user creation date, as follows:

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

Then, check the creation date of the guest user in the resource tenant against the creation date of the user account in the home tenant. The scenario is confirmed if the guest user was created before the home tenant’s user account was created.

Run the Get-MsolUser PowerShell cmdlet to review the user creation date, as follows:

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

Then, check the creation date of the guest user in the resource tenant against the creation date of the user account in the home tenant. The scenario is confirmed if the guest user was created before the home tenant’s user account was created.

When a guest user accepts an invitation, the user’s LiveID attribute (the unique sign-in ID of the user) is stored within AlternativeSecurityIds in the key attribute. Because the user account was deleted and created in the home tenant, the NetID value for the account will have changed for the user in the home tenant. Compare the NetID value of the user account in the home tenant against the key value that’s stored within AlternativeSecurityIds of the guest account in the resource tenant, as follows:

1. In the home tenant, retrieve the value of the LiveID attribute using the Get-MsolUser PowerShell cmdlet:
   Azure PowerShell

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

2. In the resource tenant, convert the value of the key attribute within AlternativeSecurityIds to a base64-encoded string:

   Azure PowerShell

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

3. Convert the base64-encoded string to a hexadecimal value by using an online converter (such as base64.guru).
4. Compare the values from step 1 and step 3 to verify that they’re different. The NetID of the user account in the home tenant changed when the account was deleted and re-created.

Reset the redemption status of the guest user account in the resource tenant. Then, you can keep the guest user object without having to delete and then re-create the guest account. You can reset the redemption status by using the Azure portal, Azure PowerShell, or the Microsoft Graph API. For instructions, see Reset redemption status for a guest user.

So, that’s all in this blog. I will meet you soon with next stuff. Have a nice day!!!

Guys please don’t forget to like and share the post. Also join our WindowsTechno Community and where you can post your queries/doubts and our experts will address them.

You can also share the feedback on below windows techno email id.

If you have any questions, feel free to contact us on admin@windowstechno.com also follow us on facebook@windowstechno to get updates about new blog posts.