AADSTS5000211: Blocked by a tenant restrictions policy (fix)

What does AADSTS5000211 mean?

Microsoft’s error code reference doesn’t list AADSTS5000211 (checked 30 October 2026).

Microsoft shows it on its page Set up tenant restrictions v2, as the result of a blocked service principal sign-in with Microsoft Graph PowerShell:

Connect-MgGraph : ClientSecretCredential authentication failed: AADSTS5000211: A tenant restrictions policy added to this request by a device or network administrator does not allow access to ‘tenant’.

Tenant restrictions v2 (TRv2) is a policy an organization sets on which other tenants may be signed in to from its network and devices. The policy travels with the request. On a corporate proxy, Microsoft says to send this header to the Microsoft sign-in domains (login.live.com, login.microsoft.com, login.microsoftonline.com, login.windows.net):

sec-Restrict-Tenant-Access-Policy: <DirectoryID>:<policyGUID>

<DirectoryID> is the tenant ID of the organization that set the policy and <policyGUID> “the object ID for your cross-tenant access policy”. So the error doesn’t come from the tenant you are signing in to. It comes from the policy of the organization whose network or device you are on.

Microsoft names three ways the policy gets added:

Where	What Microsoft says
Corporate proxy	“This header enforces your tenant restrictions v2 policy on all sign-ins on your network.”
Managed Windows devices	“Tenant restrictions are enforced upon resource access to provide data path coverage and protection against token infiltration. A corporate proxy isn’t required for policy enforcement.”
Global Secure Access	Universal tenant restrictions “tag all traffic no matter the operating system, browser, or device form factor.”

In Microsoft’s Chrome example, the browser shows a page saying internet access is blocked rather than this text. Our reading: the 5000211 string is what you see in scripts, SDKs and command-line tools.

Is it an attack?

No. The policy blocked a sign-in it was set up to block. The question is whether that sign-in was legitimate work.

Pattern	Likely meaning
A script or tool on the corporate network fails to reach a customer’s or partner’s tenant	That tenant isn’t on your TRv2 allow list. The policy needs an exception, or the work happens elsewhere.
A user tries to sign in to a personal or unknown tenant from a managed device	The policy did its job. Whether that needs a follow-up depends on what they were trying to do.
It starts for many people on the same day	A TRv2 policy was just turned on, or the header was added to the proxy.
It happens on the corporate network but not at home	The header is added by the proxy, not the device.

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

Where the row lands depends on who you are. For service principals Microsoft is explicit: “If a service principal sign-in is blocked by tenant restrictions v2, the sign-in log will only appear in the tenant that received the sign-in request. No sign-in log will be generated in the tenant where the tenant restrictions v2 policy is configured.” For user sign-ins Microsoft doesn’t say. Our reading: the organization that set the policy may see nothing of its own blocks in its own sign-in logs.

Check where 5000211 lands in your workspace:

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType == "5000211"
| summarize Rows = count() by SourceTable

If you are the tenant receiving the sign-ins, for example a customer tenant that a partner’s staff can’t reach, see whose policy blocks them. IsTenantRestricted is documented as “Indicates if a signIn is under a tenant restrictions policy or not”, and HomeTenantId as “the tenant identifier of the user initiating the sign in”:

union SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType == "5000211" or IsTenantRestricted == true
| summarize Attempts = count(), Users = dcount(UserPrincipalName), Results = make_set(ResultType, 10),
            Apps = make_set(AppDisplayName, 10)
          by HomeTenantId, IPAddress
| sort by Attempts desc

IsTenantRestricted == true also catches sign-ins that were under a policy and allowed, which is why Results is there. Not checked against real data yet.

How do I fix AADSTS5000211?

For the user: your organization’s network or device doesn’t allow sign-in to that tenant. Use an account in an allowed tenant, or ask your IT team to allow the one you need. Signing in from another network may work if the block comes from the proxy, but check your organization’s rules first.

For developers and script owners:

1. Check whether the request goes through a proxy or runs on a managed device. The error means the header or device policy was added, not that your app or secret is wrong.
2. Ask the team that owns the TRv2 policy to allow the target tenant for your app, or run the job from an environment the policy doesn’t cover, if your organization allows that.

For admins of the organization that set the policy:

1. Find where the policy is added: proxy header, Windows device policy, or Global Secure Access. The <policyGUID> in the header is the object ID of your cross-tenant access policy.
2. Review the tenant restrictions settings in that cross-tenant access policy. If the access is legitimate, allow the external tenant there. Our reading of the setup page; we have not tested a policy change.
3. If you previously set up tenant restrictions v1 to block consumer sign-ins, Microsoft says “you need to stop sending restrict-msa to login.live.com” once you move to v2.

For admins of the tenant being signed in to: you can’t fix it on your side. The block is the other organization’s policy. Tell them which tenant ID and app their people need.