AADSTS5000224 fix: tenant blocked for suspected fraud

What does AADSTS5000224 mean?

Microsoft’s description:

NotAllowedTenantBlockedTenantFraud: We are sorry, this resource is not available. If you are seeing this message by mistake, please contact Microsoft support.

The message the user sees says only that the resource isn’t available. The internal name says more: the tenant is not allowed because it was blocked, and the block is tagged as fraud. Microsoft doesn’t publish the criteria, how the block is decided, or how long it lasts. Its own text gives one remedy: contact Microsoft support.

In the Microsoft Q&A threads about this code, Microsoft moderators describe it as the tenant’s authentication being “temporarily disabled due to a recent security incident”, and in one thread say it is not caused by a subscription expiring. Those are forum answers, not documentation. In one thread the product group later reported that the tenant the user named was not blocked at all, and the error came from a different tenant.

Don’t confuse it with 5000225, a tenant made inaccessible because it was inactive. That one has a documented reactivation process and a 20-day deadline. For 5000224, Microsoft documents neither.

Is it an attack?

Not on you, in most cases. Which tenant is blocked decides what it means:

Pattern	Likely meaning
Every account in your own tenant, admins included, fails with 5000224	Microsoft has blocked your tenant. Contact Microsoft support.
One person, in the Azure portal only, with an old demo or trial tenant	The portal opened a blocked directory. A user on Q&A traced it to the Startup directory set to “Last accessed”, pointing at an expired demo tenant. Their own fix, not Microsoft guidance, and a Microsoft moderator in the same thread said expiry was not the cause.
Your users, in your logs, failing for a resource or app in another tenant	Our interpretation: they tried to reach a tenant Microsoft flagged for fraud. Find out which tenant and app, and how the user got there (a link, a guest invitation, an app consent).

The third row is why this page rates the signal medium rather than low. Microsoft doesn’t document what a fraud block covers, so the link to phishing or abuse is our reading, not a fact.

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

Microsoft doesn’t document whether 5000224 is logged, or in which tenant. If your own tenant is blocked, you probably can’t sign in to read its logs at all. For the other case, check whether your workspace has rows:

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

Which tenants and apps your users were trying to reach. Microsoft documents HomeTenantId as “the tenant identifier of the user initiating the sign in” and ResourceTenantId as “the tenant identifier of the resource referenced in the sign in”:

union SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType == "5000224"
| summarize Attempts = count(), Users = make_set(UserPrincipalName, 20), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
          by HomeTenantId, ResourceTenantId, AppOwnerTenantId, AppDisplayName, AppId, CrossTenantAccessType
| sort by Attempts desc

A foreign ResourceTenantId or AppOwnerTenantId in the result is the lead. Check what else your users did with that tenant ID or app ID in the same period. Any row is worth a look; there is no baseline to set a threshold against. ResultType is a string column, so compare it with "5000224", not 5000224.

How do I fix AADSTS5000224?

For the user: you can’t fix it. If it is your organization’s tenant, tell your IT team. If you see it in the Azure portal and you have more than one directory, one user reports that signing in directly to their own tenant (https://portal.azure.com/<your-tenant-ID>) and changing the startup directory got them past it.

For admins of the blocked tenant:

1. Microsoft documents no admin setting that lifts this block. The error text sends you to Microsoft support, and that is the only route.
2. The normal route is a support request in the Microsoft Entra admin center, as at least a Service Support Administrator. If any admin account can still sign in, use it.
3. Microsoft’s support page also lists two other routes: a request through your Azure support plan, or Microsoft Support for business if you are not an Azure customer. Microsoft says support “is available online and by phone for Microsoft paid and trial subscriptions”. It doesn’t document a route specific to blocked tenants.
4. Have the tenant ID, the full error, the correlation ID and the timestamp from the error page ready. Microsoft moderators on Q&A asked for the tenant’s onmicrosoft.com domain and the Global Administrator’s UPN, sent privately.
5. Expect it to take time. One user on Q&A reported a case running for about seven weeks without a public resolution.

For admins who see it for another tenant: you can’t and shouldn’t fix it. Run the second query, identify the tenant and app, and decide whether to block that app or domain in your own tenant.