This week is all about Windows Hello for Business. Windows Hello for Business provides a really convenient and user-friendly method to authenticate in Windows, as it enables users to verify their identity by using a gesture (face, fingerprint or PIN). More importantly, however, Windows Hello for Business is also an important step in the transition to a passwordless environment, as it replaces the need for the traditional username-password authentication with a strong two-factor authentication on Windows devices. By default, Windows Hello for Business will be an additional method to get authenticated in Windows.
When working towards a passwordless environment, it’s important to also take further actions for Windows devices, by preventing the use of the traditional username-password and by requiring the use of Windows Hello for Business or smart cards. That would force users in to using Windows Hello for Business. Forcing users in to using Windows Hello for Business does require an organization and their users to be ready. To be ready to provision new users on devices, to facilitate PIN reset functionalities on devices, to accept the limitations for new accounts and local accounts on devices, and to be able to address the different scenarios for password usage by the applications on devices. This post will focus on the technical implementation of requiring the use of Windows Hello for Business. The steps for the implementation, some technical challenges and the user experience.
Important: The intention of this post is not to discuss Windows Hello for Business as a true multi-factor authentication solution, only to provide guidance with the technical implementation of requiring Windows Hello for Business. It is good, however, to keep in mind that the definition of NIST considers the construction of Windows Hello for Business as multi-factor authentication. Windows Hello for Business combines something that you have (e.g. a device with a hardware TPM that contains the private key) with something that you know (e.g. a PIN to unlock the private key) or something that you are (e.g. a fingerprint match to unlock the private key). That is similar to smart cards. Big difference, however, is the portability. And even though portability is not part of that definition of multi-factor authentication, organizations might consider it as an important part of the solution. When Windows Hello for Business alone is considered as not sufficient, have a look at adding multi-factor unlock, FIDO2 security keys or smart cards.
Configuring the required use of Windows Hello for Business for interactive logons
When looking at requiring the use of Windows Hello for Business, there is the option to require the use of Windows Hello for Business for interactive logons and the option to completely exclude the password credential provider. The former is the more elegant initial option, as it leaves the password credential provider available for use and provides the user with a clear message that Windows Hello for Business should be used. The latter is the more disrupting option, as it completely hides the password credential provider from Windows and other applications that are relying on that credential provider. This post will focus on the former option and more about the latter option is for another post.
For the configuration to require the use of Windows Hello for Business, there is a Group Policy setting available that can be used. That policy setting exists as Interactive logon: Require Windows Hello for Business or smart card for Windows 10, version 1703 and later. The challenge, however, is that this policy settings isn’t easily configurable via Microsoft Intune at this moment. Not available via the Administrative Templates, nor via the Settings Catalog. The good thing is that this setting configures a registry value (scforceoption) and that can be relatively easily scripted by using PowerShell. As PowerShell scripts are the road forward, the best controlled method to distribute the required configuration is by using proactive remediations.
Constructing the PowerShell script to detect the Windows Hello for Business configuration
When using proactive remediations, there should be a detection script. That detection script should detect the Windows Hello for Business configuration. Below is a snippet of a PowerShell script that performs the required detection. That snippet verifies the existence of the registry key, the registry value and the registry data, that are required for the Windows Hello for Business configuration. That verification is achieved by checking the existence of the registry key (line 5), by checking the availability of the registry value (line 6) and by verifying the registry data (line 7).
$registryPath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System"
$registryValueName = "scforceoption"
$registryValueData = "1"
if((Test-Path $registryPath)) {
if(Get-ItemProperty -Path $registryPath -Name $registryValueName -ErrorAction Ignore) {
if((Get-ItemPropertyValue -Path $registryPath -Name $registryValueName -ErrorAction Ignore)-eq $registryValueData) {
Write-Host "Windows Hello for Business is required"
exit 0
}
else {
Write-Host "Windows Hello for Business is currently not required"
exit 1
}
}
else {
Write-Host "Windows Hello for Business is currently not required"
exit 1
}
}
else {
Write-Host "Windows Hello for Business is currently not required"
exit 1
}
Constructing the PowerShell script to remediate the Windows Hello for Business configuration
When using proactive remediations, there should also be a remediation script. That remediation script should remediate the Windows Hello for Business configuration. Below is a snippet of a PowerShell script that performs the required remediation. That snippet creates the registry configuration that is required for the Windows Hello for Business configuration. That creation is achieved by checking the existence of the registry key. When the registry key doesn’t exist (line 6), the registry key (line 7), the registry value and the registry data are created (line 8). When the registry key does exist (line 11), only the registry value and registry data are set (line 12).
$registryPath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System"
$registryValueName = "scforceoption"
$registryValueData = "1"
try {
if(!(Test-Path $registryPath)) {
New-Item -Path $registryPath -Force
New-ItemProperty -Path $registryPath -Name $registryValueName -Value $registryValueData -PropertyType DWORD -Force
Write-Host "Successfully configured Windows Hello for Business as required"
}
else {
New-ItemProperty -Path $registryPath -Name $registryValueName -Value $registryValueData -PropertyType DWORD -Force
Write-Host "Successfully configured Windows Hello for Business as required"
}
}
catch {
$errorMessage = $_.Exception.Message
Write-Error $errorMessage
exit 1
}
Using proactive remediation to detect and remediate the Windows Hello for Business configuration
After constructing the different PowerShell scripts to detect and remediate the Windows Hello for Business configuration, it’s time to look at the best method for applying those scripts. That best method is proactive remediations. Proactive remediations are script packages that can detect and remediate any scriptable challenge, as long as those challenges can be addressed by using PowerShell. The nice thing about script packages is the ability to schedule the execution and to configure recurring behavior. That provides a lot of control and flexibility. For deploying those script packages, Microsoft Intune relies on the Intune Management Extension (IME). The following six steps walk through the creation of a script package to detect and remediate the Windows Hello for Business configuration.
- Open the Microsoft Endpoint Manager admin center portal navigate to Reports > Endpoint analytics > Proactive remediations
- On the Endpoint analytics (Preview) | Proactive remediations blade, click Create script package to open the Create custom script wizard
- On the Basics page, provide the following information and click Next
- Name: Provide a valid name for the custom script package to distinguish it from other similar script packages
- Description: (Optional) Provide a valid description for the custom script package to further differentiate script packages
- Publisher: (Optional) Provide a valid publisher for the custom script package, by default the creator of the script package
- Version: [Greyed out]
- On the Settings page, provide the following information and click Next
- Detection script file: Select the created detection script to detect the status of the Windows Hello for Business configuration
- Detection script: [Greyed out]
- Remediation script file: Select the created remediation script to remediate the Windows Hello for Business configuration
- Remediation script: [Greyed out]
- Run this script using the logged-on credentials: Select No as value to make sure that the script runs in SYSTEM context
- Enforce script signature check: Select No as value to make sure that the signature of the script is not checked
- Run script in 64-bit PowerShell: Select Yes as value to make sure that the script runs in 64-bit, if possible
- On the Scope tags page, configure the required scope tags click Next
- On the Assignments page, provide the following information and click Next
- Assign to: Select the assigned group and configure the schedule by clicking on the three dots
- Schedule: Select the recurrence frequency by choosing between Once, Daily, or Hourly
- When choosing Once, a specific date and time should be configured
- When choosing Daily, a frequency and daily time should be configured
- When choosing Hourly, a frequency should be configured
Important: The assignment of the script package is an important part of creating a working solution. When the script package is applied during the out-of-the-box experience, that will already disrupt the configuration of the device and that will prevent the user from configuring Windows Hello for Business on the device.
- On the Review + create page, verify the information and click Create
Experiencing the required use of Windows Hello for Business for interactive logons
Experiencing the behavior with the required use of Windows Hello for Business is pretty straight forward. Simply start a configured Windows 10 device, select Password (the key icon) as the Sign-in option, provide username-password and click Submit (the arrow icon). That will trigger the configuration and will tell the user to use Windows Hello or a smart card to sign in (as shown below in Figure 2). This behavior is also successfully tested on the current preview version of Windows 11.
Important: Keep in mind that this configuration also allows the use of FIDO2 security keys.
As mentioned earlier, this does require Windows Hello for Business to be configured for the user before the configuration is applied. That makes it important to make the user configure Windows Hello for Business immediately during the out-of-the-box experience. After applying the configuration, to require Windows Hello for Business, it’s no longer possible for a user to set up Windows Hello for Business. At that point the configuration becomes a loop. Windows Hello for Business is required, but can’t be configured. That might bring challenges for local accounts or new user accounts. In those cases, or when using shared devices, think about using FIDO2 security keys, or smart cards. Those are already configured and connected to the identity of the user. And can also be used in combination with the configuration to require Windows Hello for Business.
More information
For more information about the passwordless strategy of Microsoft and and the different configuration options, refer to the following docs.
This is great. How do we apply this reg key AFTER the user has enrolled WHFB? I have tried to deploy this and during the autopilot process it deployed before the user has a chance to enroll locking them out.
Hi David,
My experience so far has been that the user would be required to set up Windows Hello. Unless they deliberately skipped it. One thing you could do is add a small check to the script that for example checks the credential provider that’s been used for signing in.
Regards, Peter
I have the same experience, we and even scheduling it using remediate script using autopilot, the script is getting applied which prevents the users from getting enrolled, this is also the case when hiding the username and password option using config profiles … as well as this is going to be a big challenge for the shared devices as you mentioned before! anyone done smart things to get this working or script around it ?
I haven’t looked at a solution for shared devices yet.
Regards, Peter
Hi!
As far as I can tell the solution is TAP. you can log in with TAP during OOBE and then set up Windows Hello. TAP is designed for this to be a one time sign-in method to enable strong auth. IF you can’t get this to work I suggest you trigger the remediation script after the enrollment process by using a dynamic group requiring the device to already be enrolled under management. A bit less streamlined but should work.
Hi Peter,
Thank you for this post. I am definitely interested in the latter option as well. Our current SSO Idp doesn’t sync passwords with Azure AD so our employees have to use a PIN or biometrics login on Windows. I’d love to just remove the password sign in option.
Hi Dallin,
For that option you can refer to this post: https://petervanderwoude.nl/post/excluding-the-password-credential-provider/
Regards, Peter
Peter – The setting you’re applying here is at the device level, whether done via GPO or through modifying the registry. Active Directory has a similar option that can be configured at the user level, with the “Microsoft Passport or Smart Card is required for Interactive Logon” setting on the user account. This seems like a better way to go, as it can target only the users desired, and still allow other users or local accounts to log in via password only.
However, this setting doesn’t seem to be enforced for a user when logging on to an AzureAD Joined computer, even though the user account is synchronized to AzureAD from the on-prem directory. Do you know whether there’s a way to configure this requirement at the user level in AAD or Intune so that it is enforced on AADJ computers?
Hi Steve,
As mentioned on Twitter, this will probably introduce a chicken-egg situation. You want to apply a user policy before login, but Intune only applies policies after login.
Regards, Peter
Do you have a script to detect whether WHFB has been enrolled for users or not? We are trying to determine the compliance data for this.
Hi Chris,
You could have a look for some inspiration at this script provided by Martin Bengtsson: https://github.com/imabdk/Powershell/blob/master/Detect-WindowsHelloEnrollment.ps1
Regards, Peter
Hi Peter, i enable the registry on a computer that already have Windows hello (no business) configured.
I was now unable to login. My previous Windows hello passcode not works, either my yubico fido2 key 🙁
Any idea for that issue please ?
Thanks for that post and this experience 😉
Hi Nicolas,
Not sure about your set-up, as it should just work, but you could remotely reconfigure the device again.
Regards, Peter
My setup is to edit the registry on my laptop that already have a Windows hello pin configured.
When i enforce use of Windows hello, my passcode doesn’t work anymore.
My laptop is hybrid azure ad join.
The configuration requires the use of Windows Hello for Business or a smartcard.
Regards, Peter
Hi!
There are additional configurations that has to be in place with hybrid AADJ. You´re in fact logging on to your AD account in this case. You need to enable WHfB in AD GPO or enable smart cards for login. OR i guess at this point set up Kerberos Cloud Trust that enables WHfB login to AD.
Hi Nicholas,
I have the same issue. Biometrics and Pin was setup, used for multiple logins, then when setting the policy, the biometric stops functioning.
Did you ever find a fix beyond wiping the device?
Thanks,
Alistair
Hi, great article, and it works great to setup WHfB with PIN+biometrics for a user on a new PC.
But as you mention, it becomes a loop if it’s not setup. On the fingerprint setup there is the “skip for now” button.
Know of any way to force this setup, so that I cannot be skipped?
Hi Eirik,
Not to my knowledge. The only thing you can do, is to add an additional step to actually check the status of the user.
Regards, Peter
Anyone figured out how to except administrative accounts?
It’s kind of all or nothing settings, as it’s a device setting.
Regards, Peter
Hi!
Well, you can use Security keys to log in as admin. and if you´re AADJ you can leverage new capabilities in intune to elevate stuff via policys and remotely temporarily allow standard users to run elevated processes like installers. look at intune extras.
Interesting, I was able to get this set up, and it does in fact force Windows Hello logins. However, it kills the ability to user passwords, even past the login. I was hoping to be able to still RDP into a computer that had this enabled, and no dice. I then quickly found that I cannot ‘Run as different user’ which kind of stinks.
I am hoping to set it up so that users cannot skip past Windows Hello for their sign in by simply choosing the Password Provider option at Sign-in options (kinda defeats the point of setting up Windows Hello and MFA if they can just skip it). However, I would love to still be able to use a password + PIN on the Windows Hello side of things, if the biometric device is having issues. I’ve tried opening a few cases with Microsoft about this, and have had no luck.
Really, I would just love to remove the password and smartcard options, leaving only Windows Hello. From there, it works perfect, and even falls back to a password if the biometric is not working, but still needs a PIN.
Hi Michael,
Thank you for that. Yes, it’s not ideal. Hopefully there will be something better in the future.
Regards, Peter
Hi!
If you combine this solution with Remote credential guard and Kerberos Cloud trust and force kerberos for sign in to the RDS server you should be able to use WHfB to sign in to a domain joined RDS server as the signed in user on the client. you can force kerberos auth via policy on server and client or just use mstsc /remoteguard launching the RDS connection. Or if you use WVD it now supports WHfB for signin using the win32 app.
Great article. We are also in the process of introducing it. But also face the challenge of the lifecycle of a notebook with its user.
What if a user wants to log on to other devices when they don’t even remember their password. How can I enforce that a user always logs in with Hello for Business only, but administrators can still log in to the systems?
Are there any experiences from Microsoft employees on how Microsoft handles it themselves?
Hi Stefan,
This is always challenging. At this moment it’s picking between a challenging experience when something goes wrong, versus always having the username-password option available. Most organization opt for the latter option and simply configure a preferred option.
Regards, Peter
this is what I did:
-Enforce WhfB when client is set up, so they will be forced to setup a PIN (biometrics,faceID optional if hardware support is present)
-Replace the users password with some 30 character random string…
-Users need to setup their authenticator app with passwordless login
User forgets PIN? they can click “reset PIN” and confirm the new one using their authenticator app.
User wants to login to a new device? sure, login using upn and authenticator app, and setup WhfB again.
Users phone is damaged or stolen? sure, give them a new phone and a temporary access pass to get their auth app setup again.
So accounts have a password the users dont need or know. Should the need for a password arise, it is possible to supply them with one – and the possibility to use it is always there.
Great article. Lucky for us we have group policy available to enforce the setting for now, so no script required. However, our challenge is similar to that which others have mentioned here. If we enforce the WHFB authentication method, users must already have created a PIN. If not, they will be unable to sign in. This affects existing employees who are signing into a system for the first time (either move to a new location or computer is replaced), and new employees who have never signed into a new computer. I suppose we could keep users or devices in a separate “password allowed” OU for a provisional amount of time to allow creation of a PIN, then move them the “WHFB enforced” OU. However it would sure be nice if the policy checked for the existence of a Windows Hello container, then enforced WHFB if present or allowed X number of password sign-ins before enforcement.
Hi Mike,
Sadly there is no real intelligence in the setting. The only thing you can do is to add some custom scripting around it.
Regards, Peter