deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-05-19 00:37:22 +00:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

updates

Browse Source
This commit is contained in:
Paolo Matarazzo 2022-12-21 09:37:44 -05:00
parent ccb82c428c
commit 6d5751a45c
3 changed files with 259 additions and 378 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

144
windows/security/identity-protection/hello-for-business/hello-hybrid-key-new-install.md
View File

@ -1,144 +0,0 @@
---
title: Windows Hello for Business Hybrid Azure AD joined Key Trust New Installation
description: Learn how to configure a hybrid key trust deployment of Windows Hello for Business for systems with no previous installations.
ms.date: 4/30/2021
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
ms.topic: article
---
# Windows Hello for Business Hybrid Azure AD joined Key Trust New Installation
[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-key-trust.md)]
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
- [Active Directory](#active-directory)
- [Public Key Infrastructure](#public-key-infrastructure)
- [Azure Active Directory](#azure-active-directory)
- [Multifactor Authentication Services](#multifactor-authentication-services)
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](hello-hybrid-key-trust-dirsync.md) 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](hello-adequate-domain-controllers.md) 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](https://support.microsoft.com/en-us/help/4487044/windows-10-update-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.
```PowerShell
add-windowsfeature adcs-cert-authority -IncludeManagementTools
```
3. Use the following command to configure the Certificate Authority using a basic certificate authority configuration.
```PowerShell
Install-AdcsCertificationAuthority
```
## Configure a Production Public Key Infrastructure
If you do not have an existing public key infrastructure, please review [Certification Authority Guidance](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831574(v=ws.11)) from Microsoft TechNet to properly design your infrastructure. Then, consult the [Test Lab Guide: Deploying an AD CS Two-Tier PKI Hierarchy](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831348(v=ws.11)) 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](/azure/active-directory/develop/active-directory-howto-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](/azure/multi-factor-authentication/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](/azure/multi-factor-authentication/multi-factor-authentication-whats-next) 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](/azure/multi-factor-authentication/multi-factor-authentication-get-started-user-states) 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](/windows-server/identity/ad-fs/operations/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](hello-hybrid-key-trust-devreg.md)
<br><br>
<hr>
## Follow the Windows Hello for Business hybrid key trust deployment guide
1. [Overview](hello-hybrid-key-trust.md)
2. [Prerequisites](hello-hybrid-key-trust-prereqs.md)
3. New Installation Baseline (*You are here*)
4. [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md)
5. [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md)
6. [Configure Windows Hello for Business settings](hello-hybrid-key-whfb-settings.md)
7. [Sign-in and Provision](hello-hybrid-key-whfb-provision.md)

238
windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md Normal file
View File

