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. Token Type Default Lifetime Renewal Behavior Access Token ~1 hour Automatically renewed via refresh token Refresh Token 90 days of inactivity (rolling) Each successful refresh resets the timer Persistent Session Until refresh token expiry or manual deletion Cached in Keychain until removed 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 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. 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.Azure Container Registry Repository Permissions with Attribute-based Access Control (ABAC)
General Availability announcement Today marks the general availability of Azure Container Registry (ACR) repository permissions with Microsoft Entra attribute-based access control (ABAC). ABAC augments the familiar Azure RBAC model with namespace and repository-level conditions so platform teams can express least-privilege access at the granularity of specific repositories or entire logical namespaces. This capability is designed for modern multi-tenant platform engineering patterns where a central registry serves many business domains. With ABAC, CI/CD systems and runtime consumers like Azure Kubernetes Service (AKS) clusters have least-privilege access to ACR registries. Why this matters Enterprises are converging on a central container registry pattern that hosts artifacts and container images for multiple business units and application domains. In this model: CI/CD pipelines from different parts of the business push container images and artifacts only to approved namespaces and repositories within a central registry. AKS clusters, Azure Container Apps (ACA), Azure Container Instances (ACI), and consumers pull only from authorized repositories within a central registry. With ABAC, these repository and namespace permission boundaries become explicit and enforceable using standard Microsoft Entra identities and role assignments. This aligns with cloud-native zero trust, supply chain hardening, and least-privilege permissions. What ABAC in ACR means ACR registries now support a registry permissions mode called “RBAC Registry + ABAC Repository Permissions.” Configuring a registry to this mode makes it ABAC-enabled. When a registry is configured to be ABAC-enabled, registry administrators can optionally add ABAC conditions during standard Azure RBAC role assignments. This optional ABAC conditions scope the role assignment’s effect to specific repositories or namespace prefixes. ABAC can be enabled on all new and existing ACR registries across all SKUs, either during registry creation or configured on existing registries. ABAC-enabled built-in roles Once a registry is ABAC-enabled (configured to “RBAC Registry + ABAC Repository Permissions), registry admins can use these ABAC-enabled built-in roles to grant repository-scoped permissions: Container Registry Repository Reader: grants image pull and metadata read permissions, including tag resolution and referrer discoverability. Container Registry Repository Writer: grants Repository Reader permissions, as well as image and tag push permissions. Container Registry Repository Contributor: grants Repository Reader and Writer permissions, as well as image and tag delete permissions. Note that these roles do not grant repository list permissions. The separate Container Registry Repository Catalog Lister must be assigned to grant repository list permissions. The Container Registry Repository Catalog Lister role does not support ABAC conditions; assigning it grants permissions to list all repositories in a registry. Important role behavior changes in ABAC mode When a registry is ABAC-enabled by configuring its permissions mode to “RBAC Registry + ABAC Repository Permissions”: Legacy data-plane roles such as AcrPull, AcrPush, AcrDelete are not honored in ABAC-enabled registries. For ABAC-enabled registries, use the ABAC-enabled built-in roles listed above. Broad roles like Owner, Contributor, and Reader previously granted full control plane and data plane permissions, which is typically an overprivileged role assignment. In ABAC-enabled registries, these broad roles will only grant control plane permissions to the registry. They will no longer grant data plane permissions, such as image push, pull, delete or repository list permissions. ACR Tasks, Quick Tasks, Quick Builds, and Quick Runs no longer inherit default data-plane access to source registries; assign the ABAC-enabled roles above to the calling identity as needed. Identities you can assign ACR ABAC uses standard Microsoft Entra role assignments. Assign RBAC roles with optional ABAC conditions to users, groups, service principals, and managed identities, including AKS kubelet and workload identities, ACA and ACI identities, and more. Next steps Start using ABAC repository permissions in ACR to enforce least-privilege artifact push, pull, and delete boundaries across your CI/CD systems and container image workloads. This model is now the recommended approach for multi-tenant platform engineering patterns and central registry deployments. To get started, follow the step-by-step guides in the official ACR ABAC documentation: https://aka.ms/acr/auth/abac
Azure AD PIM token lifetimes
Does anyone know if Azure AD PIM has any impact on token lifetimes? I know an access token remains valid for 1 hour whereas a refresh token can have long life. Does this mean if user activates their role for only 30mins, they will continue to have privileged access for at least one hour unless user explicitly logs-out of the session.
Set Force a user to change password on next logon via Powershell
I have created a script to try and change the user setting 'force password change at next login'. I wish to do this without having to change their password. I have tried both user authentication (using a global admin account) and application authentication (via Client Secret). When I run the script in either authentication context I get access denied when it comes to updating the user. The script was to read in a csv file and do this but I have simplified a script to the following to show the basic concept of the commands I am trying to run and the authentication process. $secureSecret = ConvertTo-SecureString "xxxxxxxxxxxxxxxxx" -AsPlainText -Force $credential = New-Object PSCredential("xxxxxxxxxxxxxxxxxxxxx", $secureSecret) Connect-MgGraph -TenantId "xxxxxxxxxxxxxxxs" -ClientSecretCredential $credential Get-MgUser -UserId "email address removed for privacy reasons" -Property "userPrincipalName,userType,onPremisesSyncEnabled" Update-MgUser -UserId "email address removed for privacy reasons" -PasswordProfile @{ForceChangePasswordNextSignIn = $true} In the application I have created I have assigned the permissions I believe would be required to support this action (I added Directory.ReadWrite.All, just in case) The read user works fine but I get the error below when trying to update Update-MgUser_UpdateExpanded: Insufficient privileges to complete the operation. Status: 403 (Forbidden) ErrorCode: Authorization_RequestDenied Date: 2025-10-15T13:36:46 I have tried this is two different 365 tenants but both fail with the same error. The tenant is a cloud only with no synchronisation from on-premise. I have tried many iterations but have reached the dead end point. Is it possible to force a password reset via a PowerShell script and if so what am I doing wrong with my permissions? TIA
Not able to logon office 365 account or change it
If I want to logon to my Office 365 account I have to enter my emailaddress. Its is an @.onmicrosoft.com account. Entering password is ok, but then I am have to verify my phone number. The last two digits are shown, but clicking on this phone number I am getting an error like: 399287. There is no way of resetting this. I already contacted helpdesk but they cannot solve this problem. I have a bussniess account and I need some help about this. Every time I want to reset or want to make a change the account I am stuck in this error screen (endless loop). Please help me.Problem restoring deleted user with mggraph
Hello, I have done a few 365 migration and almost everytime there are some user data that has been missed in the migration. Earlier I solved this by restoring the 365 user in the source tenant to another domain using this msol script in powershell: Restore-MsolUser -UserPrincipalName email address removed for privacy reasons -Verbose Restore-MsolUser -UserPrincipalName email address removed for privacy reasons -Verbose -AutoReconcileProxyConflicts Restore-MsolUser -UserPrincipalName email address removed for privacy reasons -Verbose -AutoReconcileProxyConflicts -NewUserPrincipalName email address removed for privacy reasons I know it is not perfect but it worked well and saved a bunch of times. I have now done another migration now and got the same issue so I need to restore the users so we can access the data again and move it. BUT! I realized today that msol service is no more, so I am kinda stuck with figuring this out in mggraph. I have tried for a few hours now and I am not sure if this even possible with mggraph. Whenever I try to build a script using Restore-MgDirectoryDeletedUser/Item which google, copilote etc tells me to use I only get this error: The term 'Restore-MgDirectoryDeletedUser/item' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. Or I get that it "works" but that the proxy/domain conflicts: Errors detected while trying to restore the user restoreUserErrors: ErrorValue:<pii><pii>E*****.E*******</pii>@domain.com</pii> ObjectType: ConflictingObjectId:, ErrorType:UserPrincipalName, ErrorId:InvalidDomainErrorValue:<pii>smtp:<pii>ee</pii>@domain.com</pii> ObjectType: ConflictingObjectId:, ErrorType:ProxyAddress, ErrorId:InvalidDomain Status: 400 (BadRequest) ErrorCode: Request_BadRequest Date: 2025-09-08T13:49:36 Since I do not have the first domain in the source tenant anymore I need to restore the user to a different domain. Does anyone have any idea on how I can recreate the msol version to mggraph? I feel like I have tried everything to my knowledge now so hopefully anyone here can give me help or tips. Thanks! /AdamPeople Settings Appear in the Microsoft 365 Admin Center
The Org Settings section of the Microsoft 365 admin center has a new People Settings section where you can choose properties for the Microsoft 365 profile card instead of using PowerShell. The kicker is that the old method of using Exchange custom properties to customize what appears on the profile card is being replaced with standard Entra ID properties. A migration is needed, and it’s easily done with PowerShell. https://office365itpros.com/2025/09/04/microsoft-365-profile-card-2/Develop Custom Engine Agent to Microsoft 365 Copilot Chat with pro-code
There are some great articles that explain how to integrate an MCP server built on Azure with a declarative agent created using Microsoft Copilot Studio. These approaches aim to extend the agent’s capabilities by supplying it with tools, rather than defining a fixed role. Here were some of the challenges w encountered: The agent's behavior can only be tested through the Copilot Studio web interface, which isn't ideal for iterative development. You don’t have control over which LLM is used as the orchestrator—for example, there's no way to specify GPT-4o. The agent's responses don’t always behave the same as they would if you were prompting the LLM directly. These limitations got me thinking: why not build the entire agent myself? At the same time, I still wanted to take advantage of the familiar Microsoft 365 Copilot interface on the frontend. As I explored further, I discovered that the Microsoft 365 Copilot SDK makes it possible to bring in your own custom-built agent.Entra ID Allows People to Update their User Principal Names
Entra ID allows unprivileged users to update the user principal name for their accounts via the admin center or PowerShell. It seems silly because no justification for allowing people to update such a fundamental property is evident. Perhaps Microsoft has some excellent logic for allowing such updates to occur, but blocking access seems like the right thing to do. https://office365itpros.com/2025/01/24/update-user-principal-names/
