Windows Hello for Business – Hybrid Azure AD Key Trust Deployment

The key premise with Windows Hello for Business is to replace passwords with strong two-factor authentication. Microsoft have been driving strongly towards a password-less environment, and are continually making improvements in this area (see here for one of the latest). I have been working with Windows Hello lately. Microsoft have some really good guidance on deploying Windows Hello for Business, and there is a fair bit of information to digest. Below I have summarised the high-level requirements, some of my findings and considerations for one of the deployment models (Hybrid Azure AD Joined Key Trust).

Deployment Considerations and Supporting Infrastructure

When considering a Windows Hello for Business (WHfB) deployment, the first thing to consider is where your identities are stored. This defines the core approach you will take. The scenarios are:

  • Cloud Only
  • Hybrid
  • On-premises only

Cloud only (Azure AD) is the most straight forward scenario. In a nutshell, having no on-premises resources simplifies the requirements and deployment. Hybrid is the most common scenario, where on-premises identities are synchronised to Azure AD (with Azure AD Connect), and use password synchronisation or federation with Azure AD. There are identities hosted in on-premises AD and Azure AD. And on-premises is self-explanatory.

Secondly, there are 2 types of trust models that you need to consider with WHfB;

  • Key trust
  • Certificate trust

Neither is necessarily better than the other, but they do have differing requirements. Summarising from the Microsoft online documentation, Hybrid Azure AD Joined Key Trust has the below requirements:

  1. Forest and domain functional levels 2008 R2 minimum
  2. You will need adequate number of Windows Server 2016 DC(s) in each AD site where user authenticate to
  3. Azure AD subscription
  4. Some method of user MFA is required
  5. Windows Server 2012 or above enterprise CA installed
  6. Latest version of Azure AD Connect
  7. Device Registration with Azure Device Registration
  8. This model can be deployed with password sync or AD FS
  9. Preferably latest version of Windows 10, but minimum 1703
  10. Make sure client devices support your requirements for WHfB (e.g. TPM, biometric sensor)

Expanding on some of the above points, below are some important or not so obvious considerations:

  • For larger environments, you don’t have to upgrade all the DCs in a site to 2016. Be aware though that an upgraded DC will share the load of existing authentications with other DCs in the site, as well as exclusively handling the WHfB key-trust authentications. So the performance of this DC needs to be monitored and proper planning is required.
  • With your Azure AD subscription, hopefully you have appropriate licensing for Azure MFA (e.g. Azure AD Premium). Azure MFA is cloud-based and offers the simplest deployment method, especially if you do not have AD FS deployed
  • Make sure Azure AD tenant is set up for device registration. See How to manage devices using the Azure portal
  • Azure AD Connect facilitates registration of device with Azure AD/Hybrid Azure AD join.
  • Hybrid Azure AD join for devices, follow Tutorial: Configure hybrid Azure Active Directory joined devices manually. There are instructions here to help you determine if the service connection point (SCP) has already been created, and if not, how to create it. As with WHfB, you can also scope which devices in your organisation join Azure AD. Refer to this article to scope deployment: How to control the hybrid Azure AD join of your devices.
  • If you deploy your first 2016 DC as part of this exercise and Azure AD Connect was already deployed, you’ll need to do a refresh of the schema in Azure AD Connect
  • Even with the key-trust deployment model an Enterprise PKI is required. They provide a trust anchor and certificate for domain controllers so that Windows 10 clients trust the DCs.

Deploying WHfB

Configure Hybrid Windows Hello for Business key trust settings provides a good explanation of the various configuration steps required to implement this. Some considerations and discoveries I made that may be handy to know up front are listed below.

  • WHfB can be scoped to deploy to a pilot group of users and a staged migration approach used to control rollout
  • When following the instructions on Configure Hybrid Windows Hello for Business: Directory Synchronization, the Enterprise Key Admins group was not provisioned until the FSMO roles where transferred across to a 2016 DC
  • Configuring the PKI infrastructure involves creating a new certificate to include KDC Authentication and stronger encryption and replacing existing DC authentication certificates with the new one. Group policy configuration is also required to facilitate the DCs renewing a newer certificate. This is reasonably straight forward to do but obviously and important step on your DCs (change control)
  • The documentation provides group policy settings to enable WHfB, but there are other policy settings to consider also. These are computer-based policies.
  • There is an option for WHfB called Multifactor Unlock, which basically further strengthens your security posture by requiring 2 credentials, such as a PIN and then a biometric credential, to unlock a device. This requires Windows 10 1709 minimum. If the password is known the user can log in with that and the multifactor credentials can be circumvented.
  • Windows 10 can also be locked down by requiring WHfB or smart card, effectively not allowing the use of passwords at the logon screen. This is a computer-based policy also, located under Windows Settings > Security Settings > Local Policies > Security Options. When this is combined with the Multifactor Unlock policy in the previous point, you can protect against potential device and password theft or compromise by requiring a biometric credential (as one of the factors), as the multifactor credentials can’t be circumvented with the password as highlighted in the previous point.

I hope that you have found something in this article that will aid your research. On one final interesting note, following on from the last 2 points above and looking at third party products that can facilitate MFA authentication at the Windows logon screen, you might also like to have a look at Duo. Duo provides a MFA solution that provides MFA at the Windows logon screen, even when the device is offline, which is a pretty handy feature!







Andrew Matthews
Andrew Matthews
SENIOR CLOUD CONSULTANT AT CUBESYS Andrew has 14+ years’ experience in senior operational and support roles, solution architecture, design, professional services and project management. Andrew specialises in Office 365 and Azure AD, EM+S, Exchange and Lync/Skype for Business.