Forum Discussion
Windows Remote Desktop Client - You were disconnected because your session was locked
Good day, I see a behavior with Remote Desktop client that once the machine inactivity timeout is passed , the remote session will be disconnection with a message " You were disconnected because you...
Kobyahsi There is still no clue from Microsoft side about this behavior but here is my analysis so far for troubleshooting the issue :
The issue is related to the new Single Sign-on feature that was released in September for Azure VD by attempting to authenticate to Azure Active Directory .
If I disable that feature from host pool RDP settings , the screen locks properly and asks for Password .
The issue looks related to how the conditional access policy is configured and if the account has MFA enabled .
Although I am able to login with Single Sign-on it looks like when the screen locks the MFA part kicks in and disconnect the session instead of locking the screen and this is where I see the below error in the logs :
I am currently checking with our AD Team on how to prevent MFA on those machines to see if the issue is resolved with Machine Inactivity Time and Screen Lock .
You can try the same procedure from your side by disabling Azure AD authentication to confirm the issue and check with AD Team what policies are getting applied when you enable that feature .
I will update the thread once I have that discussion and confirm if the issue is resolved .
- DavidBelanger
Microsoft
Hi folks, disconnecting a session when it locks is the expected behavior when enabling Azure AD authentication either in Azure Virtual Desktop with the RDP property above or in MSTSC on the Advanced tab by checking the option "Use a web account to sign to the remote computer".
I will add this to the documentation, but this was done for security reasons. The user is signing in to the session host using an Azure AD token and this allows the use of passwordless authentication and ensures CA/MFA policies are applied. The lock screen in Windows does not support passwordless and doesn't enforce CA/MFA policies. So users who sign using passwordless would not be able to unlock the session and another user could unlock the session, bypassing all CA/MFA policies. With SSO enabled, users should be able to easily launch the resource again and be connected.
Appreciate any feedback on this.
Thank you.- Imagine how this “for security” reasons is not secure at all. So my session disconnects rather than locking, then if someone other than the user goes to the client, can SSO into the resource with the other user’s creds. Bring lock back please!
- Hello David, any clue if we can add more time so it doesn't lock/disconnect automatically?
Where can I find the documentation about this? - Experiencing this same thing in Windows 365 VDI desktops and found no documentation around it. Is there at least a way to extend the timeout? I am so far unable to find one and it seems very short, maybe 5 minutes. Yes, it's easy to get back in but it seems like you turn around to have a conversation at your desk and you are disconnected. At least the session does not appear to ever actually log you off or kill open items.
