Tenant Lockout

Question

Hi folks,

I'm really struggling with this one. I set up a tenant with federated login to Google Workspace for our domain. My email is a part of that federated bucket, but it was always a pure Microsoft account and it never had me go through the federated login sequence. The federated login has been working fine for all other domain accounts.

Well, apparently I was on borrowed time because now my Microsoft account does try to go through the federated sequence. I get kicked over to workspace. I log in successfully (according to Workspace admin logs) and it bounces me back to Microsoft with an error: "Sorry, but we're having trouble signing you in. AADSTS51004: The user account [Moderator note: Personally Identifiable Information removed] does not exist in the <tenant-id> directory. To sign into this application, the account must be added to the directory."

I am the global admin and I did not set up a redundant global admin account, and now I'm locked out of the tenant.

Through some separate blue password recovery web page trying to recover my account, it gives possibly a more direct cause:

The tenant 'Default Directory (<tenant-id>)' has been deauthenticated and is no longer available. Try signing into another tenant from the dropdown below. Error message: interaction_required: AADSTS5000225: This tenant has been blocked due to inactivity. To learn more about tenant lifecycle policies, see Trace ID: <id> Correlation ID: <id> Timestamp: 2026-07-06 21:19:44Z Select a different tenant to sign in to: Default Directory (<tenant-id>)

I was literally using the account the previous day and same day, so not sure what is meant by the inactivity. But this makes it seem like some default behavior was revoked and my account was part of it.

Consumer chat support got me a ticket opened with data protection team, great! However they ask for times to call me, so I give them times, and then they call me outside those call times. I scramble to find the phone outside that window, and it only rings once before they are gone already. They send a generic email with a case ID and a link to phone support and that I can call with the case ID. Every single number I have called goes to the generic MS support, and there is zero paths in the phone tree to reach a person, or put in the case ID. It always kicks me out saying Microsoft support is now online.

How can I get anyone to support this? I am at a loss.

Thank for your time!

Answer 1

I think you just call Microsoft 365 support, say “AADSTS5000225, only global admin locked out,” and read the tenant ID and trace ID on the error page so they can start reactivation.

Answer 2

So, about 4+ weeks going and I finally figured it out. I did two things concurrently so I am not sure which fixed it:

1. I originally followed https://learn.microsoft.com/en-us/education/windows/configure-aad-google-trust instructions. However, noticing my existing user didn't have the immutable ID set I thought maybe this is something we should map in the SAML attributes. In Google Workspace, I added a second SAML attribute mapping to have a second attribute:

Primary email > IDPEmail* (required)

Primary email > onPremisesImmutableId

1. I did this shortly after #1, so not sure if it was incidental or not:

PS> Install-Module Microsoft.Graph -Scope CurrentUser

PS> Connect-MgGraph -Scopes "User.ReadWrite.All"

PS> Update-MgUser -UserPrincipalName ******@domain.com -OnPremisesImmutableId ******@domain.com --UserId ******@domain.com

And sure enough, global admin user has the attribute set now and I can log into my tenant. Huzzah!

Answer 3

Duplicate comment.

Answer 4

Dear @Jacob,

I completely understand how frustrating it is to be caught in a loop with missed calls and an automated phone tree, especially when you are completely locked out of your own tenant.

The errors you are seeing point to two distinct issues. AADSTS51004 typically occurs during federation when the user's anchor attributes (like the ImmutableId) do not match between Google Workspace and Microsoft Entra ID. Meanwhile, AADSTS5000225 indicates that the directory itself has been flagged or suspended by automated lifecycle or security policies.

Because you are the sole Global Admin and federated login is failing, there is no self-service way to bypass this from your end. The Microsoft Data Protection Team is the only team with the backend authority to verify your identity and restore access to your tenant.

If you have already contacted the support team and have a case ID, here is the best way to break out of the support loop and reconnect with the backend engineer assigned to your case:

Do not rely solely on them calling you back. Reply directly to the generic email you received containing your case ID. Provide 2–3 specific windows of time (including your time zone) when you are guaranteed to be by your phone. These replies route directly into the engineer's active queue.

When calling the official Microsoft 365 Business support lines, the automated system will try to force you online if you say "technical support." To bypass this and get to a human:

• When the automated voice asks what you are calling about, say "Update an existing case" or "Case status."
• If prompted, speak or enter your case ID clearly.
• If the system tries to redirect you to an online link, explicitly say "I am completely locked out of my admin portal and cannot log in online." This keyword sequence typically triggers a route to a live agent who can transfer you to the Data Protection queue.

Please hang in there. Because this involves tenant security and identity verification, the Data Protection team must follow strict protocols, but using your existing ticket number is your definitive path to resolution.