Entra ID error AADSTS50020: “User account from identity provider does not exist in tenant”

You click a link to a Teams channel, a SharePoint folder or a client’s app, sign in, and instead of the content you get a sign-in error page with this text:

AADSTS50020: User account 'user@domain.com' from identity provider 'live.com' does not exist in tenant 'Contoso'
and cannot access the application ... 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 Microsoft Entra user account.

The wording varies a little between apps, and the identity provider might be live.com (a personal Microsoft account), another organisation’s tenant, or something else. The meaning is always the same: you signed in successfully somewhere, but the account you used is not known to the organisation you are trying to get into. Changing a password does not help, because nothing is wrong with the password.

Applies to: any sign-in that goes through Microsoft Entra ID (formerly Azure AD), whether the app is Teams, SharePoint, OneDrive, the Entra admin center or a custom business app. A tenant is one organisation’s own Entra directory. A guest (B2B, business-to-business, collaboration user) is someone from outside who has been invited into it.

What is going on

Microsoft describes AADSTS50020 as being returned when a guest user from an identity provider cannot sign in to a resource tenant. Put simply, there are two organisations involved: the one that owns the account (the home) and the one that owns the thing you want to open (the resource tenant). For the second organisation to let you in, your account must exist in its directory, normally as a guest created by an invitation that you have accepted. The error appears when that is not true, or when the account you are using this minute is not the one that was invited.

These are the causes Microsoft lists, in the order you are most likely to meet them:

• You signed in with the wrong account or have an old session open. Very common if you have both a personal Microsoft account and a work account, or have been in several organisations’ tenants. Microsoft’s example is a person who signs in to live.com with a different personal account from the one that was invited.
• You were never invited, or the invitation was sent to a different email address from the one you use.
• The app is limited to one organisation (a single-tenant app registration), or it sends everyone to that organisation’s own sign-in address, so people from other directories are rejected unless they are guests.
• The app requires assignment and you are not on its list of allowed users.
• Your account was deleted and re-created in your own organisation after the guest was set up. The guest in the resource tenant is then tied to the old account.
• Cached sign-in information in the OneDrive sync app, usually after a move between organisations.
• Someone signed in to the Entra admin center with a personal Microsoft account. That lands in a default Microsoft tenant that has no directory to manage. This is expected behaviour, not a fault.

Diagnosis

1. Read the error properly

Three values in the message matter: the user account, the identity provider and the tenant name. Check them against what you expected. Did you sign in with your work account to someone else’s tenant when you meant to use a personal guest account, or the other way round? Is the email address the one the invitation went to? Half of these cases end here.

2. Rule out a session problem

Paste the link into an InPrivate (Edge) or Incognito (Chrome) window, or a different browser, and sign in again. Microsoft’s own guidance for the wrong-account case is to sign out of the active session and sign in again from a new private session or another browser. If that works, the problem was an existing session using the wrong account. Use a separate browser profile for each organisation you work with, and you will see this less.

3. (Admin) Check whether the guest exists and has accepted

In the Microsoft Entra admin center of the tenant named in the error, go to Entra ID, Users, and search for the person by email address. Look at three things: whether a guest object exists at all, whether its invitation has been accepted, and which email address it is tied to. The sign-in logs on the user’s home tenant record these failures with error code 90072, which is a useful check if you have access to them.

4. (Admin) Check for the deleted-and-re-created account case

If the guest exists and was working before, ask whether the person’s own organisation deleted and re-created their account. Microsoft’s method: compare the guest’s created date in the resource tenant with the user’s created date in the home tenant. If the guest is older than the home account, that is the case. With Microsoft Graph PowerShell:

$p = @('Id', 'UserPrincipalName', 'CreatedDateTime')
Get-MgUser -UserId "user@domain.com" -Property $p | Select-Object $p

5. (Admin) Check the app

For an enterprise application, open it in the Entra admin center, choose Properties and look at Assignment required. If it is Yes, the guest must be assigned to the app directly or through a group. If you are the developer, check the app registration’s supported account types and which sign-in address the app uses, as described under the fix.

Root cause

The sign-in succeeded at the identity provider but the account is not present, or not usable, in the tenant that owns the resource. Typically a guest was never created, was created for a different email address or identity, belongs to an account that no longer exists, or the person used a different account from the one invited.

The fix

For the user

1. Sign out of Microsoft 365 everywhere, open a fresh InPrivate or Incognito window and open the link again.
2. When asked to choose, pick the work or school account if that is what the invitation was for, not the personal one with the same email address. If you do not know which account was invited, ask the person who sent the link which address they invited.
3. Look in your mailbox (and spam) for the invitation email and accept it. If it is old, ask for a new invitation.

For the admin of the tenant that owns the resource

• Not invited: invite the person as a guest. In the Entra admin center go to Users and add an external user, using the exact email address they sign in with. Microsoft’s quickstart for adding guest users covers the steps.
• Invited but wrong identity, or home account re-created: reset the redemption status. Open the guest user, choose Overview, and in the B2B collaboration tile select Reset redemption status, then Reset. You need at least the Helpdesk Administrator role. This sends a new invitation and keeps the guest’s object ID, group memberships and app assignments, which deleting and re-inviting would lose. Microsoft also documents doing this with PowerShell or the Microsoft Graph invitation API.
• Assignment required: assign the guest, or a group they are in, to the enterprise application.
• Invitation is blocked or cannot be sent: a different problem, but related. If sending an invitation says it is blocked by cross-tenant access settings, both organisations’ cross-tenant access settings (and the external collaboration settings, which can allow or block domains) must permit B2B collaboration. B2B collaboration is enabled by default, so this means somebody changed it. Do not loosen these settings just to make one guest work without checking why they were tightened.

For the developer of the app

If the app is yours and people from other organisations must sign in, check the signInAudience value in the app registration manifest. It must be AzureADMultipleOrgs, AzureADandPersonalMicrosoftAccount or PersonalMicrosoftAccount. A single-tenant registration rejects everyone outside the directory, and Microsoft says you cannot change this value later, so you would have to register the app again with the right account type. Also check which sign-in address the app uses:

https://login.microsoftonline.com/organizations   (any organisation, multitenant apps)
https://login.microsoftonline.com/common          (organisations and personal accounts)
https://login.microsoftonline.com/consumers       (personal accounts only)

An address with a specific tenant name or ID in it (https://login.microsoftonline.com/<tenant>) means authentication runs against that tenant only, so people from elsewhere must be guests in it. That is intended for many line-of-business apps. It becomes an error only when you expect people to sign in with their own organisation’s account.

Only if it is the OneDrive sync app

If the message names OneDrive SyncEngine, Microsoft attributes it to cached identities from a previous tenant, most often after a move between organisations. Microsoft’s documented fix is to remove the cached Office identities. Back up the registry first, close OneDrive and the Office apps, then delete this key:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Common\Identity

If Shared Computer Activation is on, remove the same Identity key under HKEY_USERS\<user SID>\SOFTWARE\Microsoft\Office\16.0\Common as well. Get the SID with whoami /user. If it still fails, sign out of OneDrive and delete the contents of these two folders:

%localappdata%\Microsoft\OneAuth
%localappdata%\Microsoft\IdentityCache

Microsoft’s page also points to its Office activation article for further cleanup, including stored credentials in Windows Credential Manager. Only go there if the steps above are not enough; I did not check that article for this write-up.

This registry key is only for the OneDrive sync app case. Deleting it signs you out of Office apps on that PC. Do not go clearing Credential Manager entries or removing work accounts from Windows settings as a general cure for AADSTS50020. Microsoft’s guidance for this error does not include that, and it will not create a missing guest account.

Verification

Ask the user to open the original link in a new InPrivate or Incognito window and sign in with the account that was invited. They should reach the resource without the error page. On the admin side, the guest user in the Entra admin center should show a completed invitation, and a new sign-in from that user should appear in the sign-in logs as a success.

Notes

• Since the rollout that Microsoft says finished at the end of 2025, B2B guests are redirected to their own organisation’s sign-in page to give their credentials and then returned to the host tenant. If a guest is still prompted at the wrong place, an old browser session is a more likely cause than anything in the tenant.
• In its example for re-sending an invitation, Microsoft sets the redirect address to https://myapps.microsoft.com?tenantId=<tenant-id>, so the guest lands in the right tenant after accepting. When you can, send guests a link from the tenant that owns the resource rather than one copied from your own browser session.
• To get a directory to manage with a personal Microsoft account, you cannot sign in to the Entra admin center with it. Microsoft says to create an Azure account, which generates a new tenant and makes you its Global Administrator.
• Resetting the user’s local Active Directory password, or registering a new domain name, does not fix this. The problem is guest membership in another organisation’s directory, not the user’s password.

Seeing AADSTS50020 with a detail that is not covered here? Post the error text with names and addresses removed in The Patch Panel and we will work through it. The best answer earns points on Top of the Stack.