A short introduction into Windows Hello for Business

Windows Hello for Business replaces passwords with strong multi-factor authentication on Windows 10 platforms, including PCs and mobile devices. This type of authentication consists of a new type of user credential that’s linked to a device and uses a biometric or PIN. It lets you sign in with your face, fingerprint or a PIN, and enables you to authenticate to enterprise applications, content, and resources without a password being stored on your device or in a network at all. The biometric data is only used locally and never leaves the device. Windows Hello for Business is of course only applicable to device with supported hardware.

Important to know is that you can also run Windows Hello for Business in a hybrid scenario. This means that an Azure AD Joined or Hybrid Azure AD joined device can authenticate with Windows Hello for Business credentials to your on-premises Active Directory resources (such as a file share). This will improve adoption and prevent a lot of authentication prompts and therefore frustration for your end users.

Different deployment methods

Windows Hello for Business can be deployed in three different methods:

• WHfB on-premises only deployment: The on-premises deployment method is based on a deployment method from Active Directory and managed via Group Policy. This method does support the WHfB hybrid options but do require an Active Directory domain join and therefore isn’t future proof (more and more resources are moving to the Azure AD so you should also explore to get your devices connected to the Azure AD).
• WHfB cloud-only deployment: The cloud-only deployment method is based on a deployment method directly from the Azure Active Directory. For this method it’s required that your devices are Azure AD Joined (or Hybrid Azure AD joined in case of the WHfB hybrid deployment), therefore this solution is a more persistent option and a recommended approach.
• WHfB hybrid deployment: The hybrid deployment option is available for both of the options mentioned above. In this case you make sure that the WHfB credentials (passport authentication) can be used cross-premises. So that for WHfB on-premises hybrid deployments, these credentials can be used for authentication within the Azure Active Directory. For the WHfB cloud hybrid deployment these credentials can be used for authentication in the on-premises Active Directory.

Different deployment options

Within the deployment methods mentioned above, you always have two options for your deployment, Key Trust and Certificate trust. Both methods are described below.

• Key Trust: This model is for enterprises that have Windows 10 desktops and/or laptops with a TPM available within their environment. This model therefore doesn’t require issuing end-entity certificates to your users and therefore an AD FS environment isn’t required.
• Certificate Trust: This model is for enterprises that don’t have Windows 10 desktops and/or laptops with a TPM available. Therefore you need to issue end-entity certificates to your users to enable the use of Windows Hello for Business and (unfortunately) therefore also have to use an AD FS environment.

NOTE 1: The Remote Desktop Protocol (RDP) does not support authentication with Windows Hello for Business key trust deployments. RDP is only supported with certificate trust deployments at the time of writing this blog.

NOTE 2: If the majority of your Windows 10 devices have a TPM available and some of them don’t the last group can’t use Widows Hello for Business. For this user group a FIDO2 Security key can be provided to give these users a password-less experience as a replacement for Windows Hello for Business.

Now I know all these options what should I choose??

Now that you know all of the above probably the question arises: “Ok, but what model should I choose?”. This question is fairly simple, if you want to use the full password-less experience (with the Authenticator App, Azure AD authentication including all security measurements). Then the advice is to use the WHfB cloud-only deployment – Key Trust model and when required run this scenario in a hybrid configuration (which I will described in the next blog). This is due to the fact that AD FS (a requirement for the Certificate Trust model) will interrupt the password-less flow of the Authenticator app as described in the previous blog. Putting effort into an on-premises deployment these days isn’t future ready. Therefore the way to go is the WHfB cloud-only deployment – Key Trust model.

Required technical steps for Windows Hello for Business Cloud-only – Key Trust

NOTE: For all of the next steps in this blog and the upcoming or previous blogs an AD Premium P1 license must be used. Next to this a device with a TPM 1.2 or higher is required with a Windows 10 Pro license.

STEP 1: Prepare for Windows Hello for Business Cloud-only – Key Trust

Option 1: For new or reinstalled devices (advised).

Execute an Azure AD Join on your device via the Out of Box Experience (OOBE) within Windows 10 when deploying a device. When you choose for this option, during the OOBE choose for ‘Set up for an organization’ and hit ‘Next’.

