Forum Discussion
WIndows 365 SSO preview disconnects on lock instead of showing lock screen
MicrosoftHi Carlos_Capellan, thank you for the feedback. We changed the experience in part for the reason you mentioned. The lock screen doesn't support the new Azure AD authentication. It also doesn't allow users to unlock the session with passwordless credentials like FIDO keys and some configurations of WHfB. Passwordless authentication is a key benefit of the new protocol. The disconnection also ensures the CA/MFA policies are re-evaluated when the user reconnects, providing a more secure solution that doesn't allow simply entering a username and password.
With that said, the current experience on Windows is definitely sub-par as the user has to dismiss the dialog, open the client and relaunch their session. Before general availability, we're adding an easy reconnect button on the disconnect dialog. This will allow users to easily get back into the session, potentially without having to enter their credentials, unless you configure re-authentication policies.
We'll of course continue to watch the feedback post-GA to see what further adjustments may be needed.
Hi DavidBelanger,
Thank you SO MUCH for the detailed reply, I certainly appreciate the technical roadblocks you and the team are dealing with.
Unfortunately, I feel this limitation substantially weakens the BYOD use case. In a mobile/WFH use case I would need to have an aggressive lock screen inactivity timeout, say 10 minutes, and I am concerned about getting very negative user feedback if we do this. A reconnect button helps, but does not solve this.
I think to fully work around this limitation I would need to allow access to Cloud PCs only from corp-owned endpoints with inactivity timeouts enforced on the endpoints, but no timeout for the Cloud PCs themselves. But now we're losing part of the ease of use of the experience.
I understand just surfacing the traditional RDP username/password prompt on the Cloud PC lock screen defeats all the SSO/passwordless auth methods you are trying to deliver. But I expect you will get this same feedback from many more customers that we still need a standard inactivity timeout experience with no reconnect needed.
If there are any other approaches around this current limitation that I haven't considered here, a guidance or best practices page or blog post would be greatly appreciated! And still hoping this is a top priority on the roadmap!