Some users can RDP to Azure VM with Entra ID, others can’t (Windows Server 2019 Datacenter; Entra login enabled)

Question

Environment

• VM OS: Windows Server 2019 Datacenter
• Azure sign‑in: Microsoft Entra ID (formerly Azure AD) login enabled via AADLoginForWindows extension
• Access method: RDP
• Scope & roles: Users/groups assigned either Virtual Machine User Login or Virtual Machine Administrator Login on the VM scope (some inherited at RG/Subscription)
• Network: Outbound 443 allowed; standard NSG; no proxy (or: behind corporate proxy – exceptions added)

Problem

Only some users can sign in to this VM using their Entra ID credentials (format AzureAD\******@domain.com). A subset of users get RDP sign‑in failures (e.g., “The sign‑in method you’re trying to use isn’t allowed” / “The user name or password is incorrect” / NLA/CredSSP prompts loop). All affected users can sign in to Microsoft 365 / Azure Portal in the browser with the same accounts.

What I’ve checked / tried

1. Extension & identity
   • AADLoginForWindows extension shows Provisioning succeeded.
   • System‑assigned managed identity is On.
2. RBAC
   • Confirmed users (or their groups) have Virtual Machine User Login or Virtual Machine Administrator Login at the VM (or higher) scope.
   • “Check access” on the VM shows Allowed for the same users.
3. Username format
   • Using AzureAD\******@domain.com (also tried just UPN without prefix).
4. Network
   • VM has outbound 443 to login.microsoftonline.com, enterpriseregistration.windows.net, pas.windows.net; IMDS reachable at 169.254.169.254.
5. Client side
   • Users are connecting from Windows 10/11 devices that are Entra registered/joined/hybrid‑joined to the same tenant.
   • Tried disabling NLA in VM settings as a test.
   • Tried RDP file edits (enablecredsspsupport:i:0, authentication level:i:2)—still inconsistent.
6. Device join state (on the VM)
   • dsregcmd /status shows AzureAdJoined : YES.

Symptoms for affected users

• RDP prompts for credentials repeatedly or fails with error; browser sign‑in works fine.
• Some users succeed immediately from the same network and same RDP client version.

Questions

1. What are the common causes for user‑specific Entra RDP failures when the VM is Entra‑joined and RBAC looks correct?
2. Are there additional role assignments or privileges required beyond Virtual Machine User Login / Virtual Machine Administrator Login?
3. Could Conditional Access, Authentication Strength, or Sign‑in risk policies block RDP while still allowing browser sign‑in? If so, which CA conditions are known to affect Windows sign‑in to Azure VMs?
4. Are there known client prerequisites (e.g., device must be Entra joined vs. registered; minimum Windows build; certain RDP client versions) that explain why only some users can log in?
5. Which Event IDs on the VM or Sign‑in logs in Entra should I focus on to pinpoint the failure (NLA/CredSSP vs. Entra token vs. RBAC)?
6. Any other network endpoints or TLS settings that differ for interactive Windows sign‑in vs. browser sign‑in that I should validate?Symptoms for affected users
   • RDP prompts for credentials repeatedly or fails with error; browser sign‑in works fine.
   • Some users succeed immediately from the same network and same RDP client version.
   Questions
   1. What are the common causes for user‑specific Entra RDP failures when the VM is Entra‑joined and RBAC looks correct?
   2. Are there additional role assignments or privileges required beyond Virtual Machine User Login / Virtual Machine Administrator Login?
   3. Could Conditional Access, Authentication Strength, or Sign‑in risk policies block RDP while still allowing browser sign‑in? If so, which CA conditions are known to affect Windows sign‑in to Azure VMs?
   4. Are there known client prerequisites (e.g., device must be Entra joined vs. registered; minimum Windows build; certain RDP client versions) that explain why only some users can log in?
   5. Which Event IDs on the VM or Sign‑in logs in Entra should I focus on to pinpoint the failure (NLA/CredSSP vs. Entra token vs. RBAC)?
   6. Any other network endpoints or TLS settings that differ for interactive Windows sign‑in vs. browser sign‑in that I should validate?

What help I’m looking for

• A troubleshooting decision tree or specific checks to differentiate RBAC, CA, client state (device join / PRT), NLA/CredSSP, or network causes.
• Any known issues or patch/build requirements for Windows Server 2019 + AADLoginForWindows that would cause intermittent user‑specific failures.
• Guidance on the minimum client state (e.g., must the client be Entra joined vs. registered) for reliable RDP with Entra credentials.

Thank you!

Answer 1

Hi Timothy Werunga,

Other Options:

Event logs will explicitly tell you why the user was blocked

Refer to Entra Admin Center → Sign‑in logs

Filter:

• User = failing user
• Application = Microsoft Azure Windows VM Sign‑In
• Client app = Other clients

Look for:

• CA policy name
• Failure reason
• Device state
• Authentication requirement not satisfied

RBAC roles are sufficient and those required are:

• Virtual Machine User Login
• Virtual Machine Administrator Login

CA settings known to break Entra RDP include Conditional Access → Sign‑in logs for a failing user. Look for:

 Device conditions such as:

• “Require device to be marked as compliant”
• “Require Hybrid Azure AD joined device”

RDP requires the client to be Entra joined or Hybrid joined, not just registered.

• Working users are almost always on Entra joined / Hybrid joined devices
• Failing users are often on Entra registered only

NLA / CredSSP (Server 2019‑specific gotchas)- Windows Server 2019 is far more sensitive here than 2022.

Known issues

• Older Server 2019 builds + newer Windows 11 clients
• CredSSP negotiation loops
• “Username or password incorrect” even with valid creds

What to verify on the VM

• Fully patched Server 2019 (especially 2023–2025 cumulative updates)
• CredSSP policy alignment

 If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.