Now login with your business credentials, this automatically joins a device to the Azure AD.

After all the OOBE Screens you will be prompted for a WHfB enrollment as described within step 3.

NOTE: Hybrid Azure AD Joined devices are also supported, this however also requires that Windows Hello for Business is deployed within the hybrid model. This is therefore included in the next blog for the Windows Hello for Business Hybrid deployment.

Option 2: For existing devices which you don’t want to reinstall (not advised).

First make sure the device for which you want to enable Windows Hello for Business has a TPM chip.

You can easily verify if the device has a TPM by right-clicking ‘Start’ and hit ‘Run’.

The Run window will open, in here type ‘tpm.msc’ and hit enter.

The MMC will open, in here you will see that a TPM is available (the number and versions can be different as this is depending on your hardware):

If a TPM isn’t available you will see the message shown below within the MMC console.

NOTE: Another way to check the TPM is to enter the BIOS and check if TPM options are available.

Now that we know whether a TPM is available let’s check if your users can join devices to the Azure AD. To verify this setting go to the ‘Azure Active Directory’ blade in the Azure Portal. From there select the ‘Devices’ tab and hit ‘Device Settings’. In here make sure that ‘Users may join devices to the Azure AD’ is set to ‘All’ or to a ‘specific group’ of users.

Now we know for sure that devices can be joined to the Azure AD. Let’s join a device to the Azure AD. To do that open the ‘Settings’ within Windows 10.

Within the settings pane go to ‘Accounts’ and hit ‘Access work or school’.

As you can see, this device isn’t joined to any Active Directory or Azure Active Directory. Now let’s make sure to join this device by pressing the ‘Connect’ button.

Now the wizard will open, please don’t logon but hit ‘Join this device to Azure Active Directory’.

Now ‘logon’ with your credentials which are available in your tenant.

Verify you’re connecting to the right organization and once verified hit ‘Join’.

You’re now joined to the Azure Active Directory, please hit ‘Done’.

Now you also see you’re connected to the Azure AD within the ‘Settings’.

And as an admin you can also see that the device is Azure AD joined within the Azure Portal. Also note that MDM is set to ‘None’ this is correct as the device doesn’t need to be managed within Intune (even though the Windows Hello for Business settings do reside within Intune).

We are now ready to deploy the Windows Hello for Business policy!

STEP 2: Implement Windows Hello for Business cloud-only – Key Trust

To enable Windows Hello for Business within your tenant, go to the ‘Intune’ blade within the Azure Portal. From there select the ‘Device Enrollment’ tab and hit the ‘Windows enrollment’ tab. In this tab select ‘Windows Hello for Business’.

Within the Windows Hello for Business settings make sure to at least set the:

• ‘Configure Windows Hello for Business’ to ‘Enabled’ to enable Windows Hello for Business.
• In addition to the settings noted above, make sure that the ‘Use a Trusted Platform Module (TPM)’ is set to ‘Required’. This makes sure that Windows Hello for business is enabled and set to the ‘key trust’ model (if you still had some doubts, yes key-trust is a trust via TPM 🙂 ).
• Walk through the PIN requirement setting and configure them according to your needs and security requirements (personally I would recommend you keep the settings as is, a 6 digits number with complexity enforced should be enough).

When you scroll down within the settings pane, you will also see find additional settings like:

• ‘Allow biometric authentication’, this is used for face recognition and fingerprint scanners, and really helpful to set to ‘Yes’ for a solid password-less experience.
• ‘Use enhanced anti-spoofing, when available’, this is used to differentiate a photo from a real person when using face recognition. If turned on a photo can’t be used to login to the device. On the other hand, it means that face recognition won’t be available on some devices as they don’t support enhanced anti-spoofing. I would strongly recommend you to set this setting to ‘Yes’ to make sure an appropriate level of security is in place.
• ‘Allow phone sign-in’, this option makes sure users can use a remote passport to serve as a portable companion device for computer authentication. Companion devices are things like watches (bands), cards and USB devices that permit PC access with just a tap, a wireless transmission (Bluetooth or near-field communications) or by plugging a small device into a port. In this example we have set this value to ‘Yes’, so we can make sure that Windows Hello for Business can make use of ‘multi-factor unlock’ in the future.
• ‘Use security keys for sign-in’, this enables the use of FIDO2 security keys. In this example, we leave this setting on the ‘Disabled’ state. This is because I will describe this option later during this blog series when we are actually going to enable Security Keys within the Azure AD and the logon screen.

