flathub / flathub/com.thincast.client
AzureAD/Entra ID authentication (Cloud Only Joined Devices)
- Dominant language
- No language data
- Stars
- 3
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Description
ThinCast works perfectly for multi-monitor RDP under Linux (Wayland), but AzureAD/Entra ID authentication does not work.
Use-case:
- Linux client (Fedora 43, Wayland-only)
- Windows 11 PC joined to AzureAD (cloud-only, no local AD)
- Login via AzureAD\user@domain or user@domain fails
- Local accounts work fine
- ThinCast offers the best multi-monitor RDP experience under Linux, but without AzureAD support it cannot be used in modern enterprise setups.
Expected behavior:
- ThinCast should support AzureAD / Entra ID authentication similar to the Windows RDP client (CloudAP / AADWAM authentication flow).
- Allow login with AzureAD\user@domain or UPN user@domain without requiring a local fallback account.
Why this matters:
- Many modern Windows devices (especially business laptops) are AzureAD-joined only.
- Linux users cannot use these systems remotely without proper AAD authentication.
- Remmina/FreeRDP can authenticate to AAD (NLA disabled) but cannot do multi-monitor under Wayland.
- ThinCast is currently the only Linux RDP client with proper multi-monitor support under Wayland, so adding AAD auth would make it the best option available.
Workaround:
Currently it is possible to trick thincast to open a coneection. If i use a local account that exist on the remote windows pc but with the wrong password, it opens a rdp session and shows me the windows login screen. Then i can switch there to "other user" and type my azuread account in that format "AzureAd\user@domain.com", it works. But this connection isnt very stable. In some different period of time the connection freezes.
It would be great to get this thing working.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reviewing ThinCast's existing RDP authentication flow and compare it with the described Windows CloudAP/AADWAM flow. Reproduce the failure with an AzureAD-joined Windows 11 PC using both AzureAD\user@domain and user@domain formats, then compare it with the local-account workaround. Done means stable direct AzureAD authentication without requiring a local fallback account.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure
- Domain
- authentication, desktop
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100