Troubleshooting Azure Virtual Desktop Sign-In Failures After Tenant Migration

Migrating an Azure subscription between tenants can sometimes surface unexpected authentication issues, especially for environments like Azure Virtual Desktop (AVD) that depend deeply on Microsoft Entra ID (formerly Azure AD) for identity and access control.

This post walks through a real-world scenario where users were suddenly locked out of AVD sessions after a tenant migration, the investigation that followed, and the steps taken to restore access.

Scenario Overview

Shortly after an Azure subscription was migrated from Tenant A to Tenant B, several users reported being unable to connect to their virtual desktops.
The error message displayed:

“Your account does not exist in this organization’s directory.”

This problem appeared immediately after the migration—even though access roles had been correctly reassigned under the new tenant.
Interestingly, users who had active sessions before the migration remained signed in until their tokens eventually expired.

Symptoms Observed

• Authentication failures during AVD sign-in
• Error code AADSTS53003, indicating a Conditional Access policy block
• The issue primarily affected macOS clients
• Reinstalling or resetting the AVD client did not resolve the problem

Root Cause Analysis

The investigation uncovered that cached tokens on user devices were still attempting to authenticate against the legacy tenant.

Contributing Factors

• Token persistence in macOS Keychain
• Cached refresh tokens still bound to the old tenant’s directory ID

This mismatch meant that even though users had permission in the new tenant, their local authentication context still pointed to the previous one.

Understanding Token Behavior on macOS

The AVD client on macOS uses tokens stored in the system Keychain.

Key Takeaways:

• Conditional Access (CA) or Sign-In Frequency policies can shorten token validity (e.g., 12 hours or 7 days).
• Cached tokens remain active until:
• The refresh token expires.
• They are manually deleted from Keychain.
• A tenant mismatch triggers forced re-authentication.

Resolution Steps

1. Validate AVD Configuration

• Verify that the host pool, workspace, and application group references all point to the new tenant’s directory ID.
• Confirm that the appropriate service principals and role assignments exist under the new tenant.

2. Clear Cached Tokens

• On macOS, manually remove AVD’s cached MSAL tokens from Keychain Access.
• Once users signed out and back in, authentication succeeded without further issues.

Mitigation Options

Option 1 – Revoke Active Sessions via Microsoft Graph PowerShell

Connect-MgGraph -Scopes "User.RevokeSessions.All"

Revoke-MgUserSignInSession

Option 2 – Manual Cleanup

• Instruct affected users to delete cached credentials or MSAL tokens from macOS Keychain.
• Have them sign back in to re-establish authentication with the correct tenant.

Key Learnings

• Cached tokens can retain old tenant information long after migration—especially on macOS devices.
• Conditional Access policies may inadvertently block token issuance during silent sign-ins.
• Proactively revoking sessions and clearing tokens helps minimize user disruption.

Best Practices for Future Tenant Migrations

• Validate all AVD resources (host pools, workspaces, app groups) against the new directory ID.
• Instruct users to clear cached credentials before reconnecting.
• Allow sufficient propagation time for identity and access updates to take effect.
• Review Conditional Access policies to prevent unintended sign-in blocks during transition periods.

Closing Thoughts

Tenant migrations are complex, and even small gaps in token or directory synchronization can interrupt access to services like Azure Virtual Desktop. By planning token cleanup and access validation steps in advance, you can ensure a smoother transition with minimal user downtime.