@ -0,0 +1,238 @@
---
title: Configure and validate the Public Key Infrastructure in a hybrid key trust model
description: Configure and validate the Public Key Infrastructure when deploying Windows Hello for Business in a hybrid key trust model.
ms.date: 12/21/2022
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
ms.topic: tutorial
---
# Configure and validate the Public Key Infrastructure - hybrid key trust
[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-key-trust.md)]
Windows Hello for Business must have a Public Key Infrastructure (PKI) when using the *key trust* or *certificate trust* models. The domain controllers must have a certificate, which serves as a *root of trust* for clients. The certificate ensures that clients don't communicate with rogue domain controllers.
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.
You can use a Windows Server-based PKI or 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](/troubleshoot/windows-server/windows-security/requirements-domain-controller).
## Deploy an enterprise certification authority
This guide assumes most enterprises have an existing public key infrastructure. Windows Hello for Business depends on an enterprise PKI running the Windows Server *Active Directory Certificate Services* role.
### Lab-based PKI
The following instructions may be used to deploy simple public key infrastructure that is suitable **for a lab environment**.
Sign in using *Enterprise Administrator* equivalent credentials on a Windows Server where you want the certification authority (CA) installed.
>[!NOTE]
>Never install a certification authority on a domain controller in a production environment.
1. Open an elevated Windows PowerShell prompt
1. Use the following command to install the Active Directory Certificate Services role.
```PowerShell
Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools
```
3. Use the following command to configure the CA using a basic certification authority configuration
```PowerShell
Install-AdcsCertificationAuthority
```
## Configure a PKI
If you don't have an existing PKI, review [Certification Authority Guidance](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831574(v=ws.11)) to properly design your infrastructure. Then, consult the [Test Lab Guide: Deploying an AD CS Two-Tier PKI Hierarchy](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831348(v=ws.11)) for instructions on how to configure your PKI using the information from your design session.
<!--
- 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 (`1.3.6.1.5.5.7.3.2`), Server Authentication (`1.3.6.1.5.5.7.3.1`), and KDC Authentication (`1.3.6.1.5.2.3.5`)
- 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](/windows/win32/seccertenroll/about-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](./hello-hybrid-key-whfb-settings-pki.md) for details -->
> [!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
Expand the following sections to configure the PKI for Windows Hello for Business.
<br>
<details>
<summary><b>Configure domain controller certificates</b></summary>
Clients must trust the domain controllers, and the best way to do it is to ensure each domain controller has a *Kerberos Authentication* certificate. Installing a certificate on the domain controllers enables the Key Distribution Center (KDC) to prove its identity to other members of the domain. The certificates provide clients a root of trust external to the domain, namely the *enterprise certification authority*.
Domain controllers automatically request a domain controller certificate (if published) when they discover an enterprise CA is added to Active Directory. However, certificates based on the *Domain Controller* and *Domain Controller Authentication* certificate templates don't include the *KDC Authentication* object identifier (OID), which was later added to the Kerberos RFC. Therefore, domain controllers need to request a certificate based on the *Kerberos Authentication* certificate template.
> [!NOTE]
> Inclusion of the *KDC Authentication* OID in domain controller certificate is not required for hybrid Azure AD-joined devices. The OID is required for enabling authentication with Windows Hello for Business to on-premises resources by Azure AD-joined devices.
By default, the Active Directory CA provides and publishes the *Kerberos Authentication* certificate template. The cryptography configuration included in the template is based on older and less performant cryptography APIs. To ensure domain controllers request the proper certificate with the best available cryptography, use the *Kerberos Authentication* certificate template as a *baseline* to create an updated domain controller certificate template.
Sign in to a CA or management workstations with *Domain Administrator* equivalent credentials.
1. Open the **Certification Authority** management console
1. Right-click **Certificate Templates > Manage**
1. In the **Certificate Template Console**, right-click the **Kerberos Authentication** template in the details pane and select **Duplicate Template**
1. On the **Compatibility** tab:
- Clear the **Show resulting changes** check box
- Select **Windows Server 2016** from the **Certification Authority** list
- Select **Windows 10 / Windows Server 2016** from the **Certificate Recipient** list
1. On the **General** tab
- Type *Domain Controller Authentication (Kerberos)* in Template display name
- Adjust the validity and renewal period to meet your enterprise's needs
> [!NOTE]
> If you use different template names, you'll need to remember and substitute these names in different portions of the lab.
1. On the **Subject Name** tab:
- Select the **Build from this Active Directory information** button if it isn't already selected
- Select **None** from the **Subject name format** list
- Select **DNS name** from the **Include this information in alternate subject** list
- Clear all other items
1. On the **Cryptography** tab:
- select **Key Storage Provider** from the **Provider Category** list
- Select **RSA** from the **Algorithm name** list
- Type *2048* in the **Minimum key size** text box
- Select **SHA256** from the **Request hash** list
1. Select **OK**
1. Close the console
</details>
<br>
<details>
<summary><b>Supersede existing domain controller certificates</b></summary>
The domain controllers may have an existing domain controller certificate. The Active Directory Certificate Services provides a default certificate template for domain controllers called *domain controller certificate*. Later releases of Windows Server provided a new certificate template called *domain controller authentication certificate*. These certificate templates were provided prior to the update of the Kerberos specification that stated Key Distribution Centers (KDCs) performing certificate authentication needed to include the *KDC Authentication* extension.
The *Kerberos Authentication* certificate template is the most current certificate template designated for domain controllers, and should be the one you deploy to all your domain controllers.\
The *autoenrollment* feature allows you to replace the domain controller certificates. Use the following configuration to replace older domain controller certificates with new ones, using the *Kerberos Authentication* certificate template.
Sign in to a CA or management workstations with *Enterprise Administrator* equivalent credentials.
1. Open the **Certification Authority** management console
1. Right-click **Certificate Templates > Manage**
1. In the **Certificate Template Console**, right-click the *Domain Controller Authentication (Kerberos)* (or the name of the certificate template you created in the previous section) template in the details pane and select **Properties**
1. Select the **Superseded Templates** tab. Select **Add**
1. From the **Add Superseded Template** dialog, select the *Domain Controller* certificate template and select **OK > Add**
1. From the **Add Superseded Template** dialog, select the *Domain Controller Authentication* certificate template and select **OK**
1. From the **Add Superseded Template** dialog, select the *Kerberos Authentication* certificate template and select **OK**
1. Add any other enterprise certificate templates that were previously configured for domain controllers to the **Superseded Templates** tab
1. Select **OK** and close the **Certificate Templates** console
The certificate template is configured to supersede all the certificate templates provided in the certificate templates superseded templates list. However, the certificate template and the superseding of certificate templates isn't active until the certificate template is published to one or more certificate authorities.
> [!NOTE]
> The domain controller's certificate must chain to a root in the NTAuth store. By default, the Active Directory Certificate Authority's root certificate is added to the NTAuth store. If you are using a third-party CA, this may not be done by default. If the domain controller certificate does not chain to a root in the NTAuth store, user authentication will fail.
>To see all certificates in the NTAuth store, use the following command:
>
> `Certutil -viewstore -enterprise NTAuth`
</details>
<br>
<details>
<summary><b>Unpublish Superseded Certificate Templates</b></summary>
The certification authority only issues certificates based on published certificate templates. For security, it's a good practice to unpublish certificate templates that the CA isn't configured to issue. This includes the pre-published certificate template from the role installation and any superseded certificate templates.
The newly created *domain controller authentication* certificate template supersedes previous domain controller certificate templates. Therefore, you need to unpublish these certificate templates from all issuing certificate authorities.
Sign in to the CA or management workstation with *Enterprise Administrator* equivalent credentials.
1. Open the **Certification Authority** management console
1. Expand the parent node from the navigation pane > **Certificate Templates**
1. Right-click the *Domain Controller* certificate template and select **Delete**. Select **Yes** on the **Disable certificate templates** window
1. Repeat step 3 for the *Domain Controller Authentication* and *Kerberos Authentication* certificate templates
</details>
<br>
<details>
<summary><b>Publish certificate templates to the CA</b></summary>
A certification authority can only issue certificates for certificate templates that are published to it. If you have more than one CA, and you want more CAs to issue certificates based on the certificate template, then you must publish the certificate template to them.
Sign in to the CA or management workstations with **Enterprise Admin** equivalent credentials.
1. Open the **Certification Authority** management console
1. Expand the parent node from the navigation pane
1. Select **Certificate Templates** in the navigation pane
1. Right-click the **Certificate Templates** node. Select **New > Certificate Template** to issue
1. In the **Enable Certificates Templates** window, select the *Domain Controller Authentication (Kerberos)*, and *Internal Web Server* templates you created in the previous steps. Select **OK** to publish the selected certificate templates to the certification authority
1. If you published the *Domain Controller Authentication (Kerberos)* certificate template, then unpublish the certificate templates you included in the superseded templates list
- To unpublish a certificate template, right-click the certificate template you want to unpublish and select **Delete**. Select **Yes** to confirm the operation
1. Close the console
</details>
### Configure automatic certificate enrollment for the domain controllers
Domain controllers automatically request a certificate from the *Domain controller certificate* template. However, domain controllers are unaware of newer certificate templates or superseded configurations on certificate templates. To continue automatic enrollment and renewal of domain controller certificates, create and configure a Group Policy Object (GPO) for automatic certificate enrollment, linking the Group Policy object to the *Domain Controllers* Organizational Unit (OU).
1. Open the **Group Policy Management Console** (gpmc.msc)
1. Expand the domain and select the **Group Policy Object** node in the navigation pane
1. Right-click **Group Policy object** and select **New**
1. Type *Domain Controller Auto Certificate Enrollment* in the name box and select **OK**
1. Right-click the **Domain Controller Auto Certificate Enrollment** Group Policy object and select **Edit**
1. In the navigation pane, expand **Policies** under **Computer Configuration**
1. Expand **Windows Settings > Security Settings > Public Key Policies**
1. In the details pane, right-click **Certificate Services Client - Auto-Enrollment** and select **Properties**
1. Select **Enabled** from the **Configuration Model** list
1. Select the **Renew expired certificates, update pending certificates, and remove revoked certificates** check box
1. Select the **Update certificates that use certificate templates** check box
1. Select **OK**
1. Close the **Group Policy Management Editor**
### Deploy the domain controller auto certificate enrollment GPO
Sign in to domain controller or management workstations with *Domain Administrator* equivalent credentials.
1. Start the **Group Policy Management Console** (gpmc.msc)
1. In the navigation pane, expand the domain and expand the node with the Active Directory domain name. Right-click the **Domain Controllers** organizational unit and select **Link an existing GPO…**
1. In the **Select GPO** dialog box, select *Domain Controller Auto Certificate Enrollment* or the name of the domain controller certificate enrollment Group Policy object you previously created
1. Select **OK**
## Validate the configuration
Windows Hello for Business is a distributed system, which on the surface appears complex and difficult. The key to a successful Windows Hello for Business deployment is to validate phases of work prior to moving to the next phase.
You want to confirm your domain controllers enroll the correct certificates and not any unnecessary (superseded) certificate templates. You need to check each domain controller that autoenrollment for the computer occurred.
### Use the event logs
Sign in to domain controller or management workstations with *Domain Administrator* equivalent credentials.
1. Using the Event Viewer, navigate to the **Application and Services > Microsoft > Windows > CertificateServices-Lifecycles-System** event log
1. Look for an event indicating a new certificate enrollment (autoenrollment):
- The details of the event include the certificate template on which the certificate was issued
- The name of the certificate template used to issue the certificate should match the certificate template name included in the event
- The certificate thumbprint and EKUs for the certificate are also included in the event
- The EKU needed for proper Windows Hello for Business authentication is Kerberos Authentication, in addition to other EKUs provide by the certificate template
Certificates superseded by your new domain controller certificate generate an archive event in the event log. The archive event contains the certificate template name and thumbprint of the certificate that was superseded by the new certificate.
### Certificate Manager
You can use the Certificate Manager console to validate the domain controller has the properly enrolled certificate based on the correct certificate template with the proper EKUs. Use **certlm.msc** to view certificate in the local computers certificate stores. Expand the **Personal** store and view the certificates enrolled for the computer. Archived certificates don't appear in Certificate Manager.
### Certutil.exe
You can use `certutil.exe` command to view enrolled certificates in the local computer. Certutil shows enrolled and archived certificates for the local computer. From an elevated command prompt, run `certutil.exe -q -store my` to view locally enrolled certificates.
To view detailed information about each certificate in the store, use `certutil.exe -q -v -store my` to validate automatic certificate enrollment enrolled the proper certificates.
### Troubleshooting
Windows triggers automatic certificate enrollment for the computer during boot, and when Group Policy updates. You can refresh Group Policy from an elevated command prompt using `gpupdate.exe /force`.
Alternatively, you can forcefully trigger automatic certificate enrollment using `certreq.exe -autoenroll -q` from an elevated command prompt.
Use the event logs to monitor certificate enrollment and archive. Review the configuration, such as publishing certificate templates to issuing certification authority and the allow auto enrollment permissions.
> [!div class="nextstepaction"]
> [Next: prepare and deploy AD FS >](hello-key-trust-adfs.md)

255
windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
View File

@ -1,5 +1,5 @@
---
title: Deploy Windows Hello for Business hybrid key trust
title: Windows Hello for Business hybrid key trust deployment
description: Learn how to deploy Windows Hello for Business in a hybrid key trust scenario.
ms.date: 12/20/2022
appliesto:
@ -7,88 +7,38 @@ appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
ms.topic: how-to
---
# Hybrid Azure AD joined Key Trust Deployment
# Hybrid key trust deployment
[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-key-trust.md)]
Windows Hello for Business replaces username and password sign-in to Windows with strong user authentication based on asymmetric key pair. The following deployment guide provides the information needed to successfully deploy Windows Hello for Business in a hybrid key trust scenario.\
This deployment guide provides guidance for new and existing deployments, where customers may already be federated with Azure AD.
Windows Hello for Business replaces password sign-in with strong authentication, using an asymmetric key pair. This deployment guide provides the information to deploy Windows Hello for Business in a hybrid key trust trust scenario.
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 and single sign-on to modern resources.
## Prerequisites
| Requirement | Notes |
| --- | --- |
| Directories |Hybrid Windows Hello for Business needs two directories: on-premises Active Directory and a cloud Azure Active Directory |
| Directory synchronization | 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 |
| Device registration| The devices must be registered to Azure Active Directory. This ensures that only approved computers are used with that Azure AD tenant. You can use Azure AD Join or Hybrid Azure AD Join to register devices to Azure Active Directory|
| Public Key Infrastructure | An enterprise PKI is required as *trust anchor* for authentication. Domain controllers require a certificate for Windows clients to trust them |
| Authentication to Azure AD | Authentication to Azure AD can be configured with or without federation:<br><ul><li>for non-federated environments, you must deploy [Password Synchronization with Azure AD Connect](/azure/active-directory/hybrid/whatis-phs) or [Azure Active Directory Pass-through-Authentication](/azure/active-directory/connect/active-directory-aadconnect-pass-through-authentication)</li><li>for federated environments, you can deploy Windows Hello for Business key trust using Active Directory Federation Services (AD FS) or third-party federation services</li></ul>|
|Multi-factor authentication|The Windows Hello for Business provisioning process lets a user enroll in Windows Hello for Business using their user name and password as one factor, but requires a second factor of authentication. Hybrid deployments can use:<br><ul><li>Azure Multifactor Authentication (MFA) service</li><li>A multi-factor authentication provided by AD FS, which includes an adapter model that enables third parties to integrate their MFA into AD FS</li></ul>|
| Device management | Devices can be configured with group polices or through mobile device management (MDM) policies|
| Requirement | Notes | Reference |
| --- | --- | ---|
| Directories |Hybrid Windows Hello for Business needs two directories: on-premises Active Directory and a cloud Azure Active Directory. Ensure that you have [adequate Domain Controllers](/windows/security/identity-protection/hello-for-business/hello-adequate-domain-controllers) in each Active Directory site where users will be authenticating with Windows Hello for Business ||
| Directory synchronization | 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. In hybrid deployments, users register the public portion of their Windows Hello for Business credential with Azure AD. Azure AD Connect synchronizes the Windows Hello for Business public key to Active Directory. Windows Hello for Business Hybrid key trust is not supported if your users' on-premises domain cannot be added as a verified domain in Azure AD. |Review the [Integrating on-prem directories with Azure Active Directory](/azure/active-directory/connect/active-directory-aadconnect) and [hardware and prerequisites](/azure/active-directory/connect/active-directory-aadconnect-prerequisites) needed and then [download the software](https://go.microsoft.com/fwlink/?LinkId=615771)|
| Device registration| The devices must be registered to Azure Active Directory. This ensures that only approved computers are used with that Azure AD tenant. You can use Azure AD Join or Hybrid Azure AD Join to register devices to Azure Active Directory||
| Public Key Infrastructure | An enterprise PKI is required as *trust anchor* for authentication. Domain controllers require a certificate for Windows clients to trust them ||
| Authentication to Azure AD | Authentication to Azure AD can be configured with or without federation:<br><ul><li>for non-federated environments, you must deploy [Password Synchronization with Azure AD Connect](/azure/active-directory/hybrid/whatis-phs) or [Azure Active Directory Pass-through-Authentication](/azure/active-directory/connect/active-directory-aadconnect-pass-through-authentication)</li><li>for federated environments, you can deploy Windows Hello for Business key trust using Active Directory Federation Services (AD FS) or third-party federation services</li></ul>||
|Multi-factor authentication|The Windows Hello for Business provisioning process lets a user enroll in Windows Hello for Business using their user name and password as one factor, but requires a second factor of authentication. Hybrid deployments can use:<br><ul><li>Azure Multifactor Authentication (MFA) service</li><li>A multi-factor authentication provided by AD FS, which includes an adapter model that enables third parties to integrate their MFA into AD FS</li></ul>|Review the [What is Azure AD Multi-Factor Authentication](/azure/multi-factor-authentication/multi-factor-authentication) topic to familiarize yourself its purpose and how it works.Review the [Configure Azure AD Multi-Factor Authentication settings](/azure/multi-factor-authentication/multi-factor-authentication-whats-next) section to configure your settings.After you have completed configuring your Azure MFA settings, you want to review [How to require two-step verification for a user](/azure/multi-factor-authentication/multi-factor-authentication-get-started-user-states) to understand user states. User states determine how you enable Azure MFA for your users.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](/windows-server/identity/ad-fs/operations/configure-ad-fs-2016-and-azure-mfa) section.|
| Device management | Devices can be configured with group polices or through mobile device management (MDM) policies||
## Next Steps
## Deployment steps
Follow the Windows Hello for Business hybrid key trust deployment guide:
Deploying Windows Hello for Business with a hybrid key trust model consists of XXX steps:
- Validate and configure a PKI
- 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**
> [!div class="op_single_selector"]
> - [New Installation Baseline](hello-hybrid-key-new-install.md)
> - [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md)
> - [Configure Windows Hello for Business settings](hello-hybrid-key-whfb-settings.md)
<!-- 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.
You can use a Windows Server-based PKI or 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](/troubleshoot/windows-server/windows-security/requirements-domain-controller).
- 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 (`1.3.6.1.5.5.7.3.2`), Server Authentication (`1.3.6.1.5.5.7.3.1`), and KDC Authentication (`1.3.6.1.5.2.3.5`)
- 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](/windows/win32/seccertenroll/about-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](./hello-hybrid-key-whfb-settings-pki.md) for details
> [!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
-->
## Deploy Azure AD Connect
Next, you need to synchronize the on-premises Active Directory with Azure Active Directory. To do this, first review the [Integrating on-prem directories with Azure Active Directory](/azure/active-directory/connect/active-directory-aadconnect) and [hardware and prerequisites](/azure/active-directory/connect/active-directory-aadconnect-prerequisites) needed and then [download the software](https://go.microsoft.com/fwlink/?LinkId=615771).
> [!NOTE]
> If you installed Azure AD Connect prior to upgrading the schema, you will need to re-run the Azure AD Connect installation and refresh the on-premises AD schema to ensure the synchronization rule for msDS-KeyCredentialLink is configured.
<br>
If the user principal name (UPN) in your on-premises Active Directory is different from the UPN in Azure AD, you also need to complete the following steps:
- Configure Azure AD Connect to sync the user's on-premises UPN to the onPremisesUserPrincipalName attribute in Azure AD.
- Add the domain name of the on-premises UPN as a [verified domain](/azure/active-directory/fundamentals/add-custom-domain) in Azure AD.
> [!NOTE]
> Windows Hello for Business Hybrid key trust is not supported if your users' on-premises domain cannot be added as a verified domain in Azure AD.
## Configure Hybrid Azure AD join
You're ready to configure device registration for your hybrid environment. Hybrid Windows Hello for Business deployment needs device registration to enable proper device authentication.
> [!NOTE]
> Before proceeding, you should familiarize yourself with device registration concepts such as:
> * Azure AD registered devices
> * Azure AD-joined devices
> * Hybrid Azure AD-joined devices
>
> You can learn about this and more by reading [What is a device identity](/azure/active-directory/devices/overview)
Begin configuring device registration to support Hybrid Windows Hello for Business by configuring device registration capabilities in Azure AD.
Follow the guidance on the [How to configure hybrid Azure Active Directory-joined devices](/azure/active-directory/devices/hybrid-azuread-join-plan) page. In the **Select your scenario based on your identity infrastructure** section, identify your configuration (either **Managed environment** or **Federated environment**) and perform only the steps applicable to your environment.
@ -100,8 +50,6 @@ If the user principal name (UPN) in your on-premises Active Directory is differe
You can learn more about this scenario by reading [Review on-premises UPN support for Hybrid Azure Ad join](/azure/active-directory/devices/hybrid-azuread-join-plan#review-on-premises-ad-users-upn-support-for-hybrid-azure-ad-join).
> [!NOTE]
> Windows Hello for Business Hybrid key trust is not supported if your users' on-premises domain cannot be added as a verified domain in Azure AD.
The configuration for Windows Hello for Business is grouped in four categories. These categories are:
### Configure AD - Creating Security Groups
@ -121,182 +69,21 @@ Sign-in a domain controller or management workstation with *Domain Admin* equiva
5. Type **Windows Hello for Business Users** in the **Group Name** text box.
6. Click **OK**.
## Directory Synchronization
In hybrid deployments, users register the public portion of their Windows Hello for Business credential with Azure AD. Azure AD Connect synchronizes the Windows Hello for Business public key to Active Directory.
### Group Memberships for the Azure AD Connect Service Account
>[!IMPORTANT]
> If you already have a Windows Server 2016 domain controller in your domain, you can skip **Configure Permissions for Key Synchronization**. For more detail see [Configure Hybrid Windows Hello for Business: Directory Synchronization](./hello-hybrid-cert-whfb-settings-dir-sync.md).
The KeyAdmins global group provides the Azure AD Connect service with the permissions needed to read and write the public key to Active Directory.
Sign-in a domain controller or management workstation with _Domain Admin_ equivalent credentials.
1. Open **Active Directory Users and Computers**.
2. Click the **Users** container in the navigation pane.
3. Right-click **Key Admins** in the details pane and click **Properties**.
4. Click the **Members** tab and click **Add**
5. In the **Enter the object names to select** text box, type the name of the service account used as an AD DS Connector account and click **OK**.
6. Click **OK** to return to **Active Directory Users and Computers**.
> [!NOTE]
> If your Active Directory forest has multiple domains, your ADConnect accounts need to be members of the **Enterprise Key Admins** group. This membership is needed to write the keys to other domain users.
# Configure Hybrid Azure AD joined Windows Hello for Business: Public Key Infrastructure
Windows Hello for Business deployments rely on certificates. Hybrid deployments use publicly issued server authentication certificates to validate the name of the server to which they are connecting and to encrypt the data that flows them and the client computer.
All deployments use enterprise issued certificates for domain controllers as a root of trust.
## Certificate Templates
This section has you configure certificate templates on your Windows Server 2012 or later issuing certificate authority.
### Domain Controller certificate template
Clients need to trust domain controllers and the best way to do this is to ensure each domain controller has a Kerberos Authentication certificate. Installing a certificate on the domain controller enables the Key Distribution Center (KDC) to prove its identity to other members of the domain. This provides clients a root of trust external to the domain - namely the enterprise certificate authority.
Domain controllers automatically request a domain controller certificate (if published) when they discover an enterprise certificate authority is added to Active Directory. However, certificates based on the *Domain Controller* and *Domain Controller Authentication* certificate templates do not include the **KDC Authentication** object identifier (OID), which was later added to the Kerberos RFC. Inclusion of the **KDC Authentication** OID in domain controller certificate is not required for key trust authentication from Hybrid Azure AD-joined devices. The OID is required for enabling authentication with Windows Hello for Business to on-premises resources by Azure AD-joined devices. The steps below to update the domain controller certificate to include the **KDC Authentication** OID may be skipped if you only have Hybrid Azure AD Joined devices in your environment, but we recommend completing these steps if you are considering adding Azure AD-joined devices to your environment in the future.
By default, the Active Directory Certificate Authority provides and publishes the Kerberos Authentication certificate template. However, the cryptography configuration included in the provided template is based on older and less performant cryptography APIs. To ensure domain controllers request the proper certificate with the best available cryptography, use the **Kerberos Authentication** certificate template a baseline to create an updated domain controller certificate template.
#### Create a Domain Controller Authentication (Kerberos) Certificate Template
Sign-in a certificate authority or management workstations with _Domain Admin_ equivalent credentials.
1. Open the **Certificate Authority** management console.
2. Right-click **Certificate Templates** and click **Manage**.
3. In the **Certificate Template Console**, right-click the **Kerberos Authentication** template in the details pane and click **Duplicate Template**.
4. On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2008 R2** from the **Certification Authority** list. Select **Windows 7.Server 2008 R2** from the **Certificate Recipient** list.
5. On the **General** tab, type **Domain Controller Authentication (Kerberos)** in Template display name. Adjust the validity and renewal period to meet your enterprise's needs.
> [!NOTE]
> If you use different template names, you'll need to remember and substitute these names in different portions of the lab.
6. On the **Subject Name** tab, select the **Build from this Active Directory information** button if it is not already selected. Select **None** from the **Subject name format** list. Select **DNS name** from the **Include this information in alternate subject** list. Clear all other items.
7. On the **Cryptography** tab, select **Key Storage Provider** from the **Provider Category** list. Select **RSA** from the **Algorithm name** list. Type **2048** in the **Minimum key size** text box. Select **SHA256** from the **Request hash** list. Click **OK**.
8. Close the console.
>[!NOTE]
>Don't confuse the **Request hash** algorithm with the hash argorithm of the certificate.
#### Configure Certificate Superseding for the Domain Controller Authentication (Kerberos) Certificate Template
Many domain controllers may have an existing domain controller certificate. The Active Directory Certificate Services provides a default certificate template for domain controllers--the domain controller certificate template. Later releases provided a new certificate template--the domain controller authentication certificate template. These certificate templates were provided prior to update of the Kerberos specification that stated Key Distribution Centers (KDCs) performing certificate authentication needed to include the **KDC Authentication** extension.
The Kerberos Authentication certificate template is the most current certificate template designated for domain controllers and should be the one you deploy to all your domain controllers (2008 or later).
The autoenrollment feature in Windows enables you to effortlessly replace these domain controller certificates. You can use the following configuration to replace older domain controller certificates with a new certificate using the Kerberos Authentication certificate template.
Sign-in a certificate authority or management workstations with _Enterprise Admin_ equivalent credentials.
1. Open the **Certificate Authority** management console.
2. Right-click **Certificate Templates** and click **Manage**.
3. In the **Certificate Template Console**, right-click the **Domain Controller Authentication (Kerberos)** (or the name of the certificate template you created in the previous section) template in the details pane and click **Properties**.
4. Click the **Superseded Templates** tab. Click **Add**.
5. From the **Add Superseded Template** dialog, select the **Domain Controller** certificate template and click **OK**. Click **Add**.
6. From the **Add Superseded Template** dialog, select the **Domain Controller Authentication** certificate template and click **OK**.
7. From the **Add Superseded Template dialog**, select the **Kerberos Authentication** certificate template and click **OK**.
8. Add any other enterprise certificate templates that were previously configured for domain controllers to the **Superseded Templates** tab.
9. Click **OK** and close the **Certificate Templates** console.
The certificate template is configured to supersede all the certificate templates provided in the certificate templates superseded templates list. However, the certificate template and the superseding of certificate templates is not active until you publish the certificate template to one or more certificate authorities.
> [!NOTE]
> The domain controller's certificate must chain to a root in the NTAuth store. By default, the Active Directory Certificate Authority's root certificate is added to the NTAuth store. If you are using a third-party CA, this may not be done by default. If the domain controller certificate does not chain to a root in the NTAuth store, user authentication will fail.
>To see all certificates in the NTAuth store, use the following command:
>
> `Certutil -viewstore -enterprise NTAuth`
### Publish Certificate Templates to a Certificate Authority
The certificate authority may only issue certificates for certificate templates that are published to that certificate authority. If you have more than one certificate authority and you want that certificate authority to issue certificates based on a specific certificate template, then you must publish the certificate template to all certificate authorities that are expected to issue the certificate.
Sign-in to the certificate authority or management workstations with _enterprise administrator_ equivalent credentials.
1. Open the **Certificate Authority** management console.
2. Expand the parent node from the navigation pane.
3. Click **Certificate Templates** in the navigation pane.
4. Right-click the **Certificate Templates** node. Click **New**, and click **Certificate Template** to issue.
5. In the **Enable Certificates Templates** window, select the **Domain Controller Authentication (Kerberos)** template you created in the previous steps. Click **OK** to publish the selected certificate templates to the certificate authority.
6. If you published the **Domain Controller Authentication (Kerberos)** certificate template, then you should unpublish the certificate templates you included in the superseded templates list.
- To unpublish a certificate template, right-click the certificate template you want to unpublish in the details pane of the Certificate Authority console and select **Delete**. Click **Yes** to confirm the operation.
7. Close the console.
### Unpublish Superseded Certificate Templates
The certificate authority only issues certificates based on published certificate templates. For defense in depth security, it is a good practice to unpublish certificate templates that the certificate authority is not configured to issue. This includes the pre-published certificate template from the role installation and any superseded certificate templates.
The newly created domain controller authentication certificate template supersedes previous domain controller certificate templates. Therefore, you need to unpublish these certificate templates from all issuing certificate authorities.
Sign-in to the certificate authority or management workstation with _Enterprise Admin_ equivalent credentials.
1. Open the **Certificate Authority** management console.
2. Expand the parent node from the navigation pane.
3. Click **Certificate Templates** in the navigation pane.
4. Right-click the **Domain Controller** certificate template in the content pane and select **Delete**. Click **Yes** on the **Disable certificate templates** window.
5. Repeat step 4 for the **Domain Controller Authentication** and **Kerberos Authentication** certificate templates.
## Policy Configuration
You need at least a Windows 10, version 1703 workstation to run the Group Policy Management Console, which provides the latest Windows Hello for Business and PIN Complexity Group Policy settings. To run the Group Policy Management Console, you need to install the Remote Server Administration Tools for Windows. You can download these tools from the [Microsoft Download Center](https://www.microsoft.com/download/details.aspx?id=45520).
Install the Remote Server Administration Tools for Windows on a computer running Windows 10, version 1703 or later.
Alternatively, you can create copy the .ADMX and .ADML files from a Windows 10 Creators Edition (1703) to their respective language folder on a Windows Server or you can create a Group Policy Central Store and copy them their respective language folder. See [How to create and manage the Central Store for Group Policy Administrative Templates in Windows](/troubleshoot/windows-client/group-policy/create-and-manage-central-store) for more information.
Domain controllers of Windows Hello for Business deployments need one Group Policy setting, which enables automatic certificate enrollment for the newly create domain controller authentication certificate. This policy setting ensures domain controllers (new and existing) automatically request and renew the correct domain controller certificate.
Hybrid Azure AD-joined devices need one Group Policy setting:
* Enable Windows Hello for Business
### Configure Domain Controllers for Automatic Certificate Enrollment
Domain controllers automatically request a certificate from the *Domain Controller* certificate template. However, the domain controller is unaware of newer certificate templates or superseded configurations on certificate templates.
To continue automatic enrollment and renewal of domain controller certificates that understand newer certificate template and superseded certificate template configurations, create and configure a Group Policy object for automatic certificate enrollment and link the Group Policy object to the Domain Controllers OU.
#### Create a Domain Controller Automatic Certificate Enrollment Group Policy object
Sign-in a domain controller or management workstations with _Domain Admin_ equivalent credentials.
1. Start the **Group Policy Management Console** (gpmc.msc)
2. Expand the domain and select the **Group Policy Object** node in the navigation pane.
3. Right-click **Group Policy object** and select **New**
4. Type *Domain Controller Auto Certificate Enrollment* in the name box and click **OK**.
5. Right-click the **Domain Controller Auto Certificate Enrollment** Group Policy object and click **Edit**.
6. In the navigation pane, expand **Policies** under **Computer Configuration**.
7. Expand **Windows Settings**, **Security Settings**, and click **Public Key Policies**.
8. In the details pane, right-click **Certificate Services Client <20> Auto-Enrollment** and select **Properties**.
9. Select **Enabled** from the **Configuration Model** list.
10. Select the **Renew expired certificates**, **update pending certificates**, and **remove revoked certificates** check box.
11. Select the **Update certificates that use certificate templates** check box.
12. Click **OK**. Close the **Group Policy Management Editor**.
#### Deploy the Domain Controller Auto Certificate Enrollment Group Policy Object
Sign-in a domain controller or management workstations with _Domain Admin_ equivalent credentials.
1. Start the **Group Policy Management Console** (gpmc.msc)
2. In the navigation pane, expand the domain and expand the node that has your Active Directory domain name. Right-click the **Domain Controllers** organizational unit and click **Link an existing GPO<50>**
3. In the **Select GPO** dialog box, select **Domain Controller Auto Certificate Enrollment** or the name of the domain controller certificate enrollment Group Policy object you previously created and click **OK**.
>[!IMPORTANT]
>If you don't find options in GPO, you have to load the [PolicyDefinitions folder](/troubleshoot/windows-client/group-policy/create-and-manage-central-store).
### Windows Hello for Business Group Policy
## Windows Hello for Business Group Policy
The Windows Hello for Business Group Policy object delivers the correct Group Policy settings to the user, which enables them to enroll and use Windows Hello for Business to authenticate to Azure and Active Directory
> [!NOTE]
> If you deployed Windows Hello for Business configuration using both Group Policy and Microsoft Intune, Group Policy settings will take precedence and Intune settings will be ignored. For more details about deploying Windows Hello for Business configuration using Microsoft Intune, see [Windows device settings to enable Windows Hello for Business in Intune](/mem/intune/protect/identity-protection-windows-settings) and [PassportForWork CSP](/windows/client-management/mdm/passportforwork-csp). For more details about policy conflicts, see [Policy conflicts from multiple policy sources](./hello-manage-in-organization.md#policy-conflicts-from-multiple-policy-sources)
#### Enable Windows Hello for Business
### Enable Windows Hello for Business
The Enable Windows Hello for Business Group Policy setting is the configuration needed for Windows to determine if a user should attempt to enroll for Windows Hello for Business. A user will only attempt enrollment if this policy setting is configured to enabled.
You can configure the Enable Windows Hello for Business Group Policy setting for computer or users. Deploying this policy setting to computers results in ALL users that sign-in that computer to attempt a Windows Hello for Business enrollment. Deploying this policy setting to a user results in only that user attempting a Windows Hello for Business enrollment. Additionally, you can deploy the policy setting to a group of users so only those users attempt a Windows Hello for Business enrollment. If both user and computer policy settings are deployed, the user policy setting has precedence.
#### Create the Windows Hello for Business Group Policy object
### Create the Windows Hello for Business Group Policy object
The Group Policy object contains the policy setting needed to trigger Windows Hello for Business provisioning.
@ -311,7 +98,7 @@ Sign-in a domain controller or management workstations with _Domain Admin_ equiv
7. Expand **Administrative Templates > Windows Component**, and select **Windows Hello for Business**.
8. In the content pane, double-click **Use Windows Hello for Business**. Click **Enable** and click **OK**. Close the **Group Policy Management Editor**.
#### Configure Security in the Windows Hello for Business Group Policy object
### Configure Security in the Windows Hello for Business Group Policy object
The best way to deploy the Windows Hello for Business Group Policy object is to use security group filtering. The enables you to easily manage the users that should receive Windows Hello for Business by simply adding them to a group. This enables you to deploy Windows Hello for Business in phases.
1. Start the **Group Policy Management Console** (gpmc.msc)
@ -321,7 +108,7 @@ The best way to deploy the Windows Hello for Business Group Policy object is to
5. Click the **Delegation** tab. Select **Authenticated Users** and click **Advanced**.
6. In the **Group or User names** list, select **Authenticated Users**. In the **Permissions for Authenticated Users** list, clear the **Allow** check box for the **Apply Group Policy** permission. Click **OK**.
#### Deploy the Windows Hello for Business Group Policy object
### Deploy the Windows Hello for Business Group Policy object
The application of the Windows Hello for Business Group Policy object uses security group filtering. This enables you to link the Group Policy object at the domain, ensuring the Group Policy object is within scope to all users. However, the security group filtering ensures only the users included in the *Windows Hello for Business Users* global group receive and apply the Group Policy object, which results in the provisioning of Windows Hello for Business.
1. Start the **Group Policy Management Console** (gpmc.msc)