Microsoft have been advocating passwordless for a long time and we (me, colleagues at Coligo, friends and others working with security in the Microsoft area) are pushing more and more customers towards passwordless. The most obvious reason for going passwordless is improved security, but it can and will also mean an increased user experience. However, there is a problem in the modern world which still lingers and negatively impacts the user experience.
Modern deployment meaning Autopilot and Intune
Organizations staying at the top of game is not using only passwordless but also Autopilot and Intune. Using Autopilot without the ESP page is not really an option, so I see this as a requirement for most organizations and use cases. That means blocking the device until “everything” is deployed to the device. This is also where the problem kicks in.
The problem: Update rings containing devices
The problem is with update rings when using Windows Update for Business or Autopatch (which by the way are in the process of being merged together). If the update ring has the setting “Enable pre-release builds” set to Enabled in combination with the update ring being targeted to devices, this causes a forced reboot during the Autopilot process. The setting behind the scene is the ManagePreviewBuilds CSP.
Enabling this setting breaks the passwordless flow, as the user will have to go through a second round of passwordless authentication before ultimately reaching the desktop, causing potential service desk calls and causing a bad user experience.
History
This problem has been around for a long time and still exist in Windows 11 24H2 which has just been released. Two additional problems are that the current release of Windows 11 24H2 breaks web sign-in (step 5 below) and that is really troublesome as these users will be forced to going back to using passwords!
Also, the coming feature to automatically have Windows updated during OOBE will likely break this passwordless flow, but fortunately I think we will see controls for the Windows updates during OOBE.
However, it would be best if Microsoft could just make sure to make sure that (new) features do not interfere with the passwordless authentication flow in the first place, of course.
Let’s look at the difference in flow during Autopilot
Below is an illustration of difference in flow and how the user targeted update rings mean a better user experience!
Autopilot with update rings targeted to devices, and having preview builds enabled.
Autopilot with update tings targeted to users, and having preview builds enabled
1. OOBE sign-in with passwordless phone sign-in (could also be FIDO2 or certificate for instance).
2. ESP page kicks in.
3. Reboot occurs during Device setup due to update ring target groups containing devices and having preview builds enabled.
4. Windows welcome screen – passwordless authentication flow is broken.
5. Sign in with for example TAP or passwordless phone sign-in to continue (using web sign-in).
6. Windows Hello for Business enrollment.
7. Desktop.
1. OOBE sign-in with passwordless phone sign-in (could also be FIDO2 or certificate for instance).
2. ESP page kicks in.
3. Windows Hello for Business enrollment.
4. Desktop.
Root cause and workarounds?
Applying this configuration, i.e. ManagePreviewBuilds should not warrant a forced reboot. The fix to this issue is something Microsoft must fix.
Potential workarounds are to keep using Windows Update for Business Update Rings (or Autopatch) targeted to devices, and to keep devices that should be running a preview build in a separate group which is excluded from all regular update rings. Then target update rings with preview build specifically to groups containing users instead.
What about upcoming Windows Autopilot device preparation?
The new “Autopilot 2.0” which is called Windows Autopilot device preparation do not have this problem (for the moment). The flow is a bit different from Autopilot and the Enrollment Status Page so let’s keep this under monitoring as device preparation evolves. For the moment there are quite a few things missing before we can start migrating away from Windows Autopilot to Windows Autopilot device preparation.
Summary
Reducing necessary (or unnecessary) reboots should be top of mind to fix, and if not easily fixed we should be able to control this and make a decision of our own instead of having a reboot forced upon us.
Whenever new features are built from scratch, or changed, two very strict guidelines should apply; 1) Do not force reboots upon anyone (or let organizations control this behavior). 2) Do not break the passwordless flow and keep it intact to keep a secure and user-friendly experience.
Going passwordless should be the goal for anyone who cares about security and preventing identity and cyber attacks. It is possible to be almost 100% passwordless using Microsoft passwordless technologies. However, even if you have moved to not using your password, the password options are still available at Windows sign-in and also within Windows when signed in. It is now possible to reduce the password use in Windows.
New passwordless experience options available in Windows 11
One big step towards truer passwordless experience is to set the policy named EnablePasswordlessExperience. This will give you the following benefits:
No password sign-in option on the default Windows sign-in screen.
The primary user of the device sees only non-password sign-in options, and can only sign into the device using:
Windows Hello for Business.
FIDO2 security keys.
Web sign-in, which in turn uses either Temporary Access Pass (TAP) or the Authenticator app.
Smart cards.
No password options within Windows, when for instance elevating as administrator (UAC prompts). Note: You can still use runas to elevate with password as well as use the password for a local admin account (such as when using Windows LAPS).
The password setting option is removed from Settings > Accounts > Sign-in options.
This will mean that once this new setting is enabled, any user who used to use passwords is now much more likely to sign into Windows with anything else than the password. You can find more about this CSP setting at learn.microsoft.com: Authentication Policy CSP – Windows Client Management | Microsoft Learn.
Password credential provider is hidden from certain UI part of Windows
The reason why I say much more likely to sign in with anything else other than password is that the EnablePasswordlessExperience setting means that the password credential provider is only hidden on the Windows “primary user” sign-in screen.
That means that there are a number of ways to still use passwords in Windows, which is for example required to make sure for instance remote support through help desk is still a viable option:
Clicking Other users on the sign-in screen will allow the user to sign in using a password, as the password credential provider is enabled there.
Password use is available in Remote Desktop Connections and for web sites in Microsoft Edge.
Password can be used with runas to elevate with password as well as use the password for local admin accounts (such as when using Windows LAPS
Password change can still be accessed from Ctrl+Alt+Delete prompt.
Pre-reqs:
Currently, the following operating systems support the new setting EnablePasswordlessExperience:
The Enable Passwordless Experience settings are configured via Intune and are available in the Settings Catalog and this is how I recommend that you configure this new feature:
Enable Passwordless Experience is set to Enabled. This will in practice remove the password credential provider from the aforementioned parts of the Windows UI.
Enable Web Sign In is set to Enabled. This will show the “globe” as a sign-in option on the sign-in screen and acts as fallback for logging in if Windows Hello for Business sign-in fails, or if an administrator needs to sign into the device.
UI changed when passwordless is enabled
When these two settings are enabled, the password credential provider is removed from some UI elements, as well as introducing the web sign-in “globe” on the sign-in screen.
Sign-in screen
At the sign in screen, this is where we have maybe the most benefit of enabling the passwordless experience. The reason is that the option to sign in using password is gone! This will certainly reduce the use of password to sign in. At the same time you see the globe which can be used to sign in when or if Windows Hello for Business fails.
UAC Elevation Prompt
When trying to elevate as admin, UAC kicks in. With the passwordless experience enabled, you will only see passwordless options + the ability to use any local admin account (with password). This is to make sure that help desk for instance can still help via remote connections. The important thing is that the typical end users cannot choose any password options. Basically, this means that there is no option “Use a different account”.
Extra #1 – Interactive logon: Require Windows Hello for Business or smart card policy
Just to get this new passwordless experience one step further, I tried the good old policy setting Interactive logon: Require Windows Hello for Business or smart card policy to Enabled. The idea was to also prevent circumventing the “Other users” trick and disable password use even there, as well as completely in Windows.
But no, that setting will not allow you to sign in with Web Sign-in (which is working by design) so that means the setting is useless unless you can live with having no “back door” into your computers if authentication fails or there are problems.
Extra #2 – Excluding the password credential provider all together
This means that you can disable the password credential provider all together in Windows, leaving no room to use a password anywhere within Windows. This might sound good at first thought but will likely mean trouble for remote help for instance by help desk staff, as they will not be able to elevate as admin when needed.
Extra #3 – KQL Kusto Query to find out who are signing into Windows using passwords
The following query is something I use all the time, and it lists how many times your users sign into a Windows device using password. This is useful for “smoking out” password use at Windows sign-in but also in general in Microsoft 365, with a slight modification.
Extra #4 – Single Sign-On to on-premises resources
When signing into Windows with Windows Hello for Business or security keys, you do not have single-sign on to on-premises resources such as file shares, printers or applications. By enabling Azure AD Kerberos you enable single sign-on using security keys and by settings an Intune setting to use Windows Hello for Business Cloud Trust, you enable single sign-on using Windows Hello for Business.
Summary
The Enable Passwordless Experience that has been added to Windows 11 is a great step in the right direction of becoming fully passwordless, at the same time as not interfering with remote help and support. Anything that can be done to reduce the use of passwords is simply great!
Sidenote: If you use security keys with multiple identities, you have probably learned that when trying to sign into Windows it will sign you in with the last written identity on the security key. If you like me want to be able to choose which identity to sign in with, please upvote this Windows Feedback item!
You must be logged in to post a comment.