Hybrid Azure AD joined Key trust Windows Hello for Business Prerequisites
This document describes Windows Hello for Business functionalities or scenarios that apply to:
✅ Deployment type: hybrid
✅ Trust type: key trust
✅ Device registration type: Azure AD join, Hybrid Azure AD join
Hybrid environments are distributed systems that enable organizations to use on-premises and Azure AD-based identities and resources. Windows Hello for Business uses the existing distributed system as a foundation on which organizations can provide two-factor authentication that provides a single sign-in like experience to modern resources.
The distributed systems on which these technologies were built involved several pieces of on-premises and cloud infrastructure. High-level pieces of the infrastructure include:
- Public Key Infrastructure
- Directory Synchronization
- Multifactor authentication
- Device Registration
Hybrid Windows Hello for Business needs two directories: on-premises Active Directory and a cloud Azure Active Directory. The minimum required domain functional and forest functional levels for Windows Hello for Business deployment is Windows Server 2008 R2.
A hybrid Windows Hello for Business deployment requires Azure Active Directory. The hybrid key trust deployment does not need a premium Azure Active Directory subscription.
You can deploy Windows Hello for Business in any environment with Windows Server 2008 R2 or later domain controllers.
If using the key trust deployment model, you MUST ensure that you have adequate (1 or more, depending on your authentication load) Windows Server 2016 or later Domain Controllers in each Active Directory site where users will be authenticating for Windows Hello for Business.
Read the Planning an adequate number of Windows Server 2016 or later Domain Controllers for Windows Hello for Business deployments to learn more.
There was an issue with key trust authentication on Windows Server 2019. If you are planning to use Windows Server 2019 domain controllers refer to KB4487044 to fix this issue.
Review these requirements and those from the Windows Hello for Business planning guide and worksheet. Based on your deployment decisions you may need to upgrade your on-premises Active Directory or your Azure Active Directory subscription to meet your needs.
- Active Directory Domain Functional Level
- Active Directory Forest Functional Level
- Domain Controller version
- Azure Active Directory subscription
- Correct subscription for desired features and outcomes
Public Key Infrastructure
The Windows Hello for Business deployment depends on an enterprise public key infrastructure as trust anchor for authentication. Domain controllers for hybrid deployments need a certificate in order for Windows devices to trust the domain controller.
Key trust deployments do not need client issued certificates for on-premises authentication. Active Directory user accounts are automatically configured for public key mapping by Azure AD Connect synchronizing the public key of the registered Windows Hello for Business credential to an attribute on the user's Active Directory object.
The minimum required Enterprise certificate authority that can be used with Windows Hello for Business is Windows Server 2012, but you can also use a third-party Enterprise certification authority. The requirements for the domain controller certificate are shown below. For more details, see Requirements for domain controller certificates from a third-party CA.
- The certificate must have a Certificate Revocation List (CRL) distribution point extension that points to a valid CRL, or an Authority Information Access (AIA) extension that points to an Online Certificate Status Protocol (OCSP) responder.
- Optionally, the certificate Subject section could contain the directory path of the server object (the distinguished name).
- The certificate Key Usage section must contain Digital Signature and Key Encipherment.
- Optionally, the certificate Basic Constraints section should contain: [Subject Type=End Entity, Path Length Constraint=None].
- The certificate Enhanced Key Usage section must contain Client Authentication (220.127.116.11.18.104.22.168.2), Server Authentication (22.214.171.124.126.96.36.199.1), and KDC Authentication (188.8.131.52.184.108.40.206).
- The certificate Subject Alternative Name section must contain the Domain Name System (DNS) name.
- The certificate template must have an extension that has the value "DomainController", encoded as a BMPstring. If you are using Windows Server Enterprise Certificate Authority, this extension is already included in the domain controller certificate template.
- The domain controller certificate must be installed in the local computer's certificate store. See Configure Hybrid Windows Hello for Business: Public Key Infrastructure for details.
For Azure AD joined device to authenticate to and use on-premises resources, ensure you:
- Install the root certificate authority certificate for your organization in the user's trusted root certificate store.
- Publish your certificate revocation list to a location that is available to Azure AD-joined devices, such as a web-based url.
- Windows Server 2012 Issuing Certificate Authority
The two directories used in hybrid deployments must be synchronized. You need Azure Active Directory Connect to synchronize user accounts in the on-premises Active Directory with Azure Active Directory.
Organizations using older directory synchronization technology, such as DirSync or Azure AD sync, need to upgrade to Azure AD Connect.
Federation with Azure
You can deploy Windows Hello for Business key trust in non-federated and federated environments. For non-federated environments, key trust deployments work in environments that have deployed Password Synchronization with Azure AD Connect or Azure Active Directory Pass-through-Authentication. For federated environments, you can deploy Windows Hello for Business key trust using Active Directory Federation Services (AD FS) 2012 R2 or later.
- Non-federated environments
- Federated environments
Windows Hello for Business is a strong, two-factor credential the helps organizations reduce their dependency on passwords. The provisioning process lets a user enroll in Windows Hello for Business using their user name and password as one factor, but needs a second factor of authentication.
Hybrid Windows Hello for Business deployments can use Azure's Multifactor Authentication (MFA) service or they can use multifactor authentication provided by AD FS, which includes an adapter model that enables third parties to integrate their MFA into AD FS.
- Azure MFA Service
- Windows Server 2016 AD FS and Azure (optional, if federated)
- Windows Server 2016 AD FS and third party MFA Adapter (optional, if federated)
Organizations wanting to deploy hybrid key trust need their domain joined devices to register to Azure Active Directory. Just as a computer has an identity in Active Directory, that same computer has an identity in the cloud. This ensures that only approved computers are used with that Azure Active Directory. Each computer registers its identity in Azure Active Directory.
You need to allow access to the URL account.microsoft.com to initiate Windows Hello for Business provisioning. This URL launches the subsequent steps in the provisioning process and is required to successfully complete Windows Hello for Business provisioning. This URL does not require any authentication and as such, does not collect any user data.
- Device Registration with Azure Device Registration
Follow the Windows Hello for Business hybrid key trust deployment guide. For proof-of-concepts, labs, and new installations, choose the New Installation Baseline.
For environments transitioning from on-premises to hybrid, start with Configure Azure Directory Synchronization.
For federated and non-federated environments, start with Configure Windows Hello for Business settings.
Follow the Windows Hello for Business hybrid key trust deployment guide
Submit and view feedback for