Paolo Matarazzo 3e9b5143c1 updates
2022-11-18 16:37:54 -05:00

9.3 KiB

title, description, ms.date, appliesto, ms.topic
title description ms.date appliesto ms.topic
Windows Hello for Business Hybrid Azure AD joined Key Trust New Installation Learn how to configure a hybrid key trust deployment of Windows Hello for Business for systems with no previous installations. 4/30/2021
<a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
article

Windows Hello for Business Hybrid Azure AD joined Key Trust New Installation

[!INCLUDE hello-hybrid-key-trust]

Windows Hello for Business involves configuring distributed technologies that may or may not exist in your current infrastructure. Hybrid key trust deployments of Windows Hello for Business rely on these technologies

New installations are considerably more involved than existing implementations because you are building the entire infrastructure. Microsoft recommends you review the new installation baseline to validate your existing environment has all the needed configurations to support your hybrid certificate trust Windows Hello for Business deployment. If your environment meets these needs, you can read the Configure Directory Synchronization section to prepare your Windows Hello for Business deployment by configuring directory synchronization.

The new installation baseline begins with a basic Active Directory deployment and enterprise PKI.

Active Directory

This document expects you have Active Directory deployed with an adequate number of Windows Server 2016 or later domain controllers for each site. Read the Planning an adequate number of Windows Server 2016 Domain Controllers for Windows Hello for Business deployments to learn more.

Note

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.

Lab environments and isolated proof of concepts may want to limit the number of domain controllers. The purpose of these environments is to experiment and learn. Reducing the number of domain controllers can prevent troubleshooting issue, such as Active Directory replication, which is unrelated to activity's goal.

Section Review

[!div class="checklist"]

  • An adequate number of Windows Server 2016 domain controllers
  • Minimum Windows Server 2008 R2 domain and forest functional level
  • Functional networking, name resolution, and Active Directory replication

Public Key Infrastructure

Windows Hello for Business must have a public key infrastructure regardless of the deployment or trust model. All trust models depend on the domain controllers having a certificate. The certificate serves as a root of trust for clients to ensure they are not communicating with a rogue domain controller.

This guide assumes most enterprises have an existing public key infrastructure. Windows Hello for Business depends on a Windows enterprise public key infrastructure running the Active Directory Certificate Services role from Windows Server 2012 or later.

Lab-based public key infrastructure

The following instructions may be used to deploy simple public key infrastructure that is suitable for a lab environment.

Sign-in using Enterprise Admin equivalent credentials on Windows Server 2012 or later server where you want the certificate authority installed.

Note

Never install a certificate authority on a domain controller in a production environment.

  1. Open an elevated Windows PowerShell prompt.

  2. Use the following command to install the Active Directory Certificate Services role.

    add-windowsfeature adcs-cert-authority -IncludeManagementTools
    
  3. Use the following command to configure the Certificate Authority using a basic certificate authority configuration.

    Install-AdcsCertificationAuthority
    

Configure a Production Public Key Infrastructure

If you do not have an existing public key infrastructure, please review Certification Authority Guidance from Microsoft TechNet to properly design your infrastructure. Then, consult the Test Lab Guide: Deploying an AD CS Two-Tier PKI Hierarchy for instructions on how to configure your public key infrastructure using the information from your design session.

Important

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.

Section Review

[!div class="checklist"]

  • Minimum Windows Server 2012 Certificate Authority.
  • Enterprise Certificate Authority.
  • Functioning public key infrastructure.
  • Root certificate authority certificate (Azure AD Joined devices).
  • Highly available certificate revocation list (Azure AD Joined devices).

Azure Active Directory

You've prepared your Active Directory. Hybrid Windows Hello for Business deployment needs Azure Active Directory to host your cloud-based identities.

The next step of the deployment is to follow the Creating an Azure AD tenant process to provision an Azure tenant for your organization.

Section Review

[!div class="checklist"]

  • Review the different ways to establish an Azure Active Directory tenant.
  • Create an Azure Active Directory Tenant.
  • Purchase the appropriate Azure Active Directory subscription or licenses, if necessary.

Multifactor Authentication Services

Windows Hello for Business uses multifactor authentication during provisioning and during user initiated PIN reset scenarios, such as when a user forgets their PIN. There are two preferred multifactor authentication configurations with hybrid deployments—Azure MFA and AD FS using Azure MFA or a third-party MFA adapter

Review the What is Azure AD Multi-Factor Authentication topic to familiarize yourself its purpose and how it works.

Azure AD Multi-Factor Authentication (MFA) Cloud

Important

As long as your users have licenses that include Azure AD Multi-Factor Authentication, there's nothing that you need to do to turn on Azure MFA. You can start requiring two-step verification on an individual user basis. The licenses that enable Azure MFA are:

  • Azure AD Multi-Factor Authentication
  • Azure Active Directory Premium
  • Enterprise Mobility + Security

If you have one of these subscriptions or licenses, skip the Azure MFA Adapter section.

Configure Azure MFA Settings

Review the Configure Azure AD Multi-Factor Authentication settings section to configure your settings.

Azure MFA User States

After you have completed configuring your Azure MFA settings, you want to review How to require two-step verification for a user to understand user states. User states determine how you enable Azure MFA for your users.

Azure MFA via ADFS

Alternatively, you can configure Windows Server 2016 Active Directory Federation Services (AD FS) to provide additional multi-factor authentication. To configure, read the Configure AD FS 2016 and Azure MFA section.

Section Review

[!div class="checklist"]

  • Review the overview and uses of Azure AD Multi-Factor Authentication.
  • Review your Azure Active Directory subscription for Azure AD Multi-Factor Authentication.
  • Create an Azure AD Multi-Factor Authentication Provider, if necessary.
  • Configure Azure AD Multi-Factor Authentication features and settings.
  • Understand the different User States and their effect on Azure AD Multi-Factor Authentication.
  • Consider using Azure AD Multi-Factor Authentication or a third-party multifactor authentication provider with Windows Server Active Directory Federation Services, if necessary.

[!div class="nextstepaction"] Configure Azure Device Registration




Follow the Windows Hello for Business hybrid key trust deployment guide

  1. Overview
  2. Prerequisites
  3. New Installation Baseline (You are here)
  4. Configure Directory Synchronization
  5. Configure Azure Device Registration
  6. Configure Windows Hello for Business settings
  7. Sign-in and Provision