Browser RDP fails to authenticate against Azure AD-only joined Windows devices (CredSSP negotiates NTLM, which cannot resolve cloud-only identities)

[blakey108]

Describe the Bug

Pangolin's browser-based RDP feature (built on IronRDP, since v1.19) authenticates via CredSSP, which negotiates down to NTLM for the Windows logon. NTLM cannot resolve Azure AD-only joined identities (no on-prem AD, no hybrid join), so RDP into any cloud-only Azure AD joined Windows device fails outright, regardless of correct credentials.

This is a protocol-level failure, not a configuration or credentials issue. The target machine's Event Viewer shows every attempt failing locally in the NTLM stack:

• Failure Reason: Unknown user name or bad password
• Status: 0xC000006D
• Sub Status: 0xC0000064 (account does not exist)
• Authentication Package: NTLM

The failure is identical across every username format (AzureAD\user, user@domain.com, DOMAIN\user). Entra ID sign-in logs show no sign-in attempt at all for these connections, confirming Azure AD is never reached, the connection dies in Windows' local NTLM stack before any cloud validation occurs. This also rules out Conditional Access/MFA as the cause.

Notably, Pangolin already supports Entra ID as an OIDC identity provider for portal authentication, including group-based role mapping controlling access to the RDP resource itself. So a user can be fully authenticated and authorised via Entra ID, yet still be completely unable to open the RDP session, because the final hop uses an auth protocol that cannot resolve their identity.

There is currently no error surfaced to the user indicating this scenario is unsupported, the connection just fails with a generic CredSSP error, which makes this extremely time-consuming to diagnose.

Environment

• Pangolin version: v1.19.4
• Deployment: Self-hosted, Docker (homelab)
• Target machine: Windows 11, Azure AD joined only (no on-prem AD, no hybrid join), Intune managed
• RDP client: Pangolin browser-based RDP (IronRDP)
• Identity provider: Entra ID configured as OIDC IdP in Pangolin (working for portal auth and role mapping)

To Reproduce

1. Set up a Windows 11 machine joined only to Azure AD (Entra ID), no on-prem domain, no hybrid join. Verify with dsregcmd /status (AzureAdJoined: YES, DomainJoined: NO).
2. Ensure RDP works to this machine from the native Windows Remote Desktop client using Azure AD sign-in mode, to confirm the target itself accepts RDP for the Azure AD identity.
3. In Pangolin (v1.19+), create an RDP resource pointing at this machine.
4. Attempt to connect via the browser RDP client using a valid Azure AD identity, trying any/all of these username formats:
   • AzureAD\user@domain.com
   • user@domain.com
   • DOMAIN\user
5. Observe the connection fail with a CredSSP authentication error in every case.
6. On the target machine, check Event Viewer → Windows Logs → Security for Event ID 4625. Every attempt shows:
   • Status 0xC000006D, Sub Status 0xC0000064, Authentication Package NTLM
7. Check Entra ID → Sign-in logs for the same time window. No sign-in attempts (successful or failed) are recorded, confirming the failure occurs locally in NTLM before Azure AD is ever contacted.

Expected Behavior

One of the following:

1. Ideally: Pangolin's RDP gateway supports an authentication path compatible with Azure AD-joined devices, e.g. PRT (Primary Refresh Token) based auth via WAM/CloudAP, similar to the native Windows Remote Desktop client's "Azure AD" sign-in mode. Since Pangolin already authenticates the user via Entra ID OIDC for portal access, that session could potentially be bridged/exchanged to complete the RDP logon rather than requiring a second, incompatible CredSSP/NTLM credential exchange. If IronRDP has existing or in-progress upstream support for this, wiring it into Pangolin's RDP resource config may be a smaller lift than a from-scratch implementation.

2. At minimum: Pangolin detects this failure mode and surfaces a clear, actionable error (e.g. "target does not support NTLM authentication; Azure AD-only joined devices are not currently supported"), and the docs state this limitation explicitly, rather than the current generic CredSSP failure that users can spend days debugging.

Happy to provide full logs or test against a reference environment if useful for reproducing.

[AstralDestiny]

Could've sworn this was opened as an issue by someone already.
Ah right was you sorry, I get github issues funneled to a discord, So always glancing at the same location.

[blakey108]

i submitted this as a feature request but read the message again and i got told to submit as an issue

[github-actions]

This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.

[scm7ak]

do we think there will be a fix for this one?

it would be wonderful to have it addressed and move away from guac.