AADSTS50020 User Account Does Not Exist in Tenant: A Read-First Guest, B2B, and Wrong-Tenant Triage

Helpdesk: "Our auditor from the partner firm can't open the SharePoint site we shared. She gets a red page that says AADSTS50020, user account does not exist in tenant." Ten minutes later a second ticket: a new hire's Outlook on her Mac throws the same code, and her account works fine in a browser. Someone has already deleted the auditor's guest account "so we can re-invite her clean," and someone else is asking whether to turn off the Conditional Access policy for guests.

Don't delete or re-invite anything yet. AADSTS50020 is a lookup failure, not a policy block: Microsoft Entra ID authenticated an identity, then went looking for a matching user object in the tenant that owns the app, and found none. It only resolves when the whole chain holds: the identity in the error is the one the user meant to use → the request went to the tenant you think it did (URL, domain hint, app, cached session) → a guest object for that identity exists and is enabled → that object was redeemed with the same identity provider the user is signing in with now (Entra ID, Microsoft account, email one-time passcode, Google, SAML/WS-Fed) → both tenants live in clouds that are allowed to collaborate → the app accepts accounts from other tenants and this user is allowed in → only then do cross-tenant access settings and Conditional Access get a say. Microsoft lists eight causes for this one code, and the message text usually tells you which one you have.

If the sign-in gets past account lookup and is then denied by policy, that's AADSTS53003; read the AADSTS53003 Conditional Access triage. If the error names a device ("your organization has disabled this device"), see the AADSTS135011 device triage. If a Windows device simply won't give the user SSO, start with AzureAdPrt: NO. This post covers AADSTS50020 for guest (B2B collaboration) users, personal Microsoft accounts, and people signing in to the wrong tenant, read-only first.

TL;DR

• Read the three values in the message before anything else: User account '{email}', from identity provider '{idp}', does not exist in tenant '{tenant}'. Microsoft's fix for "wrong tenant" is literally: check whether that account and IdP are the combination you expected. A live.com IdP means a personal Microsoft account; a different work account means a cached session.
• Grab the Correlation ID, Trace ID, and timestamp from the error page. Microsoft says the home tenant logs the same failure as 90072.
• Find the guest object in the resource tenant. No object = never invited (or deleted). externalUserState = PendingAcceptance = invitation not redeemed. identities shows which IdP it was redeemed with: if that differs from what the user is signing in with now, that's your mismatch.
• Don't delete and re-invite. Microsoft's fix for a guest whose home account was re-created, who changed email, or who needs a different IdP is Reset redemption status, which keeps the object ID, group memberships, and app assignments.
• App causes are real: a single-tenant registration, the wrong authority endpoint, ROPC with personal accounts, or Assignment required can all produce 50020, per Microsoft.
• Conditional Access comes last. CA can't evaluate a user object that doesn't exist. Turning off a guest CA policy doesn't fix 50020; it only removes protection.

Where in the chain did it break?

Write down the exact error text (copy it, don't paraphrase), the Correlation ID, Trace ID, and Timestamp from the error page, the app or URL the user opened, the browser or client (and whether it was private/InPrivate), and the account the user thinks they used.

Step 1: Decode the exact message (read-only)

Microsoft's error-code reference gives 50020 the internal name UserUnauthorized and this message:

User account '{email}' from identity provider '{idp}' does not exist in tenant '{tenant}' and cannot access the application '{appid}'({appName}) in that tenant. This 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.

Every placeholder is a clue. Paste the text from the ticket into a quick parser so nobody misreads a domain:

$msg = @'
AADSTS50020: User account '[email protected]' from identity provider 'live.com' does not exist in tenant 'Contoso' and cannot access the application '00000003-0000-0ff1-ce00-000000000000'(Office 365 SharePoint Online) in that tenant.
'@

$pattern = "User account '(?<acct>[^']+)' from identity provider '(?<idp>[^']+)' does not exist in tenant '(?<tenant>[^']+)'(?: and cannot access the application '(?<app>[^']+)')?"
if ($msg -match $pattern) {
  [pscustomobject]@{
    Account  = $Matches.acct
    IdP      = $Matches.idp
    Tenant   = $Matches.tenant
    AppId    = $Matches.app
  }
}

If the ticket says the guest is [email protected] and the error says [email protected], it's a session problem (Step 2), not a directory problem. If Tenant isn't the organization that shared the resource, the link or app sent the user somewhere else. If only the AppId app fails and My Apps works, go to Step 6.

The codes that look like 50020 but aren't

Microsoft notes error codes and messages can change, and points to https://login.microsoftonline.com/error?code=50020 for the current description.

Step 2: Which tenant is the user actually hitting?

Two of Microsoft's causes need nothing changed in the directory. A personal Microsoft account at the Entra admin center lands in the Microsoft Services tenant, which has no directory for that person; Microsoft calls this expected, and the fix is a real tenant (for example an Azure account signup), not a guest invite. A wrong session means the browser already holds a different personal account, or the work account when the guest invite is on a personal one (or the reverse); Microsoft's fix is to sign out and use a new private session or another browser.

Use a tenant-specific link

Guests can use common URLs such as https://myapps.microsoft.com by choosing Sign-in options > Sign in to an organization and typing your domain. A direct link with tenant context skips that step and authenticates in the right tenant:

If the user's link had no tenant in it, test with a tenant-specific link in a private window before touching anything else.

Map tenant IDs and domains (read-only)

When the IdP in the error is a tenant GUID, or the tenant name looks unfamiliar, resolve it:

# Anonymous OpenID Connect metadata: which tenant answers for a domain?
$domain = 'fabrikam.com'
(Invoke-RestMethod "https://login.microsoftonline.com/$domain/v2.0/.well-known/openid-configuration").issuer

# Graph: tenant ID <-> default domain and display name (CrossTenantInformation.ReadBasic.All, no admin role needed)
Connect-MgGraph -Scopes 'CrossTenantInformation.ReadBasic.All'
Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/v1.0/tenantRelationships/findTenantInformationByDomainName(domainName='$domain')"

$tenantId = '00000000-0000-0000-0000-000000000000'   # GUID from the error's identity provider URL
Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/v1.0/tenantRelationships/findTenantInformationByTenantId(tenantId='$tenantId')"

Read both tenants' sign-in logs

Microsoft says a B2B sign-in creates a log entry in both the home tenant and the resource tenant, with tenant names and IDs for each. The sign-in log tracks a Home tenant and a Resource tenant, and Microsoft's tip is to filter for entries where they differ. The Cross-tenant access type field shows b2bCollaboration for guest sign-ins.

The cross-tenant fields (homeTenantId, resourceTenantId, crossTenantAccessType) are on the beta sign-in resource in Graph, not v1.0. A read-only pull (sign-in log API access generally needs Entra ID P1/P2):

Connect-MgGraph -Scopes 'AuditLog.Read.All'
$since = (Get-Date).ToUniversalTime().AddDays(-2).ToString('yyyy-MM-ddTHH:mm:ssZ')

# Resource tenant: 50020; home tenant: look for 90072 instead
Get-MgBetaAuditLogSignIn -Filter "createdDateTime ge $since and (status/errorCode eq 50020 or status/errorCode eq 90072)" -Top 50 |
  Select-Object CreatedDateTime, UserPrincipalName, AppDisplayName, CrossTenantAccessType,
    HomeTenantId, ResourceTenantId, CorrelationId,
    @{n = 'Code';   e = { $_.Status.ErrorCode }},
    @{n = 'Reason'; e = { $_.Status.FailureReason }}

Ask the partner's admin to search their log by your Correlation ID and timestamp. An empty result on your side isn't proof nothing happened: a user with no object in your directory may only show up in the home tenant's log (inference from Microsoft's 90072 note).

Desktop and mobile clients replay cached accounts

A private window doesn't help Outlook, Teams, or the Microsoft 365 apps, which keep their own token caches. "Works in the browser, 50020 in Outlook on the Mac" is usually the app replaying a cached account from an old or different tenant. Read the account the app shows in its own settings first. Removing and re-adding the account (Outlook for iOS/Android) or clearing Office identity entries from the macOS Keychain is what Microsoft Q&A answers recommend. That's Q&A guidance, not a Learn article, and it signs the user out of every Office app, so treat it as a change.

Step 3: Find the guest object and read its state (read-only)

Microsoft's guest-properties page describes what an invited user looks like in the resource tenant: a user object with a UPN like jane_fabrikam.com#EXT#@contoso.onmicrosoft.com, userType Guest (or Member for external members), and no credentials of its own. Find it by email, because the UPN carries the #EXT# mangling:

Connect-MgGraph -Scopes 'User.Read.All'
$email = '[email protected]'
$props = 'id', 'displayName', 'userPrincipalName', 'mail', 'otherMails', 'userType', 'externalUserState',
         'externalUserStateChangeDateTime', 'creationType', 'accountEnabled', 'createdDateTime', 'identities'

Get-MgUser -Filter "mail eq '$email' or otherMails/any(x:x eq '$email')" -Property $props `
    -ConsistencyLevel eventual -CountVariable hits |
  Select-Object Id, DisplayName, UserPrincipalName, UserType, ExternalUserState, ExternalUserStateChangeDateTime,
    CreationType, AccountEnabled, CreatedDateTime,
    @{n = 'Identities'; e = { ($_.Identities | ForEach-Object { "$($_.SignInType):$($_.Issuer)" }) -join '; ' }}

# Deleted in the last 30 days? (read-only)
Get-MgDirectoryDeletedItemAsUser -All | Where-Object { $_.Mail -eq $email -or $_.UserPrincipalName -like "*$($email -replace '@','_')*" } |
  Select-Object Id, DisplayName, UserPrincipalName, DeletedDateTime

In the admin center: Entra ID > Users > the user > Overview (B2B collaboration tile).

For cause 8, Microsoft's check is the same createdDateTime read on both sides: ask the partner's admin for their user's creation date. For contact conflicts, Microsoft's read is Get-MgContact -All | Where-Object { $_.Mail -match '[email protected]' }.

Step 4: Which identity provider did the guest redeem with?

This is where most "it worked last month" cases live. Microsoft's default redemption order when a guest selects Accept invitation:

1. User-based discovery: does the user exist in a managed Entra tenant? (Unmanaged accounts can't be used to redeem.) If the UPN matches both an Entra account and a personal Microsoft account, the user is asked to choose.
2. SAML/WS-Fed federation, if the admin configured it for the user's domain.
3. Google federation, if configured, for gmail.com and googlemail.com.
4. An existing personal Microsoft account.
5. Sign-in at the home directory's IdP, once identified.
6. If no home directory is found and email one-time passcode is on, a passcode is sent to the invited email.
7. If OTP is off, the user is prompted to create a Microsoft account with the invited email.
8. Consent (privacy statement, then terms of use if configured).

The provider that won the first redemption is the one the guest object trusts. Three documented behaviors turn that into 50020 later:

Read the tenant's settings (read-only):

Connect-MgGraph -Scopes 'Policy.Read.All'

# Email one-time passcode for guests (default / enabled / disabled)
(Invoke-MgGraphRequest -Method GET -Uri 'https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/email').allowExternalIdToUseEmailOtp

To keep new guests off personal accounts, Microsoft's option is the Redemption order in cross-tenant access settings: turn off Microsoft accounts as a fallback (OTP must then stay on). Existing MSA guests keep using MSA until you reset their redemption status. Changing the redemption order needs Entra ID P1.

Step 5: Cross-cloud, sovereign, and wrong-directory cases

Read your side (read-only):

Connect-MgGraph -Scopes 'Policy.Read.All'
$ctap = Invoke-MgGraphRequest -Method GET -Uri 'https://graph.microsoft.com/v1.0/policies/crossTenantAccessPolicy'
$ctap.allowedCloudEndpoints        # empty by default; microsoftonline.us = Azure Government, partner.microsoftonline.cn = 21Vianet

(Invoke-MgGraphRequest -Method GET -Uri 'https://graph.microsoft.com/v1.0/policies/crossTenantAccessPolicy/partners').value.tenantId   # partners you've added

Step 6: Does the app accept this account at all?

If the guest object is healthy and only one app fails, suspect the app. Microsoft lists four app-side causes.

Single-tenant registration. If the app registration's supported account type is single tenant, users from other directories can't sign in. Check signInAudience:

Microsoft says you can't change signInAudience in the manifest for this case; re-create the registration with the right account type.

Wrong authority URL. A multitenant app that authenticates against a tenant-specific https://login.microsoftonline.com/<tenant> expects every user to exist in that tenant as a guest. Microsoft's table:

ROPC with personal accounts. Microsoft supports the resource owner password credentials flow only within Entra tenants; personal accounts, including MSA guests, get 50020. Developer fix: switch flows.

Assignment required. Microsoft's 50020 article says an enterprise app with Assignment required = Yes returns 50020 when the user isn't assigned. Microsoft's error-code reference maps "not assigned to a role for the app" to 50105, so read the code you actually see; both point to the same check. Remember Microsoft's limits: group-based assignment needs Entra ID P1/P2, and assignment doesn't cascade to nested groups.

Read the app and the guest's assignments (read-only):

Connect-MgGraph -Scopes 'Application.Read.All', 'User.Read.All'
$appId   = '00000000-0000-0000-0000-000000000000'   # the application '{appid}' from the error
$guestId = '<guest object id from Step 3>'

$sp = Get-MgServicePrincipal -Filter "appId eq '$appId'" -Property id, displayName, appId, appOwnerOrganizationId,
        appRoleAssignmentRequired, accountEnabled, signInAudience
$sp | Select-Object DisplayName, AppId, AppOwnerOrganizationId, AppRoleAssignmentRequired, AccountEnabled, SignInAudience

# Is the guest assigned? (direct assignments; check groups assigned to the app too)
Get-MgUserAppRoleAssignment -UserId $guestId -All | Where-Object ResourceId -eq $sp.Id |
  Select-Object PrincipalDisplayName, ResourceDisplayName, AppRoleId, CreatedDateTime

Step 7: Only now, cross-tenant access and Conditional Access

Conditional Access evaluates a user. With 50020, there's no user in your tenant to evaluate, which is why disabling a CA policy doesn't change the result. Once the guest object exists and is redeemed, the next layer is policy, and it has its own codes:

Three Microsoft notes that prevent the next guest ticket: you currently can't apply authentication strength to email OTP guests (use Require MFA); if you trust external MFA, exclude external users from the ID Protection MFA registration policy; and if you block all apps in cross-tenant access, allow Microsoft App Access Panel (0000000c-0000-0000-c000-000000000000) and Terms of Use (d52792f4-ba38-424d-8140-ada5b883f293) so guests can register MFA and accept terms (Microsoft says the inbound side currently needs Graph).

When you review guest policies, keep the break-glass exclusions straight; the break-glass accounts post covers which policies exclude those accounts and how they still meet mandatory MFA. For reading which policy blocked a guest once the account exists, use the AADSTS53003 triage.

Step 8: Verify cleanly

Private window, tenant-specific link (https://myapps.microsoft.com/<your verified domain>), and the exact account in the guest's identities. If that works, fix the link or session the user had. If it fails, compare the new message's account and IdP with Step 3. Test the specific app only after My Apps works.

Timing: when "still broken" is just waiting

When a change is justified

Roles Microsoft lists: Guest Inviter or User Administrator to invite; Helpdesk Administrator or User Administrator to reset redemption; at least Security Administrator for cross-tenant access settings (P1 for trust, redemption order, and scoping). Cross-tenant changes are audited under CrossTenantAccessSettings.

FAQ

What does AADSTS50020 mean?
Microsoft Entra ID signed in an identity, then found no matching user in the tenant that owns the app. The message names the account, identity provider, tenant, and app. Microsoft lists eight causes: personal account at the admin center, single-tenant app, wrong endpoint, wrong tenant or session, guest never invited, assignment required, ROPC with personal accounts, and a home account re-created after the guest redeemed.

How do I fix AADSTS50020 for a guest user?
Read the account and IdP in the error. If they aren't what the guest should use, have them sign out and try a private window with a tenant-specific link such as https://myapps.microsoft.com/yourdomain.com. If they are, find the guest object: no object means invite them; PendingAcceptance means they haven't redeemed; a mismatch between identities and today's sign-in method, or a re-created home account, means reset redemption status. That keeps the object ID, groups, and app assignments. Don't delete and re-invite.

Why does AADSTS50020 mention live.com?
live.com is the identity provider for personal Microsoft accounts. Either the user is signed in with a personal account the browser remembered, or the guest originally redeemed with a Microsoft account (for example one created on their work email) and is now using a different account. Microsoft's fix for the first is a new private session. For the second, reset redemption. To stop new guests from redeeming with personal accounts, turn off Microsoft accounts as a fallback in the redemption order (that needs Entra ID P1 and email OTP left on).

Why do I get AADSTS50020 in Outlook on a Mac or in Outlook mobile when the browser works?
The app is usually replaying a cached account, often from an old tenant after a migration. Compare the account the app uses with the one in the error, then remove and re-add the account in the app. On macOS, Microsoft Q&A answers recommend clearing the Office identity and ADAL/MSAL entries in Keychain Access; that's Q&A guidance, not a Learn article, and it signs the user out of all Office apps.

What's the difference between AADSTS50020, AADSTS50034, and AADSTS53003?
50020: an authenticated identity has no user object in the resource tenant (guest, personal account, or wrong tenant). 50034: the typed username doesn't exist in the tenant. 53003: the account was found and Conditional Access blocked the token. The home tenant logs a 50020 failure as 90072. Fix 50020 in the directory and redemption flow; check Conditional Access only once the code changes to 53003.

Related posts

• AADSTS53003 Blocked by Conditional Access (the account exists; a policy blocked it)
• Your organization has disabled this device (AADSTS135011) (device object, not user object)
• AzureAdPrt: NO in dsregcmd /status (Windows SSO for your own users)
• Hybrid Azure AD Join Pending (device registration before CA can trust it)
• Entra ID break-glass accounts after mandatory MFA (emergency access that survives a bad policy change)

Free checklist

Once guests can sign in, the next request is usually "require MFA for guests" or "block guests from everything except SharePoint," and that's where well-meant Conditional Access changes lock people out. Before you enforce, the free Conditional Access pre-enforcement checklist keeps break-glass accounts, pilot groups, and report-only review on one page:

👉 https://cashflow4375.gumroad.com/l/ujkqxb?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=aadsts50020-identity-provider-does-not-exist

If you want a starting policy set and the exclusions pattern written down before guest policies grow, the Entra ID Conditional Access Starter Pack has a starter policy library, a break-glass and exclusions playbook, and read-only Graph exports for policies and named locations: https://cashflow4375.gumroad.com/l/nhuyrc?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=aadsts50020-identity-provider-does-not-exist

Admin Pack Studio; not affiliated with Microsoft. Steps 1–8 only read: string parsing, OpenID metadata, `Get-Mg cmdlets, and GET-only Graph requests. Inviting, resending, restoring, resetting redemption status, editing mail/otherMails`, changing OTP or redemption-order settings, cross-tenant access or Microsoft cloud settings, app assignments, and clearing client caches are deliberate changes. Make them one user or one partner at a time, and check current Microsoft Learn for portal labels and role names.*