We are now ready to enroll a device :-).

STEP 3: Enroll a device with Windows Hello for Business

To do this, go to the logon screen of your Azure AD Joined machine and login with your business credentials (yes for now, this is still your username and password).

After logon the following screen appears, this is the Windows Hello for Business enrollment screen which will be triggered during the first login. Please hit ‘Set up PIN’ (as in this example this is a virtual machine with a TPM, this is my only option).

Now as the enrollment of Windows Hello for Business requires Multi-factor authentication (which we enabled in the first blog of this series), I’m prompted for verification with my Authenticator App.

NOTE: some people already asked me why this screen isn’t password-less. That’s due to the fact that password-less isn’t multi-factor authentication. Password-less is password-less authentication so there is a difference between them (but on the other hand the two also overlap).

On the next screen I’m asked for my PIN. When configuring Windows Hello for Business I always need to set a PIN besides my Fingerprint and Face recognition. Sometimes your fingerprint or face isn’t recognized in that situation the PIN functions as a fall back. As you can see the PIN requirements are matching the settings configured earlier within the tenant. Once you have typed in your PIN please hit ‘OK’.

Once the PIN is configured you can see everything is set correctly, please hit ‘OK’ to finish the Windows Hello for Business enrollment.

Now, when you lock your screen, you can see that I’m asked for my PIN, the password can still be used as a fall back by hitting ‘Sign-in options’.

NOTE: There are ways to disable the password from being used to logon to Windows 10. I’ve tried this myself and I wouldn’t recommend you take this approach. The problem here is that passwords then can’t be used anymore to login to remote desktop sessions for example. This is due to the fact that you can currently only remove password-logon as a credential provider for the whole system, not just for the logon to Windows 10.

Q: Now I’ve enrolled WHfB, where is my fingerprint or face stored?

Now that you can logon password-less to Windows 10 with your PIN, Face or Fingerprint the questions arises with some customers: “Where is this information stored?”. First of all, a Windows Hello for Business configuration is enrolled per device, so it’s a device trust between the end user and the device. This basically means that when you logon to another Azure AD Joined device in the example above you need to enroll Windows Hello for Business again. For this reason a PIN is always better and more secure than a password, as that PIN can only be used for that specific device.

This also means that your biometrics like your face or fingerprint aren’t stored within the Azure AD. During the enrollment, your fingerprint or face is stored on the local device and not being sent over to the internet. Now in simple terms: during a logon you use your fingerprint to get your private key out of the TPM, this private key is then used to logon to the Azure AD, where the public key is stored. If the private key and public key do match you have a successful logon and you will be able to access Windows Hello for Business.

In the next three blogs I will continue explaining how to implement the password-less options from a technical and user point of view. When they are available the links below will become active:

• Introduction to a password-less era
• Password-less 1 of 5: Going password-less with phone sign-in
• Password-less 2 of 5: Going password-less with Windows Hello for Business
• Password-less 3 of 5: Going password-less with Windows Hello for Business Hybrid
• Password-less 4 of 5: Going password-less with FIDO2 Security Keys Part 1
• Password-less 4 of 5: Going password-less with FIDO2 Security Keys Part 2
• Password-less 5 of 5: Expanding password-less to Azure AD Applications Part 1
• Password-less 5 of 5: Expanding password-less to Azure AD Applications Part 2
• Password-less 5 of 5: Expanding password-less to Azure AD Applications Part 3
• Password-less continued: Upgrading your password-less experience with Windows Hello for Business Hybrid cloud-trust.
• Password-less continued: Using the Passwordless Phone Sign-in experience for multiple accounts on iOS!
• Password-less continued: Using a Temporary Access Pass for Bootstrapping your Passwordless Journey