Forum Discussion
Single-Sign On
After troubleshooting an issue for a customer, we determined that the prerequisites for enabling SSO at the AVD host pool level is not strictly enforced when a user goes to execute the SSO workflow from MSRDC or the Windows App. Meaning, that if an administrator does not enable the -IsRemoteDesktopEnabled flag on the Service Principals "Microsoft Remote Desktop" and "Windows Cloud Login" respectively.
Setup: Deploy Entra ID Joined session hosts to a host pool and enable the "Microsoft Entra single sign-on" RDP property to "Connections will use Microsoft Entra authentication to provide single sign-on" or update the RDP connection string with 'enablerdsaadauth:i:1'.
Result: User will not receive the 'Windows Security' dialog box to access the session host with their Entra ID credentials.
Caveat: Be aware that to sign in with Entra ID credentials, minimally, the host pool RDP settings must contain 'targetisaddjoined:i:1'. Microsoft states this is going away and blending into 'enablerdsaadauth:i:1', which also enables SSO. It seems a bit odd of a move in my opinion and having two separate RDP properties makes sense if a company does not want SSO. But it is in alignment with Microsoft's push for passwordless authentication.
For the Microsoft AVD team, why does this behavior exist and is it on the roadmap to be fixed if it's a known gap?
3 Replies
This behavior exists because the current implementation doesn't strictly validate prerequisite settings (like -IsRemoteDesktopEnabled on the service principals) when initiating SSO via MSRDC or the Windows App. It's a known gap tied to the transition from targetisaadjoined:i:1 to enablerdsaadauth:i:1, as Microsoft streamlines toward passwordless and Entra ID-based SSO.
While Microsoft hasn't publicly confirmed a fix, it's likely part of ongoing improvements to align with their identity-first and seamless access roadmap. For now, admins should ensure all prerequisites are manually validated to avoid silent failures in SSO.
I thought Microsoft spotted this and consolidating authentication settings, moving towards passwordless authentication. The shift from targetisaddjoined:i:1 to enablerdsaadauth:i:1 aligns with this strategy.
I'm waiting to touch base with one of the CSAs with the Virtualization team to get an official answer, but it would make sense that the lack of validation is due to the RDP property migration.
