flathub / flathub/com.thincast.client

AzureAD/Entra ID authentication (Cloud Only Joined Devices)

Open
#25 1 comment 0 reactions 0 assignees View on GitHub
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.