AADSTS50076 blocking one user's AVD sign-in on Entra-joined session host

Question

AADSTS50076 blocking one user's AVD sign-in on Entra-joined session host

Aanchal Bajaj 0

Environment:

AVD host pool, session hosts Microsoft Entra ID joined only (no hybrid/ADDS)
No SSO configured on the host pool (legacy connection flow — targetisaadjoined:i:1 set as custom RDP property)
Web client and Windows App client both tested, same result on both

Symptom: One user in our test group can connect successfully end-to-end. A second user, in the identical Entra group with identical RBAC roles, gets stuck at the Windows sign-in prompt with "The sign-in method you're trying to use isn't allowed."

What we've already ruled out:

RBAC: confirmed via CLI that the affected user's group has "Virtual Machine User Login" correctly assigned at the resource group scope
Legacy per-user MFA: confirmed disabled for the affected user
RDP property: targetisaadjoined:i:1 is set on the host pool; without it, both clients failed immediately at the browser-level credential check — with it, we now reach the actual Windows logon screen, so that part is working
Local account test: connecting worked with a local admin account, confirming the VM itself, network path, and RDP negotiation are healthy — the failure is specific to this user's Entra token request

Hard evidence from the machine — ran dsregcmd /status directly on the session host under the SSO State section:

Attempt Status: 0xc0000250
User Identity: [affected user UPN]
HTTP status: 400
Server Error Code: interaction_required
Server Error Description: AADSTS50076: Due to a configuration change made by your 
administrator, or because you moved to a new location, you must use multi-factor 
authentication to access the Azure Windows VM Sign-In application.

Since this is a non-interactive token request during VM sign-in, there's no way to actually complete an MFA challenge, so it fails outright.

0 comments

2 answers

Your answer

Answer 1

Hello Aanchal,

The error AADSTS50076 is expected behavior when Conditional Access or security defaults enforce MFA for the "Azure Windows VM Sign-In" application. Unlike browser-based sign-ins, the AVD session host logon flow is non-interactive and cannot surface an MFA prompt. That’s why one user succeeds (likely exempt from MFA or already has a valid PRT with MFA satisfied), while the other fails because their token request requires MFA but cannot complete it during the RDP handshake.

To resolve this, you need to adjust Conditional Access or security defaults so that the affected user can obtain a valid token without MFA being required at the VM sign-in stage. The two supported approaches are:

Exclude the "Azure Windows VM Sign-In" application from MFA enforcement in Conditional Access. This is the recommended path documented by Microsoft for Entra-joined AVD scenarios. You can do this by editing the Conditional Access policy that enforces MFA and adding an exclusion for the application “Azure Windows VM Sign-In” (App ID: 9a4e2f1c-2b3f-4e0a-9f5d-3f2f7f3e9c6d). This ensures that interactive MFA is not required during the VM logon flow.

Alternatively, if you are using security defaults instead of Conditional Access, you cannot configure exclusions. In that case, you must disable security defaults and replace them with Conditional Access policies that explicitly exclude the AVD sign-in application from MFA.

Once this exclusion is in place, the affected user should be able to sign in normally, as the token request will succeed without requiring MFA. If you want MFA protection for AVD, Microsoft’s guidance is to enforce MFA at the point of accessing the AVD client (web or Windows app) rather than at the VM sign-in stage.

I recommend reviewing your Conditional Access policies in Entra admin center under Security > Conditional Access, and confirming whether the “Azure Windows VM Sign-In” application is included in MFA enforcement. Adjusting that will resolve the AADSTS50076 error.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!HP.

Answer 2

The failure is caused by multifactor authentication being required for the Azure Windows VM Sign-In flow for that specific user. On Microsoft Entra joined Azure Virtual Desktop session hosts, that sign-in path is non-interactive in this scenario, so an MFA challenge cannot be completed and Windows sign-in fails with "The sign-in method you're trying to use isn't allowed."

The supported fix is:

Keep legacy per-user MFA disabled for the affected user. That is required for Microsoft Entra joined session host VMs.
Review Conditional Access policies affecting that user.
In the Microsoft Entra admin center, go to Identity > Monitoring & health > Sign-in logs.
Filter for the affected user and check failures for:
- Azure Virtual Desktop
- Windows Cloud Login
Open the failed sign-in and use the Conditional Access tab to identify which policy is enforcing MFA or otherwise blocking the request.
If MFA is being enforced for VM sign-in, exclude the Azure Windows VM Sign-In app from that Conditional Access policy if strong authentication at that app is not required.
If the policy is intended to enforce MFA for Azure Virtual Desktop access, use Conditional Access for Azure Virtual Desktop as documented, rather than per-user MFA on the VM sign-in path.

Important points for this exact scenario:

The fact that one user works and one user fails, with identical AVD RBAC and host pool settings, points to a user-targeted Conditional Access or MFA difference, not an AVD host pool or RDP property problem.
The targetisaadjoined:i:1 property is required for web, Android, macOS, and iOS clients, and also for clients/devices that do not meet the default Microsoft Entra join conditions. It only enables access to the Microsoft Entra joined VM using username/password in the legacy flow; it does not bypass MFA requirements.
The documented guidance for Microsoft Entra joined session host VMs is to disable legacy per-user MFA. If sign-in must not be restricted to strong methods such as Windows Hello for Business, the Azure Windows VM Sign-In app must be excluded from the Conditional Access policy.

Given the dsregcmd /status evidence showing AADSTS50076 for the affected user, the next action is to identify the exact Conditional Access policy in the sign-in logs and remove MFA enforcement from the Azure Windows VM Sign-In path for that user population.

References: