AADSTS500571: The guest user account is disabled (fix)

What does AADSTS500571 mean?

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

Microsoft documents it in a troubleshooting article:

When a guest user tries to sign in to an application that’s integrated into Microsoft Entra ID, they receive an “AADSTS500571” error message (“The guest user account is disabled”).

The cause, in Microsoft’s words: “The guest user object is disabled on the resource tenant.”

A user posting on Microsoft Tech Community quotes the full string as returned to Visual Studio:

V2Error: invalid_grant AADSTS500571: The guest user account is disabled

Background: when you invite a guest, Microsoft says “an account is created in your tenant. This account doesn’t have any credentials associated with it because authentication is performed by the guest user’s identity provider.” So there are two accounts. The one in the user’s home tenant can be enabled and working while the guest object in the resource tenant is disabled. 500571 is about the second one. If the account in the user’s own tenant were disabled, that would be 50057.

Is it an attack?

Usually not. A disabled guest object is a deliberate block by the resource tenant, or a mistake.

Pattern	Likely meaning
A partner user who was offboarded or whose project ended	The guest was disabled on purpose. Access is blocked as intended.
Many guests from one partner disabled on the same day	A bulk clean-up, an access review, or a script. Check the audit log for who did it.
A user who says “I’m not a guest, I signed in with my own account”	An admin on Q&A reports this for a Teams user who said he signed in with his own account. Our reading: the app tried to reach another tenant where the user has a disabled guest object, for example a tenant switch in Teams or a link from a partner.
Repeated 500571 for a guest who was disabled during an incident	Something still holds that person’s sign-in and keeps trying. Worth a look. Our interpretation, not a documented pattern.

Our reading: the block works. A failed sign-in with 500571 means no token was issued for that guest in your tenant.

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

Microsoft doesn’t document which sign-in table 500571 is logged in. Check where it lands:

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

Which guests, from which home tenants, on which apps. HomeTenantId is documented as “the tenant identifier of the user initiating the sign in” and UserType as identifying “whether the user is a member or guest in the tenant”:

SigninLogs
| where TimeGenerated > ago(30d)
| where ResultType == "500571"
| summarize Attempts = count(), LastSeen = max(TimeGenerated), Apps = make_set(AppDisplayName, 10)
          by UserPrincipalName, UserId, HomeTenantId, UserType
| sort by Attempts desc

Who disabled the guest, and when. Disable account and Update user are both activity names in Microsoft’s audit activity list. Which one a disable produces depends on how it was done, so search for both:

AuditLogs
| where TimeGenerated > ago(90d)
| where ActivityDisplayName in ("Disable account", "Update user")
| extend TargetUpn = tostring(TargetResources[0].userPrincipalName),
         TargetId = tostring(TargetResources[0].id),
         Actor = coalesce(tostring(InitiatedBy.user.userPrincipalName), tostring(InitiatedBy.app.displayName))
| where TargetUpn has "#EXT#" or TargetId == "<guest object id>"
| project TimeGenerated, ActivityDisplayName, Actor, TargetUpn, TargetId, Result
| sort by TimeGenerated desc

The #EXT# filter is a shortcut for guest UPNs. Microsoft’s B2B user properties page says a guest’s UPN contains #EXT#. Put the UserId from the second query in place of <guest object id> to be exact. Update user also covers changes that have nothing to do with sign-in, so read the modified properties in TargetResources before drawing a conclusion.

How do I fix AADSTS500571?

For the user: your own organization can’t fix this. The block is in the other organization’s tenant. Contact whoever invited you there, or their IT. Microsoft says to “engage the resource tenant owners or sponsor.”

For admins of the resource tenant: find out why the guest was disabled, then follow Microsoft’s two cases:

Case	Microsoft’s action
The guest is supposed to be disabled	“No actions should be performed. Access is expectedly blocked.”
It was disabled by mistake	“Resource tenant owners should re-enable the account.”

To re-enable the guest with Microsoft Graph PowerShell, set accountEnabled to true. This is the command from Microsoft’s page on blocking accounts with PowerShell; -UserId takes the UPN or object ID:

Connect-Graph -Scopes User.ReadWrite.All
$params = @{
    accountEnabled = $true
}
Update-MgUser -UserId "<guest object id>" -BodyParameter $params

Microsoft’s troubleshooting article points to Set-AzureADUser with -AccountEnabled $true, from the AzureAD module. Both set the same accountEnabled property, as far as we can tell.

For admins of the user’s home tenant: nothing to change on your side. Check that the user is trying to reach the tenant they think they are.