Strange issue of credential invalid

Question

Strange issue of credential invalid

Anonymous

Hi. I am working on AVD POC. I used windows 10,windows 11 and windows 2022 as session host in pooled host pools. I can see the assigned desktop to me in windows app as well as web client .Now I don't have sso,so I need to enter my credentials twice, first at the workspace gate and second to launch my desktop. At second stage,it simply says credential not working. I tried simply RDP to those vms from entra id user login but similar error. To rule out issue with avd authentication and authorisation mechanism,I simply created one azure vm and tried rdping it with same fate..fyi virtual machine login user role added to resource group.

Please help me ,this is getting insane..

0 comments

3 answers

Your answer

Answer 1

Domic Vo 29,480 Independent Advisor

Good morning

I hope you are doing well.

Have you found the answer useful? If everything is okay, don't forget to share your experience with the issue by accepting the answer. Should you need more information, free free to leave a message. Happy to help! :)

Domic Vo.

0 comments

Answer 2

Hello DHIRAJ KUMAR,

The root of your problem is that the session hosts (Windows 10, Windows 11, Windows Server 2022) are not joined or properly hybrid‑joined to Entra ID, so when you attempt to log in with Entra ID credentials, the operating system rejects them. AVD requires that the session host VMs be domain‑joined (either to Entra ID only, or hybrid‑joined to on‑prem AD synchronized with Entra ID). Simply assigning the “Virtual Machine User Login” role at the resource group level is not sufficient; that role only grants permission to attempt RDP, but the OS itself must trust Entra ID for interactive logon.

That explains why even a standalone Azure VM fails with the same error: the VM is not domain‑joined to Entra ID, so the credentials are not recognized locally. In AVD, the workspace authentication succeeds, but the second stage (desktop logon) fails because the OS cannot validate the Entra ID account.

To resolve this, you need to ensure that your session hosts are either:

Azure AD joined (Entra ID join enabled during VM creation, with “Login with Entra ID” option enabled), or
Hybrid joined to on‑prem Active Directory synchronized with Entra ID via Azure AD Connect.

Once the host is properly joined, Entra ID credentials will be accepted at the OS level, and the “Virtual Machine User Login” role will allow RDP. Without that join, you will always see “credentials not working.”

In short: this is a Windows for Business identity and AVD configuration issue, not Windows 365 Enterprise. The fix is to domain‑join your session hosts to Entra ID or hybrid AD so that Entra ID credentials can be validated during desktop logon.

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!

Domic Vo.

Answer 3

The behavior matches known Microsoft Entra ID sign-in limitations and requirements for RDP/AVD when using Entra accounts.

Check and fix the following in order:

Verify required Azure role assignment

For every VM (including AVD session hosts and the standalone Azure VM), the Entra user must have Virtual Machine User Login or Virtual Machine Administrator Login assigned via Azure RBAC at the VM, resource group, or subscription scope.
The error message
- “Your account is configured to prevent you from using this device” directly indicates missing VM login role.
Re-check that the role is assigned to the correct user or group in the same tenant as the VM.

Ensure the client device is correctly joined/registered For RDP/AVD sign-in with Entra credentials:

The client device must be:
- Microsoft Entra joined or Microsoft Entra hybrid joined to the same Entra tenant as the VM/session host, or
- Microsoft Entra registered (in which case a special username format is required).
On the client, run:
- dsregcmd /status and confirm:
  - AzureAdJoined : YES (or AzureAdDeviceId present if registered)
  - AzureAdPrt : YES for SSO state.

Use the correct username format when RDP’ing

If the client is Entra registered (not joined/hybrid joined), RDP must use:
- AzureAD\******@contoso.com
If the client is Entra joined/hybrid joined to the same tenant, normal UPN usually works, but using AzureAD\******@contoso.com is still valid.
If the wrong format is used, Windows will show “Your credentials didn’t work” even though the account and password are correct.

Confirm the AADLoginForWindows extension is present

For Entra sign-in to Azure VMs and AVD session hosts, the AADLoginForWindows extension must be installed and not removed.
If it was uninstalled after the Entra join, reinstall it and test again.

Check MFA / Conditional Access configuration

VM sign-ins do not support per-user enabled/enforced MFA.
If the user has legacy per-user MFA enabled, RDP sign-in will fail with “Your credentials didn’t work” or “The sign-in method you’re trying to use isn’t allowed”.
Fix:
- Remove per-user MFA and instead use Conditional Access as described in Enforce Microsoft Entra multifactor authentication for Azure Virtual Desktop using Conditional Access.
- If Conditional Access requires MFA, ensure the client uses Windows Hello for Business or exclude the Microsoft Azure Windows Virtual Machine Sign-in app from that policy.

Enable PKU2U on client and session hosts For AVD Windows Desktop client and direct RDP with Entra accounts:

Ensure the security policy Network security: Allow PKU2U authentication requests to this computer to use online identities is enabled on both:
- The local PC (client)
- Each session host / Azure VM
If PKU2U is disabled, Entra-based RDP authentication can fail with generic credential errors.

Confirm no temporary password and password validity

If the Entra account has a temporary password or requires password change, RDP sign-in will fail.
Test by signing into a web app (for example, Azure portal) in a private browser session; if prompted to change password, complete that first, then retry RDP/AVD.

Check logs for precise cause

On the VM/session host, open Event Viewer → Applications and Services Logs → Microsoft → Windows → AAD → Operational and review events for the failed RDP attempts.
This will show whether the failure is due to unauthorized client, missing role, MFA, or device state.

Once the above are aligned for both the AVD session hosts and the standalone Azure VM (correct RBAC role, correct device join/registration, correct username format, PKU2U enabled, no per-user MFA, AADLoginForWindows present), Entra ID credentials should work consistently at the second logon prompt.

References: