AADSTS500021 fix: tenant blocked by tenant restrictions

What does AADSTS500021 mean?

Microsoft’s description:

Access to ‘{tenant}’ tenant is denied. AADSTS500021 indicates that the tenant restriction feature is configured and that the user is trying to access a tenant that isn’t in the list of allowed tenants specified in the header Restrict-Access-To-Tenant. For more information, see Use tenant restrictions to manage access to SaaS cloud applications.

Microsoft gives this code no name. The block comes from the network, not from the tenant the user is signing in to.

Tenant restrictions (the original version, which Microsoft’s v2 page calls “Tenant restrictions v1”) work like this. A corporate proxy that does TLS inspection adds two headers to every request to login.microsoftonline.com, login.microsoft.com and login.windows.net:

• Restrict-Access-To-Tenants: “a comma-separated list of tenants you want to allow users to access”.
• Restrict-Access-Context: “a single directory ID, declaring which tenant is setting the tenant restrictions”.

If the tenant the user tries to reach isn’t on the list, sign-in fails. Microsoft’s tenant restrictions page says the user “sees an access denial message” about “a resource that belongs to an organization unapproved by your IT department.” Microsoft’s error description writes the header as Restrict-Access-To-Tenant; the tenant restrictions page spells it Restrict-Access-To-Tenants, with an s. Use the page’s spelling on your proxy.

v1 or v2?

Be precise here, because the two versions use different headers and, as far as Microsoft documents, different codes.

	Tenant restrictions v1	Tenant restrictions v2
Where the allow list lives	In the proxy header itself	“moved to the server-side cloud policy” (cross-tenant access settings)
Header	Restrict-Access-To-Tenants + Restrict-Access-Context	sec-Restrict-Tenant-Access-Policy: <DirectoryID>:<policyGUID>
Enforcement	Corporate proxy only	Proxy, Windows devices (Group Policy) or Global Secure Access
Protects	Authentication plane	Authentication plane, plus data plane with device signalling
Code Microsoft shows	500021 (error reference)	5000211 (v2 setup page)

So: 500021 points at a v1 allow list on a proxy. If the message says “A tenant restrictions policy added to this request by a device or network administrator”, you are looking at v2 and 5000211. Microsoft notes that migrating from v1 to v2 “is a one-time operation”.

Is it an attack?

No. It is a block working as designed. Tenant restrictions exist to stop users signing in to tenants their organisation hasn’t approved, for example a personal or competitor tenant used to move data out.

Pattern	Likely meaning
A guest from a customer or partner organisation gets 500021 on your app	Their IT runs tenant restrictions and your tenant isn’t on their list. Users report exactly this in Microsoft Q&A, including for Power BI shared with external customers.
Your own users get 500021 when opening a partner’s app	Your proxy doesn’t list the partner’s tenant. Add it if the access is approved.
Your own users get 500021 for a tenant nobody recognises	The control stopped a sign-in to an unapproved tenant. Our interpretation: worth asking the user why, because this is the data-leak path tenant restrictions are meant to close.
500021 started for many users at once	Someone changed the proxy’s allow list, or traffic moved to a proxy with a different list.

How do I find it in my logs (KQL)?

Microsoft gives the admin of the Restrict-Access-Context tenant a dedicated report: Entra ID > Overview > Tenant restrictions. It shows “sign-ins blocked because of the tenant restrictions policy, including the identity used and the target directory ID.” Microsoft adds that “Sign-ins are included if the tenant setting the restriction is either the user tenant or resource tenant for the sign-in”, and that identities from other tenants are masked.

Microsoft doesn’t document which Log Analytics table 500021 rows land in, or in which tenant’s workspace. Check yours:

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(7d)
| where ResultType == "500021"
| summarize Rows = count(), Users = dcount(UserPrincipalName) by SourceTable

Which target tenants are being blocked, for whom, and from which egress IPs (each egress IP points at a proxy):

SigninLogs
| where TimeGenerated > ago(30d)
| where ResultType == "500021"
| summarize Rows = count(),
            Users = dcount(UserPrincipalName),
            Apps = make_set(AppDisplayName, 5),
            EgressIPs = make_set(IPAddress, 10)
          by HomeTenantId, ResourceTenantId, IsTenantRestricted
| sort by Users desc

The IsTenantRestricted column is documented as “Indicates if a signIn is under a tenant restrictions policy or not.” Whether Microsoft sets it on 500021 rows isn’t documented. If it does, this finds every sign-in under a restrictions policy, blocked or not:

SigninLogs
| where TimeGenerated > ago(7d)
| where IsTenantRestricted == true
| summarize Rows = count(), Users = dcount(UserPrincipalName) by ResultType, ResourceTenantId
| sort by Rows desc

ResultType is a string column, so compare it with "500021".

How does Conditional Access affect it?

• 500021 is not a Conditional Access block. The proxy header decides it, whatever the target tenant’s policies say.
• Don’t confuse it with 53003, which is a Conditional Access block in the target tenant. The owner of the fix is different.
• Cross-tenant access settings for B2B collaboration are also a different control. One Q&A answer suggests changing outbound B2B settings for this error. Microsoft’s description of 500021 points only at the v1 header, so start there.

How do I fix AADSTS500021?

For the user: the network you are on only allows sign-in to approved tenants. Ask your own IT team to allow the tenant you need. If you are a guest on someone else’s app, the app’s owner can’t fix this for you.

For app owners and B2B hosts: you can’t fix this from your tenant. Tell the guest’s IT team your tenant ID or verified domain and ask them to add it to their tenant restrictions list. Users in Microsoft Q&A report this is the step that’s missing.

For admins who run the proxy:

1. Find the proxy rule that adds Restrict-Access-To-Tenants to traffic for the Microsoft sign-in hosts.
2. Add the target tenant. Microsoft says “Any domain that is registered with a tenant can be used to identify the tenant in this list, and the directory ID itself.” Microsoft’s example: Restrict-Access-To-Tenants: contoso.com,fabrikam.onmicrosoft.com,aaaabbbb-0000-cccc-1111-dddd2222eeee.
3. Keep Restrict-Access-Context set to your own directory ID. Microsoft warns that with any other ID “the sign-in logs appear in someone else’s tenant, with all personal information removed.”
4. Before you allow a tenant nobody asked for, check why users tried to reach it.
5. If you are moving to tenant restrictions v2, the allow list moves into cross-tenant access settings and the v1 header should be removed from the proxy. Blocks then show as 5000211.