From 611b44e1cfd22fe9e5fd1ec738ebc60890b6040f Mon Sep 17 00:00:00 2001
From: Paolo Matarazzo <74918781+paolomatarazzo@users.noreply.github.com>
Date: Wed, 14 Dec 2022 09:36:01 -0500
Subject: [PATCH 01/70] updates
---
.../hello-for-business/hello-hybrid-aadj-sso-base.md | 2 ++
1 file changed, 2 insertions(+)
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base.md
index a53b5977d6..012d660c6d 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base.md
@@ -1,3 +1,5 @@
+### YamlMime:MyArticle
+
---
title: Configure Azure AD-joined devices for On-premises Single-Sign On using Windows Hello for Business
description: Before adding Azure Active Directory (Azure AD) joined devices to your existing hybrid deployment, you need to verify the existing deployment can support them.
From fffe13efa824c1b18ffc4c18702257dd5a6fb0ef Mon Sep 17 00:00:00 2001
From: Paolo Matarazzo <74918781+paolomatarazzo@users.noreply.github.com>
Date: Wed, 14 Dec 2022 10:40:02 -0500
Subject: [PATCH 02/70] updates
---
.../hello-for-business/hello-hybrid-aadj-sso-base.md | 2 --
1 file changed, 2 deletions(-)
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base.md
index 012d660c6d..a53b5977d6 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base.md
@@ -1,5 +1,3 @@
-### YamlMime:MyArticle
-
---
title: Configure Azure AD-joined devices for On-premises Single-Sign On using Windows Hello for Business
description: Before adding Azure Active Directory (Azure AD) joined devices to your existing hybrid deployment, you need to verify the existing deployment can support them.
From 074be7f48f0c70c10fcd7bb2ac619f6ba3da10bd Mon Sep 17 00:00:00 2001
From: Paolo Matarazzo <74918781+paolomatarazzo@users.noreply.github.com>
Date: Tue, 20 Dec 2022 11:02:03 -0500
Subject: [PATCH 03/70] updates
---
windows/security/TOC.yml | 2 +-
.../hello-hybrid-aadj-sso-base.md | 2 +-
.../hello-hybrid-aadj-sso-cert.md | 2 +-
.../hello-hybrid-key-trust-prereqs.md | 157 +++++-------------
4 files changed, 41 insertions(+), 122 deletions(-)
diff --git a/windows/security/TOC.yml b/windows/security/TOC.yml
index 70275d478d..174d16071d 100644
--- a/windows/security/TOC.yml
+++ b/windows/security/TOC.yml
@@ -306,7 +306,7 @@
items:
- name: Overview
href: identity.md
- - name: Windows Hello for Business
+ - name: Windows Hello for Business >>
href: identity-protection/hello-for-business/index.yml
- name: Windows credential theft mitigation guide
href: identity-protection/windows-credential-theft-mitigation-guide-abstract.md
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base.md
index a53b5977d6..96c6e82af9 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base.md
@@ -4,7 +4,7 @@ description: Before adding Azure Active Directory (Azure AD) joined devices to y
ms.date: 01/14/2021
appliesto:
- ✅ Windows 10 and later
-ms.topic: article
+ms.topic: how-to
---
# Configure Azure AD-joined devices for On-premises Single-Sign On using Windows Hello for Business
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md
index e8e87a1d23..ceddc51ed4 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md
@@ -4,7 +4,7 @@ description: If you want to use certificates for on-premises single-sign on for
ms.date: 08/19/2018
appliesto:
- ✅ Windows 10 and later
-ms.topic: article
+ms.topic: how-to
---
# Using Certificates for AADJ On-premises Single-sign On
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-prereqs.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-prereqs.md
index 17e3fe7e61..321eeccceb 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-prereqs.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-prereqs.md
@@ -1,159 +1,78 @@
---
-title: Hybrid Azure AD joined Key trust Windows Hello for Business Prerequisites (Windows Hello for Business)
-description: Learn about the prerequisites for hybrid Windows Hello for Business deployments using key trust and what the next steps are in the deployment process.
-ms.date: 4/30/2021
+title: Deploy Windows Hello for Business hybrid key trust
+description: Learn about the prerequisites for the deployment of Windows Hello for Business in a hybrid key trust scenario.
+ms.date: 12/20/2022
appliesto:
- ✅ Windows 10 and later
-ms.topic: article
+- ✅ Windows Server 2016 and later
+ms.topic: how-to
---
-# Hybrid Azure AD joined Key trust Windows Hello for Business Prerequisites
+# Deploy Windows Hello for Business hybrid key trust
[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-key-trust.md)]
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:
+## Prerequisites
+### Directories
-- [Directories](#directories)
-- [Public Key Infrastructure](#public-key-infrastructure)
-- [Directory Synchronization](#directory-synchronization)
-- [Federation](#federation-with-azure)
-- [Multifactor authentication](#multifactor-authentication)
-- [Device Registration](#device-registration)
-
-## Directories
+Hybrid Windows Hello for Business needs two directories: on-premises Active Directory and a cloud Azure Active Directory.
-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.
+### Directory synchronization
-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.
+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.
-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](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.
-
-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.
-
-### Section Review
-
-> [!div class="checklist"]
-> * 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
+### 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.
+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](/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.
+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.
+> - 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"]
-> * Windows Server 2012 Issuing Certificate Authority
+### Federation with Azure
-
+You can deploy Windows Hello for Business key trust in non-federated or federated environments:
+- for non-federated environments, key trust deployments work iif you have deployed [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)
+- for federated environments, you can deploy Windows Hello for Business key trust using Active Directory Federation Services (AD FS) or third-party federation services
-## Directory Synchronization
+### Multi-factor authentication
-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.
-
-### Section Review
+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 requires a second factor of authentication.
-> [!div class="checklist"]
-> * Azure Active Directory Connect directory synchronization
-> * [Upgrade from DirSync](/azure/active-directory/connect/active-directory-aadconnect-dirsync-upgrade-get-started)
-> * [Upgrade from Azure AD Sync](/azure/active-directory/connect/active-directory-aadconnect-upgrade-previous-version)
+Hybrid Windows Hello for Business deployments can use Azure Multifactor Authentication (MFA) service or a multi-factor authentication provided by AD FS, which includes an adapter model that enables third parties to integrate their MFA into AD FS.
-
-
-## 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](/azure/active-directory/hybrid/whatis-phs) or [Azure Active Directory Pass-through-Authentication](/azure/active-directory/connect/active-directory-aadconnect-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.
-
-> [!div class="checklist"]
-> * Non-federated environments
-> * Federated environments
-
-
-
-## Multifactor Authentication
-
-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.
-
-### Section Review
-
-> [!div class="checklist"]
-> * 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)
-
-
-
-## Device Registration
+### Device Registration
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.
-## Provisioning
+### Provisioning
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.
-### Section Checklist
+## Next Steps
-> [!div class="checklist"]
-> * Device Registration with Azure Device Registration
+Follow the Windows Hello for Business hybrid key trust deployment guide:
-
-
-### Next Steps
-
-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**.
+- 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)
-
-
-
-
-
-## Follow the Windows Hello for Business hybrid key trust deployment guide
-
-1. [Overview](hello-hybrid-key-trust.md)
-2. Prerequisites (*You are here*)
-3. [New Installation Baseline](hello-hybrid-key-new-install.md)
-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)
From 527bfc5fa0c138392a75b65d5555ce3b7d9a6dd4 Mon Sep 17 00:00:00 2001
From: Paolo Matarazzo <74918781+paolomatarazzo@users.noreply.github.com>
Date: Tue, 20 Dec 2022 11:25:55 -0500
Subject: [PATCH 04/70] toc update
---
windows/security/TOC.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/windows/security/TOC.yml b/windows/security/TOC.yml
index 174d16071d..369c94ba95 100644
--- a/windows/security/TOC.yml
+++ b/windows/security/TOC.yml
@@ -306,7 +306,7 @@
items:
- name: Overview
href: identity.md
- - name: Windows Hello for Business >>
+ - name: Windows Hello for Business ⇒
href: identity-protection/hello-for-business/index.yml
- name: Windows credential theft mitigation guide
href: identity-protection/windows-credential-theft-mitigation-guide-abstract.md
From fcc60421c48add3449770f49ebf01a8bc32ef417 Mon Sep 17 00:00:00 2001
From: Paolo Matarazzo <74918781+paolomatarazzo@users.noreply.github.com>
Date: Tue, 20 Dec 2022 15:42:38 -0500
Subject: [PATCH 05/70] updates
---
.../hello-hybrid-key-trust-prereqs.md | 78 -------------------
.../hello-hybrid-key-trust.md | 66 ++++++++++------
2 files changed, 44 insertions(+), 100 deletions(-)
delete mode 100644 windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-prereqs.md
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-prereqs.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-prereqs.md
deleted file mode 100644
index 321eeccceb..0000000000
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-prereqs.md
+++ /dev/null
@@ -1,78 +0,0 @@
----
-title: Deploy Windows Hello for Business hybrid key trust
-description: Learn about the prerequisites for the deployment of Windows Hello for Business in a hybrid key trust scenario.
-ms.date: 12/20/2022
-appliesto:
-- ✅ Windows 10 and later
-- ✅ Windows Server 2016 and later
-ms.topic: how-to
----
-# Deploy Windows Hello for Business hybrid key trust
-
-[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-key-trust.md)]
-
-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.
-
-## Prerequisites
-### 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.
-
-### 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.
-
-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
-
-### Federation with Azure
-
-You can deploy Windows Hello for Business key trust in non-federated or federated environments:
-- for non-federated environments, key trust deployments work iif you have deployed [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)
-- for federated environments, you can deploy Windows Hello for Business key trust using Active Directory Federation Services (AD FS) or third-party federation services
-
-### Multi-factor authentication
-
-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 requires a second factor of authentication.
-
-Hybrid Windows Hello for Business deployments can use Azure Multifactor Authentication (MFA) service or a multi-factor authentication provided by AD FS, which includes an adapter model that enables third parties to integrate their MFA into AD FS.
-
-### Device Registration
-
-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.
-
-### Provisioning
-
-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.
-
-## Next Steps
-
-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**
-
-> [!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)
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
index 9ab687ded9..42e2fe2435 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
@@ -1,40 +1,62 @@
---
-title: Hybrid Key Trust Deployment (Windows Hello for Business)
-description: Review this deployment guide to successfully deploy Windows Hello for Business in a hybrid key trust scenario.
-ms.date: 08/20/2018
+title: Deploy Windows Hello for Business hybrid key trust
+description: Learn how to deploy Windows Hello for Business in a hybrid key trust scenario.
+ms.date: 12/20/2022
appliesto:
- ✅ Windows 10 and later
-ms.topic: article
+- ✅ Windows Server 2016 and later
+ms.topic: how-to
---
# Hybrid Azure AD joined 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.
+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.
-It is recommended that you review the Windows Hello for Business planning guide prior to using the deployment guide. The planning guide helps you make decisions by explaining the available options with each aspect of the deployment and explains the potential outcomes based on each of these decisions. You can review the [planning guide](/windows/access-protection/hello-for-business/hello-planning-guide) and download the [planning worksheet](https://go.microsoft.com/fwlink/?linkid=852514).
+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.
-This deployment guide provides guidance for new deployments and customers who are already federated with Azure AD. These two scenarios provide a baseline from which you can begin your deployment.
+## Prerequisites
-## New Deployment Baseline ##
+| 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:
- 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)
- for federated environments, you can deploy Windows Hello for Business key trust using Active Directory Federation Services (AD FS) or third-party federation services
|
+|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:
- Azure Multifactor Authentication (MFA) service
- A multi-factor authentication provided by AD FS, which includes an adapter model that enables third parties to integrate their MFA into AD FS
|
+| Device management | Devices can be configured with group polices or through mobile device management (MDM) policies|
-The new deployment baseline helps organizations who are moving to Azure AD to include Windows Hello for Business as part of their deployments. This baseline is good for organizations who are looking to deploy proof of concepts as well as IT professionals who want to familiarize themselves Windows Hello for Business by deploying a lab environment.
+## Next Steps
-This baseline provides detailed procedures to move your environment from an on-premises only environment to a hybrid environment using Windows Hello for Business to authenticate to Azure Active Directory and to your on-premises Active Directory using a single Windows sign-in.
+Follow the Windows Hello for Business hybrid key trust deployment guide:
-Your next step is to familiarize yourself with the prerequisites needed for the deployment. Many of the prerequisites will be new for organizations and individuals pursuing the new deployment baseline. Organizations and individuals starting from the federated baseline will likely be familiar with most of the prerequisites, but should validate they are using the proper versions that include the latest updates.
+- 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="nextstepaction"]
-> [Prerequisites](hello-hybrid-key-trust-prereqs.md)
+> [!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)
-
-## Follow the Windows Hello for Business hybrid key trust deployment guide
+
From 5416caeda5ed190ec8c9c80185a4aab1f50a0556 Mon Sep 17 00:00:00 2001
From: Paolo Matarazzo <74918781+paolomatarazzo@users.noreply.github.com>
Date: Tue, 20 Dec 2022 16:12:39 -0500
Subject: [PATCH 06/70] merged multiple files
---
.../hello-hybrid-key-trust-devreg.md | 47 ---
.../hello-hybrid-key-trust-dirsync.md | 41 ---
.../hello-hybrid-key-trust.md | 344 ++++++++++++++++++
.../hello-hybrid-key-whfb-provision.md | 59 ---
.../hello-hybrid-key-whfb-settings-ad.md | 53 ---
...hello-hybrid-key-whfb-settings-dir-sync.md | 54 ---
.../hello-hybrid-key-whfb-settings-pki.md | 128 -------
.../hello-hybrid-key-whfb-settings-policy.md | 169 ---------
.../hello-hybrid-key-whfb-settings.md | 37 --
9 files changed, 344 insertions(+), 588 deletions(-)
delete mode 100644 windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-devreg.md
delete mode 100644 windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-dirsync.md
delete mode 100644 windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-provision.md
delete mode 100644 windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-ad.md
delete mode 100644 windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-dir-sync.md
delete mode 100644 windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-pki.md
delete mode 100644 windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-policy.md
delete mode 100644 windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings.md
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-devreg.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-devreg.md
deleted file mode 100644
index e6d1d3275c..0000000000
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-devreg.md
+++ /dev/null
@@ -1,47 +0,0 @@
----
-title: Configure Device Registration for Hybrid Azure AD joined key trust Windows Hello for Business
-description: Azure Device Registration for Hybrid Certificate Key Deployment (Windows Hello for Business)
-ms.date: 05/04/2022
-appliesto:
-- ✅ Windows 10 and later
-ms.topic: article
----
-# Configure Device Registration for Hybrid Azure AD joined key trust Windows Hello for Business
-
-[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-key-trust.md)]
-
-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)
-
-## Configure Hybrid Azure AD join
-
-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.
-
-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.
-
-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.
-
-## Follow the Windows Hello for Business hybrid key trust deployment guide
-
-1. [Overview](hello-hybrid-cert-trust.md)
-2. [Prerequisites](hello-hybrid-cert-trust-prereqs.md)
-3. [New installation baseline](hello-hybrid-key-new-install.md)
-4. [Configure directory synchronization](hello-hybrid-key-trust-dirsync.md)
-5. Configure Azure Device Registration (*you're here*)
-6. [Configure Windows Hello for Business settings](hello-hybrid-key-whfb-settings.md)
-7. [Sign-in and provision](hello-hybrid-key-whfb-provision.md)
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-dirsync.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-dirsync.md
deleted file mode 100644
index 18df532ca9..0000000000
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-dirsync.md
+++ /dev/null
@@ -1,41 +0,0 @@
----
-title: Configure Directory Synchronization for Hybrid Azure AD joined key trust Windows Hello for Business
-description: Azure Directory Synchronization for Hybrid Certificate Key Deployment (Windows Hello for Business)
-ms.date: 4/30/2021
-appliesto:
-- ✅ Windows 10 and later
-ms.topic: article
----
-# Configure Directory Synchronization for Hybrid Azure AD joined key trust Windows Hello for Business
-
-[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-key-trust.md)]
-
-You are ready to configure directory synchronization for your hybrid environment. Hybrid Windows Hello for Business deployment needs both a cloud and an on-premises identity to authenticate and access resources in the cloud or on-premises.
-
-## 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.
-
-
-
-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.
-
-
-
-## 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](hello-hybrid-key-new-install.md)
-4. Configure Directory Synchronization (*You are here*)
-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)
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
index 42e2fe2435..da93775507 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
@@ -60,3 +60,347 @@ You can use a Windows Server-based PKI or a third-party Enterprise certification
> - 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.
+
+
+
+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.
+
+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.
+
+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
+
+Windows Hello for Business uses a security group to simplify the deployment and management.
+
+#### Create the Windows Hello for Business Users Security Group
+
+The Windows Hello for Business Users group is used to make it easy to deploy Windows Hello for Business in phases. You assign Group Policy and Certificate template permissions to this group to simplify the deployment by simply adding the users to the group. This provides users with the proper permissions to provision Windows Hello for Business and to enroll in the Windows Hello for Business authentication certificate.
+
+Sign-in a domain controller or management workstation with *Domain Admin* equivalent credentials.
+
+1. Open **Active Directory Users and Computers**.
+2. Click **View** and click **Advanced Features**.
+3. Expand the domain node from the navigation pane.
+4. Right-click the **Users** container. Click **New**. Click **Group**.
+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 � 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�**
+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
+
+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
+
+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
+
+The Group Policy object contains the policy setting needed to trigger Windows Hello for Business provisioning.
+
+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 *Enable Windows Hello for Business* in the name box and click **OK**.
+5. In the content pane, right-click the **Enable Windows Hello for Business** Group Policy object and click **Edit**.
+6. In the navigation pane, expand **Policies** under **User Configuration**.
+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
+
+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)
+2. Expand the domain and select the **Group Policy Object** node in the navigation pane.
+3. Double-click the **Enable Windows Hello for Business** Group Policy object.
+4. In the **Security Filtering** section of the content pane, click **Add**. Type *Windows Hello for Business Users* or the name of the security group you previously created and click **OK**.
+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
+
+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)
+2. In the navigation pane, expand the domain and right-click the node that has your Active Directory domain name and click **Link an existing GPO**
+3. In the **Select GPO** dialog box, select **Enable Windows Hello for Business** or the name of the Windows Hello for Business Group Policy object you previously created and click **OK**.
+
+Just to reassure, linking the **Windows Hello for Business** Group Policy object to the domain ensures the Group Policy object is in scope for all domain users. However, not all users will have the policy settings applied to them. Only users who are members of the Windows Hello for Business group receive the policy settings. All others users ignore the Group Policy object.
+
+## Other Related Group Policy settings
+
+### Windows Hello for Business
+
+There are other Windows Hello for Business policy settings you can configure to manage your Windows Hello for Business deployment. These policy settings are computer-based policy setting; so they are applicable to any user that sign-in from a computer with these policy settings.
+
+#### Use a hardware security device
+
+The default configuration for Windows Hello for Business is to prefer hardware protected credentials; however, not all computers are able to create hardware protected credentials. When Windows Hello for Business enrollment encounters a computer that cannot create a hardware protected credential, it will create a software-based credential.
+
+You can enable and deploy the **Use a hardware security device** Group Policy Setting to force Windows Hello for Business to only create hardware protected credentials. Users that sign-in from a computer incapable of creating a hardware protected credential do not enroll for Windows Hello for Business.
+
+Another policy setting becomes available when you enable the **Use a hardware security device** Group Policy setting that enables you to prevent Windows Hello for Business enrollment from using version 1.2 Trusted Platform Modules (TPM). Version 1.2 TPMs typically perform cryptographic operations slower than version 2.0 TPMs and are more unforgiving during anti-hammering and PIN lockout activities. Some organizations may not want slow sign-in performance and management overhead associated with version 1.2 TPMs. To prevent Windows Hello for Business from using version 1.2 TPMs, select the TPM 1.2 check box after you enable the Use a hardware security device Group Policy object.
+
+#### Use biometrics
+
+Windows Hello for Business provides a great user experience when combined with the use of biometrics. Rather than providing a PIN to sign-in, a user can use a fingerprint or facial recognition to sign-in to Windows, without sacrificing security.
+
+The default Windows Hello for Business enables users to enroll and use biometrics. However, some organization may want more time before using biometrics and want to disable their use until they are ready. To not allow users to use biometrics, configure the **Use biometrics** Group Policy setting to disabled and apply it to your computers. The policy setting disabled all biometrics. Currently, Windows doesn't provide the ability to set granular policies that enable you to disable specific modalities of biometrics, such as allowing facial recognition but disallowing fingerprint recognition.
+
+### PIN Complexity
+
+PIN complexity is not specific to Windows Hello for Business. Windows enables users to use PINs outside of Windows Hello for Business. PIN Complexity Group Policy settings apply to all uses of PINs, even when Windows Hello for Business is not deployed.
+
+>[!IMPORTANT]
+> Starting from Windows 10, version 1703, the PIN complexity Group Policy settings have moved to remove misunderstanding that PIN complexity policy settings were exclusive to Windows Hello for Business. The new location of these Group Policy settings is under **Computer Configuration\Administrative Templates\System\PIN Complexity** of the Group Policy editor.
+
+Windows provides eight PIN Complexity Group Policy settings that give you granular control over PIN creation and management. You can deploy these policy settings to computers, where they affect all users creating PINs on that computer; or, you can deploy these settings to users, where they affect those users creating PINs regardless of the computer they use. If you deploy both computer and user PIN complexity Group Policy settings, the user policy settings have precedence over computer policy settings. Also, this conflict resolution is based on the last applied policy. Windows does not merge the policy settings automatically; however, you can deploy Group Policy to provide to accomplish a variety of configurations. The policy settings included are:
+* Require digits
+* Require lowercase letters
+* Maximum PIN length
+* Minimum PIN length
+* Expiration
+* History
+* Require special characters
+* Require uppercase letters
+
+## Add users to the Windows Hello for Business Users group
+
+Users must receive the Windows Hello for Business group policy settings and have the proper permission to provision Windows Hello for Business. You can provide users with these settings and permissions by adding the users or groups to the **Windows Hello for Business Users** group. Users and groups who are not members of this group will not attempt to enroll for Windows Hello for Business.
+
+## Provisioning
+
+The Windows Hello for Business provisioning begins immediately after the user has signed in, after the user profile is loaded, but before the user receives their desktop. Windows only launches the provisioning experience if all the prerequisite checks pass. You can determine the status of the prerequisite checks by viewing the **User Device Registration** in the **Event Viewer** under **Applications and Services Logs\Microsoft\Windows**.
+
+
+
+The first thing to validate is the computer has processed device registration. You can view this from the User device registration logs where the check **Device is Azure Active Directory-joined (AADJ or DJ++): Yes** appears. Additionally, you can validate this using the **dsregcmd /status** command from a console prompt where the value for **AzureADJoined** reads **Yes**.
+
+Windows Hello for Business provisioning begins with a full screen page with the title **Setup a PIN** and button with the same name. The user clicks **Setup a PIN**.
+
+
+
+The provisioning flow proceeds to the Multi-Factor authentication portion of the enrollment. Provisioning informs the user that it is actively attempting to contact the user through their configured form of MFA. The provisioning process does not proceed until authentication succeeds, fails or times out. A failed or timeout MFA results in an error and asks the user to retry.
+
+
+
+After a successful MFA, the provisioning flow asks the user to create and validate a PIN. This PIN must observe any PIN complexity requirements that you deployed to the environment.
+
+
+
+The provisioning flow has all the information it needs to complete the Windows Hello for Business enrollment.
+
+- A successful single factor authentication (username and password at sign-in)
+- A device that has successfully completed device registration
+- A fresh, successful multi-factor authentication
+- A validated PIN that meets the PIN complexity requirements
+
+The remainder of the provisioning includes Windows Hello for Business requesting an asymmetric key pair for the user, preferably from the TPM (or required if explicitly set through policy). Once the key pair is acquired, Windows communicates with Azure Active Directory to register the public key. When key registration completes, Windows Hello for Business provisioning informs the user they can use their PIN to sign-in. The user may close the provisioning application and see their desktop. While the user has completed provisioning, Azure AD Connect synchronizes the user's key to Active Directory.
+
+> [!IMPORTANT]
+> The minimum time needed to synchronize the user's public key from Azure Active Directory to the on-premises Active Directory is 30 minutes. The Azure AD Connect scheduler controls the synchronization interval.
+> **This synchronization latency delays the user's ability to authenticate and use on-premises resources until the user's public key has synchronized to Active Directory.** Once synchronized, the user can authenticate and use on-premises resources.
+> Read [Azure AD Connect sync: Scheduler](/azure/active-directory/connect/active-directory-aadconnectsync-feature-scheduler) to view and adjust the **synchronization cycle** for your organization.
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-provision.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-provision.md
deleted file mode 100644
index b5c704fb93..0000000000
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-provision.md
+++ /dev/null
@@ -1,59 +0,0 @@
----
-title: Hybrid Azure AD joined Windows Hello for Business key trust Provisioning (Windows Hello for Business)
-description: Learn about provisioning for hybrid key trust deployments of Windows Hello for Business and learn where to find the hybrid key trust deployment guide.
-ms.date: 4/30/2021
-appliesto:
-- ✅ Windows 10 and later
-ms.topic: article
----
-# Hybrid Azure AD joined Windows Hello for Business Key Trust Provisioning
-
-[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-key-trust.md)]
-
-## Provisioning
-
-The Windows Hello for Business provisioning begins immediately after the user has signed in, after the user profile is loaded, but before the user receives their desktop. Windows only launches the provisioning experience if all the prerequisite checks pass. You can determine the status of the prerequisite checks by viewing the **User Device Registration** in the **Event Viewer** under **Applications and Services Logs\Microsoft\Windows**.
-
-
-
-The first thing to validate is the computer has processed device registration. You can view this from the User device registration logs where the check **Device is Azure Active Directory-joined (AADJ or DJ++): Yes** appears. Additionally, you can validate this using the **dsregcmd /status** command from a console prompt where the value for **AzureADJoined** reads **Yes**.
-
-Windows Hello for Business provisioning begins with a full screen page with the title **Setup a PIN** and button with the same name. The user clicks **Setup a PIN**.
-
-
-
-The provisioning flow proceeds to the Multi-Factor authentication portion of the enrollment. Provisioning informs the user that it is actively attempting to contact the user through their configured form of MFA. The provisioning process does not proceed until authentication succeeds, fails or times out. A failed or timeout MFA results in an error and asks the user to retry.
-
-
-
-After a successful MFA, the provisioning flow asks the user to create and validate a PIN. This PIN must observe any PIN complexity requirements that you deployed to the environment.
-
-
-
-The provisioning flow has all the information it needs to complete the Windows Hello for Business enrollment.
-
-- A successful single factor authentication (username and password at sign-in)
-- A device that has successfully completed device registration
-- A fresh, successful multi-factor authentication
-- A validated PIN that meets the PIN complexity requirements
-
-The remainder of the provisioning includes Windows Hello for Business requesting an asymmetric key pair for the user, preferably from the TPM (or required if explicitly set through policy). Once the key pair is acquired, Windows communicates with Azure Active Directory to register the public key. When key registration completes, Windows Hello for Business provisioning informs the user they can use their PIN to sign-in. The user may close the provisioning application and see their desktop. While the user has completed provisioning, Azure AD Connect synchronizes the user's key to Active Directory.
-
-> [!IMPORTANT]
-> The minimum time needed to synchronize the user's public key from Azure Active Directory to the on-premises Active Directory is 30 minutes. The Azure AD Connect scheduler controls the synchronization interval.
-> **This synchronization latency delays the user's ability to authenticate and use on-premises resources until the user's public key has synchronized to Active Directory.** Once synchronized, the user can authenticate and use on-premises resources.
-> Read [Azure AD Connect sync: Scheduler](/azure/active-directory/connect/active-directory-aadconnectsync-feature-scheduler) to view and adjust the **synchronization cycle** for your organization.
-
-
-
-
-
-## 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](hello-hybrid-key-new-install.md)
-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(*You are here*)
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-ad.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-ad.md
deleted file mode 100644
index cb30af909d..0000000000
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-ad.md
+++ /dev/null
@@ -1,53 +0,0 @@
----
-title: Configuring Hybrid Azure AD joined key trust Windows Hello for Business - Active Directory (AD)
-description: Configuring Hybrid key trust Windows Hello for Business - Active Directory (AD)
-ms.date: 4/30/2021
-appliesto:
-- ✅ Windows 10 and later
-ms.topic: article
----
-# Configuring Hybrid Azure AD joined key trust Windows Hello for Business: Active Directory
-
-[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-key-trust-ad.md)]
-
-Configure the appropriate security groups to efficiently deploy Windows Hello for Business to users.
-
-### Creating Security Groups
-
-Windows Hello for Business uses a security group to simplify the deployment and management.
-
-#### Create the Windows Hello for Business Users Security Group
-
-The Windows Hello for Business Users group is used to make it easy to deploy Windows Hello for Business in phases. You assign Group Policy and Certificate template permissions to this group to simplify the deployment by simply adding the users to the group. This provides users with the proper permissions to provision Windows Hello for Business and to enroll in the Windows Hello for Business authentication certificate.
-
-Sign-in a domain controller or management workstation with *Domain Admin* equivalent credentials.
-
-1. Open **Active Directory Users and Computers**.
-2. Click **View** and click **Advanced Features**.
-3. Expand the domain node from the navigation pane.
-4. Right-click the **Users** container. Click **New**. Click **Group**.
-5. Type **Windows Hello for Business Users** in the **Group Name** text box.
-6. Click **OK**.
-
-### Section Review
-
-> [!div class="checklist"]
-> * Create the Windows Hello for Business Users group
->
-> [!div class="step-by-step"]
-> [< Configure Windows Hello for Business](hello-hybrid-key-whfb-settings.md)
-> [Configure Azure AD Connect >](hello-hybrid-key-whfb-settings-dir-sync.md)
-
-
-
-
-
-## Follow the Windows Hello for Business hybrid key trust deployment guide
-
-1. [Overview](hello-hybrid-cert-trust.md)
-2. [Prerequisites](hello-hybrid-key-trust-prereqs.md)
-3. [New Installation Baseline](hello-hybrid-key-new-install.md)
-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: Active Directory (*You are here*)
-7. [Sign-in and Provision](hello-hybrid-key-whfb-provision.md)
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-dir-sync.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-dir-sync.md
deleted file mode 100644
index f19aab257d..0000000000
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-dir-sync.md
+++ /dev/null
@@ -1,54 +0,0 @@
----
-title: Hybrid Azure AD joined Windows Hello for Business - Directory Synchronization
-description: How to configure Hybrid key trust Windows Hello for Business - Directory Synchronization
-ms.date: 4/30/2021
-appliesto:
-- ✅ Windows 10 and later
-ms.topic: article
----
-# Configure Hybrid Azure AD joined Windows Hello for Business: Directory Synchronization
-
-[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-key-trust.md)]
-
-## 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.
-
-### Section Review
-
-> [!div class="checklist"]
-> * Configure group membership for Azure AD Connect
-
-> [!div class="step-by-step"]
-> [< Configure Active Directory](hello-hybrid-key-whfb-settings-ad.md)
-> [Configure PKI >](hello-hybrid-key-whfb-settings-pki.md)
-
-
-
-## Follow the Windows Hello for Business hybrid key trust deployment guide
-
-1. [Overview](hello-hybrid-cert-trust.md)
-2. [Prerequisites](hello-hybrid-key-trust-prereqs.md)
-3. [New Installation Baseline](hello-hybrid-key-new-install.md)
-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: Directory Synchronization (*You are here*)
-7. [Sign-in and Provision](hello-hybrid-key-whfb-provision.md)
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-pki.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-pki.md
deleted file mode 100644
index 9e36481b2a..0000000000
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-pki.md
+++ /dev/null
@@ -1,128 +0,0 @@
----
-title: Configure Hybrid Azure AD joined key trust Windows Hello for Business
-description: Configuring Hybrid key trust Windows Hello for Business - Public Key Infrastructure (PKI)
-ms.date: 04/30/2021
-appliesto:
-- ✅ Windows 10 and later
-ms.topic: article
----
-# Configure Hybrid Azure AD joined Windows Hello for Business: Public Key Infrastructure
-
-[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-key-trust.md)]
-
-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.
-
-### Section Review
-
-> [!div class="checklist"]
-> * Domain Controller certificate template
-> * Configure superseded domain controller certificate templates
-> * Publish Certificate templates to certificate authorities
-> * Unpublish superseded certificate templates
-> s
-> [!div class="step-by-step"]
-> [< Configure Azure AD Connect](hello-hybrid-key-whfb-settings-dir-sync.md)
-> [Configure policy settings >](hello-hybrid-key-whfb-settings-policy.md)
-
-
-
-
-
-## Follow the Windows Hello for Business hybrid key trust deployment guide
-
-1. [Overview](hello-hybrid-cert-trust.md)
-2. [Prerequisites](hello-hybrid-key-trust-prereqs.md)
-3. [New Installation Baseline](hello-hybrid-key-new-install.md)
-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: PKI (*You are here*)
-7. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md)
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-policy.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-policy.md
deleted file mode 100644
index 333f505d95..0000000000
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-policy.md
+++ /dev/null
@@ -1,169 +0,0 @@
----
-title: Configure Hybrid Azure AD joined Windows Hello for Business - Group Policy
-description: Configuring Hybrid key trust Windows Hello for Business - Group Policy
-ms.date: 4/30/2021
-appliesto:
-- ✅ Windows 10 and later
-ms.topic: article
----
-# Configure Hybrid Azure AD joined Windows Hello for Business: Group Policy
-
-[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-key-trust-ad.md)]
-
-## 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 � 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�**
-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
-
-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
-
-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
-
-The Group Policy object contains the policy setting needed to trigger Windows Hello for Business provisioning.
-
-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 *Enable Windows Hello for Business* in the name box and click **OK**.
-5. In the content pane, right-click the **Enable Windows Hello for Business** Group Policy object and click **Edit**.
-6. In the navigation pane, expand **Policies** under **User Configuration**.
-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
-
-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)
-2. Expand the domain and select the **Group Policy Object** node in the navigation pane.
-3. Double-click the **Enable Windows Hello for Business** Group Policy object.
-4. In the **Security Filtering** section of the content pane, click **Add**. Type *Windows Hello for Business Users* or the name of the security group you previously created and click **OK**.
-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
-
-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)
-2. In the navigation pane, expand the domain and right-click the node that has your Active Directory domain name and click **Link an existing GPO**
-3. In the **Select GPO** dialog box, select **Enable Windows Hello for Business** or the name of the Windows Hello for Business Group Policy object you previously created and click **OK**.
-
-Just to reassure, linking the **Windows Hello for Business** Group Policy object to the domain ensures the Group Policy object is in scope for all domain users. However, not all users will have the policy settings applied to them. Only users who are members of the Windows Hello for Business group receive the policy settings. All others users ignore the Group Policy object.
-
-## Other Related Group Policy settings
-
-### Windows Hello for Business
-
-There are other Windows Hello for Business policy settings you can configure to manage your Windows Hello for Business deployment. These policy settings are computer-based policy setting; so they are applicable to any user that sign-in from a computer with these policy settings.
-
-#### Use a hardware security device
-
-The default configuration for Windows Hello for Business is to prefer hardware protected credentials; however, not all computers are able to create hardware protected credentials. When Windows Hello for Business enrollment encounters a computer that cannot create a hardware protected credential, it will create a software-based credential.
-
-You can enable and deploy the **Use a hardware security device** Group Policy Setting to force Windows Hello for Business to only create hardware protected credentials. Users that sign-in from a computer incapable of creating a hardware protected credential do not enroll for Windows Hello for Business.
-
-Another policy setting becomes available when you enable the **Use a hardware security device** Group Policy setting that enables you to prevent Windows Hello for Business enrollment from using version 1.2 Trusted Platform Modules (TPM). Version 1.2 TPMs typically perform cryptographic operations slower than version 2.0 TPMs and are more unforgiving during anti-hammering and PIN lockout activities. Some organizations may not want slow sign-in performance and management overhead associated with version 1.2 TPMs. To prevent Windows Hello for Business from using version 1.2 TPMs, select the TPM 1.2 check box after you enable the Use a hardware security device Group Policy object.
-
-#### Use biometrics
-
-Windows Hello for Business provides a great user experience when combined with the use of biometrics. Rather than providing a PIN to sign-in, a user can use a fingerprint or facial recognition to sign-in to Windows, without sacrificing security.
-
-The default Windows Hello for Business enables users to enroll and use biometrics. However, some organization may want more time before using biometrics and want to disable their use until they are ready. To not allow users to use biometrics, configure the **Use biometrics** Group Policy setting to disabled and apply it to your computers. The policy setting disabled all biometrics. Currently, Windows doesn't provide the ability to set granular policies that enable you to disable specific modalities of biometrics, such as allowing facial recognition but disallowing fingerprint recognition.
-
-### PIN Complexity
-
-PIN complexity is not specific to Windows Hello for Business. Windows enables users to use PINs outside of Windows Hello for Business. PIN Complexity Group Policy settings apply to all uses of PINs, even when Windows Hello for Business is not deployed.
-
->[!IMPORTANT]
-> Starting from Windows 10, version 1703, the PIN complexity Group Policy settings have moved to remove misunderstanding that PIN complexity policy settings were exclusive to Windows Hello for Business. The new location of these Group Policy settings is under **Computer Configuration\Administrative Templates\System\PIN Complexity** of the Group Policy editor.
-
-Windows provides eight PIN Complexity Group Policy settings that give you granular control over PIN creation and management. You can deploy these policy settings to computers, where they affect all users creating PINs on that computer; or, you can deploy these settings to users, where they affect those users creating PINs regardless of the computer they use. If you deploy both computer and user PIN complexity Group Policy settings, the user policy settings have precedence over computer policy settings. Also, this conflict resolution is based on the last applied policy. Windows does not merge the policy settings automatically; however, you can deploy Group Policy to provide to accomplish a variety of configurations. The policy settings included are:
-* Require digits
-* Require lowercase letters
-* Maximum PIN length
-* Minimum PIN length
-* Expiration
-* History
-* Require special characters
-* Require uppercase letters
-
-## Add users to the Windows Hello for Business Users group
-
-Users must receive the Windows Hello for Business group policy settings and have the proper permission to provision Windows Hello for Business. You can provide users with these settings and permissions by adding the users or groups to the **Windows Hello for Business Users** group. Users and groups who are not members of this group will not attempt to enroll for Windows Hello for Business.
-
-### Section Review
-> [!div class="checklist"]
-> * Configure domain controllers for automatic certificate enrollment.
-> * Create Windows Hello for Business Group Policy object.
-> * Enable the Use Windows Hello for Business policy setting.
-> * Add users or groups to the Windows Hello for Business group
->
->
-> [!div class="nextstepaction"]
-> [Sign-in and Provision](hello-hybrid-key-whfb-provision.md)
-
-
-
-
-
-## Follow the Windows Hello for Business hybrid key trust deployment guide
-1. [Overview](hello-hybrid-cert-trust.md)
-2. [Prerequisites](hello-hybrid-key-trust-prereqs.md)
-3. [New Installation Baseline](hello-hybrid-key-new-install.md)
-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 policy settings (*You are here*)
-7. [Sign-in and Provision](hello-hybrid-key-whfb-provision.md)
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings.md
deleted file mode 100644
index 5e24b6de2c..0000000000
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings.md
+++ /dev/null
@@ -1,37 +0,0 @@
----
-title: Configure Hybrid Azure AD joined Windows Hello for Business key trust Settings
-description: Begin the process of configuring your hybrid key trust environment for Windows Hello for Business. Start with your Active Directory configuration.
-ms.date: 4/30/2021
-appliesto:
-- ✅ Windows 10 and later
-ms.topic: article
----
-# Configure Hybrid Azure AD joined Windows Hello for Business key trust settings
-
-[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-key-trust.md)]
-
-You are ready to configure your hybrid Azure AD joined key trust environment for Windows Hello for Business.
-
-> [!IMPORTANT]
-> Ensure your environment meets all the [prerequisites](hello-hybrid-key-trust-prereqs.md) before proceeding. Review the [New Installation baseline](hello-hybrid-key-new-install.md) section of this deployment document to learn how to prepare your environment for your Windows Hello for Business deployment.
-
-The configuration for Windows Hello for Business is grouped in four categories. These categories are:
-* [Active Directory](hello-hybrid-key-whfb-settings-ad.md)
-* [Azure AD Connect](hello-hybrid-key-whfb-settings-dir-sync.md)
-* [Public Key Infrastructure](hello-hybrid-key-whfb-settings-pki.md)
-* [Group Policy](hello-hybrid-key-whfb-settings-policy.md)
-
-For the most efficient deployment, configure these technologies in order beginning with the Active Directory configuration
-
-> [!div class="step-by-step"]
-> [Configure Active Directory >](hello-hybrid-key-whfb-settings-ad.md)
-
-## 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](hello-hybrid-key-new-install.md)
-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 (*You are here*)
-7. [Sign-in and Provision](hello-hybrid-key-whfb-provision.md)
From ccb82c428c667d8fc168e614982232707bc1a99b Mon Sep 17 00:00:00 2001
From: Paolo Matarazzo <74918781+paolomatarazzo@users.noreply.github.com>
Date: Wed, 21 Dec 2022 07:38:48 -0500
Subject: [PATCH 07/70] updates
---
.../hello-for-business/toc.yml | 40 ++++---------------
1 file changed, 7 insertions(+), 33 deletions(-)
diff --git a/windows/security/identity-protection/hello-for-business/toc.yml b/windows/security/identity-protection/hello-for-business/toc.yml
index fb4c92826f..99f20b0f21 100644
--- a/windows/security/identity-protection/hello-for-business/toc.yml
+++ b/windows/security/identity-protection/hello-for-business/toc.yml
@@ -28,35 +28,9 @@
- name: Cloud Kerberos trust deployment
href: hello-hybrid-cloud-kerberos-trust.md
- name: Key trust deployment
- items:
- - name: Overview
- href: hello-hybrid-key-trust.md
- - name: Prerequisites
- href: hello-hybrid-key-trust-prereqs.md
- - name: New installation baseline
- href: hello-hybrid-key-new-install.md
- - name: Configure directory synchronization
- href: hello-hybrid-key-trust-dirsync.md
- - name: Configure Azure AD device registration
- href: hello-hybrid-key-trust-devreg.md
- - name: Configure Windows Hello for Business settings
- items:
- - name: Overview
- href: hello-hybrid-key-whfb-settings.md
- - name: Configure Active Directory
- href: hello-hybrid-key-whfb-settings-ad.md
- - name: Configure Azure AD Connect Sync
- href: hello-hybrid-key-whfb-settings-dir-sync.md
- - name: Configure PKI
- href: hello-hybrid-key-whfb-settings-pki.md
- - name: Configure Group Policy settings
- href: hello-hybrid-key-whfb-settings-policy.md
- - name: Sign-in and provision Windows Hello for Business
- href: hello-hybrid-key-whfb-provision.md
- - name: On-premises SSO for Azure AD joined devices
- href: hello-hybrid-aadj-sso.md
- - name: Configure Azure AD joined devices for on-premises SSO
- href: hello-hybrid-aadj-sso-base.md
+ href: hello-hybrid-key-trust.md
+ - name: New installation baseline
+ href: hello-hybrid-key-new-install.md
- name: Certificate trust deployment
items:
- name: Overview
@@ -83,12 +57,12 @@
href: hello-hybrid-cert-whfb-settings-policy.md
- name: Sign-in and provision Windows Hello for Business
href: hello-hybrid-cert-whfb-provision.md
- - name: On-premises SSO for Azure AD joined devices
- href: hello-hybrid-aadj-sso.md
- - name: Configure Azure AD joined devices for on-premises SSO
- href: hello-hybrid-aadj-sso-base.md
- name: Using certificates for on-premises SSO
href: hello-hybrid-aadj-sso-cert.md
+ - name: On-premises SSO for Azure AD joined devices
+ href: hello-hybrid-aadj-sso.md
+ - name: Configure Azure AD joined devices for on-premises SSO
+ href: hello-hybrid-aadj-sso-base.md
- name: Planning for Domain Controller load
href: hello-adequate-domain-controllers.md
- name: On-premises deployments
From 6d5751a45c4d719c9868a234c2a47efbe92aa089 Mon Sep 17 00:00:00 2001
From: Paolo Matarazzo <74918781+paolomatarazzo@users.noreply.github.com>
Date: Wed, 21 Dec 2022 09:37:44 -0500
Subject: [PATCH 08/70] updates
---
.../hello-hybrid-key-new-install.md | 144 ----------
.../hello-hybrid-key-trust-validate-pki.md | 238 ++++++++++++++++
.../hello-hybrid-key-trust.md | 255 ++----------------
3 files changed, 259 insertions(+), 378 deletions(-)
delete mode 100644 windows/security/identity-protection/hello-for-business/hello-hybrid-key-new-install.md
create mode 100644 windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-new-install.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-new-install.md
deleted file mode 100644
index 32f0d91fc6..0000000000
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-new-install.md
+++ /dev/null
@@ -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:
-- ✅ Windows 10 and later
-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)
-
-
-
-
-
-## 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)
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md
new file mode 100644
index 0000000000..a7201bc0f1
--- /dev/null
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md
@@ -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:
+- ✅ Windows 10 and later
+- ✅ Windows Server 2016 and later
+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.
+
+
+
+> [!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.
+
+
+
+Configure domain controller certificates
+
+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
+
+
+
+
+
+Supersede existing domain controller certificates
+
+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`
+
+
+
+
+
+Unpublish Superseded Certificate Templates
+
+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
+
+
+
+
+
+Publish certificate templates to the CA
+
+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
+
+
+
+### 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)
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
index da93775507..9a6226bcd7 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
@@ -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:
- ✅ Windows Server 2016 and later
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:
- 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)
- for federated environments, you can deploy Windows Hello for Business key trust using Active Directory Federation Services (AD FS) or third-party federation services
|
-|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:
- Azure Multifactor Authentication (MFA) service
- A multi-factor authentication provided by AD FS, which includes an adapter model that enables third parties to integrate their MFA into AD FS
|
-| 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:
- 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)
- for federated environments, you can deploy Windows Hello for Business key trust using Active Directory Federation Services (AD FS) or third-party federation services
||
+|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:
- Azure Multifactor Authentication (MFA) service
- A multi-factor authentication provided by AD FS, which includes an adapter model that enables third parties to integrate their MFA into AD FS
|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)
-
-
-
-
-## 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.
-
-
-
-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 � 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�**
-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)
From aa323478b0014f35b60dbcee8c27ee4568bce7a4 Mon Sep 17 00:00:00 2001
From: Paolo Matarazzo <74918781+paolomatarazzo@users.noreply.github.com>
Date: Wed, 21 Dec 2022 10:25:34 -0500
Subject: [PATCH 09/70] updates
---
.../hello-hybrid-key-trust.md | 69 +++++++++----------
1 file changed, 33 insertions(+), 36 deletions(-)
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
index 9a6226bcd7..2dc2f79ecc 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
@@ -15,27 +15,29 @@ Windows Hello for Business replaces password sign-in with strong authentication,
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.
+> [!IMPORTANT]
+> Windows Hello for Business *cloud Kerberos trust* is the recommended deployment model when compared to the *key trust model*. It is also the preferred deployment model if you do not need to support certificate authentication scenarios. For more information see [cloud Kerberos trust deployment](hello-hybrid-cloud-kerberos-trust.md).
+
## Prerequisites
-| 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:
- 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)
- for federated environments, you can deploy Windows Hello for Business key trust using Active Directory Federation Services (AD FS) or third-party federation services
||
+| Requirement | Notes |
+| --- | --- |
+| 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:
- 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)
- for federated environments, you can deploy Windows Hello for Business key trust using Active Directory Federation Services (AD FS) or third-party federation services
|
|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:
- Azure Multifactor Authentication (MFA) service
- A multi-factor authentication provided by AD FS, which includes an adapter model that enables third parties to integrate their MFA into AD FS
|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||
+| Device management | Devices can be configured with group polices or through mobile device management (MDM) policies|
## Deployment steps
-Deploying Windows Hello for Business with a hybrid key trust model consists of XXX steps:
+Once the prerequisites listed in the table above are met, deploying Windows Hello for Business with a hybrid key trust model consists of the following 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**
+- Validate directory synchronization and device registration
+- Configure Windows Hello for Business settings
+- Provision Windows Hello for Business
## Configure Hybrid Azure AD join
@@ -69,7 +71,6 @@ 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**.
-
## 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
@@ -158,36 +159,32 @@ Windows provides eight PIN Complexity Group Policy settings that give you granul
Users must receive the Windows Hello for Business group policy settings and have the proper permission to provision Windows Hello for Business. You can provide users with these settings and permissions by adding the users or groups to the **Windows Hello for Business Users** group. Users and groups who are not members of this group will not attempt to enroll for Windows Hello for Business.
-## Provisioning
+## Provision Windows Hello for Business
-The Windows Hello for Business provisioning begins immediately after the user has signed in, after the user profile is loaded, but before the user receives their desktop. Windows only launches the provisioning experience if all the prerequisite checks pass. You can determine the status of the prerequisite checks by viewing the **User Device Registration** in the **Event Viewer** under **Applications and Services Logs\Microsoft\Windows**.
+The Windows Hello for Business provisioning process begins immediately after the user profile is loaded and before the user receives their desktop. For the provisioning process to begin, all prerequisite checks must pass.
+
+You can determine the status of the prerequisite checks by viewing the **User Device Registration** admin log under **Applications and Services Logs > Microsoft > **Windows**.\
+This information is also available using the `dsregcmd /status` command from a console. For more information, see [dsregcmd][AZ-4].

-The first thing to validate is the computer has processed device registration. You can view this from the User device registration logs where the check **Device is Azure Active Directory-joined (AADJ or DJ++): Yes** appears. Additionally, you can validate this using the **dsregcmd /status** command from a console prompt where the value for **AzureADJoined** reads **Yes**.
+### PIN Setup
-Windows Hello for Business provisioning begins with a full screen page with the title **Setup a PIN** and button with the same name. The user clicks **Setup a PIN**.
+This is the process that occurs after a user signs in, to enroll in Windows Hello for Business:
-
+1. The user is prompted with a full screen page to use Windows Hello with the organization account. The user selects **OK**
+1. The provisioning flow proceeds to the multi-factor authentication portion of the enrollment. Provisioning informs the user that it's actively attempting to contact the user through their configured form of MFA. The provisioning process doesn't proceed until authentication succeeds, fails or times out. A failed or timeout MFA results in an error and asks the user to retry
+1. After a successful MFA, the provisioning flow asks the user to create and validate a PIN. This PIN must observe any PIN complexity policies configured on the device
-The provisioning flow proceeds to the Multi-Factor authentication portion of the enrollment. Provisioning informs the user that it is actively attempting to contact the user through their configured form of MFA. The provisioning process does not proceed until authentication succeeds, fails or times out. A failed or timeout MFA results in an error and asks the user to retry.
-
-
+:::image type="content" source="images/haadj-whfb-pin-provisioning.gif" alt-text="Animation showing a user logging on to an HAADJ device with a password, and being prompted to enroll in Windows Hello for Business.":::
-After a successful MFA, the provisioning flow asks the user to create and validate a PIN. This PIN must observe any PIN complexity requirements that you deployed to the environment.
-
-
-
-The provisioning flow has all the information it needs to complete the Windows Hello for Business enrollment.
-
-- A successful single factor authentication (username and password at sign-in)
-- A device that has successfully completed device registration
-- A fresh, successful multi-factor authentication
-- A validated PIN that meets the PIN complexity requirements
-
-The remainder of the provisioning includes Windows Hello for Business requesting an asymmetric key pair for the user, preferably from the TPM (or required if explicitly set through policy). Once the key pair is acquired, Windows communicates with Azure Active Directory to register the public key. When key registration completes, Windows Hello for Business provisioning informs the user they can use their PIN to sign-in. The user may close the provisioning application and see their desktop. While the user has completed provisioning, Azure AD Connect synchronizes the user's key to Active Directory.
+The remainder of the provisioning includes Windows Hello for Business requesting an asymmetric key pair for the user, preferably from the TPM (or required if explicitly set through policy). Once the key pair is acquired, Windows communicates with Azure Active Directory to register the public key. When key registration completes, Windows Hello for Business provisioning informs the user they can use their PIN to sign-in. The user may close the provisioning application and see their desktop. While the user has completed provisioning, Azure AD Connect synchronizes the user's key to Active Directory.
> [!IMPORTANT]
-> The minimum time needed to synchronize the user's public key from Azure Active Directory to the on-premises Active Directory is 30 minutes. The Azure AD Connect scheduler controls the synchronization interval.
+> The minimum time needed to synchronize the user's public key from Azure Active Directory to the on-premises Active Directory is 30 minutes. The Azure AD Connect scheduler controls the synchronization interval.
> **This synchronization latency delays the user's ability to authenticate and use on-premises resources until the user's public key has synchronized to Active Directory.** Once synchronized, the user can authenticate and use on-premises resources.
-> Read [Azure AD Connect sync: Scheduler](/azure/active-directory/connect/active-directory-aadconnectsync-feature-scheduler) to view and adjust the **synchronization cycle** for your organization.
\ No newline at end of file
+> Read [Azure AD Connect sync: Scheduler][AZ-5] to view and adjust the **synchronization cycle** for your organization.
+
+
+[AZ-4]: /azure/active-directory/devices/troubleshoot-device-dsregcmd
+[AZ-5]: /azure/active-directory/connect/active-directory-aadconnectsync-feature-scheduler
\ No newline at end of file
From 31a88c6e5ef9e6a642151543efbae8f8a0e38e06 Mon Sep 17 00:00:00 2001
From: Paolo Matarazzo <74918781+paolomatarazzo@users.noreply.github.com>
Date: Wed, 21 Dec 2022 10:32:41 -0500
Subject: [PATCH 10/70] updates
---
.../hello-hybrid-cloud-kerberos-trust.md | 4 ++--
.../hello-for-business/hello-hybrid-key-trust.md | 15 +--------------
2 files changed, 3 insertions(+), 16 deletions(-)
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md
index ebcff732f3..aa375eaaf1 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md
@@ -189,7 +189,7 @@ The cloud Kerberos trust prerequisite check detects whether the user has a parti
This is the process that occurs after a user signs in, to enroll in Windows Hello for Business:
1. The user is prompted with a full screen page to use Windows Hello with the organization account. The user selects **OK**
-1. The provisioning flow proceeds to the multi-factor authentication portion of the enrollment. Provisioning informs the user that it's actively attempting to contact the user through their configured form of MFA. The provisioning process doesn't proceed until authentication succeeds, fails or times out. A failed or timeout MFA results in an error and asks the user to retry
+1. The provisioning flow proceeds to the multi-factor authentication portion of the enrollment. Provisioning informs the user that it's actively attempting to contact the user through their configured form of MFA. The provisioning process doesn't proceed until authentication succeeds, fails or times out. A failed or timeout MFA results in an error and asks the user to retry
1. After a successful MFA, the provisioning flow asks the user to create and validate a PIN. This PIN must observe any PIN complexity policies configured on the device
:::image type="content" source="images/haadj-whfb-pin-provisioning.gif" alt-text="Animation showing a user logging on to an HAADJ device with a password, and being prompted to enroll in Windows Hello for Business.":::
@@ -261,7 +261,7 @@ Windows Hello for Business cloud Kerberos trust can't be used as a supplied cred
No, only the number necessary to handle the load from all cloud Kerberos trust devices.
----
+
[AZ-1]: /azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises
[AZ-2]: /azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises#install-the-azure-ad-kerberos-powershell-module
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
index 2dc2f79ecc..20d65afa66 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
@@ -24,7 +24,7 @@ Hybrid environments are distributed systems that enable organizations to use on-
| --- | --- |
| 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|
+| 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 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|
| 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:
- 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)
- for federated environments, you can deploy Windows Hello for Business key trust using Active Directory Federation Services (AD FS) or third-party federation services
|
|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:
- Azure Multifactor Authentication (MFA) service
- A multi-factor authentication provided by AD FS, which includes an adapter model that enables third parties to integrate their MFA into AD FS
|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.|
@@ -35,22 +35,9 @@ Hybrid environments are distributed systems that enable organizations to use on-
Once the prerequisites listed in the table above are met, deploying Windows Hello for Business with a hybrid key trust model consists of the following steps:
- Validate and configure a PKI
-- Validate directory synchronization and device registration
- Configure Windows Hello for Business settings
- Provision Windows Hello for Business
-## Configure Hybrid Azure AD join
-
-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.
-
-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.
-
-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).
The configuration for Windows Hello for Business is grouped in four categories. These categories are:
From ee58747947f07a0f99d7886e1dcd90fe9daf106e Mon Sep 17 00:00:00 2001
From: Paolo Matarazzo <74918781+paolomatarazzo@users.noreply.github.com>
Date: Wed, 21 Dec 2022 12:06:59 -0500
Subject: [PATCH 11/70] updates
---
.../hello-hybrid-key-trust.md | 52 +++++++++++++++----
1 file changed, 42 insertions(+), 10 deletions(-)
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
index 20d65afa66..2950ff92da 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
@@ -20,14 +20,46 @@ Hybrid environments are distributed systems that enable organizations to use on-
## Prerequisites
-| Requirement | Notes |
-| --- | --- |
-| 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 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|
-| 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:
- 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)
- for federated environments, you can deploy Windows Hello for Business key trust using Active Directory Federation Services (AD FS) or third-party federation services
|
-|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:
- Azure Multifactor Authentication (MFA) service
- A multi-factor authentication provided by AD FS, which includes an adapter model that enables third parties to integrate their MFA into AD FS
|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.|
+Review the following section to ensure that you have the required prerequisites for a hybrid key trust deployment.
+
+### Directories and directory synchronization
+
+Hybrid Windows Hello for Business needs two directories:
+
+- an on-premises Active Directory
+- an Azure Active Directory tenant
+
+The two directories must be synchronized. You need [Azure AD Connect Sync][AZ-1] to synchronize user accounts from the on-premises Active Directory to Azure AD.\
+During the Window Hello for Business provisioning process, users register the public portion of their Windows Hello for Business credential with Azure AD. *Azure AD Connect Sync* synchronizes the Windows Hello for Business public key to Active Directory.
+
+> [!NOTE]
+> Windows Hello for Business Hybrid key trust is not supported if the users' on-premises domain cannot be added as a verified domain in Azure AD.
+
+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.
+
+### Authentication to Azure AD
+
+Authentication to Azure AD can be configured with or without federation:
+
+- for non-federated environments, you must deploy [password hash synchronization](/azure/active-directory/hybrid/whatis-phs) or [Azure Active Directory Pass-through-Authentication](/azure/active-directory/connect/active-directory-aadconnect-pass-through-authentication)
+- for federated environments, you use Active Directory Federation Services (AD FS) or third-party federation services
+
+### Device registration
+
+The Windows client devices where Windows Hello for Business will be provisioned, must be registered in Azure AD. This ensures that only approved computers are used with that Azure AD tenant. You can *Azure AD join* or *hybrid Azure AD join* to register devices to Azure AD. For *hybrid Azure AD join* devices, review the guidance on the [Plan your hybrid Azure Active Directory join implementation](/azure/active-directory/devices/hybrid-azuread-join-plan) page.
+
+### Public Key Infrastructure
+
+An enterprise PKI is required as *trust anchor* for authentication. Domain controllers require a certificate for Windows clients to trust them.
+
+### 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:
+- [Azure AD Multi-Factor Authentication](/azure/multi-factor-authentication/multi-factor-authentication)
+- A multi-factor authentication provided by AD FS, which includes an adapter model that enables third parties to integrate their MFA into AD FS
+
+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|
## Deployment steps
@@ -162,16 +194,16 @@ This is the process that occurs after a user signs in, to enroll in Windows Hell
1. The user is prompted with a full screen page to use Windows Hello with the organization account. The user selects **OK**
1. The provisioning flow proceeds to the multi-factor authentication portion of the enrollment. Provisioning informs the user that it's actively attempting to contact the user through their configured form of MFA. The provisioning process doesn't proceed until authentication succeeds, fails or times out. A failed or timeout MFA results in an error and asks the user to retry
1. After a successful MFA, the provisioning flow asks the user to create and validate a PIN. This PIN must observe any PIN complexity policies configured on the device
+1. The remainder of the provisioning includes Windows Hello for Business requesting an asymmetric key pair for the user, preferably from the TPM (or required if explicitly set through policy). Once the key pair is acquired, Windows communicates with Azure Active Directory to register the public key. When key registration completes, Windows Hello for Business provisioning informs the user they can use their PIN to sign-in. The user may close the provisioning application and see their desktop. While the user has completed provisioning, Azure AD Connect synchronizes the user's key to Active Directory
:::image type="content" source="images/haadj-whfb-pin-provisioning.gif" alt-text="Animation showing a user logging on to an HAADJ device with a password, and being prompted to enroll in Windows Hello for Business.":::
-The remainder of the provisioning includes Windows Hello for Business requesting an asymmetric key pair for the user, preferably from the TPM (or required if explicitly set through policy). Once the key pair is acquired, Windows communicates with Azure Active Directory to register the public key. When key registration completes, Windows Hello for Business provisioning informs the user they can use their PIN to sign-in. The user may close the provisioning application and see their desktop. While the user has completed provisioning, Azure AD Connect synchronizes the user's key to Active Directory.
-
> [!IMPORTANT]
> The minimum time needed to synchronize the user's public key from Azure Active Directory to the on-premises Active Directory is 30 minutes. The Azure AD Connect scheduler controls the synchronization interval.
> **This synchronization latency delays the user's ability to authenticate and use on-premises resources until the user's public key has synchronized to Active Directory.** Once synchronized, the user can authenticate and use on-premises resources.
> Read [Azure AD Connect sync: Scheduler][AZ-5] to view and adjust the **synchronization cycle** for your organization.
+[AZ-1]: /azure/active-directory/hybrid/how-to-connect-sync-whatis
[AZ-4]: /azure/active-directory/devices/troubleshoot-device-dsregcmd
[AZ-5]: /azure/active-directory/connect/active-directory-aadconnectsync-feature-scheduler
\ No newline at end of file
From 26b4e6c071ca41ff180a7430bb34177c2d2fbd1f Mon Sep 17 00:00:00 2001
From: Paolo Matarazzo <74918781+paolomatarazzo@users.noreply.github.com>
Date: Wed, 21 Dec 2022 12:42:01 -0500
Subject: [PATCH 12/70] updates
---
.../hello-for-business/hello-hybrid-key-trust.md | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
index 2950ff92da..1712a5710f 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
@@ -56,11 +56,16 @@ An enterprise PKI is required as *trust anchor* for authentication. Domain contr
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:
+
- [Azure AD Multi-Factor Authentication](/azure/multi-factor-authentication/multi-factor-authentication)
- A multi-factor authentication provided by AD FS, which includes an adapter model that enables third parties to integrate their MFA into AD FS
-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|
+For more information how to configure Azure AD Multi-Factor Authentication, see [Configure Azure AD Multi-Factor Authentication settings](/azure/multi-factor-authentication/multi-factor-authentication-whats-next).\
+For more information how to configure Active Directory Federation Services (AD FS) to provide additional multi-factor authentication, see [Configure Azure MFA as authentication provider with AD FS](/windows-server/identity/ad-fs/operations/configure-ad-fs-2016-and-azure-mfa).
+
+### Device management
+
+To configure Windows Hello for Business, devices can be configured through a mobile device management (MDM) solution like Intune, or via group policy.
## Deployment steps
@@ -70,8 +75,7 @@ Once the prerequisites listed in the table above are met, deploying Windows Hell
- Configure Windows Hello for Business settings
- Provision Windows Hello for Business
-
-
+
The configuration for Windows Hello for Business is grouped in four categories. These categories are:
### Configure AD - Creating Security Groups
@@ -177,7 +181,7 @@ Windows provides eight PIN Complexity Group Policy settings that give you granul
## Add users to the Windows Hello for Business Users group
Users must receive the Windows Hello for Business group policy settings and have the proper permission to provision Windows Hello for Business. You can provide users with these settings and permissions by adding the users or groups to the **Windows Hello for Business Users** group. Users and groups who are not members of this group will not attempt to enroll for Windows Hello for Business.
-
+-->
## Provision Windows Hello for Business
The Windows Hello for Business provisioning process begins immediately after the user profile is loaded and before the user receives their desktop. For the provisioning process to begin, all prerequisite checks must pass.
From 27ef2374349bea488bfaf85f01d46172686282d1 Mon Sep 17 00:00:00 2001
From: Paolo Matarazzo <74918781+paolomatarazzo@users.noreply.github.com>
Date: Wed, 21 Dec 2022 16:43:14 -0500
Subject: [PATCH 13/70] updates
---
.../hello-for-business/hello-hybrid-key-trust.md | 13 +++++++------
.../identity-protection/hello-for-business/toc.yml | 10 ++++++----
2 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
index 1712a5710f..a1a6b93b28 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
@@ -16,7 +16,7 @@ Windows Hello for Business replaces password sign-in with strong authentication,
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.
> [!IMPORTANT]
-> Windows Hello for Business *cloud Kerberos trust* is the recommended deployment model when compared to the *key trust model*. It is also the preferred deployment model if you do not need to support certificate authentication scenarios. For more information see [cloud Kerberos trust deployment](hello-hybrid-cloud-kerberos-trust.md).
+> Windows Hello for Business *cloud Kerberos trust* is the recommended deployment model when compared to the *key trust model*. For more information see [cloud Kerberos trust deployment](hello-hybrid-cloud-kerberos-trust.md).
## Prerequisites
@@ -29,11 +29,11 @@ Hybrid Windows Hello for Business needs two directories:
- an on-premises Active Directory
- an Azure Active Directory tenant
-The two directories must be synchronized. You need [Azure AD Connect Sync][AZ-1] to synchronize user accounts from the on-premises Active Directory to Azure AD.\
+The two directories must be synchronized with [Azure AD Connect Sync][AZ-1], which synchronizes user accounts from the on-premises Active Directory to Azure AD.\
During the Window Hello for Business provisioning process, users register the public portion of their Windows Hello for Business credential with Azure AD. *Azure AD Connect Sync* synchronizes the Windows Hello for Business public key to Active Directory.
> [!NOTE]
-> Windows Hello for Business Hybrid key trust is not supported if the users' on-premises domain cannot be added as a verified domain in Azure AD.
+> Windows Hello for Business Hybrid key trust is not supported if the users' on-premises UPN suffix cannot be added as a verified domain in Azure AD.
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.
@@ -41,12 +41,13 @@ Ensure that you have [adequate Domain Controllers](/windows/security/identity-pr
Authentication to Azure AD can be configured with or without federation:
-- for non-federated environments, you must deploy [password hash synchronization](/azure/active-directory/hybrid/whatis-phs) or [Azure Active Directory Pass-through-Authentication](/azure/active-directory/connect/active-directory-aadconnect-pass-through-authentication)
-- for federated environments, you use Active Directory Federation Services (AD FS) or third-party federation services
+- for non-federated environments, you must deploy [password hash synchronization](/azure/active-directory/hybrid/whatis-phs) or [Azure Active Directory Pass-through-Authentication](/azure/active-directory/connect/active-directory-aadconnect-pass-through-authentication)
+- for federated environments, you can use Active Directory Federation Services (AD FS) or third-party federation services
### Device registration
-The Windows client devices where Windows Hello for Business will be provisioned, must be registered in Azure AD. This ensures that only approved computers are used with that Azure AD tenant. You can *Azure AD join* or *hybrid Azure AD join* to register devices to Azure AD. For *hybrid Azure AD join* devices, review the guidance on the [Plan your hybrid Azure Active Directory join implementation](/azure/active-directory/devices/hybrid-azuread-join-plan) page.
+The Windows client devices where Windows Hello for Business will be provisioned, must be registered in Azure AD. This ensures that only approved computers are used with that Azure AD tenant. You can *Azure AD join* or *hybrid Azure AD join* to register devices to Azure AD.\
+For *hybrid Azure AD joined* devices, review the guidance on the [Plan your hybrid Azure Active Directory join implementation](/azure/active-directory/devices/hybrid-azuread-join-plan) page.
### Public Key Infrastructure
diff --git a/windows/security/identity-protection/hello-for-business/toc.yml b/windows/security/identity-protection/hello-for-business/toc.yml
index 99f20b0f21..16e5fbceaf 100644
--- a/windows/security/identity-protection/hello-for-business/toc.yml
+++ b/windows/security/identity-protection/hello-for-business/toc.yml
@@ -28,9 +28,11 @@
- name: Cloud Kerberos trust deployment
href: hello-hybrid-cloud-kerberos-trust.md
- name: Key trust deployment
- href: hello-hybrid-key-trust.md
- - name: New installation baseline
- href: hello-hybrid-key-new-install.md
+ items:
+ - name: Overview
+ href: hello-hybrid-key-trust.md
+ - name: Configure and validate the PKI
+ href: hello-hybrid-key-trust-validate-pki.md
- name: Certificate trust deployment
items:
- name: Overview
@@ -73,7 +75,7 @@
href: hello-deployment-key-trust.md
- name: Validate Active Directory prerequisites
href: hello-key-trust-validate-ad-prereq.md
- - name: Configure and validate Public Key Infrastructure (PKI)
+ - name: Configure and validate the PKI
href: hello-key-trust-validate-pki.md
- name: Prepare and deploy Active Directory Federation Services (AD FS)
href: hello-key-trust-adfs.md
From 5403c39c207c97a4a95f0d18fb8ae0dbfc04f2f3 Mon Sep 17 00:00:00 2001
From: Paolo Matarazzo <74918781+paolomatarazzo@users.noreply.github.com>
Date: Wed, 21 Dec 2022 16:50:51 -0500
Subject: [PATCH 14/70] updates
---
.../hello-hybrid-key-trust-validate-pki.md | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md
index a7201bc0f1..eeeb654fb8 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md
@@ -61,7 +61,6 @@ If you don't have an existing PKI, review [Certification Authority Guidance](/pr
Expand the following sections to configure the PKI for Windows Hello for Business.
-
Configure domain controller certificates
@@ -103,9 +102,8 @@ Sign in to a CA or management workstations with *Domain Administrator* equivalen
-
-Supersede existing domain controller certificates
+Supersede existing domain controller certificates
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.
@@ -134,7 +132,6 @@ The certificate template is configured to supersede all the certificate template
-
Unpublish Superseded Certificate Templates
@@ -151,7 +148,6 @@ Sign in to the CA or management workstation with *Enterprise Administrator* equi
-
Publish certificate templates to the CA
From 007602b4434f840253dbaafa285881fdd304da0b Mon Sep 17 00:00:00 2001
From: Paolo Matarazzo <74918781+paolomatarazzo@users.noreply.github.com>
Date: Wed, 21 Dec 2022 17:04:27 -0500
Subject: [PATCH 15/70] updates
---
.../hello-hybrid-key-trust-validate-pki.md | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md
index eeeb654fb8..5bdba905fb 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md
@@ -40,7 +40,7 @@ Sign in using *Enterprise Administrator* equivalent credentials on a Windows Ser
Install-AdcsCertificationAuthority
```
-## Configure a PKI
+## Configure the enterprise 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.
@@ -103,7 +103,7 @@ Sign in to a CA or management workstations with *Domain Administrator* equivalen
-Supersede existing domain controller certificates
+Supersede existing domain controller certificates
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.
@@ -166,7 +166,12 @@ Sign in to the CA or management workstations with **Enterprise Admin** equivalen
-### Configure automatic certificate enrollment for the domain controllers
+## Configure and deploy certificates to domain controllers
+
+Expand the following sections to configure the group policy for domain controllers and validate the certificate deployment.
+
+
+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).
@@ -184,7 +189,10 @@ Domain controllers automatically request a certificate from the *Domain controll
1. Select **OK**
1. Close the **Group Policy Management Editor**
-### Deploy the domain controller auto certificate enrollment GPO
+
+
+
+Deploy the domain controller auto certificate enrollment GPO
Sign in to domain controller or management workstations with *Domain Administrator* equivalent credentials.
@@ -193,6 +201,8 @@ Sign in to domain controller or management workstations with *Domain Administrat
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.
From d88e26a9294075ddb60fcc156758b384980c3618 Mon Sep 17 00:00:00 2001
From: Paolo Matarazzo <74918781+paolomatarazzo@users.noreply.github.com>
Date: Wed, 21 Dec 2022 17:10:27 -0500
Subject: [PATCH 16/70] updates
---
.../hello-hybrid-key-trust-validate-pki.md | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md
index 5bdba905fb..c1e30ef64a 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md
@@ -62,7 +62,7 @@ If you don't have an existing PKI, review [Certification Authority Guidance](/pr
Expand the following sections to configure the PKI for Windows Hello for Business.
-Configure domain controller certificates
+Step 1: configure domain controller certificates
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*.
@@ -103,7 +103,7 @@ Sign in to a CA or management workstations with *Domain Administrator* equivalen
-Supersede existing domain controller certificates
+Step 2: supersede existing domain controller certificates
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.
@@ -133,7 +133,7 @@ The certificate template is configured to supersede all the certificate template
-Unpublish Superseded Certificate Templates
+Step 3: unpublish Superseded Certificate Templates
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.
@@ -149,7 +149,7 @@ Sign in to the CA or management workstation with *Enterprise Administrator* equi
-Publish certificate templates to the CA
+Step 4: publish certificate templates to the CA
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.
@@ -171,7 +171,7 @@ Sign in to the CA or management workstations with **Enterprise Admin** equivalen
Expand the following sections to configure the group policy for domain controllers and validate the certificate deployment.
-Configure automatic certificate enrollment for the domain controllers
+Step 5: 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).
@@ -192,7 +192,7 @@ Domain controllers automatically request a certificate from the *Domain controll
-Deploy the domain controller auto certificate enrollment GPO
+Step 6: deploy the domain controller auto certificate enrollment GPO
Sign in to domain controller or management workstations with *Domain Administrator* equivalent credentials.
From c4a9613e540e9ac9713aaadd933d504458d17b5d Mon Sep 17 00:00:00 2001
From: Paolo Matarazzo <74918781+paolomatarazzo@users.noreply.github.com>
Date: Wed, 21 Dec 2022 17:14:55 -0500
Subject: [PATCH 17/70] updates
---
.../hello-hybrid-key-trust-validate-pki.md | 8 +++++++-
.../hello-for-business/hello-hybrid-key-trust.md | 4 ++++
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md
index c1e30ef64a..7b17053489 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md
@@ -101,6 +101,7 @@ Sign in to a CA or management workstations with *Domain Administrator* equivalen
1. Close the console
+
Step 2: supersede existing domain controller certificates
@@ -131,6 +132,7 @@ The certificate template is configured to supersede all the certificate template
> `Certutil -viewstore -enterprise NTAuth`
+
Step 3: unpublish Superseded Certificate Templates
@@ -147,6 +149,7 @@ Sign in to the CA or management workstation with *Enterprise Administrator* equi
1. Repeat step 3 for the *Domain Controller Authentication* and *Kerberos Authentication* certificate templates
+
Step 4: publish certificate templates to the CA
@@ -165,6 +168,7 @@ Sign in to the CA or management workstations with **Enterprise Admin** equivalen
1. Close the console
+
## Configure and deploy certificates to domain controllers
@@ -190,6 +194,7 @@ Domain controllers automatically request a certificate from the *Domain controll
1. Close the **Group Policy Management Editor**
+
Step 6: deploy the domain controller auto certificate enrollment GPO
@@ -202,6 +207,7 @@ Sign in to domain controller or management workstations with *Domain Administrat
1. Select **OK**
+
## Validate the configuration
@@ -241,4 +247,4 @@ Alternatively, you can forcefully trigger automatic certificate enrollment using
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)
\ No newline at end of file
+> [Next: configure Windows Hello for Business policies >](hello-hybrid-key-trust-validate-pki.md)
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
index a1a6b93b28..558bb15207 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
@@ -208,6 +208,10 @@ This is the process that occurs after a user signs in, to enroll in Windows Hell
> **This synchronization latency delays the user's ability to authenticate and use on-premises resources until the user's public key has synchronized to Active Directory.** Once synchronized, the user can authenticate and use on-premises resources.
> Read [Azure AD Connect sync: Scheduler][AZ-5] to view and adjust the **synchronization cycle** for your organization.
+> [!div class="nextstepaction"]
+> [Next: configure and validate the Public Key Infrastructure >](hello-hybrid-key-trust-validate-pki.md)
+
+
[AZ-1]: /azure/active-directory/hybrid/how-to-connect-sync-whatis
[AZ-4]: /azure/active-directory/devices/troubleshoot-device-dsregcmd
From 7a6b019f4f2c95b021dc1bba4d182452eb410535 Mon Sep 17 00:00:00 2001
From: Paolo Matarazzo <74918781+paolomatarazzo@users.noreply.github.com>
Date: Wed, 28 Dec 2022 11:03:07 -0500
Subject: [PATCH 18/70] redirects
---
.openpublishing.redirection.json | 45 +++++++++++++++++++
.../hello-hybrid-key-trust-validate-pki.md | 12 ++---
2 files changed, 51 insertions(+), 6 deletions(-)
diff --git a/.openpublishing.redirection.json b/.openpublishing.redirection.json
index decbbc3864..1bff04c89b 100644
--- a/.openpublishing.redirection.json
+++ b/.openpublishing.redirection.json
@@ -20294,6 +20294,51 @@
"source_path": "windows/security/identity-protection/hello-for-business/reset-security-key.md",
"redirect_url": "/azure/active-directory/authentication/howto-authentication-passwordless-security-key",
"redirect_document_id": false
+ },
+ {
+ "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-prereqs.md",
+ "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust",
+ "redirect_document_id": true
+ },
+ {
+ "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-dirsync.md",
+ "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust",
+ "redirect_document_id": true
+ },
+ {
+ "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings.md",
+ "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust",
+ "redirect_document_id": true
+ },
+ {
+ "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-ad.md",
+ "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust",
+ "redirect_document_id": true
+ },
+ {
+ "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-pki.md",
+ "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust",
+ "redirect_document_id": true
+ },
+ {
+ "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-dir-sync.md",
+ "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust",
+ "redirect_document_id": true
+ },
+ {
+ "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-policy.md",
+ "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust",
+ "redirect_document_id": true
+ },
+ {
+ "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-devreg.md",
+ "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust",
+ "redirect_document_id": true
+ },
+ {
+ "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-provision.md",
+ "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust",
+ "redirect_document_id": true
}
]
}
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md
index 7b17053489..f393d2abed 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md
@@ -62,7 +62,7 @@ If you don't have an existing PKI, review [Certification Authority Guidance](/pr
Expand the following sections to configure the PKI for Windows Hello for Business.
-Step 1: configure domain controller certificates
+Configure domain controller certificates
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*.
@@ -104,7 +104,7 @@ Sign in to a CA or management workstations with *Domain Administrator* equivalen
-Step 2: supersede existing domain controller certificates
+Supersede existing domain controller certificates
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.
@@ -135,7 +135,7 @@ The certificate template is configured to supersede all the certificate template
-Step 3: unpublish Superseded Certificate Templates
+Unpublish Superseded Certificate Templates
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.
@@ -152,7 +152,7 @@ Sign in to the CA or management workstation with *Enterprise Administrator* equi
-Step 4: publish certificate templates to the CA
+Publish certificate templates to the CA
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.
@@ -175,7 +175,7 @@ Sign in to the CA or management workstations with **Enterprise Admin** equivalen
Expand the following sections to configure the group policy for domain controllers and validate the certificate deployment.
-Step 5: configure automatic certificate enrollment for the domain controllers
+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).
@@ -197,7 +197,7 @@ Domain controllers automatically request a certificate from the *Domain controll
-Step 6: deploy the domain controller auto certificate enrollment GPO
+Deploy the domain controller auto certificate enrollment GPO
Sign in to domain controller or management workstations with *Domain Administrator* equivalent credentials.
From e8c45591045306eb4ac4511002b0db81e5bb5ab4 Mon Sep 17 00:00:00 2001
From: Paolo Matarazzo <74918781+paolomatarazzo@users.noreply.github.com>
Date: Wed, 28 Dec 2022 11:14:58 -0500
Subject: [PATCH 19/70] updates
---
.openpublishing.redirection.json | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/.openpublishing.redirection.json b/.openpublishing.redirection.json
index 1bff04c89b..de0c50c701 100644
--- a/.openpublishing.redirection.json
+++ b/.openpublishing.redirection.json
@@ -20303,42 +20303,47 @@
{
"source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-dirsync.md",
"redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust",
- "redirect_document_id": true
+ "redirect_document_id": false
},
{
"source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings.md",
"redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust",
- "redirect_document_id": true
+ "redirect_document_id": false
},
{
"source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-ad.md",
"redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust",
- "redirect_document_id": true
+ "redirect_document_id": false
},
{
"source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-pki.md",
"redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust",
- "redirect_document_id": true
+ "redirect_document_id": false
},
{
"source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-dir-sync.md",
"redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust",
- "redirect_document_id": true
+ "redirect_document_id": false
},
{
"source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-policy.md",
"redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust",
- "redirect_document_id": true
+ "redirect_document_id": false
},
{
"source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-devreg.md",
"redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust",
- "redirect_document_id": true
+ "redirect_document_id": false
},
{
"source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-provision.md",
"redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust",
- "redirect_document_id": true
+ "redirect_document_id": false
+ },
+ {
+ "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-key-new-install.md",
+ "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust",
+ "redirect_document_id": false
}
]
}
From 89fe87655b2dbc3e2ed9abc1c28ea522782e1a33 Mon Sep 17 00:00:00 2001
From: Paolo Matarazzo <74918781+paolomatarazzo@users.noreply.github.com>
Date: Wed, 28 Dec 2022 12:11:25 -0500
Subject: [PATCH 20/70] updates
---
.../hello-cert-trust-validate-pki.md | 156 +---------------
.../hello-hybrid-key-trust-provision.md | 131 +++++++++++++
.../hello-hybrid-key-trust-validate-pki.md | 176 +++---------------
.../hello-hybrid-key-trust.md | 138 +-------------
.../hello-key-trust-validate-pki.md | 160 +---------------
.../includes/dc-certificate-deployment.md | 43 +++++
.../includes/dc-certificate-supersede.md | 31 +++
.../includes/dc-certificate-template.md | 39 ++++
.../includes/dc-certificate-validate.md | 41 ++++
.../unpublish-superseded-templates.md | 17 ++
.../web-server-certificate-template.md | 37 ++++
11 files changed, 382 insertions(+), 587 deletions(-)
create mode 100644 windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-provision.md
create mode 100644 windows/security/identity-protection/hello-for-business/includes/dc-certificate-deployment.md
create mode 100644 windows/security/identity-protection/hello-for-business/includes/dc-certificate-supersede.md
create mode 100644 windows/security/identity-protection/hello-for-business/includes/dc-certificate-template.md
create mode 100644 windows/security/identity-protection/hello-for-business/includes/dc-certificate-validate.md
create mode 100644 windows/security/identity-protection/hello-for-business/includes/unpublish-superseded-templates.md
create mode 100644 windows/security/identity-protection/hello-for-business/includes/web-server-certificate-template.md
diff --git a/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-pki.md b/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-pki.md
index f543372332..810a289475 100644
--- a/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-pki.md
+++ b/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-pki.md
@@ -46,38 +46,7 @@ Expand the following sections to configure the PKI for Windows Hello for Busines
Configure domain controller certificates
-Clients must trust the domain controllers, and to it each domain controller must have 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.
-
-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
+[!INCLUDE [dc-certificate-template](includes/dc-certificate-template.md)]
@@ -85,24 +54,7 @@ Sign in to a CA or management workstations with *Domain Administrator* equivalen
Supersede existing domain controller certificates
-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.
+[!INCLUDE [dc-certificate-template-supersede](includes/dc-certificate-supersede.md)]
@@ -110,36 +62,7 @@ The certificate template is configured to supersede all the certificate template
Configure an internal web server certificate template
-Windows clients use the https protocol when communicating with Active Directory Federation Services (AD FS). To meet this need, you must issue a server authentication certificate to all the nodes in the AD FS farm. On-premises deployments can use a server authentication certificate issued by their enterprise PKI. You must configure a server authentication certificate template so the host running theAD FS can request the certificate.
-
-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** and select **Manage**
-1. In the **Certificate Template Console**, right-click the **Web Server** 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 *Internal Web Server* 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 **Request Handling** tab, select **Allow private key to be exported**
-1. On the **Subject** tab, select the **Supply in the request** button if it isn't already selected
-1. On the **Security** tab:
- - Select **Add**
- - Type **Domain Computers** in the **Enter the object names to select** box
- - Select **OK**
- - Select the **Allow** check box next to the **Enroll** permission
-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
- - Select **OK**
-1. Close the console
+[!INCLUDE [web-server-certificate-template](includes/web-server-certificate-template.md)]
@@ -248,16 +171,7 @@ certutil.exe -dsTemplate WHFBAuthentication msPKI-Private-Key-Flag +CTPRIVATEKEY
Unpublish Superseded Certificate Templates
-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
+[!INCLUDE [unpublish-superseded-templates](includes/unpublish-superseded-templates.md)]
@@ -280,69 +194,13 @@ Sign in to the CA or management workstations with **Enterprise Admin** equivalen
-### Configure automatic certificate enrollment for the domain controllers
+## Configure and deploy certificates to 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**
+[!INCLUDE [dc-certificate-deployment](includes/dc-certificate-deployment.md)]
## 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.
+[!INCLUDE [dc-certificate-validate](includes/dc-certificate-validate.md)]
> [!div class="nextstepaction"]
> [Next: prepare and deploy AD FS >](hello-cert-trust-adfs.md)
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-provision.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-provision.md
new file mode 100644
index 0000000000..8d6706dae8
--- /dev/null
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-provision.md
@@ -0,0 +1,131 @@
+
+The configuration for Windows Hello for Business is grouped in four categories. These categories are:
+### Configure AD - Creating Security Groups
+
+Windows Hello for Business uses a security group to simplify the deployment and management.
+
+#### Create the Windows Hello for Business Users Security Group
+
+The Windows Hello for Business Users group is used to make it easy to deploy Windows Hello for Business in phases. You assign Group Policy and Certificate template permissions to this group to simplify the deployment by simply adding the users to the group. This provides users with the proper permissions to provision Windows Hello for Business and to enroll in the Windows Hello for Business authentication certificate.
+
+Sign-in a domain controller or management workstation with *Domain Admin* equivalent credentials.
+
+1. Open **Active Directory Users and Computers**.
+2. Click **View** and click **Advanced Features**.
+3. Expand the domain node from the navigation pane.
+4. Right-click the **Users** container. Click **New**. Click **Group**.
+5. Type **Windows Hello for Business Users** in the **Group Name** text box.
+6. Click **OK**.
+
+## 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
+
+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
+
+The Group Policy object contains the policy setting needed to trigger Windows Hello for Business provisioning.
+
+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 *Enable Windows Hello for Business* in the name box and click **OK**.
+5. In the content pane, right-click the **Enable Windows Hello for Business** Group Policy object and click **Edit**.
+6. In the navigation pane, expand **Policies** under **User Configuration**.
+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
+
+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)
+2. Expand the domain and select the **Group Policy Object** node in the navigation pane.
+3. Double-click the **Enable Windows Hello for Business** Group Policy object.
+4. In the **Security Filtering** section of the content pane, click **Add**. Type *Windows Hello for Business Users* or the name of the security group you previously created and click **OK**.
+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
+
+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)
+2. In the navigation pane, expand the domain and right-click the node that has your Active Directory domain name and click **Link an existing GPO**
+3. In the **Select GPO** dialog box, select **Enable Windows Hello for Business** or the name of the Windows Hello for Business Group Policy object you previously created and click **OK**.
+
+Just to reassure, linking the **Windows Hello for Business** Group Policy object to the domain ensures the Group Policy object is in scope for all domain users. However, not all users will have the policy settings applied to them. Only users who are members of the Windows Hello for Business group receive the policy settings. All others users ignore the Group Policy object.
+
+## Other Related Group Policy settings
+
+### Windows Hello for Business
+
+There are other Windows Hello for Business policy settings you can configure to manage your Windows Hello for Business deployment. These policy settings are computer-based policy setting; so they are applicable to any user that sign-in from a computer with these policy settings.
+
+#### Use a hardware security device
+
+The default configuration for Windows Hello for Business is to prefer hardware protected credentials; however, not all computers are able to create hardware protected credentials. When Windows Hello for Business enrollment encounters a computer that cannot create a hardware protected credential, it will create a software-based credential.
+
+You can enable and deploy the **Use a hardware security device** Group Policy Setting to force Windows Hello for Business to only create hardware protected credentials. Users that sign-in from a computer incapable of creating a hardware protected credential do not enroll for Windows Hello for Business.
+
+Another policy setting becomes available when you enable the **Use a hardware security device** Group Policy setting that enables you to prevent Windows Hello for Business enrollment from using version 1.2 Trusted Platform Modules (TPM). Version 1.2 TPMs typically perform cryptographic operations slower than version 2.0 TPMs and are more unforgiving during anti-hammering and PIN lockout activities. Some organizations may not want slow sign-in performance and management overhead associated with version 1.2 TPMs. To prevent Windows Hello for Business from using version 1.2 TPMs, select the TPM 1.2 check box after you enable the Use a hardware security device Group Policy object.
+
+#### Use biometrics
+
+Windows Hello for Business provides a great user experience when combined with the use of biometrics. Rather than providing a PIN to sign-in, a user can use a fingerprint or facial recognition to sign-in to Windows, without sacrificing security.
+
+The default Windows Hello for Business enables users to enroll and use biometrics. However, some organization may want more time before using biometrics and want to disable their use until they are ready. To not allow users to use biometrics, configure the **Use biometrics** Group Policy setting to disabled and apply it to your computers. The policy setting disabled all biometrics. Currently, Windows doesn't provide the ability to set granular policies that enable you to disable specific modalities of biometrics, such as allowing facial recognition but disallowing fingerprint recognition.
+
+### PIN Complexity
+
+PIN complexity is not specific to Windows Hello for Business. Windows enables users to use PINs outside of Windows Hello for Business. PIN Complexity Group Policy settings apply to all uses of PINs, even when Windows Hello for Business is not deployed.
+
+>[!IMPORTANT]
+> Starting from Windows 10, version 1703, the PIN complexity Group Policy settings have moved to remove misunderstanding that PIN complexity policy settings were exclusive to Windows Hello for Business. The new location of these Group Policy settings is under **Computer Configuration\Administrative Templates\System\PIN Complexity** of the Group Policy editor.
+
+Windows provides eight PIN Complexity Group Policy settings that give you granular control over PIN creation and management. You can deploy these policy settings to computers, where they affect all users creating PINs on that computer; or, you can deploy these settings to users, where they affect those users creating PINs regardless of the computer they use. If you deploy both computer and user PIN complexity Group Policy settings, the user policy settings have precedence over computer policy settings. Also, this conflict resolution is based on the last applied policy. Windows does not merge the policy settings automatically; however, you can deploy Group Policy to provide to accomplish a variety of configurations. The policy settings included are:
+* Require digits
+* Require lowercase letters
+* Maximum PIN length
+* Minimum PIN length
+* Expiration
+* History
+* Require special characters
+* Require uppercase letters
+
+## Add users to the Windows Hello for Business Users group
+
+Users must receive the Windows Hello for Business group policy settings and have the proper permission to provision Windows Hello for Business. You can provide users with these settings and permissions by adding the users or groups to the **Windows Hello for Business Users** group. Users and groups who are not members of this group will not attempt to enroll for Windows Hello for Business.
+-->
+## Provision Windows Hello for Business
+
+The Windows Hello for Business provisioning process begins immediately after the user profile is loaded and before the user receives their desktop. For the provisioning process to begin, all prerequisite checks must pass.
+
+You can determine the status of the prerequisite checks by viewing the **User Device Registration** admin log under **Applications and Services Logs > Microsoft > **Windows**.\
+This information is also available using the `dsregcmd /status` command from a console. For more information, see [dsregcmd][AZ-4].
+
+
+
+### PIN Setup
+
+This is the process that occurs after a user signs in, to enroll in Windows Hello for Business:
+
+1. The user is prompted with a full screen page to use Windows Hello with the organization account. The user selects **OK**
+1. The provisioning flow proceeds to the multi-factor authentication portion of the enrollment. Provisioning informs the user that it's actively attempting to contact the user through their configured form of MFA. The provisioning process doesn't proceed until authentication succeeds, fails or times out. A failed or timeout MFA results in an error and asks the user to retry
+1. After a successful MFA, the provisioning flow asks the user to create and validate a PIN. This PIN must observe any PIN complexity policies configured on the device
+1. The remainder of the provisioning includes Windows Hello for Business requesting an asymmetric key pair for the user, preferably from the TPM (or required if explicitly set through policy). Once the key pair is acquired, Windows communicates with Azure Active Directory to register the public key. When key registration completes, Windows Hello for Business provisioning informs the user they can use their PIN to sign-in. The user may close the provisioning application and see their desktop. While the user has completed provisioning, Azure AD Connect synchronizes the user's key to Active Directory
+
+:::image type="content" source="images/haadj-whfb-pin-provisioning.gif" alt-text="Animation showing a user logging on to an HAADJ device with a password, and being prompted to enroll in Windows Hello for Business.":::
+
+> [!IMPORTANT]
+> The minimum time needed to synchronize the user's public key from Azure Active Directory to the on-premises Active Directory is 30 minutes. The Azure AD Connect scheduler controls the synchronization interval.
+> **This synchronization latency delays the user's ability to authenticate and use on-premises resources until the user's public key has synchronized to Active Directory.** Once synchronized, the user can authenticate and use on-premises resources.
+> Read [Azure AD Connect sync: Scheduler][AZ-5] to view and adjust the **synchronization cycle** for your organization.
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md
index f393d2abed..4ccdf8010e 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md
@@ -44,92 +44,23 @@ Sign in using *Enterprise Administrator* equivalent credentials on a Windows Ser
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.
-
-
-> [!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.
Configure domain controller certificates
-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.
+[!INCLUDE [dc-certificate-template](includes/dc-certificate-template.md)]
> [!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
-
Supersede existing domain controller certificates
-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`
+[!INCLUDE [dc-certificate-template-supersede](includes/dc-certificate-supersede.md)]
@@ -137,16 +68,7 @@ The certificate template is configured to supersede all the certificate template
Unpublish Superseded Certificate Templates
-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
+[!INCLUDE [unpublish-superseded-templates](includes/unpublish-superseded-templates.md)]
@@ -162,7 +84,7 @@ Sign in to the CA or management workstations with **Enterprise Admin** equivalen
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. In the **Enable Certificates Templates** window, select the *Domain Controller Authentication (Kerberos)* template you created in the previous steps > select **OK**
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
@@ -172,79 +94,29 @@ Sign in to the CA or management workstations with **Enterprise Admin** equivalen
## Configure and deploy certificates to domain controllers
-Expand the following sections to configure the group policy for domain controllers and validate the certificate deployment.
-
-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**
-
-
-
+[!INCLUDE [dc-certificate-deployment](includes/dc-certificate-deployment.md)]
## 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.
+[!INCLUDE [dc-certificate-validate](includes/dc-certificate-validate.md)]
> [!div class="nextstepaction"]
-> [Next: configure Windows Hello for Business policies >](hello-hybrid-key-trust-validate-pki.md)
\ No newline at end of file
+> [Next: configure and provision Windows Hello for Business >](hello-hybrid-key-trust-provision.md)
+
+
+
+
+
+> [!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
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
index 558bb15207..b8bf8e693d 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
@@ -70,143 +70,11 @@ To configure Windows Hello for Business, devices can be configured through a mob
## Deployment steps
-Once the prerequisites listed in the table above are met, deploying Windows Hello for Business with a hybrid key trust model consists of the following steps:
+Once the prerequisites are met, deploying Windows Hello for Business with a hybrid key trust model consists of the following steps:
-- Validate and configure a PKI
+- Configure and validate the PKI
- Configure Windows Hello for Business settings
-- Provision Windows Hello for Business
-
-
-The configuration for Windows Hello for Business is grouped in four categories. These categories are:
-### Configure AD - Creating Security Groups
-
-Windows Hello for Business uses a security group to simplify the deployment and management.
-
-#### Create the Windows Hello for Business Users Security Group
-
-The Windows Hello for Business Users group is used to make it easy to deploy Windows Hello for Business in phases. You assign Group Policy and Certificate template permissions to this group to simplify the deployment by simply adding the users to the group. This provides users with the proper permissions to provision Windows Hello for Business and to enroll in the Windows Hello for Business authentication certificate.
-
-Sign-in a domain controller or management workstation with *Domain Admin* equivalent credentials.
-
-1. Open **Active Directory Users and Computers**.
-2. Click **View** and click **Advanced Features**.
-3. Expand the domain node from the navigation pane.
-4. Right-click the **Users** container. Click **New**. Click **Group**.
-5. Type **Windows Hello for Business Users** in the **Group Name** text box.
-6. Click **OK**.
-
-## 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
-
-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
-
-The Group Policy object contains the policy setting needed to trigger Windows Hello for Business provisioning.
-
-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 *Enable Windows Hello for Business* in the name box and click **OK**.
-5. In the content pane, right-click the **Enable Windows Hello for Business** Group Policy object and click **Edit**.
-6. In the navigation pane, expand **Policies** under **User Configuration**.
-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
-
-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)
-2. Expand the domain and select the **Group Policy Object** node in the navigation pane.
-3. Double-click the **Enable Windows Hello for Business** Group Policy object.
-4. In the **Security Filtering** section of the content pane, click **Add**. Type *Windows Hello for Business Users* or the name of the security group you previously created and click **OK**.
-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
-
-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)
-2. In the navigation pane, expand the domain and right-click the node that has your Active Directory domain name and click **Link an existing GPO**
-3. In the **Select GPO** dialog box, select **Enable Windows Hello for Business** or the name of the Windows Hello for Business Group Policy object you previously created and click **OK**.
-
-Just to reassure, linking the **Windows Hello for Business** Group Policy object to the domain ensures the Group Policy object is in scope for all domain users. However, not all users will have the policy settings applied to them. Only users who are members of the Windows Hello for Business group receive the policy settings. All others users ignore the Group Policy object.
-
-## Other Related Group Policy settings
-
-### Windows Hello for Business
-
-There are other Windows Hello for Business policy settings you can configure to manage your Windows Hello for Business deployment. These policy settings are computer-based policy setting; so they are applicable to any user that sign-in from a computer with these policy settings.
-
-#### Use a hardware security device
-
-The default configuration for Windows Hello for Business is to prefer hardware protected credentials; however, not all computers are able to create hardware protected credentials. When Windows Hello for Business enrollment encounters a computer that cannot create a hardware protected credential, it will create a software-based credential.
-
-You can enable and deploy the **Use a hardware security device** Group Policy Setting to force Windows Hello for Business to only create hardware protected credentials. Users that sign-in from a computer incapable of creating a hardware protected credential do not enroll for Windows Hello for Business.
-
-Another policy setting becomes available when you enable the **Use a hardware security device** Group Policy setting that enables you to prevent Windows Hello for Business enrollment from using version 1.2 Trusted Platform Modules (TPM). Version 1.2 TPMs typically perform cryptographic operations slower than version 2.0 TPMs and are more unforgiving during anti-hammering and PIN lockout activities. Some organizations may not want slow sign-in performance and management overhead associated with version 1.2 TPMs. To prevent Windows Hello for Business from using version 1.2 TPMs, select the TPM 1.2 check box after you enable the Use a hardware security device Group Policy object.
-
-#### Use biometrics
-
-Windows Hello for Business provides a great user experience when combined with the use of biometrics. Rather than providing a PIN to sign-in, a user can use a fingerprint or facial recognition to sign-in to Windows, without sacrificing security.
-
-The default Windows Hello for Business enables users to enroll and use biometrics. However, some organization may want more time before using biometrics and want to disable their use until they are ready. To not allow users to use biometrics, configure the **Use biometrics** Group Policy setting to disabled and apply it to your computers. The policy setting disabled all biometrics. Currently, Windows doesn't provide the ability to set granular policies that enable you to disable specific modalities of biometrics, such as allowing facial recognition but disallowing fingerprint recognition.
-
-### PIN Complexity
-
-PIN complexity is not specific to Windows Hello for Business. Windows enables users to use PINs outside of Windows Hello for Business. PIN Complexity Group Policy settings apply to all uses of PINs, even when Windows Hello for Business is not deployed.
-
->[!IMPORTANT]
-> Starting from Windows 10, version 1703, the PIN complexity Group Policy settings have moved to remove misunderstanding that PIN complexity policy settings were exclusive to Windows Hello for Business. The new location of these Group Policy settings is under **Computer Configuration\Administrative Templates\System\PIN Complexity** of the Group Policy editor.
-
-Windows provides eight PIN Complexity Group Policy settings that give you granular control over PIN creation and management. You can deploy these policy settings to computers, where they affect all users creating PINs on that computer; or, you can deploy these settings to users, where they affect those users creating PINs regardless of the computer they use. If you deploy both computer and user PIN complexity Group Policy settings, the user policy settings have precedence over computer policy settings. Also, this conflict resolution is based on the last applied policy. Windows does not merge the policy settings automatically; however, you can deploy Group Policy to provide to accomplish a variety of configurations. The policy settings included are:
-* Require digits
-* Require lowercase letters
-* Maximum PIN length
-* Minimum PIN length
-* Expiration
-* History
-* Require special characters
-* Require uppercase letters
-
-## Add users to the Windows Hello for Business Users group
-
-Users must receive the Windows Hello for Business group policy settings and have the proper permission to provision Windows Hello for Business. You can provide users with these settings and permissions by adding the users or groups to the **Windows Hello for Business Users** group. Users and groups who are not members of this group will not attempt to enroll for Windows Hello for Business.
--->
-## Provision Windows Hello for Business
-
-The Windows Hello for Business provisioning process begins immediately after the user profile is loaded and before the user receives their desktop. For the provisioning process to begin, all prerequisite checks must pass.
-
-You can determine the status of the prerequisite checks by viewing the **User Device Registration** admin log under **Applications and Services Logs > Microsoft > **Windows**.\
-This information is also available using the `dsregcmd /status` command from a console. For more information, see [dsregcmd][AZ-4].
-
-
-
-### PIN Setup
-
-This is the process that occurs after a user signs in, to enroll in Windows Hello for Business:
-
-1. The user is prompted with a full screen page to use Windows Hello with the organization account. The user selects **OK**
-1. The provisioning flow proceeds to the multi-factor authentication portion of the enrollment. Provisioning informs the user that it's actively attempting to contact the user through their configured form of MFA. The provisioning process doesn't proceed until authentication succeeds, fails or times out. A failed or timeout MFA results in an error and asks the user to retry
-1. After a successful MFA, the provisioning flow asks the user to create and validate a PIN. This PIN must observe any PIN complexity policies configured on the device
-1. The remainder of the provisioning includes Windows Hello for Business requesting an asymmetric key pair for the user, preferably from the TPM (or required if explicitly set through policy). Once the key pair is acquired, Windows communicates with Azure Active Directory to register the public key. When key registration completes, Windows Hello for Business provisioning informs the user they can use their PIN to sign-in. The user may close the provisioning application and see their desktop. While the user has completed provisioning, Azure AD Connect synchronizes the user's key to Active Directory
-
-:::image type="content" source="images/haadj-whfb-pin-provisioning.gif" alt-text="Animation showing a user logging on to an HAADJ device with a password, and being prompted to enroll in Windows Hello for Business.":::
-
-> [!IMPORTANT]
-> The minimum time needed to synchronize the user's public key from Azure Active Directory to the on-premises Active Directory is 30 minutes. The Azure AD Connect scheduler controls the synchronization interval.
-> **This synchronization latency delays the user's ability to authenticate and use on-premises resources until the user's public key has synchronized to Active Directory.** Once synchronized, the user can authenticate and use on-premises resources.
-> Read [Azure AD Connect sync: Scheduler][AZ-5] to view and adjust the **synchronization cycle** for your organization.
+- Provision Windows Hello for Business on Windows clients
> [!div class="nextstepaction"]
> [Next: configure and validate the Public Key Infrastructure >](hello-hybrid-key-trust-validate-pki.md)
diff --git a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-pki.md b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-pki.md
index dac396577a..e21fe61df1 100644
--- a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-pki.md
+++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-pki.md
@@ -36,9 +36,9 @@ Sign in using *Enterprise Administrator* equivalent credentials on a Windows Ser
Install-AdcsCertificationAuthority
```
-## Configure a PKI
+## Configure the enterprise PKI
-If you 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.
+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.
Expand the following sections to configure the PKI for Windows Hello for Business.
@@ -46,38 +46,7 @@ Expand the following sections to configure the PKI for Windows Hello for Busines
Configure domain controller certificates
-Clients must trust the domain controllers, and to it each domain controller must have 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.
-
-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
+[!INCLUDE [dc-certificate-template](includes/dc-certificate-template.md)]
@@ -86,24 +55,7 @@ Sign in to a CA or management workstations with *Domain Administrator* equivalen
Supersede existing domain controller certificates
-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.
+[!INCLUDE [dc-certificate-template-supersede](includes/dc-certificate-supersede.md)]
@@ -111,36 +63,7 @@ The certificate template is configured to supersede all the certificate template
Configure an internal web server certificate template
-Windows clients use the https protocol when communicating with Active Directory Federation Services (AD FS). To meet this need, you must issue a server authentication certificate to all the nodes in the AD FS farm. On-premises deployments can use a server authentication certificate issued by their enterprise PKI. You must configure a server authentication certificate template so the host running theAD FS can request the certificate.
-
-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** and select **Manage**
-1. In the **Certificate Template Console**, right-click the **Web Server** 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 *Internal Web Server* 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 **Request Handling** tab, select **Allow private key to be exported**
-1. On the **Subject** tab, select the **Supply in the request** button if it isn't already selected
-1. On the **Security** tab:
- - Select **Add**
- - Type **Domain Computers** in the **Enter the object names to select** box
- - Select **OK**
- - Select the **Allow** check box next to the **Enroll** permission
-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
- - Select **OK**
-1. Close the console
+[!INCLUDE [web-server-certificate-template](includes/web-server-certificate-template.md)]
@@ -148,16 +71,7 @@ Sign in to a CA or management workstations with *Domain Administrator* equivalen
Unpublish Superseded Certificate Templates
-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
+[!INCLUDE [unpublish-superseded-templates](includes/unpublish-superseded-templates.md)]
@@ -180,69 +94,13 @@ Sign in to the CA or management workstations with **Enterprise Admin** equivalen
-### Configure automatic certificate enrollment for the domain controllers
+## Configure and deploy certificates to 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**
+[!INCLUDE [dc-certificate-deployment](includes/dc-certificate-deployment.md)]
## 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.
+[!INCLUDE [dc-certificate-validate](includes/dc-certificate-validate.md)]
> [!div class="nextstepaction"]
> [Next: prepare and deploy AD FS >](hello-key-trust-adfs.md)
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/includes/dc-certificate-deployment.md b/windows/security/identity-protection/hello-for-business/includes/dc-certificate-deployment.md
new file mode 100644
index 0000000000..e658d55e32
--- /dev/null
+++ b/windows/security/identity-protection/hello-for-business/includes/dc-certificate-deployment.md
@@ -0,0 +1,43 @@
+---
+author: paolomatarazzo
+ms.author: paoloma
+ms.date: 12/28/2022
+ms.topic: include
+---
+
+Expand the following sections to configure the group policy for domain controllers and validate the certificate deployment.
+
+
+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**
+
+
+
diff --git a/windows/security/identity-protection/hello-for-business/includes/dc-certificate-supersede.md b/windows/security/identity-protection/hello-for-business/includes/dc-certificate-supersede.md
new file mode 100644
index 0000000000..756daf10c7
--- /dev/null
+++ b/windows/security/identity-protection/hello-for-business/includes/dc-certificate-supersede.md
@@ -0,0 +1,31 @@
+---
+author: paolomatarazzo
+ms.author: paoloma
+ms.date: 12/28/2022
+ms.topic: include
+---
+
+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`
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/includes/dc-certificate-template.md b/windows/security/identity-protection/hello-for-business/includes/dc-certificate-template.md
new file mode 100644
index 0000000000..ba828af53d
--- /dev/null
+++ b/windows/security/identity-protection/hello-for-business/includes/dc-certificate-template.md
@@ -0,0 +1,39 @@
+---
+author: paolomatarazzo
+ms.author: paoloma
+ms.date: 12/28/2022
+ms.topic: include
+---
+
+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.
+
+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
diff --git a/windows/security/identity-protection/hello-for-business/includes/dc-certificate-validate.md b/windows/security/identity-protection/hello-for-business/includes/dc-certificate-validate.md
new file mode 100644
index 0000000000..d051eb625e
--- /dev/null
+++ b/windows/security/identity-protection/hello-for-business/includes/dc-certificate-validate.md
@@ -0,0 +1,41 @@
+---
+author: paolomatarazzo
+ms.author: paoloma
+ms.date: 12/28/2022
+ms.topic: include
+---
+
+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.
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/includes/unpublish-superseded-templates.md b/windows/security/identity-protection/hello-for-business/includes/unpublish-superseded-templates.md
new file mode 100644
index 0000000000..cdf7076f1b
--- /dev/null
+++ b/windows/security/identity-protection/hello-for-business/includes/unpublish-superseded-templates.md
@@ -0,0 +1,17 @@
+---
+author: paolomatarazzo
+ms.author: paoloma
+ms.date: 12/28/2022
+ms.topic: include
+---
+
+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
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/includes/web-server-certificate-template.md b/windows/security/identity-protection/hello-for-business/includes/web-server-certificate-template.md
new file mode 100644
index 0000000000..ca5ca4486a
--- /dev/null
+++ b/windows/security/identity-protection/hello-for-business/includes/web-server-certificate-template.md
@@ -0,0 +1,37 @@
+---
+author: paolomatarazzo
+ms.author: paoloma
+ms.date: 12/28/2022
+ms.topic: include
+---
+
+Windows clients use the https protocol when communicating with Active Directory Federation Services (AD FS). To meet this need, you must issue a server authentication certificate to all the nodes in the AD FS farm. On-premises deployments can use a server authentication certificate issued by their enterprise PKI. You must configure a server authentication certificate template so the host running AD FS can request the certificate.
+
+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** and select **Manage**
+1. In the **Certificate Template Console**, right-click the **Web Server** 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 *Internal Web Server* 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 **Request Handling** tab, select **Allow private key to be exported**
+1. On the **Subject** tab, select the **Supply in the request** button if it isn't already selected
+1. On the **Security** tab:
+ - Select **Add**
+ - Type **Domain Computers** in the **Enter the object names to select** box
+ - Select **OK**
+ - Select the **Allow** check box next to the **Enroll** permission
+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
+ - Select **OK**
+1. Close the console
\ No newline at end of file
From b1ffb7f6f9d3c5045b64160255347086f8b40a6d Mon Sep 17 00:00:00 2001
From: Paolo Matarazzo <74918781+paolomatarazzo@users.noreply.github.com>
Date: Wed, 28 Dec 2022 12:36:39 -0500
Subject: [PATCH 21/70] updates
---
.../hello-aad-join-cloud-only-deploy.md | 2 +-
.../hello-for-business/hello-cert-trust-adfs.md | 2 +-
.../hello-cert-trust-policy-settings.md | 2 +-
.../hello-cert-trust-validate-ad-prereq.md | 2 +-
.../hello-cert-trust-validate-deploy-mfa.md | 2 +-
.../hello-for-business/hello-cert-trust-validate-pki.md | 2 +-
.../hello-for-business/hello-deployment-cert-trust.md | 2 +-
.../hello-for-business/hello-deployment-key-trust.md | 2 +-
.../hello-for-business/hello-deployment-rdp-certs.md | 6 +++---
.../hello-for-business/hello-hybrid-aadj-sso-base.md | 2 +-
.../hello-for-business/hello-hybrid-aadj-sso-cert.md | 2 +-
.../hello-for-business/hello-hybrid-aadj-sso.md | 2 +-
.../hello-for-business/hello-hybrid-cert-new-install.md | 2 +-
.../hello-for-business/hello-hybrid-cert-trust-devreg.md | 2 +-
.../hello-for-business/hello-hybrid-cert-trust-prereqs.md | 2 +-
.../hello-for-business/hello-hybrid-cert-trust.md | 2 +-
.../hello-hybrid-cert-whfb-provision.md | 2 +-
.../hello-hybrid-cert-whfb-settings-ad.md | 2 +-
.../hello-hybrid-cert-whfb-settings-adfs.md | 2 +-
.../hello-hybrid-cert-whfb-settings-dir-sync.md | 2 +-
.../hello-hybrid-cert-whfb-settings-pki.md | 2 +-
.../hello-hybrid-cert-whfb-settings-policy.md | 2 +-
.../hello-for-business/hello-hybrid-cert-whfb-settings.md | 2 +-
.../hello-hybrid-cloud-kerberos-trust.md | 2 +-
.../hello-hybrid-key-trust-validate-pki.md | 2 +-
.../hello-for-business/hello-hybrid-key-trust.md | 2 +-
.../hello-for-business/hello-key-trust-adfs.md | 2 +-
.../hello-for-business/hello-key-trust-policy-settings.md | 2 +-
.../hello-key-trust-validate-ad-prereq.md | 2 +-
.../hello-key-trust-validate-deploy-mfa.md | 2 +-
.../hello-for-business/hello-key-trust-validate-pki.md | 2 +-
.../includes/dc-certificate-deployment.md | 2 +-
.../hello-for-business}/includes/hello-cloud.md | 0
.../hello-for-business/includes/hello-deployment-cloud.md | 8 ++++++++
.../includes/hello-deployment-hybrid.md | 8 ++++++++
.../includes/hello-deployment-onpremises.md | 8 ++++++++
.../includes/hello-hybrid-cert-trust-aad.md | 0
.../includes/hello-hybrid-cert-trust-ad.md | 0
.../includes/hello-hybrid-cert-trust.md | 0
.../includes/hello-hybrid-cloudkerb-trust.md | 0
.../includes/hello-hybrid-key-trust-ad.md | 0
.../includes/hello-hybrid-key-trust.md | 0
.../includes/hello-hybrid-keycert-trust-aad.md | 0
.../hello-for-business}/includes/hello-intro.md | 0
.../hello-for-business/includes/hello-join-aad.md | 8 ++++++++
.../hello-for-business/includes/hello-join-domain.md | 8 ++++++++
.../hello-for-business/includes/hello-join-hybrid.md | 8 ++++++++
.../includes/hello-on-premises-cert-trust.md | 0
.../includes/hello-on-premises-key-trust.md | 0
.../includes/hello-trust-certificate.md | 8 ++++++++
.../includes/hello-trust-cloud-kerberos.md | 8 ++++++++
.../hello-for-business/includes/hello-trust-key.md | 8 ++++++++
windows/security/includes/hello-deployment-cloud.md | 8 --------
windows/security/includes/hello-deployment-hybrid.md | 8 --------
windows/security/includes/hello-deployment-onpremises.md | 8 --------
windows/security/includes/hello-join-aad.md | 8 --------
windows/security/includes/hello-join-domain.md | 8 --------
windows/security/includes/hello-join-hybrid.md | 8 --------
windows/security/includes/hello-trust-certificate.md | 8 --------
windows/security/includes/hello-trust-cloud-kerberos.md | 8 --------
windows/security/includes/hello-trust-key.md | 8 --------
61 files changed, 106 insertions(+), 106 deletions(-)
rename windows/security/{ => identity-protection/hello-for-business}/includes/hello-cloud.md (100%)
create mode 100644 windows/security/identity-protection/hello-for-business/includes/hello-deployment-cloud.md
create mode 100644 windows/security/identity-protection/hello-for-business/includes/hello-deployment-hybrid.md
create mode 100644 windows/security/identity-protection/hello-for-business/includes/hello-deployment-onpremises.md
rename windows/security/{ => identity-protection/hello-for-business}/includes/hello-hybrid-cert-trust-aad.md (100%)
rename windows/security/{ => identity-protection/hello-for-business}/includes/hello-hybrid-cert-trust-ad.md (100%)
rename windows/security/{ => identity-protection/hello-for-business}/includes/hello-hybrid-cert-trust.md (100%)
rename windows/security/{ => identity-protection/hello-for-business}/includes/hello-hybrid-cloudkerb-trust.md (100%)
rename windows/security/{ => identity-protection/hello-for-business}/includes/hello-hybrid-key-trust-ad.md (100%)
rename windows/security/{ => identity-protection/hello-for-business}/includes/hello-hybrid-key-trust.md (100%)
rename windows/security/{ => identity-protection/hello-for-business}/includes/hello-hybrid-keycert-trust-aad.md (100%)
rename windows/security/{ => identity-protection/hello-for-business}/includes/hello-intro.md (100%)
create mode 100644 windows/security/identity-protection/hello-for-business/includes/hello-join-aad.md
create mode 100644 windows/security/identity-protection/hello-for-business/includes/hello-join-domain.md
create mode 100644 windows/security/identity-protection/hello-for-business/includes/hello-join-hybrid.md
rename windows/security/{ => identity-protection/hello-for-business}/includes/hello-on-premises-cert-trust.md (100%)
rename windows/security/{ => identity-protection/hello-for-business}/includes/hello-on-premises-key-trust.md (100%)
create mode 100644 windows/security/identity-protection/hello-for-business/includes/hello-trust-certificate.md
create mode 100644 windows/security/identity-protection/hello-for-business/includes/hello-trust-cloud-kerberos.md
create mode 100644 windows/security/identity-protection/hello-for-business/includes/hello-trust-key.md
delete mode 100644 windows/security/includes/hello-deployment-cloud.md
delete mode 100644 windows/security/includes/hello-deployment-hybrid.md
delete mode 100644 windows/security/includes/hello-deployment-onpremises.md
delete mode 100644 windows/security/includes/hello-join-aad.md
delete mode 100644 windows/security/includes/hello-join-domain.md
delete mode 100644 windows/security/includes/hello-join-hybrid.md
delete mode 100644 windows/security/includes/hello-trust-certificate.md
delete mode 100644 windows/security/includes/hello-trust-cloud-kerberos.md
delete mode 100644 windows/security/includes/hello-trust-key.md
diff --git a/windows/security/identity-protection/hello-for-business/hello-aad-join-cloud-only-deploy.md b/windows/security/identity-protection/hello-for-business/hello-aad-join-cloud-only-deploy.md
index 004083bb85..1382df5771 100644
--- a/windows/security/identity-protection/hello-for-business/hello-aad-join-cloud-only-deploy.md
+++ b/windows/security/identity-protection/hello-for-business/hello-aad-join-cloud-only-deploy.md
@@ -8,7 +8,7 @@ ms.topic: article
---
# Cloud-only deployment
-[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-cloud.md)]
+[!INCLUDE [hello-hybrid-key-trust](./includes/hello-cloud.md)]
## Introduction
diff --git a/windows/security/identity-protection/hello-for-business/hello-cert-trust-adfs.md b/windows/security/identity-protection/hello-for-business/hello-cert-trust-adfs.md
index d258d207f7..aa37d9804e 100644
--- a/windows/security/identity-protection/hello-for-business/hello-cert-trust-adfs.md
+++ b/windows/security/identity-protection/hello-for-business/hello-cert-trust-adfs.md
@@ -9,7 +9,7 @@ ms.topic: tutorial
---
# Prepare and deploy Active Directory Federation Services - on-premises certificate trust
-[!INCLUDE [hello-on-premises-cert-trust](../../includes/hello-on-premises-cert-trust.md)]
+[!INCLUDE [hello-on-premises-cert-trust](./includes/hello-on-premises-cert-trust.md)]
Windows Hello for Business works exclusively with the Active Directory Federation Service (AD FS) role included with Windows Server. The on-premises certificate trust deployment model uses AD FS for *certificate enrollment* and *device registration*.
diff --git a/windows/security/identity-protection/hello-for-business/hello-cert-trust-policy-settings.md b/windows/security/identity-protection/hello-for-business/hello-cert-trust-policy-settings.md
index 870fc37596..a73ef3f3f2 100644
--- a/windows/security/identity-protection/hello-for-business/hello-cert-trust-policy-settings.md
+++ b/windows/security/identity-protection/hello-for-business/hello-cert-trust-policy-settings.md
@@ -11,7 +11,7 @@ ms.topic: tutorial
---
# Configure Windows Hello for Business group policy settings - on-premises certificate Trust
-[!INCLUDE [hello-on-premises-cert-trust](../../includes/hello-on-premises-cert-trust.md)]
+[!INCLUDE [hello-on-premises-cert-trust](./includes/hello-on-premises-cert-trust.md)]
On-premises certificate-based deployments of Windows Hello for Business need three Group Policy settings:
- Enable Windows Hello for Business
diff --git a/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-ad-prereq.md b/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-ad-prereq.md
index bac1a4e528..629e59b1e2 100644
--- a/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-ad-prereq.md
+++ b/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-ad-prereq.md
@@ -9,7 +9,7 @@ ms.topic: tutorial
---
# Validate Active Directory prerequisites - on-premises certificate trust
-[!INCLUDE [hello-on-premises-cert-trust](../../includes/hello-on-premises-cert-trust.md)]
+[!INCLUDE [hello-on-premises-cert-trust](./includes/hello-on-premises-cert-trust.md)]
The key registration process for the on-premises deployment of Windows Hello for Business requires the Windows Server 2016 Active Directory or later schema.
diff --git a/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-deploy-mfa.md b/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-deploy-mfa.md
index e5c4b9a2a4..f18107264e 100644
--- a/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-deploy-mfa.md
+++ b/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-deploy-mfa.md
@@ -10,7 +10,7 @@ ms.topic: tutorial
# Validate and deploy multi-factor authentication - on-premises certificate trust
-[!INCLUDE [hello-on-premises-cert-trust](../../includes/hello-on-premises-cert-trust.md)]
+[!INCLUDE [hello-on-premises-cert-trust](./includes/hello-on-premises-cert-trust.md)]
Windows Hello for Business requires users perform multi-factor authentication (MFA) prior to enroll in the service. On-premises deployments can use, as MFA option:
diff --git a/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-pki.md b/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-pki.md
index 810a289475..3b2425c95d 100644
--- a/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-pki.md
+++ b/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-pki.md
@@ -9,7 +9,7 @@ ms.topic: tutorial
---
# Configure and validate the Public Key Infrastructure - on-premises certificate trust
-[!INCLUDE [hello-on-premises-cert-trust](../../includes/hello-on-premises-cert-trust.md)]
+[!INCLUDE [hello-on-premises-cert-trust](./includes/hello-on-premises-cert-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. The certificate trust model extends certificate issuance to client computers. During Windows Hello for Business provisioning, the user receives a sign-in certificate.
diff --git a/windows/security/identity-protection/hello-for-business/hello-deployment-cert-trust.md b/windows/security/identity-protection/hello-for-business/hello-deployment-cert-trust.md
index d19452cbd8..0775ea4e9d 100644
--- a/windows/security/identity-protection/hello-for-business/hello-deployment-cert-trust.md
+++ b/windows/security/identity-protection/hello-for-business/hello-deployment-cert-trust.md
@@ -9,7 +9,7 @@ ms.topic: tutorial
---
# Deployment guide overview - on-premises certificate trust
-[!INCLUDE [hello-on-premises-cert-trust](../../includes/hello-on-premises-cert-trust.md)]
+[!INCLUDE [hello-on-premises-cert-trust](./includes/hello-on-premises-cert-trust.md)]
Windows Hello for Business replaces username and password authentication to Windows with an asymmetric key pair. This deployment guide provides the information to deploy Windows Hello for Business in an on-premises environment:
diff --git a/windows/security/identity-protection/hello-for-business/hello-deployment-key-trust.md b/windows/security/identity-protection/hello-for-business/hello-deployment-key-trust.md
index 34d860c531..6104c34401 100644
--- a/windows/security/identity-protection/hello-for-business/hello-deployment-key-trust.md
+++ b/windows/security/identity-protection/hello-for-business/hello-deployment-key-trust.md
@@ -9,7 +9,7 @@ ms.topic: tutorial
---
# Deployment guide overview - on-premises key trust
-[!INCLUDE [hello-on-premises-key-trust](../../includes/hello-on-premises-key-trust.md)]
+[!INCLUDE [hello-on-premises-key-trust](./includes/hello-on-premises-key-trust.md)]
Windows Hello for Business replaces username and password authentication to Windows with an asymmetric key pair. This deployment guide provides the information to deploy Windows Hello for Business in an on-premises environment::
diff --git a/windows/security/identity-protection/hello-for-business/hello-deployment-rdp-certs.md b/windows/security/identity-protection/hello-for-business/hello-deployment-rdp-certs.md
index 5fe62506a6..e4cd07d400 100644
--- a/windows/security/identity-protection/hello-for-business/hello-deployment-rdp-certs.md
+++ b/windows/security/identity-protection/hello-for-business/hello-deployment-rdp-certs.md
@@ -12,9 +12,9 @@ appliesto:
# Deploy certificates for remote desktop (RDP) sign-in
This document describes Windows Hello for Business functionalities or scenarios that apply to:
-- **Deployment type:** [!INCLUDE [hybrid](../../includes/hello-deployment-hybrid.md)]
-- **Trust type:** [!INCLUDE [cloud-kerberos](../../includes/hello-trust-cloud-kerberos.md)], [!INCLUDE [key](../../includes/hello-trust-key.md)]
-- **Join type:** [!INCLUDE [hello-join-aadj](../../includes/hello-join-aad.md)], [!INCLUDE [hello-join-hybrid](../../includes/hello-join-hybrid.md)]
+- **Deployment type:** [!INCLUDE [hybrid](./includes/hello-deployment-hybrid.md)]
+- **Trust type:** [!INCLUDE [cloud-kerberos](./includes/hello-trust-cloud-kerberos.md)], [!INCLUDE [key](./includes/hello-trust-key.md)]
+- **Join type:** [!INCLUDE [hello-join-aadj](./includes/hello-join-aad.md)], [!INCLUDE [hello-join-hybrid](./includes/hello-join-hybrid.md)]
---
Windows Hello for Business supports using a certificate as the supplied credential, when establishing a remote desktop connection to another Windows device. This document discusses three approaches for *cloud Kerberos trust* and *key trust* deployments, where authentication certificates can be deployed to an existing Windows Hello for Business user:
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base.md
index 96c6e82af9..c4bf986ede 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base.md
@@ -8,7 +8,7 @@ ms.topic: how-to
---
# Configure Azure AD-joined devices for On-premises Single-Sign On using Windows Hello for Business
-[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-keycert-trust-aad.md)]
+[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-keycert-trust-aad.md)]
## Prerequisites
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md
index ceddc51ed4..2cc6e81fff 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md
@@ -9,7 +9,7 @@ ms.topic: how-to
# Using Certificates for AADJ On-premises Single-sign On
-[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-cert-trust-aad.md)]
+[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-cert-trust-aad.md)]
If you plan to use certificates for on-premises single-sign on, then follow these **additional** steps to configure the environment to enroll Windows Hello for Business certificates for Azure AD-joined devices.
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso.md
index 1acc6aa213..63a8074f3f 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso.md
@@ -8,7 +8,7 @@ ms.topic: article
---
# Azure AD Join Single Sign-on Deployment
-[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-keycert-trust-aad.md)]
+[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-keycert-trust-aad.md)]
Windows Hello for Business combined with Azure Active Directory-joined devices makes it easy for users to securely access cloud-based resources using a strong, two-factor credential. Some resources may remain on-premises as enterprises transition resources to the cloud and Azure AD-joined devices may need to access these resources. With additional configurations to your current hybrid deployment, you can provide single sign-on to your on-premises resources for Azure Active Directory-joined devices using Windows Hello for Business, using a key or a certificate.
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-new-install.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-new-install.md
index 234f257566..5ed3e561c2 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-new-install.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-new-install.md
@@ -8,7 +8,7 @@ ms.topic: article
---
# Hybrid Azure AD joined Windows Hello for Business Certificate Trust New Installation
-[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-cert-trust.md)]
+[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-cert-trust.md)]
Windows Hello for Business involves configuring distributed technologies that may or may not exist in your current infrastructure. Hybrid certificate trust deployments of Windows Hello for Business rely on these technologies
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-devreg.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-devreg.md
index 997dbea6e9..bfecf22dea 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-devreg.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-devreg.md
@@ -8,7 +8,7 @@ ms.topic: article
---
# Configure Device Registration for Hybrid Azure AD joined Windows Hello for Business
-[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-cert-trust-ad.md)]
+[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-cert-trust-ad.md)]
Your environment is federated and you're ready to configure device registration for your hybrid environment. Hybrid Windows Hello for Business deployment needs device registration and device write-back to enable proper device authentication.
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-prereqs.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-prereqs.md
index 56e0d50918..acac72ac78 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-prereqs.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-prereqs.md
@@ -8,7 +8,7 @@ ms.topic: article
---
# Hybrid Azure AD joined Windows Hello for Business Prerequisites
-[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-cert-trust.md)]
+[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-cert-trust.md)]
Hybrid environments are distributed systems that enable organizations to use on-premises and Azure-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.
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust.md
index caf8cfe867..e6a0f51747 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust.md
@@ -8,7 +8,7 @@ ms.topic: article
---
# Hybrid Azure AD joined Certificate Trust Deployment
-[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-cert-trust.md)]
+[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-cert-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 certificate trust scenario.
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-provision.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-provision.md
index fa4284edd5..5a7e9bb3a0 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-provision.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-provision.md
@@ -8,7 +8,7 @@ ms.topic: article
---
# Hybrid Azure AD joined Windows Hello for Business Certificate Trust Provisioning
-[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-cert-trust.md)]
+[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-cert-trust.md)]
## Provisioning
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-ad.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-ad.md
index 748cc46a44..441b9c95d7 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-ad.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-ad.md
@@ -8,7 +8,7 @@ ms.topic: article
---
# Configure Hybrid Azure AD joined Windows Hello for Business: Active Directory
-[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-cert-trust.md)]
+[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-cert-trust.md)]
The key synchronization process for the hybrid deployment of Windows Hello for Business needs the Windows Server 2016 Active Directory schema.
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-adfs.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-adfs.md
index 83988357c9..847a69e6b9 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-adfs.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-adfs.md
@@ -8,7 +8,7 @@ ms.topic: article
---
# Configure Hybrid Azure AD joined Windows Hello for Business: Active Directory Federation Services
-[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-cert-trust.md)]
+[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-cert-trust.md)]
## Federation Services
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-dir-sync.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-dir-sync.md
index 5002843385..311dd7d4b5 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-dir-sync.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-dir-sync.md
@@ -9,7 +9,7 @@ ms.topic: article
# Configure Hybrid Azure AD joined Windows Hello for Business- Directory Synchronization
-[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-cert-trust.md)]
+[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-cert-trust.md)]
## Directory Synchronization
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-pki.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-pki.md
index 2b43ffad0a..6e820da88a 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-pki.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-pki.md
@@ -9,7 +9,7 @@ ms.topic: article
# Configure Hybrid Azure AD joined Windows Hello for Business - Public Key Infrastructure
-[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-cert-trust.md)]
+[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-cert-trust.md)]
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 between them and the client computer.
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-policy.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-policy.md
index ad8ff6984f..6f6b61f93a 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-policy.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-policy.md
@@ -8,7 +8,7 @@ ms.topic: article
---
# Configure Hybrid Azure AD joined Windows Hello for Business - Group Policy
-[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-cert-trust-ad.md)]
+[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-cert-trust-ad.md)]
## Policy Configuration
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings.md
index 360f679614..e099167250 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings.md
@@ -8,7 +8,7 @@ ms.topic: article
---
# Configure Hybrid Azure AD joined Windows Hello for Business
-[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-cert-trust.md)]
+[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-cert-trust.md)]
Your environment is federated and you are ready to configure your hybrid environment for Windows Hello for business using the certificate trust model.
> [!IMPORTANT]
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md
index aa375eaaf1..3f7bb9918a 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md
@@ -8,7 +8,7 @@ ms.topic: article
---
# Cloud Kerberos trust deployment
-[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-cloudkerb-trust.md)]
+[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-cloudkerb-trust.md)]
Windows Hello for Business replaces password sign-in with strong authentication, using an asymmetric key pair. This deployment guide provides the information to successfully deploy Windows Hello for Business in a cloud Kerberos trust scenario.
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md
index 4ccdf8010e..12f2d27a3e 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md
@@ -9,7 +9,7 @@ ms.topic: tutorial
---
# Configure and validate the Public Key Infrastructure - hybrid key trust
-[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-key-trust.md)]
+[!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.
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
index b8bf8e693d..29de80a2e4 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
@@ -9,7 +9,7 @@ ms.topic: how-to
---
# Hybrid key trust deployment
-[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-key-trust.md)]
+[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-key-trust.md)]
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.
diff --git a/windows/security/identity-protection/hello-for-business/hello-key-trust-adfs.md b/windows/security/identity-protection/hello-for-business/hello-key-trust-adfs.md
index b08abdb82d..b0cf1c66b8 100644
--- a/windows/security/identity-protection/hello-for-business/hello-key-trust-adfs.md
+++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-adfs.md
@@ -9,7 +9,7 @@ ms.topic: tutorial
---
# Prepare and deploy Active Directory Federation Services - on-premises key trust
-[!INCLUDE [hello-on-premises-key-trust](../../includes/hello-on-premises-key-trust.md)]
+[!INCLUDE [hello-on-premises-key-trust](./includes/hello-on-premises-key-trust.md)]
Windows Hello for Business works exclusively with the Active Directory Federation Service (AD FS) role included with Windows Server. The on-premises key trust deployment model uses AD FS for *key registration* and *device registration*.
diff --git a/windows/security/identity-protection/hello-for-business/hello-key-trust-policy-settings.md b/windows/security/identity-protection/hello-for-business/hello-key-trust-policy-settings.md
index 03e7dbfe38..d9446b6eec 100644
--- a/windows/security/identity-protection/hello-for-business/hello-key-trust-policy-settings.md
+++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-policy-settings.md
@@ -9,7 +9,7 @@ ms.topic: tutorial
---
# Configure Windows Hello for Business group policy settings - on-premises key trust
-[!INCLUDE [hello-on-premises-key-trust](../../includes/hello-on-premises-key-trust.md)]
+[!INCLUDE [hello-on-premises-key-trust](./includes/hello-on-premises-key-trust.md)]
On-premises key trust deployments of Windows Hello for Business need one Group Policy setting: *Enable Windows Hello for Business*.
The Group Policy setting determines whether users are allowed, and prompted, to enroll for Windows Hello for Business. It can be configured for computers or users.
diff --git a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-ad-prereq.md b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-ad-prereq.md
index e53e1d194f..07673151d3 100644
--- a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-ad-prereq.md
+++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-ad-prereq.md
@@ -9,7 +9,7 @@ ms.topic: tutorial
---
# Validate Active Directory prerequisites - on-premises key trust
-[!INCLUDE [hello-on-premises-key-trust](../../includes/hello-on-premises-key-trust.md)]
+[!INCLUDE [hello-on-premises-key-trust](./includes/hello-on-premises-key-trust.md)]
Key trust deployments need an adequate number of domain controllers to ensure successful user authentication with Windows Hello for Business. To learn more about domain controller planning for key trust deployments, read the [Windows Hello for Business planning guide](hello-planning-guide.md) and the [Planning an adequate number of Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) section.
diff --git a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-deploy-mfa.md b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-deploy-mfa.md
index 6088986d1e..65f12b5274 100644
--- a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-deploy-mfa.md
+++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-deploy-mfa.md
@@ -10,7 +10,7 @@ ms.topic: tutorial
# Validate and deploy multi-factor authentication - on-premises key trust
-[!INCLUDE [hello-on-premises-key-trust](../../includes/hello-on-premises-key-trust.md)]
+[!INCLUDE [hello-on-premises-key-trust](./includes/hello-on-premises-key-trust.md)]
Windows Hello for Business requires users perform multi-factor authentication (MFA) prior to enroll in the service. On-premises deployments can use, as MFA option:
diff --git a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-pki.md b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-pki.md
index e21fe61df1..e1524b84f7 100644
--- a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-pki.md
+++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-pki.md
@@ -9,7 +9,7 @@ ms.topic: tutorial
---
# Configure and validate the Public Key Infrastructure - on-premises key trust
-[!INCLUDE [hello-on-premises-key-trust](../../includes/hello-on-premises-key-trust.md)]
+[!INCLUDE [hello-on-premises-key-trust](./includes/hello-on-premises-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.
diff --git a/windows/security/identity-protection/hello-for-business/includes/dc-certificate-deployment.md b/windows/security/identity-protection/hello-for-business/includes/dc-certificate-deployment.md
index e658d55e32..7eaedf722c 100644
--- a/windows/security/identity-protection/hello-for-business/includes/dc-certificate-deployment.md
+++ b/windows/security/identity-protection/hello-for-business/includes/dc-certificate-deployment.md
@@ -30,7 +30,7 @@ Domain controllers automatically request a certificate from the *Domain controll
-Deploy the domain controller auto certificate enrollment GPO
+Deploy the domain controller auto certificate enrollment GPO
Sign in to domain controller or management workstations with *Domain Administrator* equivalent credentials.
diff --git a/windows/security/includes/hello-cloud.md b/windows/security/identity-protection/hello-for-business/includes/hello-cloud.md
similarity index 100%
rename from windows/security/includes/hello-cloud.md
rename to windows/security/identity-protection/hello-for-business/includes/hello-cloud.md
diff --git a/windows/security/identity-protection/hello-for-business/includes/hello-deployment-cloud.md b/windows/security/identity-protection/hello-for-business/includes/hello-deployment-cloud.md
new file mode 100644
index 0000000000..bbdeb4c308
--- /dev/null
+++ b/windows/security/identity-protection/hello-for-business/includes/hello-deployment-cloud.md
@@ -0,0 +1,8 @@
+---
+author: paolomatarazzo
+ms.author: paoloma
+ms.date: 12/08/2022
+ms.topic: include
+---
+
+[cloud :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#cloud-deployment "For organizations using Azure AD-only identities. Device management is usually done via Intune/MDM")
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/includes/hello-deployment-hybrid.md b/windows/security/identity-protection/hello-for-business/includes/hello-deployment-hybrid.md
new file mode 100644
index 0000000000..b762fc7f9b
--- /dev/null
+++ b/windows/security/identity-protection/hello-for-business/includes/hello-deployment-hybrid.md
@@ -0,0 +1,8 @@
+---
+author: paolomatarazzo
+ms.author: paoloma
+ms.date: 12/08/2022
+ms.topic: include
+---
+
+[hybrid :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#hybrid-deployment "For organizations using Active Directory identities synchronized to Azure AD. Device management is usually done via Group Policy or Intune/MDM")
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/includes/hello-deployment-onpremises.md b/windows/security/identity-protection/hello-for-business/includes/hello-deployment-onpremises.md
new file mode 100644
index 0000000000..1537ad1e45
--- /dev/null
+++ b/windows/security/identity-protection/hello-for-business/includes/hello-deployment-onpremises.md
@@ -0,0 +1,8 @@
+---
+author: paolomatarazzo
+ms.author: paoloma
+ms.date: 12/08/2022
+ms.topic: include
+---
+
+[on-premises :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#on-premises-deployment "For organizations using Active Directory identities, not synchronized to Azure AD. Device management is usually done via Group Policy")
\ No newline at end of file
diff --git a/windows/security/includes/hello-hybrid-cert-trust-aad.md b/windows/security/identity-protection/hello-for-business/includes/hello-hybrid-cert-trust-aad.md
similarity index 100%
rename from windows/security/includes/hello-hybrid-cert-trust-aad.md
rename to windows/security/identity-protection/hello-for-business/includes/hello-hybrid-cert-trust-aad.md
diff --git a/windows/security/includes/hello-hybrid-cert-trust-ad.md b/windows/security/identity-protection/hello-for-business/includes/hello-hybrid-cert-trust-ad.md
similarity index 100%
rename from windows/security/includes/hello-hybrid-cert-trust-ad.md
rename to windows/security/identity-protection/hello-for-business/includes/hello-hybrid-cert-trust-ad.md
diff --git a/windows/security/includes/hello-hybrid-cert-trust.md b/windows/security/identity-protection/hello-for-business/includes/hello-hybrid-cert-trust.md
similarity index 100%
rename from windows/security/includes/hello-hybrid-cert-trust.md
rename to windows/security/identity-protection/hello-for-business/includes/hello-hybrid-cert-trust.md
diff --git a/windows/security/includes/hello-hybrid-cloudkerb-trust.md b/windows/security/identity-protection/hello-for-business/includes/hello-hybrid-cloudkerb-trust.md
similarity index 100%
rename from windows/security/includes/hello-hybrid-cloudkerb-trust.md
rename to windows/security/identity-protection/hello-for-business/includes/hello-hybrid-cloudkerb-trust.md
diff --git a/windows/security/includes/hello-hybrid-key-trust-ad.md b/windows/security/identity-protection/hello-for-business/includes/hello-hybrid-key-trust-ad.md
similarity index 100%
rename from windows/security/includes/hello-hybrid-key-trust-ad.md
rename to windows/security/identity-protection/hello-for-business/includes/hello-hybrid-key-trust-ad.md
diff --git a/windows/security/includes/hello-hybrid-key-trust.md b/windows/security/identity-protection/hello-for-business/includes/hello-hybrid-key-trust.md
similarity index 100%
rename from windows/security/includes/hello-hybrid-key-trust.md
rename to windows/security/identity-protection/hello-for-business/includes/hello-hybrid-key-trust.md
diff --git a/windows/security/includes/hello-hybrid-keycert-trust-aad.md b/windows/security/identity-protection/hello-for-business/includes/hello-hybrid-keycert-trust-aad.md
similarity index 100%
rename from windows/security/includes/hello-hybrid-keycert-trust-aad.md
rename to windows/security/identity-protection/hello-for-business/includes/hello-hybrid-keycert-trust-aad.md
diff --git a/windows/security/includes/hello-intro.md b/windows/security/identity-protection/hello-for-business/includes/hello-intro.md
similarity index 100%
rename from windows/security/includes/hello-intro.md
rename to windows/security/identity-protection/hello-for-business/includes/hello-intro.md
diff --git a/windows/security/identity-protection/hello-for-business/includes/hello-join-aad.md b/windows/security/identity-protection/hello-for-business/includes/hello-join-aad.md
new file mode 100644
index 0000000000..d953bf92d2
--- /dev/null
+++ b/windows/security/identity-protection/hello-for-business/includes/hello-join-aad.md
@@ -0,0 +1,8 @@
+---
+author: paolomatarazzo
+ms.author: paoloma
+ms.date: 12/08/2022
+ms.topic: include
+---
+
+[Azure AD join :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#azure-active-directory-join "Devices that are Azure AD joined do not have any dependencies on Active Directory. Only local users accounts and Azure AD users can sign in to these devices")
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/includes/hello-join-domain.md b/windows/security/identity-protection/hello-for-business/includes/hello-join-domain.md
new file mode 100644
index 0000000000..ac84d2985c
--- /dev/null
+++ b/windows/security/identity-protection/hello-for-business/includes/hello-join-domain.md
@@ -0,0 +1,8 @@
+---
+author: paolomatarazzo
+ms.author: paoloma
+ms.date: 12/08/2022
+ms.topic: include
+---
+
+[domain join :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md "Devices that are domain joined do not have any dependencies on Azure AD. Only local users accounts and Active Directory users can sign in to these devices")
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/includes/hello-join-hybrid.md b/windows/security/identity-protection/hello-for-business/includes/hello-join-hybrid.md
new file mode 100644
index 0000000000..bc5fc707a6
--- /dev/null
+++ b/windows/security/identity-protection/hello-for-business/includes/hello-join-hybrid.md
@@ -0,0 +1,8 @@
+---
+author: paolomatarazzo
+ms.author: paoloma
+ms.date: 12/08/2022
+ms.topic: include
+---
+
+[hybrid Azure AD join :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#hybrid-azure-ad-join "Devices that are hybrid Azure AD joined don't have any dependencies on Azure AD. Only local users accounts and Active Directory users can sign in to these devices. Active Directory users that are synchronized to Azure AD will have single-sign on to both Active Directory and Azure AD-protected resources")
\ No newline at end of file
diff --git a/windows/security/includes/hello-on-premises-cert-trust.md b/windows/security/identity-protection/hello-for-business/includes/hello-on-premises-cert-trust.md
similarity index 100%
rename from windows/security/includes/hello-on-premises-cert-trust.md
rename to windows/security/identity-protection/hello-for-business/includes/hello-on-premises-cert-trust.md
diff --git a/windows/security/includes/hello-on-premises-key-trust.md b/windows/security/identity-protection/hello-for-business/includes/hello-on-premises-key-trust.md
similarity index 100%
rename from windows/security/includes/hello-on-premises-key-trust.md
rename to windows/security/identity-protection/hello-for-business/includes/hello-on-premises-key-trust.md
diff --git a/windows/security/identity-protection/hello-for-business/includes/hello-trust-certificate.md b/windows/security/identity-protection/hello-for-business/includes/hello-trust-certificate.md
new file mode 100644
index 0000000000..de516ad8cb
--- /dev/null
+++ b/windows/security/identity-protection/hello-for-business/includes/hello-trust-certificate.md
@@ -0,0 +1,8 @@
+---
+author: paolomatarazzo
+ms.author: paoloma
+ms.date: 12/08/2022
+ms.topic: include
+---
+
+[certificate trust :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#certificate-trust "This trust type uses a certificate to authenticate the users to Active Directory. It's required to issue certificates to the users and to the domain controllers")
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/includes/hello-trust-cloud-kerberos.md b/windows/security/identity-protection/hello-for-business/includes/hello-trust-cloud-kerberos.md
new file mode 100644
index 0000000000..d12cfbf47b
--- /dev/null
+++ b/windows/security/identity-protection/hello-for-business/includes/hello-trust-cloud-kerberos.md
@@ -0,0 +1,8 @@
+---
+author: paolomatarazzo
+ms.author: paoloma
+ms.date: 12/08/2022
+ms.topic: include
+---
+
+[cloud Kerberos trust :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#cloud-kerberos-trust "This trust type uses security keys to authenticate the users to Active Directory. It's not required to issue any certificates, making it the recommended choice for environments that do not need certificate authentication")
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/includes/hello-trust-key.md b/windows/security/identity-protection/hello-for-business/includes/hello-trust-key.md
new file mode 100644
index 0000000000..4d2d677f24
--- /dev/null
+++ b/windows/security/identity-protection/hello-for-business/includes/hello-trust-key.md
@@ -0,0 +1,8 @@
+---
+author: paolomatarazzo
+ms.author: paoloma
+ms.date: 12/08/2022
+ms.topic: include
+---
+
+[key trust :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#key-trust "This trust type uses a raw key to authenticate the users to Active Directory. It's not required to issue certificates to users, but it's required to deploy certificates to domain controllers")
\ No newline at end of file
diff --git a/windows/security/includes/hello-deployment-cloud.md b/windows/security/includes/hello-deployment-cloud.md
deleted file mode 100644
index 8152da9722..0000000000
--- a/windows/security/includes/hello-deployment-cloud.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-author: paolomatarazzo
-ms.author: paoloma
-ms.date: 12/08/2022
-ms.topic: include
----
-
-[cloud :::image type="icon" source="../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#cloud-deployment "For organizations using Azure AD-only identities. Device management is usually done via Intune/MDM")
\ No newline at end of file
diff --git a/windows/security/includes/hello-deployment-hybrid.md b/windows/security/includes/hello-deployment-hybrid.md
deleted file mode 100644
index b35d4b548e..0000000000
--- a/windows/security/includes/hello-deployment-hybrid.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-author: paolomatarazzo
-ms.author: paoloma
-ms.date: 12/08/2022
-ms.topic: include
----
-
-[hybrid :::image type="icon" source="../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#hybrid-deployment "For organizations using Active Directory identities synchronized to Azure AD. Device management is usually done via Group Policy or Intune/MDM")
\ No newline at end of file
diff --git a/windows/security/includes/hello-deployment-onpremises.md b/windows/security/includes/hello-deployment-onpremises.md
deleted file mode 100644
index 8746a5e9c7..0000000000
--- a/windows/security/includes/hello-deployment-onpremises.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-author: paolomatarazzo
-ms.author: paoloma
-ms.date: 12/08/2022
-ms.topic: include
----
-
-[on-premises :::image type="icon" source="../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#on-premises-deployment "For organizations using Active Directory identities, not synchronized to Azure AD. Device management is usually done via Group Policy")
\ No newline at end of file
diff --git a/windows/security/includes/hello-join-aad.md b/windows/security/includes/hello-join-aad.md
deleted file mode 100644
index 5709970576..0000000000
--- a/windows/security/includes/hello-join-aad.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-author: paolomatarazzo
-ms.author: paoloma
-ms.date: 12/08/2022
-ms.topic: include
----
-
-[Azure AD join :::image type="icon" source="../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#azure-active-directory-join "Devices that are Azure AD joined do not have any dependencies on Active Directory. Only local users accounts and Azure AD users can sign in to these devices")
\ No newline at end of file
diff --git a/windows/security/includes/hello-join-domain.md b/windows/security/includes/hello-join-domain.md
deleted file mode 100644
index 0385e2089a..0000000000
--- a/windows/security/includes/hello-join-domain.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-author: paolomatarazzo
-ms.author: paoloma
-ms.date: 12/08/2022
-ms.topic: include
----
-
-[domain join :::image type="icon" source="../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md "Devices that are domain joined do not have any dependencies on Azure AD. Only local users accounts and Active Directory users can sign in to these devices")
\ No newline at end of file
diff --git a/windows/security/includes/hello-join-hybrid.md b/windows/security/includes/hello-join-hybrid.md
deleted file mode 100644
index 3d3e75c6b6..0000000000
--- a/windows/security/includes/hello-join-hybrid.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-author: paolomatarazzo
-ms.author: paoloma
-ms.date: 12/08/2022
-ms.topic: include
----
-
-[hybrid Azure AD join :::image type="icon" source="../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#hybrid-azure-ad-join "Devices that are hybrid Azure AD joined don't have any dependencies on Azure AD. Only local users accounts and Active Directory users can sign in to these devices. Active Directory users that are synchronized to Azure AD will have single-sign on to both Active Directory and Azure AD-protected resources")
\ No newline at end of file
diff --git a/windows/security/includes/hello-trust-certificate.md b/windows/security/includes/hello-trust-certificate.md
deleted file mode 100644
index ffc705fde0..0000000000
--- a/windows/security/includes/hello-trust-certificate.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-author: paolomatarazzo
-ms.author: paoloma
-ms.date: 12/08/2022
-ms.topic: include
----
-
-[certificate trust :::image type="icon" source="../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#certificate-trust "This trust type uses a certificate to authenticate the users to Active Directory. It's required to issue certificates to the users and to the domain controllers")
\ No newline at end of file
diff --git a/windows/security/includes/hello-trust-cloud-kerberos.md b/windows/security/includes/hello-trust-cloud-kerberos.md
deleted file mode 100644
index 5ddac53ba9..0000000000
--- a/windows/security/includes/hello-trust-cloud-kerberos.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-author: paolomatarazzo
-ms.author: paoloma
-ms.date: 12/08/2022
-ms.topic: include
----
-
-[cloud Kerberos trust :::image type="icon" source="../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#cloud-kerberos-trust "This trust type uses security keys to authenticate the users to Active Directory. It's not required to issue any certificates, making it the recommended choice for environments that do not need certificate authentication")
\ No newline at end of file
diff --git a/windows/security/includes/hello-trust-key.md b/windows/security/includes/hello-trust-key.md
deleted file mode 100644
index 133f7f5204..0000000000
--- a/windows/security/includes/hello-trust-key.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-author: paolomatarazzo
-ms.author: paoloma
-ms.date: 12/08/2022
-ms.topic: include
----
-
-[key trust :::image type="icon" source="../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#key-trust "This trust type uses a raw key to authenticate the users to Active Directory. It's not required to issue certificates to users, but it's required to deploy certificates to domain controllers")
\ No newline at end of file
From 65b195bd1305ddb53b71fdbfbd7ba7d572e4aa11 Mon Sep 17 00:00:00 2001
From: Paolo Matarazzo <74918781+paolomatarazzo@users.noreply.github.com>
Date: Wed, 28 Dec 2022 13:08:12 -0500
Subject: [PATCH 22/70] updates
---
.../hello-for-business/includes/hello-deployment-hybrid.md | 2 +-
.../hello-for-business/includes/hello-deployment-onpremises.md | 3 ++-
.../hello-for-business/includes/hello-join-domain.md | 2 +-
.../hello-for-business/includes/hello-join-hybrid.md | 2 +-
.../hello-for-business/includes/hello-trust-certificate.md | 2 +-
.../hello-for-business/includes/hello-trust-cloud-kerberos.md | 2 +-
.../hello-for-business/includes/hello-trust-key.md | 2 +-
7 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/windows/security/identity-protection/hello-for-business/includes/hello-deployment-hybrid.md b/windows/security/identity-protection/hello-for-business/includes/hello-deployment-hybrid.md
index b762fc7f9b..066cedee40 100644
--- a/windows/security/identity-protection/hello-for-business/includes/hello-deployment-hybrid.md
+++ b/windows/security/identity-protection/hello-for-business/includes/hello-deployment-hybrid.md
@@ -5,4 +5,4 @@ ms.date: 12/08/2022
ms.topic: include
---
-[hybrid :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#hybrid-deployment "For organizations using Active Directory identities synchronized to Azure AD. Device management is usually done via Group Policy or Intune/MDM")
\ No newline at end of file
+[hybrid :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#hybrid-deployment "For organizations using Active Directory identities synchronized to Azure AD. Device management is usually done via Group Policy or Intune/MDM")
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/includes/hello-deployment-onpremises.md b/windows/security/identity-protection/hello-for-business/includes/hello-deployment-onpremises.md
index 1537ad1e45..43b4857b79 100644
--- a/windows/security/identity-protection/hello-for-business/includes/hello-deployment-onpremises.md
+++ b/windows/security/identity-protection/hello-for-business/includes/hello-deployment-onpremises.md
@@ -5,4 +5,5 @@ ms.date: 12/08/2022
ms.topic: include
---
-[on-premises :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#on-premises-deployment "For organizations using Active Directory identities, not synchronized to Azure AD. Device management is usually done via Group Policy")
\ No newline at end of file
+[on-premises :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#on-premises-deployment "For organizations using Active Directory identities, not synchronized to Azure AD. Device management is usually done via Group Policy")
+
diff --git a/windows/security/identity-protection/hello-for-business/includes/hello-join-domain.md b/windows/security/identity-protection/hello-for-business/includes/hello-join-domain.md
index ac84d2985c..e502110b5c 100644
--- a/windows/security/identity-protection/hello-for-business/includes/hello-join-domain.md
+++ b/windows/security/identity-protection/hello-for-business/includes/hello-join-domain.md
@@ -5,4 +5,4 @@ ms.date: 12/08/2022
ms.topic: include
---
-[domain join :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md "Devices that are domain joined do not have any dependencies on Azure AD. Only local users accounts and Active Directory users can sign in to these devices")
\ No newline at end of file
+[domain join :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md "Devices that are domain joined do not have any dependencies on Azure AD. Only local users accounts and Active Directory users can sign in to these devices")
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/includes/hello-join-hybrid.md b/windows/security/identity-protection/hello-for-business/includes/hello-join-hybrid.md
index bc5fc707a6..562b919f98 100644
--- a/windows/security/identity-protection/hello-for-business/includes/hello-join-hybrid.md
+++ b/windows/security/identity-protection/hello-for-business/includes/hello-join-hybrid.md
@@ -5,4 +5,4 @@ ms.date: 12/08/2022
ms.topic: include
---
-[hybrid Azure AD join :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#hybrid-azure-ad-join "Devices that are hybrid Azure AD joined don't have any dependencies on Azure AD. Only local users accounts and Active Directory users can sign in to these devices. Active Directory users that are synchronized to Azure AD will have single-sign on to both Active Directory and Azure AD-protected resources")
\ No newline at end of file
+[hybrid Azure AD join :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#hybrid-azure-ad-join "Devices that are hybrid Azure AD joined don't have any dependencies on Azure AD. Only local users accounts and Active Directory users can sign in to these devices. Active Directory users that are synchronized to Azure AD will have single-sign on to both Active Directory and Azure AD-protected resources")
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/includes/hello-trust-certificate.md b/windows/security/identity-protection/hello-for-business/includes/hello-trust-certificate.md
index de516ad8cb..8c78f79b90 100644
--- a/windows/security/identity-protection/hello-for-business/includes/hello-trust-certificate.md
+++ b/windows/security/identity-protection/hello-for-business/includes/hello-trust-certificate.md
@@ -5,4 +5,4 @@ ms.date: 12/08/2022
ms.topic: include
---
-[certificate trust :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#certificate-trust "This trust type uses a certificate to authenticate the users to Active Directory. It's required to issue certificates to the users and to the domain controllers")
\ No newline at end of file
+[certificate trust :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#certificate-trust "This trust type uses a certificate to authenticate the users to Active Directory. It's required to issue certificates to the users and to the domain controllers")
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/includes/hello-trust-cloud-kerberos.md b/windows/security/identity-protection/hello-for-business/includes/hello-trust-cloud-kerberos.md
index d12cfbf47b..cb8e3a05c2 100644
--- a/windows/security/identity-protection/hello-for-business/includes/hello-trust-cloud-kerberos.md
+++ b/windows/security/identity-protection/hello-for-business/includes/hello-trust-cloud-kerberos.md
@@ -5,4 +5,4 @@ ms.date: 12/08/2022
ms.topic: include
---
-[cloud Kerberos trust :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#cloud-kerberos-trust "This trust type uses security keys to authenticate the users to Active Directory. It's not required to issue any certificates, making it the recommended choice for environments that do not need certificate authentication")
\ No newline at end of file
+[cloud Kerberos trust :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#cloud-kerberos-trust "This trust type uses security keys to authenticate the users to Active Directory. It's not required to issue any certificates, making it the recommended choice for environments that do not need certificate authentication")
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/includes/hello-trust-key.md b/windows/security/identity-protection/hello-for-business/includes/hello-trust-key.md
index 4d2d677f24..dbee55d604 100644
--- a/windows/security/identity-protection/hello-for-business/includes/hello-trust-key.md
+++ b/windows/security/identity-protection/hello-for-business/includes/hello-trust-key.md
@@ -5,4 +5,4 @@ ms.date: 12/08/2022
ms.topic: include
---
-[key trust :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#key-trust "This trust type uses a raw key to authenticate the users to Active Directory. It's not required to issue certificates to users, but it's required to deploy certificates to domain controllers")
\ No newline at end of file
+[key trust :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#key-trust "This trust type uses a raw key to authenticate the users to Active Directory. It's not required to issue certificates to users, but it's required to deploy certificates to domain controllers")
\ No newline at end of file
From db3289058213db1b8d0b23ce924af06d926ec74f Mon Sep 17 00:00:00 2001
From: Paolo Matarazzo <74918781+paolomatarazzo@users.noreply.github.com>
Date: Wed, 28 Dec 2022 14:26:48 -0500
Subject: [PATCH 23/70] updates
---
.../hello-hybrid-key-trust-validate-pki.md | 30 +++++++------------
1 file changed, 11 insertions(+), 19 deletions(-)
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md
index 12f2d27a3e..83902d8223 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md
@@ -15,7 +15,7 @@ Windows Hello for Business must have a Public Key Infrastructure (PKI) when usin
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).
+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][SERV-1].
## Deploy an enterprise certification authority
@@ -42,7 +42,7 @@ Sign in using *Enterprise Administrator* equivalent credentials on a Windows Ser
## Configure the enterprise 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.
+If you don't have an existing PKI, review [Certification Authority Guidance][PREV-1] to properly design your infrastructure. Then, consult the [Test Lab Guide: Deploying an AD CS Two-Tier PKI Hierarchy][PREV-2] for instructions on how to configure your PKI using the information from your design session.
Expand the following sections to configure the PKI for Windows Hello for Business.
@@ -54,6 +54,11 @@ Expand the following sections to configure the PKI for Windows Hello for Busines
> [!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.
+> [!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
+
@@ -94,7 +99,6 @@ Sign in to the CA or management workstations with **Enterprise Admin** equivalen
## Configure and deploy certificates to domain controllers
-
[!INCLUDE [dc-certificate-deployment](includes/dc-certificate-deployment.md)]
## Validate the configuration
@@ -104,19 +108,7 @@ Sign in to the CA or management workstations with **Enterprise Admin** equivalen
> [!div class="nextstepaction"]
> [Next: configure and provision Windows Hello for Business >](hello-hybrid-key-trust-provision.md)
-
-
-
-
-> [!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
\ No newline at end of file
+
+[SERV-1]: /troubleshoot/windows-server/windows-security/requirements-domain-controller
+[PREV-1]: /previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831574(v=ws.11)
+[PREV-2]: /previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831348(v=ws.11)
From a170dd75530a10e3fb34ad2fa57e58b1e0da2aec Mon Sep 17 00:00:00 2001
From: Paolo Matarazzo <74918781+paolomatarazzo@users.noreply.github.com>
Date: Wed, 28 Dec 2022 14:26:54 -0500
Subject: [PATCH 24/70] updates
---
.../hello-hybrid-key-trust.md | 38 +++++++++++--------
.../includes/dc-certificate-template.md | 11 ++++++
.../hello-for-business/toc.yml | 2 +
3 files changed, 35 insertions(+), 16 deletions(-)
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
index 29de80a2e4..66d3a83c8b 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
@@ -1,7 +1,7 @@
---
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
+ms.date: 12/28/2022
appliesto:
- ✅ Windows 10 and later
- ✅ Windows Server 2016 and later
@@ -11,23 +11,23 @@ ms.topic: how-to
[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-key-trust.md)]
-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.
+Windows Hello for Business replaces password sign-in with strong authentication, using an asymmetric key pair. This deployment guide describes how to deploy Windows Hello for Business in a hybrid key 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.
> [!IMPORTANT]
-> Windows Hello for Business *cloud Kerberos trust* is the recommended deployment model when compared to the *key trust model*. For more information see [cloud Kerberos trust deployment](hello-hybrid-cloud-kerberos-trust.md).
+> Windows Hello for Business *cloud Kerberos trust* is the recommended deployment model when compared to the *key trust model*. For more information, see [cloud Kerberos trust deployment](hello-hybrid-cloud-kerberos-trust.md).
## Prerequisites
-Review the following section to ensure that you have the required prerequisites for a hybrid key trust deployment.
+The following prerequisites must be met for a hybrid key trust deployment.
### Directories and directory synchronization
Hybrid Windows Hello for Business needs two directories:
-- an on-premises Active Directory
-- an Azure Active Directory tenant
+- An on-premises Active Directory
+- An Azure Active Directory tenant
The two directories must be synchronized with [Azure AD Connect Sync][AZ-1], which synchronizes user accounts from the on-premises Active Directory to Azure AD.\
During the Window Hello for Business provisioning process, users register the public portion of their Windows Hello for Business credential with Azure AD. *Azure AD Connect Sync* synchronizes the Windows Hello for Business public key to Active Directory.
@@ -35,19 +35,19 @@ During the Window Hello for Business provisioning process, users register the pu
> [!NOTE]
> Windows Hello for Business Hybrid key trust is not supported if the users' on-premises UPN suffix cannot be added as a verified domain in Azure AD.
-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.
+Ensure that you have [adequate Domain Controllers](hello-adequate-domain-controllers.md) in each Active Directory site where users will be authenticating with Windows Hello for Business.
### Authentication to Azure AD
Authentication to Azure AD can be configured with or without federation:
-- for non-federated environments, you must deploy [password hash synchronization](/azure/active-directory/hybrid/whatis-phs) or [Azure Active Directory Pass-through-Authentication](/azure/active-directory/connect/active-directory-aadconnect-pass-through-authentication)
-- for federated environments, you can use Active Directory Federation Services (AD FS) or third-party federation services
+- [Password hash synchronization][AZ-6] or [Azure Active Directory pass-through-authentication][AZ-7] is required for non-federated environments
+- Active Directory Federation Services (AD FS) or third-party federation services are required for federated environments
### Device registration
-The Windows client devices where Windows Hello for Business will be provisioned, must be registered in Azure AD. This ensures that only approved computers are used with that Azure AD tenant. You can *Azure AD join* or *hybrid Azure AD join* to register devices to Azure AD.\
-For *hybrid Azure AD joined* devices, review the guidance on the [Plan your hybrid Azure Active Directory join implementation](/azure/active-directory/devices/hybrid-azuread-join-plan) page.
+The Windows devices must be registered in Azure AD. Devices can be registered in Azure AD using either *Azure AD join* or *hybrid Azure AD join*.\
+For *hybrid Azure AD joined* devices, review the guidance on the [Plan your hybrid Azure Active Directory join implementation][AZ-8] page.
### Public Key Infrastructure
@@ -58,11 +58,11 @@ An enterprise PKI is required as *trust anchor* for authentication. Domain contr
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:
-- [Azure AD Multi-Factor Authentication](/azure/multi-factor-authentication/multi-factor-authentication)
+- [Azure AD Multi-Factor Authentication][AZ-2]
- A multi-factor authentication provided by AD FS, which includes an adapter model that enables third parties to integrate their MFA into AD FS
-For more information how to configure Azure AD Multi-Factor Authentication, see [Configure Azure AD Multi-Factor Authentication settings](/azure/multi-factor-authentication/multi-factor-authentication-whats-next).\
-For more information how to configure Active Directory Federation Services (AD FS) to provide additional multi-factor authentication, see [Configure Azure MFA as authentication provider with AD FS](/windows-server/identity/ad-fs/operations/configure-ad-fs-2016-and-azure-mfa).
+For more information how to configure Azure AD Multi-Factor Authentication, see [Configure Azure AD Multi-Factor Authentication settings][AZ-3].\
+For more information how to configure AD FS to provide multi-factor authentication, see [Configure Azure MFA as authentication provider with AD FS][SER-1].
### Device management
@@ -79,8 +79,14 @@ Once the prerequisites are met, deploying Windows Hello for Business with a hybr
> [!div class="nextstepaction"]
> [Next: configure and validate the Public Key Infrastructure >](hello-hybrid-key-trust-validate-pki.md)
-
[AZ-1]: /azure/active-directory/hybrid/how-to-connect-sync-whatis
+[AZ-2]: /azure/multi-factor-authentication/multi-factor-authentication
+[AZ-3]: /azure/multi-factor-authentication/multi-factor-authentication-whats-next
[AZ-4]: /azure/active-directory/devices/troubleshoot-device-dsregcmd
-[AZ-5]: /azure/active-directory/connect/active-directory-aadconnectsync-feature-scheduler
\ No newline at end of file
+[AZ-5]: /azure/active-directory/connect/active-directory-aadconnectsync-feature-scheduler
+[AZ-6]: /azure/active-directory/hybrid/whatis-phs
+[AZ-7]: /azure/active-directory/connect/active-directory-aadconnect-pass-through-authentication
+[AZ-8]: /azure/active-directory/devices/hybrid-azuread-join-plan
+
+[SER-1]: /windows-server/identity/ad-fs/operations/configure-ad-fs-2016-and-azure-mfa
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/includes/dc-certificate-template.md b/windows/security/identity-protection/hello-for-business/includes/dc-certificate-template.md
index ba828af53d..0b99b3bb9b 100644
--- a/windows/security/identity-protection/hello-for-business/includes/dc-certificate-template.md
+++ b/windows/security/identity-protection/hello-for-business/includes/dc-certificate-template.md
@@ -11,6 +11,17 @@ Domain controllers automatically request a domain controller certificate (if pub
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.
+> [!IMPORTANT]
+> The certificates issued to the domain controllers must meet the following requirements:
+> - The *Certificate Revocation List (CRL)* distribution point extension must 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.
+
Sign in to a CA or management workstations with *Domain Administrator* equivalent credentials.
1. Open the **Certification Authority** management console
diff --git a/windows/security/identity-protection/hello-for-business/toc.yml b/windows/security/identity-protection/hello-for-business/toc.yml
index 16e5fbceaf..2cb12193d1 100644
--- a/windows/security/identity-protection/hello-for-business/toc.yml
+++ b/windows/security/identity-protection/hello-for-business/toc.yml
@@ -33,6 +33,8 @@
href: hello-hybrid-key-trust.md
- name: Configure and validate the PKI
href: hello-hybrid-key-trust-validate-pki.md
+ - name: Configure and provision Windows Hello for Business
+ href: hello-hybrid-key-trust-provision.md
- name: Certificate trust deployment
items:
- name: Overview
From 5cada839ebca123fe89d7ba703cf2dd5e249c982 Mon Sep 17 00:00:00 2001
From: Paolo Matarazzo <74918781+paolomatarazzo@users.noreply.github.com>
Date: Thu, 29 Dec 2022 08:03:35 -0500
Subject: [PATCH 25/70] updates
---
.../hello-hybrid-cloud-kerberos-trust.md | 2 +-
.../hello-hybrid-key-trust-provision.md | 53 +++++++++++++++++--
.../hello-hybrid-key-trust-validate-pki.md | 13 +++--
.../includes/dc-certificate-template.md | 6 +--
4 files changed, 58 insertions(+), 16 deletions(-)
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md
index 3f7bb9918a..0bcb259d6a 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md
@@ -1,5 +1,5 @@
---
-title: Windows Hello for Business Cloud Kerberos trust deployment
+title: Windows Hello for Business cloud Kerberos trust deployment
description: Learn how to deploy Windows Hello for Business in a cloud Kerberos trust scenario.
ms.date: 11/1/2022
appliesto:
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-provision.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-provision.md
index 8d6706dae8..e683871c88 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-provision.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-provision.md
@@ -1,12 +1,53 @@
-
-The configuration for Windows Hello for Business is grouped in four categories. These categories are:
-### Configure AD - Creating Security Groups
+---
+title: Windows Hello for Business key trust clients configuration and enrollment
+description: Learn how to configure devices to enroll in Windows Hello for Business in a hybrid key trust scenario.
+ms.date: 11/1/2022
+appliesto:
+- ✅ Windows 10 and later
+ms.topic: tutorial
+---
-Windows Hello for Business uses a security group to simplify the deployment and management.
+# Configure a Windows Hello for Business policy and deploy it to the devices - hybrid key trust
+
+After the prerequisites are met and the PKI configuration is validated, Windows Hello for business must be enabled on the Windows devices. Follow the instructions below to configure your devices using either Microsoft Intune or group policy (GPO).
+
+## Configure Windows Hello for Business policy
+
+After setting up the *Azure AD Kerberos object*, Windows Hello for business cloud Kerberos trust must be enabled on your Windows devices. Follow the instructions below to configure your devices using either Microsoft Intune or group policy (GPO).
+
+### [:::image type="icon" source="../../images/icons/intune.svg"::: **Intune**](#tab/intune)
+
+For Azure AD joined devices and hybrid Azure AD joined devices enrolled in Intune, you can use Intune policies to manage Windows Hello for Business.
+
+Windows Hello for Business can be enabled using device enrollment or device configuration policy. Device enrollment policy is only applied at device enrollment time. Any modifications to the configuration in Intune won't apply to already enrolled devices. Device configuration policy is applied after device enrollment. Changes to this policy type in Intune are applied to already enrolled devices.
+
+#### Enable Windows Hello for Business
+
+If you already enabled Windows Hello for Business, you can skip to **configure the policy**. Otherwise, follow the instructions at [Integrate Windows Hello for Business with Microsoft Intune](/mem/intune/protect/windows-hello) to create a Windows Hello for Business device enrollment policy.
+
+You can also follow these steps to create a device configuration policy instead of using the device enrollment policy:
+
+1. Sign in to the [Microsoft Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
+1. Select **Devices** > **Windows** > **Configuration Profiles** > **Create profile**.
+1. For Platform, select **Windows 10 and later**.
+1. For Profile Type, select **Templates** and select the **Identity Protection** Template.
+1. Name the profile with a familiar name. For example, "Windows Hello for Business".
+1. In **Configurations settings**, set the **Configure Windows Hello for Business** option to **Enable**.
+1. After setting Configure Windows Hello for Business to Enable, multiple policy options become available. These policies are optional to configure. More information on these policies is available in our documentation on managing [Windows Hello for Business in your organization](hello-manage-in-organization.md#mdm-policy-settings-for-windows-hello-for-business). We recommend setting **Use a Trusted Platform Module (TPM)** to **Enable**.
+
+ [](./images/hello-intune-enable-large.png#lightbox)
+
+Assign the policy to a security group that contains as members the devices or users that you want to configure.
+
+Windows Hello for Business settings are also available in the settings catalog. For more information, see [Use the settings catalog to configure settings on Windows devices](/mem/intune/configuration/settings-catalog).
+
+### [:::image type="icon" source="../../images/icons/group-policy.svg"::: **GPO**](#tab/gpo)
+
+For hybrid Azure AD joined devices, you can use GPOs to manage Windows Hello for Business.
#### Create the Windows Hello for Business Users Security Group
-The Windows Hello for Business Users group is used to make it easy to deploy Windows Hello for Business in phases. You assign Group Policy and Certificate template permissions to this group to simplify the deployment by simply adding the users to the group. This provides users with the proper permissions to provision Windows Hello for Business and to enroll in the Windows Hello for Business authentication certificate.
+The Windows Hello for Business Users group is used to make it easy to deploy Windows Hello for Business in phases. You assign Group Policy and Certificate template permissions to this group to simplify the deployment by simply adding the users to the group. This provides users with the proper permissions to provision Windows Hello for Business and to enroll in the Windows Hello for Business authentication certificate.
Sign-in a domain controller or management workstation with *Domain Admin* equivalent credentials.
@@ -17,6 +58,8 @@ 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**.
+---
+
## 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
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md
index 83902d8223..1af49e3f0e 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md
@@ -13,7 +13,7 @@ ms.topic: tutorial
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.
+Key trust deployments do not need client issued certificates for on-premises authentication. Active Directory user accounts are configured for public key mapping by Azure AD Connect Sync, which synchronizes the public key of the 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][SERV-1].
@@ -54,9 +54,10 @@ Expand the following sections to configure the PKI for Windows Hello for Busines
> [!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.
+
> [!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
+> For Azure AD joined devices to authenticate to on-premises resources, ensure to:
+> - Install the root CA certificate in the device's trusted root certificate store. See [how to deploy a trusted certificate profile](/mem/intune/protect/certificates-trusted-root#to-create-a-trusted-certificate-profile) via Intune
> - Publish your certificate revocation list to a location that is available to Azure AD-joined devices, such as a web-based URL
@@ -79,7 +80,7 @@ Expand the following sections to configure the PKI for Windows Hello for Busines
-Publish certificate templates to the CA
+Publish certificate template to the CA
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.
@@ -88,10 +89,8 @@ Sign in to the CA or management workstations with **Enterprise Admin** equivalen
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. 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)* template you created in the previous steps > select **OK**
-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
diff --git a/windows/security/identity-protection/hello-for-business/includes/dc-certificate-template.md b/windows/security/identity-protection/hello-for-business/includes/dc-certificate-template.md
index 0b99b3bb9b..ee9a0109bf 100644
--- a/windows/security/identity-protection/hello-for-business/includes/dc-certificate-template.md
+++ b/windows/security/identity-protection/hello-for-business/includes/dc-certificate-template.md
@@ -19,8 +19,8 @@ By default, the Active Directory CA provides and publishes the *Kerberos Authent
> - 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.
+> - 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
Sign in to a CA or management workstations with *Domain Administrator* equivalent credentials.
@@ -42,7 +42,7 @@ Sign in to a CA or management workstations with *Domain Administrator* equivalen
- 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 **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
From b879625af48849fa40c4f12d89ffd036f4b5bb3d Mon Sep 17 00:00:00 2001
From: Paolo Matarazzo <74918781+paolomatarazzo@users.noreply.github.com>
Date: Thu, 29 Dec 2022 14:04:25 -0500
Subject: [PATCH 26/70] updates
---
.../hello-hybrid-key-trust-provision.md | 29 +++++++++---------
.../images/aadj/AADConnectSchema.png | Bin 316573 -> 187055 bytes
.../hello-for-business/toc.yml | 11 ++++---
3 files changed, 21 insertions(+), 19 deletions(-)
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-provision.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-provision.md
index e683871c88..ad9366ba78 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-provision.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-provision.md
@@ -11,15 +11,14 @@ ms.topic: tutorial
After the prerequisites are met and the PKI configuration is validated, Windows Hello for business must be enabled on the Windows devices. Follow the instructions below to configure your devices using either Microsoft Intune or group policy (GPO).
-## Configure Windows Hello for Business policy
-
-After setting up the *Azure AD Kerberos object*, Windows Hello for business cloud Kerberos trust must be enabled on your Windows devices. Follow the instructions below to configure your devices using either Microsoft Intune or group policy (GPO).
-
### [:::image type="icon" source="../../images/icons/intune.svg"::: **Intune**](#tab/intune)
For Azure AD joined devices and hybrid Azure AD joined devices enrolled in Intune, you can use Intune policies to manage Windows Hello for Business.
-Windows Hello for Business can be enabled using device enrollment or device configuration policy. Device enrollment policy is only applied at device enrollment time. Any modifications to the configuration in Intune won't apply to already enrolled devices. Device configuration policy is applied after device enrollment. Changes to this policy type in Intune are applied to already enrolled devices.
+Windows Hello for Business can be enabled during device enrollment in Intune, or with a policy:
+
+- The device enrollment policy is only applied at enrollment time, and any changes to its configuration won't apply to already enrolled devices
+- A device configuration policy is applied after device enrollment. Changes to this policy type in Intune are applied to already enrolled devices
#### Enable Windows Hello for Business
@@ -58,22 +57,20 @@ 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**.
----
-
-## 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.
@@ -88,7 +85,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)
@@ -98,7 +95,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)
@@ -107,9 +104,9 @@ The application of the Windows Hello for Business Group Policy object uses secur
Just to reassure, linking the **Windows Hello for Business** Group Policy object to the domain ensures the Group Policy object is in scope for all domain users. However, not all users will have the policy settings applied to them. Only users who are members of the Windows Hello for Business group receive the policy settings. All others users ignore the Group Policy object.
-## Other Related Group Policy settings
+#### Other Related Group Policy settings
-### Windows Hello for Business
+#### Windows Hello for Business
There are other Windows Hello for Business policy settings you can configure to manage your Windows Hello for Business deployment. These policy settings are computer-based policy setting; so they are applicable to any user that sign-in from a computer with these policy settings.
@@ -147,7 +144,9 @@ Windows provides eight PIN Complexity Group Policy settings that give you granul
## Add users to the Windows Hello for Business Users group
Users must receive the Windows Hello for Business group policy settings and have the proper permission to provision Windows Hello for Business. You can provide users with these settings and permissions by adding the users or groups to the **Windows Hello for Business Users** group. Users and groups who are not members of this group will not attempt to enroll for Windows Hello for Business.
--->
+
+---
+
## Provision Windows Hello for Business
The Windows Hello for Business provisioning process begins immediately after the user profile is loaded and before the user receives their desktop. For the provisioning process to begin, all prerequisite checks must pass.
diff --git a/windows/security/identity-protection/hello-for-business/images/aadj/AADConnectSchema.png b/windows/security/identity-protection/hello-for-business/images/aadj/AADConnectSchema.png
index 2a5658b1a9bd16c41cf08ea6198bf00905670d65..93085b03a825eae832a1a0e0b9aad4aa0a8d88f9 100644
GIT binary patch
literal 187055
zcmeFZhd-D9|2C|JkX;E`Ns=;)$jnYgB~fNVB_pEjGBXm2gsen_kgRM{$;wJL3E9~z
z*KvNwb$`G2@4Eki`*C?ZKA(#B`+c70>-8MRaXgQghgurSyC|3`NJvO_sj4WPBO%$b
zOhU37w*PP#5&pPj6`k9jC32eX7cf+a&Wgk9_2U?V3*MOz2BIX%u0~EI6T%WX2QH~
zLc`oc{s(!gQ`}wN5yyce<$q{^{Nn!rrx8H_$w%SWo0eY$mY9w%yRF+L{g^yFia4J&5jsPG
zbj!Px7}K{=vG+;S%TxHt>XiL|y>yXsU5TN&`oe>uS9Gd%N;d_bV?_%Zoa9
zu^;}=NB!r6SLgMW+XsjNo>(|w}kh|lc^bVr|#_k~tI)~s&l4l2Z4AnZ(yf)$Dp)8G|7knNnweg*c
z)67Xg;ef6N$^Q%kS&oA1(#7RjX`X7_Li;^b51v*OA+Jv1ipt<-if=j=Y8nyh`6~X4
zqRg@twd?gxrY{y=6`qsbWS=&AQhm$R?;B||Rt^ZJrJ0H{3o+XmogFMY!Klbd|1h4H
zf+URFv<#)8J8%$u4)d1+}1Ty%-eygB?=g`@szzB}{Z
z&pFffGxuPnBih31`1b}n-=_79yai7Vu6wq#tmTF0&z5jq@A$())NkjUFn(rzhgn%nvK
zT9mE0Iye2w*XgB>phVtJIYCteC
z@->oNUtM2!EnUd435|`dw{f3id2iMEpu%`r?O{V&8a=h&VF3Y)v2V#2E?h7cWU{<*
zV^C&uPUgC$Wx087LfY@63oF4d4pz6zBrN!~AIdMbv3^Ilvf&;O5U@PuRCY#RpSkP(
zt*hhh84iw)rYE9p#wEM?#3Ys9#Xo63Hd*xj`z5w}Kk24QmJA>5m;AW8Fusq8X*qBw
zPtR`wzcMr5#y(AEk?dbtA?-GCPDZ=`Gb(M@_WgB|bj^8`bnuynw#QK4^YScSW5M`p
zZrTREa$V8g9*#nEm#I?ulvKIe_(N^NKj*Q0dZ)ts`)T+3E6*=>;mG3v1;JzcPL^%;
z@*wxJAwTUz8D=y3#ojt0AwkQ3dHHU{(aTDTiaT=n=cbCM|1?NW2fYn1WWzS%wl8KG
zo^^MZHq45g?8?u**>Q}252c-*-Gz%6=~-CLI6A(6(YdZ8H(oY4XnHa8%I8GIK*1<=
zs$IKGay#E%;zxk@f7wZq+Zj}2S~xsn8GcGkEV7o}gEg|QCiH;v_d@$a`}glRQoYH2
zE4*NBs3T@7nC$Q&xSYu?LhN_0O$XpNT_GJgDFxIT5`psX3L*Ax7hnQ@0%%wVzjA
zq(Cm}yk>pOCf7p+uJ2YSel^Bv>gepI_PeUko}ZS6t8cweQeR&`(OnoWV$oon+c|&!
z5D8EC!^A``?3@z!$J{xef6;`W}c4GIZ4BqS7CS}I*s
zRD_l2uw)M7ro+pl)XlD48(46*EAGi}quXJv*uS|Pl~$v{ZO?z-?)=QP-Sqxv6@;G2
z7ADrQ9NeAz#`N(!Ur*Jof!j%CNf|kAWDkUB);tzt!#*D2`xp^8ldV`+PybK>w}Cwo
zzS+)Ca^=|GUAuP0NV~22Mima&G8OkUe7HBa{86k_&dQ2EE$#N~prYec_rtU_(Gw^B
zw8Z^o#BPwWyUuug^jkM?_HI0B|I4;fYN@HKtM1j=XmO9fr_$2Cb#y2r4v3|{e*JpP
zse55nel+8I4vU=;XZ<*Q+itpKDaUo?Hn%F5q-1p9UV(4lzb`*!Ts{y=uBfQUZ&384
z(0=51T%43k#QppC8`}=0rJ+*bM_*%3GAL?)e}9YR=+UE>`1e?yV40kpT>p7UhLeYf
zXyXHp#meNvMkfLiQ6&!_Jvw}!jBUAkT8WE}kB^TCptYsxl-%6&ePpiE?9pO2za~0!
zMUNlH3U6|04D$v&=(KwE@};+GI1i^Pz01~XpW{@@pK7#PuCzE^*cr_|AnN%t&6{!O?%he-?UZ+NCc
z#H$I@eH%i$|3{Ep2f2?!5n}0=uDS5_kC6-IqB}
zL{AoVZ1<823k$pS)_9AMkPylI(h>s|=^dfB85zNmhR!<`wdaEtvgm&Zg*PWDU(N42
zd3S~*t7MURuYjR~j*h9R>9dpeJbmlG#6ExiJP>8^VxYgmD?et}qxiI0yD`gYT|Z+{A>*n^d_JFV2C
zPXr%|a}B$Hf6F6wnTF&ukw_8jeo=Apy#b%ST8xUD>UA@l_6ZAhO-;0@Qf_OD&ELQK
zR~XAiTtkRxq=dgdpCatCX!WJ8PE}QPpiS54nyoFZUIftB>Q45g=DYQ(o-%s}Y@d01
zZ=Wg}KXx%g-=}tH;LmW~1zp`uok>Y_LDeu`1i)-9yG3WtHFPySdI5KeUJF-j9xRC{U;_`PfjQ-4%#Q;
zi)?y4Kkv}9F2e;u`DVZwG(u?yDseB_x2e_6<4Tn*yG2eyVCD+X;-GAtZySZ%oC*^sCGt+
zb3XeMLr(30Dtll>PYCObNvQ*KXOGL7sP*T9FL%4&5ocxGvnMPjCa7b)M2Vw4=UQ$~
z&Zqi%)Gc(VEV@-+i^Q93s=Aah6~;5q6<4HR}Q?D=JcgZX|{Z#
z#p`fZsBd72rI%VY%wH*KyH^FBqVEhYufeGExYMi~Dy?egxdf?-GhqkK_CCIxV2nis!%qFRYb>goLGy
zP0EK4G2gzO6BZE}8ynllX?5L=nc7cgwpS^M4&^zKcl*{YQd;(TlMff?EJf1-JAd4@
zeDHEH%KUm#&*g|~jEc=`cb46*>9IAZhz0IB^|`LD$~xbEs{5o{X+%T>YLbc|(+871
zWfxB^{;n**1Lt;j
z^M;@3!eIx`Sl+yO6^O*DyCC%U@8369m34H2l!lJG)C4ac){9thV%6ZL=cFYk8NF$E
zIbFYxDfr{f#g+7|mc{<)eYjego5o>x6m2$9&g}@Ipok1ChN5V5KB&8sV-ZguReunU>a?+rd})vcYf-|0fcinl-E)rcdzDN50M{|MLS
z*^8X*-p}5@KQZAbIXpc4HCim>=;imc!Ai>H^7myuahrRN>U-A>4-VD@1~DK1{d{Yp
zV{t4NQk{pPq@<*v$J&53Kq(33fu4ckVMqu&=P&On6JKB7`RSD8WCRcsGjrwi62soT
zel@0?OjN>xf}V{dEk{*ya&q2wO|Gu-1tbQJczJmh`5#iHM?2Pw`26*2YmNRSb6H^r
zigX)lKgrz^!`0PQe+90h>4>`FZzK0lSW8Js<^PPz;-yGS6UOcEXvC;^c*p<>u%Xku
zxl$NbJXI7Jen|7&<;yNTE{GVcDXMjKb@iyd;+)g;)YM1od=cwzaopMcBT=nr6u@i<
z8!Y^4!83IpDckVJk7Zq5Pq~-HVO{91rg#2*`SK+#JG&+~eL{NrnZ0=#7mq|mML8SG
zGJIKETU)s2b|h-PYRBdJA@w?U_mNnqnY*V>t^5o}CeHMG(fk?kWB=CFY!@i7*8jd(Ypr=6PfKo`r@!E4yezS6`&I-5ibYLL
z4O-f$ToyP59y@hf#=Xpl=I6nK2kG|iO=%RH+<%HKq*OX@bt_Uv#z#a@P*$9khlfXL
zZ{hAb>dwK5NQea3(t$A+n_Y{C*>;psxx^}hf?ChUEf08t{wfUg19zLwf9%m~a
z)HT_zNq&7PC@}DVnAl!L?a|-AD{th5J$oiTC~@mAO__!^qgzjHP0g4b&rx!5LBaUx
z&8n>Cc6lYGkN)ou2Rx`9GC`IC9)w3m`c(~(a2!17^N`^Xn#fL4F9#GR4Q4dmgbRO&%OO}j77DkVB7a-=C}Q}L{Sj!Ml5vU^K*`g_Rh?;}{
zXt}bovOXuXDRT1U$@K{fnW3k;hMXr(T=X!Mm){y9wa7%dho5P-5C9`1zt^ZeoLTI|%J%xljgpFEiXR}G&Xs=bO3yxH(Vs_sbEhswVjYj-NTZsgtG+*ryr
zt)Vce{+4r(g_(I7FRq&EDMla@Fl5?o+C@E1+8|#r?aiB)A3m^Vb)30;nFZO5BtjPs
z<$idrE+X5qnd^h0K%?{;KRU+Rh3Q3G@vq4KC}}qdwh%wyUfb3A>#sE98c-q+A3J6a
zmRoc;J&g}Mkk~#v+@pd>o{Kjs`*2??W11dnN=l@ge*`w=Z`|OM`8ykOZzx#IKRCE;
z?VyNAxW{UWMgN?lL3q-b`Cgy`s8v$XX0*j(};SQ`7^8NXFmRSk__GJl6;
zP~t!!W?Ro|Hg|S@4)IvOic)@eEID#{W7?x}W2vvP=+1a*X6CQ5zvE@8Sy>%EZbvz0
zf^A&A$k^_B{{DT#eLjg@`|{<$9%~D5$Tx;1`ZVO9bAlR2unfJ%Lmz{o5%lKl4ma1k
zofn^(#^*=9p9{P=AbPqR|j`j5_LU#-2nG8_rQ7{q3FyYR|CDy@!A_VpGXU><^U
z?AWmbYCv;KOI50NQfhkoP-NNqLFGrR&AGKngwi#)JQOn5behI)epI_X%cv1oTM%kO
zDPi2ZH`ih89BM5Y4cpI8p$Fy{7J8oS4%_px>BCqAzn;8?#v?Wo6lzg1vAHitvVvwN
z#F&HCW5h!}mi;_rb#&Yp(v5_i=Pe@yj56btK({{tc&tOLNh&QhY>bFIaf`Wct#=8R
zTK}zEmiYGVW1w~|8c%8}s<+TN4BZxVo<~P7gr5pk*$#sIE%}VzJ4-s0>(%LabVaB~
zmF%0#%FZq>%G(7@uU?H3x=NaUF#|iP+gG=XblY_4+A;7^bHG5{l{Ss>4WDEko#84P
znV%yvn6y-Yx7^ug;`}g6E`3
z3i@@$hqXs34m19^7DKwTjH{Xcf+aXB&k}RGGz#cN!*}9`_w|~c~MbO
z2&+0eI_v#pGV!UY{y^;Z_97&x1j*P@;=^elhlN!>KYsJ>Oa+-;;T80&mhNuInj8=+
zKqA8;B9wr>$~Go#(9NKTfGZQR_2P3+Z||e7$ybGi`%pGTnNhnKlA2X4EDoJMeVU4z
z`deq`>o~yzy657j5M{UR?N>&VLQ*p_l1oZr+uJXa{F$5EC*?d(zD1mtys5WWWODZ!8>zCyP%=xZlvA0Zc@6PjS1girOkFD&@nsL!Uf(xg;6y
zA&piI6#()r*EGkyJN>GNtw7WupRa?BW@m?LCn;eed^^UI^YV0Pist9%
zIaKKx4r!PnmZ7*oG`F<2ewC7<%wC5r6c!e~yE>NAnQs&Km-<*FB?`w&)o_w$r|t>c
z4o9B5bLTh~87(;$9K?2}zk;rF0f6|)lP8aXbDf;TB99q-Te~KX5{*?cG2z5ce3)yH
z#G3!+T1!EyA%fR?`Zo4c?mfnR@?;eBMT1L?cs7VstIu7>Gx8nI2;RzI4pw?`cW@^b
z4cZCtJ$CL+MOl7+B;=`SrbKw
zl#Fa)!vU*CG+rQvrtWTaBO`W{K%=BOk{asn|Fy?PuQn{o34
zA&_)qYBcdZ+lzorVDZt8D+RkVJ(P8JsLE%5-)Zr4h(&CdN5fry)z@Y$oIU)ZW)W{y
z=*RXvGz(X_tTo_&dEkSQ+>SpN1XXkce*5Z-QdeCMc_8=Tw%^y*OWQQOs6VYDv&b$fQ;>Q=H_mllxIyUAy1IJ_WQ8Wi%}Nar2L=WTfv&Od_>Cvl
z8KEy;P?yg&$}~oaSbzbHw7x!1bUw#PebkRm;GfI+*27S(NYI<1AV&~u54JiTk
zgCxX5FF6x=Y&Otn{lV(0Gc*IxNT6*ANywNytuAjs~cc=qw-B|I{7G`NF`!aBuM8
zp=W4+1aR%?>0y;}exhsS_H@6bb$LPjuyn
zbQpQWs&LB#O|V@kY!+AKqRYw6jS@838pdt6^5>e=ktG0%ckkY585#lr*?%vvOJci%
z>Pi4JR%zEuG{&ED)U~zgkn^S}c@Ut@p;qka`KSH
zfrZ^@LJtE2ueQ88i&cJx&q0Z=0n1rg%r6VB8Zh2iT_83aKY*44%F^Gg%ueX(@r8v^
zGV230sDfL%(nEver@Fg7_9CWz9jO$zdcn7|yK}+F-RzwgJjNhWwqlA43ofOgx6e^|G
zXAon{#~09x_Fy{k88rl?9{?7hfJw?(6x7za{HtlUp#3lPKY#up1&4rg3wow*PGn<<
z3O);=vt{h%>({EAQ}t%gZ!VDS5itA;xULC~R<=@agCRq-wb#?9Pis!oNL3>)FXdau
z8eXn2%^o#eot>SH-2G7*xgJzH{!*nx>_v6UhiThWRK5EeB*QbP4y(
zwLVnmXYA}ER7XcK2CaLRdY
z?Fy`1d2XY0V1+T(Y|ydT#^t5ae+{8BOtLS{tZjT)`4tUJNsRI2tJ4I`%@2o6|=<@P1*oph$yC_W6(86^e0{
z2^G9#J=!-)_@+|TVpJcPJorGhoM=06b=KpFYGUPeW2Kn;cay4RnW(9hzDtrEy1?*4
z`<_Y;6?_OD6O*6^UKY8ajBjO#BjG*110+0@rEoZx)2M@NYsi^@$UF*m+
zKy(bhqDX*xf+!-|C+2tDOjLgc0|owkJ0sBC)s^m|e^Wl=;+yjfM^7ivvYfCoM%)9x
zC8qJALlIyZx&l_I5YfKT-__OCS#;+J
zAPuUg!Krs$lg_>$%tvN_r)TB3Z#biWK^ezFLSoMS9vB#i(m_o|%^DAc0I;{Zwg#;X
zxd4KG24(Suo6PlZ+)^$dii@KGMaQDDzY6TDFn$c8ix^f14`6qjrz55^XV0F6TI7})WUCjEt)CGi
z>GWu?k!xsvuX7--j;w}+*6p#m0f}vfm|qhZxk!b-P8dVAm#
zQZEo#Q;9?%z|rR4jTmXS=YRre`^2OZ1t<~SB`An$ak?+0$GRiw0b0*XU~K#`^QTT=
z?pL%8;c{T2S{-BXtCACE{ncG)kI~Lqk15c&lg{(J*kuS)H&?%!3EM%1$AIM%k`@G&
zQ(F4Pix+HgN=212mDSXm&*`{KADb|3*$4{PAqx5`6!3X1BAKY7p
z#&K5Qx!XYHj=`a!6=d2+l%l&E3mq6n5RDw`ljE`J?!K5CXScp=2ig4&`Zd~CYkRw}
zxOi%aDo6;ZD+ZIKDJ`GTsR_ylz!J|IQE0c}uq6`_EjJz+i;kfa>)dpc_Y
z7?}!M#Slhl3Gd%ulu@-sr$kpHx&!8*uJg^xK*pGDp{sKoJsON|Ovo-9X5VZX6)UXs
zA%uGJ*WEqEhUw&SA2S;T4q9WNB7VIbZ`6q1dn5Y|oyQKMP7%WvR%-h{KUFb#2Gby>
zpVwPnW#iG@)bj@46Ejj`Dg{ET5>|~a2Hk@PARXBP8CIE5xFcZwFKF@*w3(FBQZ~Ja
z*I8MIa7Q3tSh3T$ZwpJuh3sVDd29BW9`wBN)Et$j%!VksFn}I}B*Z94UO2`$cswEs
zAeQnQeqe$)4QcA$@Kasnc-zreqDKx*zElxqt{IvoX@WoiZVQF*5`V<_9`FD1XUz-`
z*@{E7G;Mq#_4S#M*ZTT8ok#A{!UFM3#E8z-b^Ywk^Z8#Ec7L~IY#S&y65iHW@On8s
zSMb?cvuG3R2cciYx9y8KA~60)_Kcu>tY)&eC^t`uP>xn6t%@s?nF5S;0&k
zM{`{ZvhJQg&p;%&fq_AFZ7n9W`ydUXcOWJRo)##rzbB*9s+}?e7Y)T$fu)Mu4Q@wT
zm+xkYCdMg4wISy(U#=@JCrQv!5x95~f;{#Ugo^+%zP_YA&~NB?Tp=5OXl$@9-j{fg?pSk#=lm1b|g4HMw)^$yg1%bzmm1
zLR2qe4Cop$5AY4S@fpA>0v4K*w!Z!s)Byr}d(lYChH)!}uw}&Q14cG$I$Iv!f`CSe
zD&Jj~gh>nrAl99Mn@UVnzI2L~HW66X_qV!~u3k-IW8yt>gpk*Dbig|;7Jj!CZ3H_q
z14Hg85N^k#AbY^V0LlpfP4tAV%WVot&2(}?8Rot%W37RbefLIUQMa{pb!&k-U>!gw
zlImh>+9rs(74%GJ@BL5t>!2O}>2;abK7anSscEA7>M*1+f>2^5F>ilK_8XBg&-D&<
zYJkwUkxh%y*xnm?zc&)3=31Jz#-sfH93F;2;@(`n*!5etaF2>cUI1Gm(yRV+BaP?J
zos$PvAS9H`OpWPWS&nk#?ShoX%{a%~2RS(b7(^={kQ+ll#illY`zC+;c8;NJQD!D}
zepfxhWnNYd@DZ7?dS$t*Y~%9Aey<7+45ZMxIO~LQIXoB$1HO|0Ebr8NPdWclk;L0K
zJA`hXh%WWJv6cq6(4^ws|1wg#o_Htm25TG&fP$<~Q|*s%KDiieu1@}|Pm@w*zZ>&Bj_@*bN)&xjbH#~OPg_eyvA?6b4qC$E
zL}wMcP$j1L4kj+(fJE*?$$_tn+(%yQmQ(z0!fLr*(9sS4R(gFr283P4QphPz6^%r(IABaLy&I&E}YpJ0c^7w`(d+96IUsr^uYfq&s_vH0@jFfQ=N
zW^>VoFrkR`xrT$AK}i9|;lzL^{}6VtW_oG7R>8NWuaBUcB*3yDphL5FOCP6(@u=)!
zWYoHFVY@6E5d1U;=^w&KgSO1b$cQQEJ`r;&r#?3^fwFaBwh(1@fwSI6jvl>+_{B#M
z9sbYXwP^h+^cqi?2K>p6h5r_8DqsXAqRe-)^%+{WNToWAeLD!`#w#Gep52f)Vh9cg2!jsj
zX&CtvFrNR?TUnV{ya5!SFu1&XCkg=>4#K8epE8vgI`V#Odp`ZQeu7=!lkf21o#CGq
zFf0Y&Bs>kz;$xYFqw66~jw{AOp#hz2E*qL#$-G&0{M2{nh0k2|m1nv%Go4~9jGHuH
zfQo_YUrc|R)MG&SYIPSluY&j1dA$Pa726Wx5%eaS?Ni;2u7
zber_s?<7zEzE!&_d+o`N7*cXxzKi>KB(H4^_@XWLj#MX8#gb2-t&HOP&m$H0h5f!h
zxfG>NxqbK3$6MKU=s%#?<-Ws4L2^gDG5M-c;hNyxp8Qtc+)i}^gZ;%$)8>6?UW`~2iNvC)}yQD%A{rgreP_H~8^z4dPAHt`Y$8bRE|wE-O{z$xBrg|h@-h}p$v5$z
zeP?ll@>d}Ja@Bw!F?B^olOW>^bw%4CaTA=PpvU7mr9R!@a9t!`z;xrrjb+FrXV8lX
zg;r_yI;9bVU6#_#vR_7-538PQrN&xAx5ThnI=-Z2qi8UJTeawTU2yL~Mha+_)g?>4
zXVlav03q^jcH|(Q$K45yw6anjfA?v-K~&hl8hLTn(oC(Dd(8@6XflhFUA6n2y5*n<
zf(N5~g6S_vPyiVhc@%eADe34?vrA(sd+vytVzz@dB_`;((gHtJDKp+qehxo$XL^$*
zPt(O35CxJC#*=Q;_#faV1VS2_bu9r=mxbaR3kNW>MSlR019${|jH|n-m>Z|9^Azl2
z>-}>7wd>QJr~w`0ZCU&N+83DKN{$U{mJU=(f-t0IQ9UX0xR`Bk#*|%*R1GdXWa%>sF&^n#(kEJgeP8N+DxJdbW
zxaW3Um)nY-g7z~uK3;6zb0$oIn|@$^tc6IFial|S%0@&$Q6yg39Hqk62wQ}C$p=x9Qb!T_tNc0R-W
z-Vyjo&g|Q_@4MCe=+edo1v3;fu2g&j9v-^Ekc(m%&+kZYQ-f8h#vF1Hl(6Li8V~=v
zVN*!C-JpJ$Z_iXSXkw}aS*l`uA(58?qukXs!>mT%y`D`s_PFZbdeA7mFE8jjYB$i*
z=;UN_Qqs_Ki|f6AIy*aIF?bvve%iyM%y0zeaG`sD%=YkK^6Z-YrCYYTo0zwnF&W*8
zby!fcl`@%jp8T*XslUZYHS8{?)dc21eLPT_@^G?hoUA)l6GLAnNk@L<15~*lBZJd7
zoq!&|VuJQdMxchmOIBg5wKUV=J=PUmVT>=&=g*me#8fbKK;pocAad;sBNWe*c7xu>
zM$rhQyjIW@PHoJ$I2-s6-1_!6-ECQR+|asTw&<-k>X%&2tz;d|X2evC!Ne*fme+*xw^
zLpW4hG!^T+&T`{Pu(XwB)teVjl_q5v)N`e0WrdWMmJ0NQ7>k}>Y#rMJv-)avIG@MiPV)bBBX(=Nd)WuoN(2Kt{&*J$CME}oVq6hCP7wg>G!mZo~%7?r(1(Sg{fSL}EcGXVf?Y;gHlOUgai*gz@7
zbZ8dM3$1NZNw=NjhTs11;MUX6KAx>Oe?>L=VEFzGIt`cI^y>W~57Oj=wtPEEUqc;b
z=jfkCue47-AYfnAsqv>1ZhmqfQ_?0_{J*hk%_wJmU*t_wvmlqK><{tIb~--z=48;u
zx++!4{!i{SyxIjjIBQL_p^JR{RUb`I`roaue~yfV!^w{YA-r{2bl0SJ;Uq@wPy!?w
ztpCSg7G+GY(BBocrH>D7{I=3YWrV>3n+Iq?=#8F3)NfUR4MYai`DwYfgmVfNGc6dRz;@>wEv>9x
z!ZWAETaCOY79E5ExY!Tc!Qj$bHf&_YNc%1u2>MbZGb6O*WqhkqKJwY9ZX5Uv*UhM0#i
zQAtU~f}`bFG_q~%gDCBMv9x83n~?%`CMEKms*F_YJ6BnHeFr8feB{5zN=D*(&x{2>
zpvIW&QA4_EEdiq{|P1P(&N5?Wa$lIF23D$T!;ex1p-zeuZ&A7|i_QVpweK*>mT@
zq(|PJbT1KVZf}`c+($(UtsnfF82F=gg7hd&Nd9m>1`>vyKuKJ&O?rRbvRwp&7c&rE
zXs|)J>^9vS2Z(7V9GjZKkE83&k$d8{{UkI}^R%EoBXEyka2X=L#eQK8ZVQ;WtU33v
zu+)J81Cl{k8NaCdLkhSStP`^BsL!J^ez_}iolAF5VL$`>hB)lguwxy#!C+}G$8z%)
zjoR6>$%%;%FtONr-&5Kn)6iaj)_&6B$Ei)>F24UnXOl_{%PAVMUod8|KFs2QaA|F8
zYi@3ywP092e#?~5dJKvjybH?gM>Ghh1duntwOH@nZJxk6IMfmh^&2zqjkTpA$KtZP
z_t{lR4+eC1+&@05_{ckyako)?%pP6RjEgK`Rvd2(vxgoERbGM$UnN_l$Az((WdtT<
zu8SGMpTgAaWrq)BRaR8+p55Y8UVD}Ij3<3f|AO(@hoGTKJJvj9!MqNyJ}1TQvOlI`
zeQ!e)lYqFIySu*va}u*)T5>G|gR|$)w;WwN5mj#vwsLQ&$0-U}9;9*@f;m+Bhggvw
zhRY15(vyD??J(LCMG~HV;A;!$4j&fUFGKBuqzOz95pvJ5EB-BGW+M%;(0B)J#o;G9
z2%BV77J>jfLC^{$703g8ijUZ&)S#yjMwmF6ILw7W&U~SshE&k?7H#N1xw$$&1~~eyr>7nk0f)x90j~JI=~_!s;afjMVLqvR
zcfDm979677U~`GEwj2653v=P0^|?m)3*H1y&m6LQ4{PBPX&e;3e@VrbqG|xy#CTpx
z%FVlARn>CnHi!-u2%^CVXnpdlSH6H_v^eS#I81YDhB&N3Y$%NVr7Rk}jD$}JjjP{5
z;w0d4ie}uaSFg+!KE69~k#JqYYDvs3AO+;!n=?n_#M}S}8wi&e4kc8fB*KzW7bL5PyV*8)mk8x}cSul|QC8-^rLqFI4@p0MeC
zlNEv_hSm#z^$+2zedkj-mxJ?PuDsC9?W2w(0uA!k}+L#2Sh;upu&d(UlZgSQV0p^Cg$fsZ8tW)DcE3p
zr$aFzv;ggKg)hb7&Ydx?4>hI<5ZrTegaP-JK`$Z&j0i;??f_fNlpA5l1athhY@ePk&+lxSdU5z#teLp)V;jNqtkNr
zGzV?``}YxWvx9$PwoUk=Fp$*NG+kJ6CDM+Hib@a%iHPwX&EKvbUrj0}m1e=aq(U9K
zSD7Yi1X~03r6XlcB}@XhJ(lzROCGb3=HQd~M4a2an)#Wj$m6Tw57V01E{IP(%JC5V
zV&e4V#bY(uVYO8m_Py0qci+A@;##cMu!_{UIy(Kpll`4ag9WWEINYS8J+wafdyv}0
z=!2{{EF+@B-!6PT1ZPArPHRLv(1TAUNhx>`&jlq9*pa|=aNM8^xeqEFXQG0nXV+i8
z1-ig#oN4oz6Z1F?{)fi|oFjxkNcPFe$;1FQ<8uBvBO^_CPf+<&Qd3nL-?j-WSRi^t
znPK8F*sGrpj~8Ktlyo|V5=ERrfl2{}hHgqsE`cKrT_%si_Akw~Hm~GHsY?;&=;Rb0
z7uN{DPE6TJ3Ty|q;@WVQ-h6We?q@^-4g~!}z`K0;jFr{IanqMQ)+vy|@afq&Cj^b~
z^OrA!5GsiY7E)bMT%2$;L289csg%!;aSI`jOneu@1RUqQh>?;_?Mihr^9=FpKb_KIg3?dO
zw#YbN_Ki_x|G+@|-AAwjikB`iq5nUQh#3EO8|F#AuiVHYgu7DfBhdzEU?P2>-ttVgoVP
zqeG>1toIG^_xH@o5bW^Q$Tz(~4wvdu(-Exfo!oQW8M7o2N%!pI3w#DOyKrt-dOIm87gh)k
zvIkd=IrS*q$oug$|Hnx$`hq<(w_jP?xo2MBOK2IJ`FtoYJ}GG%%)iw*hn$V!_Narz
z^4i+z1TA9>*i=+i@AC#^>V2Q0aFy7mw7EValMTrXbH?phC-2W@I8f=ha0D8Ik=w#<
z_}yTA;t1eE8})~twbk>;G6N&y_UL+F3}gloZJC`vA>jHVWDuIRU}{5)T{gfLc7z2t9ef1Hx%oLi;C3tUv)o1XeC}yc=)aXYh
zT0m~E!eB(=nXa2P2)nfPc};OLOPB#Mlz8CpPY&xfGceJ|vW>2?!fzej?rW2mfN3IS
z;EE(rxW8C}U-ZOv>w0Oka)@|E3!#`_jYu|@*
zEtjALzZWY`W>({b*IRg1{1g2Fm#}~ErxiD36|av;#8P8+?jI6DMuKY=H6+=$7juwf
z4Ezx$%s_BHR%n>zlmZ_}yej(BR&WR)8)oN@*}D`|k{vtA$z^3_Nnq&de{TS-F)TdX
z4h{v(S9!5qW7JkkYVL;xHCA?jmvZBNb>E9jRA^4(mtrToXVs
z5L$K5lBqVSJ5l3}dPu|{+IbLSyY(pc5(-ylZ
zb<*T>4?!1j&SDR)_aG#M2Bs3N^XIpvxBVDrp-tq4XQawZ*aVeUi|=W{$P1UZXuCKk
z*E}f!ZA;vJT^!OnXa`z~plLNZoMl^xQ_qA=14b;l*B6Knz)el}mfQvC#%Sed8cQO=
zgO!zv#G1^eSf(zv&kc7GAJ36`f$#G|Orvq~xt+MP62lM>dM-Xb3PgKVtW)npU}^^E
z5;nDDdcLO=c#iKm*C-M92^Z6wfBXnQ266H7k`n-#=$nLehq6YJIsB{4bw#)#PKKuc
zhcQm!Qo!GeBT)rl_+0^zC7cMtv*q-
z>XWwqB-^KN57iA5?HRW4iUC`qLkThmKmKf%DIeDmH4Ux(G@v-bUX(fbNIju;Q}379
zj{60PDbjEN3?eq=_D>an9&AJrDd{nTB5$-#2==Ck4g)1iW@csr8$pid;@}_w%)kX;
zZg#}6yOkaF#sV0mmwOsTuRFTI;vKB8#y_-?Qn!x
zlsaKdtMDQttc}a7t3?4x?lAn};76^2Q;$!1xh(Hf7{;iH-h=v!-lTl*Uf~g@(GQ(C
zH$qEGOPn#(P0&1))a;M#udJ;lL&Nn`=Q$0hb*5nnemg?FE#@
zA2jR2{p%!|yF8KJum!R}#*v5HKq-jnK3XN{L_x2p?NUwZ>(}=Y4J=$+
z&@P!Lr_%~?M$`-dBMb`duUsIJZMQ_Wlr#Z(@|)xci+0sVohvxaX@^
zJcRRz>G%!CCu+$@Z0@4aVLXpmHt?c}bN#auTSL2l|1N|g%;&&V<(8rlLFr%^E`U=r
zvU`QXXDd(mPNG|!d#!*vga;aOwokA(!fA@qm0v8dz?q;Fknh}Sw<`kN?n>e99e6c<
zcZE;wV0nWx135YH5c?MjCSv}C<%fCivkgHDc5`#fS!SziN)_MY?^#}ThXeyAk$lyC2O!<
zW7zM>ckQ~_Xcz>23;bXTmX@jGPvubI;B%Pxkw*!YRqOQyWDyQZ
zeFRzZ{PIN&15y$b6O+s}Xt{*6XK86^+an2jjzWCtz12Rn3WPDhI+>IvJ1&H;=7m>U
zyuJ&4?;Dn5#9|KL^Lr2~kPYrF59d{5pg2R*pfs_^V%y|>+jC{yB~@xm_8t<*v1
zcNQGi^7Z2yel|6|jZRiAeSdM@#VbvLyg~+NL=wM=RppmbJ^xmx6=^1~t+Tx_b3niR
z6?+m>!~DUi02Rk$tUo%28=_wH$V?jswHlbTHPnbCueNtB7J2Zrk=guk61Xx@FVQ>S
zXCPCwS=K7iyGMG`egDhFPJ^YJ{Zn&OlRX(j_1R9-XKcn79fMw|#FmwIN5(F7mSl(s
z6r}uhFmmEpdY^y&qVtih-Fh}1>c6}1N$jyHJ>3(ccw_&F^SPxfBkxO&PWSr#Ws9yc
ztpMMdfym0
zdHUNI7I*eG4EmE4@$Xe^*0FuJ<{WE5T}&x1(IuHbFcE#h(8c1ig;48MU3c=^v2Gcg
zACeYw#grfJJ>NNfO6J9CUrFDK02c{X>d$k(HAd#Rc0Y4UnG?EGx~Hd0+@iOrSjKrg
zWiGd2Ny}m?)2ns%q|x~7g|+xOiH6cUrN>@O9e6!7>Z%d57Wu>7srQQVYx}-?9=%}_
zjj;<6PNj2&Q!$Z!(QDoJvgU^`t>!!`wr|^zp6b?hTD$Gkc+Xi{B5voNz#RZr!~w4X
zTX8KdEl(Iab=gDsIb*EQ2MN1eeR2jn~0n
ziLauQ3)#P4l8}?II(`ar=H;X8w>Tl2*-~loL*5}MdPh~!e$M<%aQo8>xCg9AzkG$9OP_9d&k%~
zCTv&^SZP11Fqi?8QQTD@hT
z7*JAuRv^1jzd-&~ie|HJgwrO~+qh}li8>C}t#ot?PwUOS*c&dqC
zH8bzL@%Vz{p?_{2S7L?8Taq#k5?fh87ETeT@(xo{lI3SVIN8N0Bl^inxGwxqTOLlS
z$m-{M@>F+A?tszC;h-
zZp*v6x=y#Lm2@_h{h15oGrDy3W74hWvIOpnb&^RhShatDiBf&OeEG7C1G~S!uQvxddW9A*BS<^W
z2#6J(`S+_7yp-H=tf_ZYnwD3nUc4h#
z!;jF?p?_75XO%rd(6RI!{MRCICCUwqj2!xOoVh-Dij1!Lv37bJfG98@Nu1NauRU*2
z$yKZ{AA3zW>Ypr^e@|WT6!pKKs5$|93V1e-R8}egDYcU3>dn
z=XU*FY4lJ#7V_xPN8(64ag6r?2bG=-aNyfpT_=cRT{-pO2eUXE#fsl77j_H0dj`@D
zp@;$|Lq#Dp9O8Vr$^2;Z>E;E)hl&1B(1xOIO662lcaq>x4Jn~YrRk){Yw=pElzo!K
z@8nSqVXMLTF1};D=Y5p89oGwwzxN=e8jSR6JHh|7jJtXS;G18!L#~`b^VEHv^otc8
z9ZM2RkNy#hA1X*>=;%TtGp`gr0H0PnMng$ig=s$KgZ_eqZ;V|9|K8y06>m
z_jh;~Bfy~Ap!1v)u4CaVq4OW^WJ>a{%A
z@3SbHE6D0ks{S{SGUL1|?Y78%3eFC++;*wi;!O-JERI?Wa^EvrO;FQp09~}FRUeS2
z!{THmOV!>Q=}zofkTA>TE~0tp=3obySP8vNjzMTM&dCf*$-ddz-w1
z!YX2BV>4wtq&4moR*X8zNlX7(^>qQDcFraQZVUP3y0-vT;rl<|jL9!>KA4n{Pz+zc
ztHNQE5OD%?FgiQmz5_)8YR}$O_oV~Cpqvh(b5!2Z@ff;Y(*PR3Y8o2;e0XSwG(*?$
zuwQ-sS*X49Ot%8p$O&IryCh8FBOTon+KG*x6#nvpFU+}DFT9~>BJ}`LAhRi_gbH8)j%U|fpD+eo^5&Z`+rX87;|x^);+sphU0Q`i7(kyqABnpQttYd3zX&O&VeYO
z{wB|`7ARP$e#W#h2cQ&E0Z1Ywwh%beAOeUO$yeYA1n}|AnX{n#k(R+>=Y}UARY-C4J4GiZSC5%
zoWjDHEnV@gCKXLdmn?hA{vvq%rBvKDGfw?E`l>i-pB6LH`f7Q%!^~_}b!`#J#mk{&zEhCR|
zxJQ%Gv{M9XUNkXu15+M(S9HknFxE8bDg{YAVwVFvgHX;8X9ZB!V|6Y&w)
zTpGLS538I@(qDj}5W5cooS2!VvXChc2SCNDoy0$uD_fDi`nvE
zcXT}AGt22?YPYIBB$B)1Ke+Xfk?%eZf6l?eat~rd($Qp6faaCZpO
zWCv^p@{@q!05Yw_{W`Dmb3&Gcr|wl)xDx%R&OitVS+Rab4mAT9KE@5}{^1j7Y~6`x
z2(~;>TsC^2q{EVulE4?hKYA$&i}wDq%iD>j88q{m1&ez{A%)bU*1}JJYirYzx^(d(
zcs0lNOF-tp<2(JRL6gzwkrQx)!ufM8t8Gu#b~ZMNXk%C(0jL4%<~&mA*a1e!!&hu(
zMii(HzUm;8pRpEVXm2moI}JL2`NnZc+s=S;-CNl99cJTJg;j{$v$NS_E8Pqf_M&XS
z+O)>{zYn?MwG*HyB_*YL<}|}vV2w^o;ShhNEL7=d*yjAKwH|yQMLoQ5z;`$BX+TCM
z!dHStV%JK0fQ8iL11;xy`X%cxnG&>lI^}=YqqM!L+6%r*dwgGB2Ypc0k9l?*Ny!k!
z=04}da|zU=qN~sT&H?IKEY(wB#dkplV>Jg(F70aZn(H@j_M%=gqgq5X1T~v^-}?T{r|J~4leROo>d2(gkX%@0F|o0PZhx(nN9cv2844d@$Y4LA?z|727t-2j^voeKNhx|OA1e*9C}GCr
z{FttR#KMUuTlmL5ALnW>k;)Q)a|3nOyLXP7@qh#3GWEfRUDzlo06?THe`^(MaR>O9lK2MU8~b*8?6EG`bAL
zFv!w0t1s@~hH88BjvanvYmK$%JcGj%zTnQmdUu32Vl<)UYirNryBo#@0q7|`^9vy9
zU1V3p#s$xb{BC?1P7qB~Ayzt1PfrqwNSq=73Vz#WW@gcWN;wiEgf#g{v3F8FwS|j^
zhX&-(=r25VFu}lE9cVSbnFynMl^(5+kbCSr8--0v`b?n~qCndlHoXiaO96J^=)p)9
z6Bnp%AF0J%;F1ERRgN~|=tk2aqw}8;XoE8;G-JzSG6@8noLxe>#zxlynkEWYnLRjf1&sk4HfAhk=2&aC8u!3;9sFX;#M_G~lfPK>y1rsc91)LHby20-we`o}T=Pz=t+)P(2~dt@4&jKa{b1QzjIS59)^YasYuSP1z7^x
zPS(^kxo!MOBO>|3XV30Jqkx{YF68m$xa#@0D&|O)bN5ML(hllqm}=!*=Um1f
z{E7x@NFYgCg}eY8sA^OT{pDyyJJwRz_kUUdX$J>UqTzt$#5Sm;sKl7aQ5Dnei<4@;
zc8i>>V6-jAW
zQCDWt`%sa^gCq~BU%-?Q)e|ttBp|@}cUrV@NA^?J_~>W~Fr=`eD&6EhTT1y-IS~BQ
zl=ztb1kJj2(#dKw&nCs64f5l_3J}?h9gi(@oO(8Y=U3!;=-NI^tdk-9M&qONyU5aR
z549xQ{16N1B?x{69;Fu=Y3AFvLhU9Uw)6d~Cz8Y393k=&Pf{O_Jb;#Bj1&XL$>B6(hDk^&G1`(3&*#7hnr?g9?V9+#iuD&%$%QV5s1kOP2pewo8k7>E_G9fHnX!$7Z(JAbu-fsA+=~z;_q4InQWGf)>F33Mn9oN~
zS<$Y9JyvKv2Se1+8@3kN4}AZM(Mb3?b`yltWa}*d3NDO}iHYf4T2D{UUcWZMxJW)_yeax`m07DY}dD9|8P=f0^-LqkInTmoBJj5;0Cey=WIdz;r6vNO-h
zw*u!-!$>YoonJ&vK4NXrnegJpT68E3w&X?-X$w%b5-2Jc*xKzsq7XDP8uD29d}(Zm
zYbv0WXNG)fpWMsWW)z57Heo{Wlb3r+V
zR~H@vUklv}EA5bTd1*YJhe(JN%k$xT4PPDetEI27{%#H`zxH%-5vIwa)yQpm3APP$^zV`xF9WhUfmzV+k-%9_cD$wu-!4s
zy*AqsG#*v=t>3W0Q*rN(M<;eWJ`D-E2N7je9}cC_N4m05X?%NYh+uaTylk5-Y9|u$
zpojWnNWB0Ly)%PXJR4(u&-~fc~yS-du&6}9UmW(i5tCR
z-Eg~PS{@0cyp~qP_0WTWL2&?)%0fNgY5L(d)6oOalc9Ddbu)w9W~&@F2tlAnVQ+y2
zgJphS-{Q{a=Mv^GtQXn6yTq2S&njnFGgL87`}dD=yagQf2Ouf$)VmCV8SM_J-D#_)
zQT@P{#OvWhhD)vtNFe>n*8ovPQrc4IH75=hne^ksqA{TIv2=HLH*s!!1JhFWYNEpi
zJ`zyKbz%QDNaG-!`7xh@GpohA@|e1FY?S}%$`)Y-;4u|ZQMBxj)P*IWI1B=YOHSCEy)QXlTHkh`&ui+5=(FLZTXg$oZmBCB_~E>SB$
zc?5ak@n#Jaszu~Fq2b(wl|5$vu+&6c38ng~p!831G8cW6;@pYt-oSx1}%h#w=A3)912
zX|5n8jC2~>cPUx|@&_Haxjn=gqRJMJio|bS=#5bfrHp5Bu1C|=>o(hPQ`BUhUS5{f
zhqAgLKrhEp^#CuRsI!v;K?)26qTMXqKGFd4Aq&lM&5M5XhBPi$etT!^Olx<{disni
z_*-~AlJc4uycQQ1Q>46{HbgQ3IY+_ryfIM_y@R~YOMn+WJO02&TJ$z+>gebYqyJ*p
znT{5{5MEzW`5n}!)!cDCALfax84`+xl+bOESAi=oLSFX9`K?Sp&o-anx|G7M`W
z{Mk(WxscamgJ=rQo;h=7GOKWj4o#`-XBiUG(l#S^kV8^bX@`uFFtEf&7`mJf+gyY~
z6p6r>h=6hWCUhN_GJ+Qr7k1~)Dub;5=xwI_}>kJ4`DvzBIE-=aU?
zjB@>Hc~%87MTqW*r&!x#V^s6l^z43yhqZDU4;RetCMXDBOKDx*CZK0!2#`eJh`hK9
zi9hHiFJTX95`2W(SF01RkKGnTR=RE5wnvnca7np_lfsPZJ<;Z&4BkVv2m~4>2uk#P
z>Pyp3$B`854Y4X4Br;*7I+&31mA#sXS&^6n+cD|LZR)j?NPy;{z;!_)E(jV3(k$$U
zuCd&R4t9i7=mCino7cHb(W$vQhhLs+HGcTLva<5%Re{H_)wF<3PC&o?;_T#X-O8eh
z#IFxr$EkzEBhk5q?8`JD39zT=1_NrFJNiOYQ65|dQ|C{-!QBNaCN#?8`BlhQ=%Fx%}j38Seq&5rQTBQ>Yirh0y=@$|%JVVa}>gGK(f5GVk
zvh~j|Pnp}JJR`gHd@|5YG?}tP%JaxHoQU0#jrE{{%+DNEPHl;ejxOpQu>xEQHcrykTp!o$w~0N;=`
z+=N;g`7@wvoR7DX_Lg1Ux|R|$HylVL7b;xCaVPe)nY;w1DUrRiciOm7UTmBg_^ZD@JQUb4Ab%fdS^tn{OeCIfh5%
z!qgjLuoD9OYPcP6F95EqE;l2bA=a@k90;xseE5(v$G`TAk!|748WE%+toH-%-J8rc
zFjiFjl%-3(k_9sY;$yW+7?5)v`tK(`J(HnnhB!>V3^VHGZSz`^BosNi5w6@IWxyHJFn;#heMK*Y8k
zP~!x70jsc5#3$}fmtCa5$YohoEO^0xWE-S}s5H%j4=`@PXaiDDPi05I3=~R)@4cT|
z;9iHmc$
z302jH<_JW607}zNVF;G^ep$r8wvZw08ja-U-e^yr?^EU2kVzu+5|(j3xyU?76$=V=
zMkC0xJwqdzJZofJ1T=!(ZmQ?(5;1GW_NBpDF+8nw4-giSD7IypE1--aGjTwdUc-t*
zV@-+2hGE~ByKn$`4u}N3XHQK;(3!JX>AvW5$$ayA&n~A5XI5G}I9iq>D-A%q90xEN
z96?9bUaQ|i?p}4loUBY)k*%wUay=jtC~j2+1`;mpKLY0rg8;9d
z7AP_o2tilHL6)xVYbmk7M$SjSFPv*eTPCt}-kf$E0krRLj$$78Us0tN%t
zN}o_yS5Fo66F<+(h@(gd=>PGb$HvDG+L@2#-J+g7#IzCNhuCJ4^BpRhUXSg63o_FZ
zR}oTZ6a67(4xOCe`NcrUq3agSL*(Q5{SNt&sQuCSmxfMAfR$a_3uo6MI5x*S7Ybsl
z;f#9QqDS)6H;@#iW{LktA`U(YGUGo^`KUZe;|wvQBbm(msn2H+3(X2?bXNJjf{m*z
zn)EK;-N0LpGZh~F521|oI^dS7Gy_1$9!qzKNYUI`0f)z7VTT*gU^X;#ABi3`J>eSt
zNk5~KGwnhs{jUdL6OPvNt(S@NoUCo{6$tsH7xw&1i=@52a2UD#_rE?KfV}IslY4FN
zHn~7A$`#$Lwn>OK2?3ncVtY8eMHw>TZi}g5&F^TYnT2(~FZfP`J%{7ba27>vYw>5~
zGPK5BVED=aLiVSzd+~f9!Em(=K&|qbPK}$u^%AkO7-czM$eoWnZ(9BU!W0XV5F^Cc
za0=RVME0*Pi%#LiV17g_Ux0&<=c}dj?weR?3_Z22ZgeALvS{2QaT~Do@u$vPqeq5m
z+n1@Y$fum)G$`N9*HRovd3XE6DB~rkgG~(~bE+PX-u-WEV)=
zjvx#mSt6h{Qq!qf*MiINKwA$D^53b&OGv;-n-Y*q(oIGVN~8&J5ZfAsDK$|uNoRTA
zps`6-ULFCupa|#w*Wsd@_K0(&Lj%$CHkw(das@Wa7C`r_UGxeiUf?gx(?Q+LZ
zf&A~88p#zTFU9~ClHtrwHL5IJ$c6#QE-c6K_rK{$=8vFr0@AL0$<<26epLV<#0%Yo
z#X$Y@Vb)h>D0*=A5`dqV(U-6Kht;t!M(?gqTw;`arWhwVT6dn6S%q=K?aIY@98&rj
zt;5#+;l-z0ynTF}!wnA;nn*7yB}%a9@RQRZl<<$s0pnc+zy(qRbkQnLb8paU@B|ET
zm%s-w+FwsgD{EoFkLagqe%R$#6_1FkMqVDF@fLPVrx*c1V`3l0q%
zff^R~^pZtpb6(e@^9=YeSf-IxiDDavvE+}`pIbN6ZO7lEmp9vKddRlJ91Y^|qr8jE
zTo-kU)>8y2+>ImcqS~cPv7p_PT<^tv9rp}n^{>!Vy@+m^Bkxr0A!{bBUYB$V{E#|q
z-m+!)u~H32IS3D8aYP`m(>84c9{Tp}g3I{v)TZ*z}qo)G|2KUXU#0YLSb!GlA?)!q3_|l=W_RCA2hHY
z4jS!oDhedqq*+`KzA$7w33^Y-PXqixdu&?EbWl(bK`9_^VE4-ZXA9eQ&QlZ$M#nT6
zp;|`OIQnP$3id82BBV=%iAIfVmKEP*L@*Z66Ow&@y;DC(a$e*Bgm-xJhMyb`%Mi^_
zZ%2#I*uuM36GTpVJiCC)?MPIKETodc9q}9+f&a$G$J$YYh&3>W7`P+_E3YHy|ETH%
zFo9QzTwyAaS>MdetZ>09AG~Tn3p&&Ltl%C?{_~@ZDcpmqwl+aDrgD#~GNJ|86Q?Z-
z?*Mjx4-XHwX-D2|jEtw~nSn%KLtXi(*tJVTbpUCgi4Ja@6=WD`Dovx1T~1F(uBSE(ndt>@CA`!Sa(<
z8v+%?%--m(pZSGIXlS;$J`f3
z+V4APsZ+?E!(4)-8$Op9I-|&kj#JnY3lnK@!Sp!FmMuik_}6+?nx!1c;sh0&`JQ_(72Lh9#Q%3
zM2_O#-$VWw;(}3DM7oEZ5Q3dNQ?4LP`W{z@Q#IOxk)Q7dbqV{?$0ltEDzL?&0iaiY
zD69RmUd}%qyQg11a`|az-)5TC4VtHP+28Epgw>nC
z0G~dU5rmjc!r_g|(wJhx1zmU=t>3h1hS{TlV2W;YH;5rT`c?NqI*xJ%q!rdOIkE`0
zLwefmb*Rq+=S&@x1pML!^lJ?sjP17LcA{(yYp>O>u>yb#_@Br#050!t<>TU_LO~=3
zPgG0^{Ojep!Ec2C5Hym%VvH(AAW5M|>9mzN;9F1-RLG2|+h>ZK+m0neONe6vjj^HZ
zD@^HaqoOeN{f=hZUGBrWuTXu%5m{cK=26x45|r2$sD+8&2B5E$@%Jd(@{{)kSMRBV
zSh9#T+JmxZFV_N&f&83+$^kQv9uwM*XeMMnfH`8PX+#?k1P+xf^EeNv_%Ou_p#FQJ|lUy-v_#bd)MWndjIW(0$lS&)iql
z>}ID+cNe8z*bgf09#$Js+rTLAj7KM;3sM|Z=9o@Ps=VJ3U~1uFdlh1)N5|&x-F;B*Xoef`?x#1gY2$d>$Ceqm@yF+7Rn001?p@YYcNm4Sbp9A8-;2Ug7TxPU;C0Jx#5
zLJy-wTZLH`7tWl*+492^aN&X35{?%x#*4c(;&odo+PNn|&KP>=7VGO6I@9Xrxb{(WlHx~@4
z;tm=8G`F<5U!v@wcSP5;TmH!K#h;&!&4hM+}Rn~H{>IHer188}<x;XVe7FlU)GgZj8hV
z#e5gaH)y5)?!Mwm99w}Jbo@N%`3J`f*sL|*9eU|ds1fBc;O*!3-!;RI~9hs7ObI*~e(SzM+}a&YB@2rKGo{|g40^}D{
z&m+C=F7be^5-Z%pOAHyOq7GHdvbgG{-=SJukME
z(g*cj5G*TTD2Orw%qjc>p;pG-Py|%M_jVgN2wYr@AuC_7pWD*>J62JcpmIt{MIrNo
zPdl|2C5GGJqbk)6cV+H22FDqqQ9l$0DDUz#;VO;(MTK{Ca99VT1If5*80E5qL@g3#
z!kl5YUgJuKeugE0Y+}0pZbz3-Two2(Um`ok4a0g2E;tHJKbsL8EXucCngBTTuI)11
z4vEhwks}X(I}=C_rmCh+5w}3KDw;
zsOsFos$mGOo)GKwWgZNa1@Vcz`kSUss&+o|@>1P2Hruc*m=pv(&QSy)mMBmSVHvTw
zc{0}o9$JJGnJ?tgABU1c6(gOY=><}=dfxI_ZR&}9QR-07QR12pbYU+%YNcnP{{g&398NKR++0w_9OD33!h}sf`@PyDwrNZGr!9x|
zAlrg^$u`BodA1RQkuI+LbQn_+Pm}`E)9!>
z%<+aU0#22k#Caix7lMS%tAl8Ozuv*u4DH;8CkYO2Fo6#$fHd{{upc_7rdEN*@hggg
z+hy)%j&v4Ap-DIM%2$58egv7Fe>A=^Wwd^(e|{2%`(}c7UmLQLp%vKjHER~@AF~f&
zo!%fD>f*(ncFyFk`Z?G|&Re}WlJP$Jaa
z2-dRG=$~gtrH*g!g9uY4th%h%5~xiXs6q`FKneqm@tg2W#@^nx!@mA_tUtUIvYagX
zLs86gW@+l7FCAIn-ii8lG;-$o*;h5LA$XZ_hNHFI2L3U;*hQ}1E_g*a0TtdpIEjvV
z+j$fJ-d!;6B*S4b<=|~=;MzApt4PK(KQrEW@OEenFN_YC#GVbZScp7bl{SX0nVd#
zLC}FECKBs)c;%sGj|^XubjpXHqiI_v@i%exow3*Xv2~>r6KG%nf)J^I4KmP@8YOx3
zd;f2I1RMcY2$`ga)eTMJH6%$0F^IeH$tACw7$IVA6GX?66}wfr`Ba4*04%^Y3|LR4KPx^WyY+_uWI9j-Xq
zqIuHLaL{mb7snCZwcE8Fx;F=?OR7@-f*FD!>INaDUYJ-Mi&OpLGt`pG0dI0a{O`9V
z%R1NHdp=7iYv%mA8(Z`G9J%=Yxy+12KNt
zBk9%PSETar%ySw6Kk5qpcwg;=XTd??b-K)iu-
zCKnbD+|a=O*yTmQLKDFn9!VHQ{=W6Xci3jY2z9V6>oD*YxP#)AdB*S(+eu0)>H#>y
z|HM!|;!Xlx2$!H>MmcY(Y+w-*Jre4iX2xo8iiK`_EpEf@qWjnwrZWJUU+5IN&EG_v
ze}R00*Oz#q6J;SR-JK>24TOB*a*LGCsjCo}8$9OF5QQ_I{K{P??+kEF_fCr9MZ@P%
zH;ow~A8k#84T=6Ei`VqO*n{|;Gz6QhvdC8Wp?J{g?LaaAH^@0$J?&w206Q=e1
z!JX3XE~2PK5HiR*1xU-a9HEW*nAPmAbiux-8Oc=@^7EaJ5_OxEu!}MfmRocgj{&m+{6mkWRQ`q
z`OYFB?~JW;5KG7aw7Z+Rva#Ht1I6G5`Wjs$zXpRB;6*iUn=TTCZjDhYNz-K3Pr5c5
zu31Dbhn@5iyqa%t7
zkq1x)vO$PJ<4K|?d8%GWDax>3oBhTvZ;v=*0?KaMA#|ScHd4Bs*4-yDqkyomViBX%
zvzM^#AP0gUr19pv(+(1=<96_52!#!y@|N{$HENntcsC%VAtbrYH%3{3wj;?X3ei?G
zad=Ppc*dN(L)(qfVlnt2Q7i&Zy8{<;HH9e%c95VTZ|W;tSt!iGs~5Y#!O2FS#d4xW
z$o~}g=b!z!e)3Xix?pHQcK=z%+d$W0h^V1-$mUg<>z}iUi9@y~-##~-aD{Wv92AWo
zU>)``YGv^zaX-c*KngHwc2boQu191f4y-xl9v
zf014X+={ki-!_s$Po44+n^G@C*mVS#gbBjlGS7vnKH;iHYb9ZnJ6an)FyLtQ8hsli
z@ByXhh5DEZs74v`&K>HR>Ia=ZR(Jy|N6XDF+$`kTQpjVIAE;kqT!(ZScE7|}O{BwS
zD`qmIcofcRX)b^-j5u0%UZ$r%LOxJBW^KTlJZ>QhO#s-YTMO@Tx~^4beMmn4GzI5%oaeDR1?I%{_h6jY5dDq*OpWM)@V&7NLGA
z=IIGz$5-3rz*3PR?CneUMv)t^(JS}~1SMC8TCm~QDwYvu}SATSK#`@MB*fi
zEI4eP8OC+Z{CzXx!C`MvM@)-Aj7Dg%YupVi>j7X+j$l)I6k$l|v#y*v*C<2|TYhE}
zTUoT!{p69F`wNe*UjR+L}RsoNr8i=bX
z(gGGy3r?IrHRmL4ZSwenlRA{2Jy@iNV>SfLVeU8m%0HX+UxpX}A(sP9SVSLt9jZz2
zX6H8*@bK^mntbIaGz^AD)p<}-VFkke6hISuKz!4Qe3UISU!gR2kcbo(zx&{a#4$A-
zTtK$T#|mb9HbQxL9Q=j?oFX&y8V7AaRI-TK@S+vaC@m6ElppB^IaOAx^yOKi28|u(
zz!)J2v1-UZ#%&CA7D|Dnf0gK4qi<~Oek`I^O)3nY!?;{1O30M1q3IxOR^&xa{Ot&Y
z3ELoWuL2s6xJ9g+;CcPE_tRDWE~}hxuT^4rKVCcENhVq0ldGj>j-mwnO%#x%%a-i_
zcIX&2G0zIu`#QA2wpjtD8mt{UH_+bNX7(D*Y5J|-^R05w1*sH;2dUdG2aVkebS
zXCmW)eg!2Pu!$)TAdcWrZh!jpi76rrjNfP+H@vGb+bXkduq_ly0o*#0^Z5_Xa;kti
zQLZ9M3R~A2)9^|=DDDtWBfw?xO$~V%f&sWwxY3_mY&!^%2mALZ-MH~md*Nr^45R~z
zozBPE0}9-f8u4W~&NAB?BrLj$VwEd5)B7N2DaQDn48|?U-?69>=a4^6u}UiJpA-k~
z(m6Ep(EGvS10vYTUwr!QyLd
z#Hv1hGRZn0k0TVI3-W_$S3`bgi@XjSRJ^VB$RLp#A|hqw@?oYmgsLduOwCdeuo1~U
zi=!ncxGnQfOQi1Ax5I2>4pqK+1EG(kzTa6M1vhqidHK8+PoR``3KKk7)!^P^QxVM}
zHJn^nA~V4X5AU+nh7{}gw*EkyUw^HxdCR!-jB
z-K*@ak>BHbNw>nIanNM*!(;4A{P%JxaZ{M*oLIAcyfNP)nxW?lvKO$QnM1OXoyYhV`SN_wz
z_?X_%*{!Q*u8d7OzN~nO5dL6`qg=r{#2-*lx}J8x
z364LnPD?xVd96#!^Vq+(avgy0u2~jB;~$t8%0k3{WoO5Afsj*5O66Di&w?QZwLaOi
zBcSpajI3d>3%F$A&FC@KdtHI6Cg|+e$|nC*Q>zuZH$%K~{Kknk6JacTsC?s4(=wj`
zT!2~`CSha-w2D7HH4thUFf5oP!vp_wpq2!O!X=qhq^yu2q=870_NGBi`M{b+ZJJ;rb}CWC&__5*#@iSbj2B~G`>z$nxn>t{n6gu|FbK@_Zj
zly04%NNw>0!V0u%{;`8n<5Wym^2n0yM}5%UYy&ffl?JM0l^*+;dAHd3sctrss2HpF5j96LJY=5%@CGb_$c+IMs3Qm=4Lar6F%%S3O2=$5Bn}l!rCHW6<+AM9Im~v1`Vv3q
zq!A4;TEDzG7hn;Tbi~mT$ODo48M4Ae8`}oCT{?Qr07pVqEw9Rmhl8_*Ab96y{;9V9S&Fhe(FT>VPQ!mc
zWsX2;hX!xc2f}FRKI~?k(W+4suxTK+Ytx~0V+}t3m1*Z7AfbJ5^AwYse&|@^&94
zJH#$rxuS5T?Tig0rsgq8FJhfwI3=t?g~P&JBcG{0e09WP;O4!+mHIE6EevQp;tYWY
z>83sVu7+_Frf=Uxc@LN%$3&e)dY2{seAPpD$nph|zyEugcY9@28DE}%&;@AUDRSYD
z&D)2sL7?lVz0JEH!#f(642!;o)HqQn2$%l`>AG6XmH-yag&
z_1DBdsmuR;eZ<3muPvFo%BR*W{_8`sJlwdPGL~w{)gL8=|M%)ekv@OBXr0)`>CI3X
zMQxYiDe?l7+I+1NcX0prLdqs@gf3^*#OKnIl&|IMm2JKL_xH%SblN_kC}j0H#rBq7wwZ3jGrFq+Y|fm^
zZR4A2ECa)g^i*uQ#6Nl}wf*4OTh?bJ@Op?>-Dfr5kiBUrR8h_M$q@wqk9HRSG^eF!s?FJ3a(rbc~8C9*CM1mLhJgRElwDP-ig`AeDno>
z=6|1}C|AUHN;isitR?%Mt38#ZbF=SMU8`tgD1XH}%c?ta@Gluz)BUfLq7PR-=Nj8q
zWMZFsYF0X>m3P}|{1cTrn+!Bk%fBv*Dft}aDoc0~F-PepbXI7coae%S
z_fZe6?L5uw^L;!jyZPB$EY$Bm^FMuFv*Xp(bk=)&)(j+8bdAyP{gG?gru598y2sN0
zTLp6zqr<*eugo=~;%-qN|2(Sr$u?*-?b;F6vq$~s-+UC=HtnL(CFfs$B~!tab&Ety
zaF}HdpTJJ000*5@t=i+P32Qcyc9-kj8s&);*JB0+M0pEf8XGjNz0;?QymDp*8lz9
z@eo&Kk#OPj8MezeudFlP)ZDf7$d8AdPa
za7xabev8r$sgmG-xjmSER7TbGuH*Q)e#5tOpBqQoh2q3p0;*zO2!Ar(QN3^4XRzBy
z<7VLD_Ako!M*kHlMdfcQd*~R>r^fJ=SSR_-RtJ|qrYT`)dh^v^!hMdyjHN9iEnoA8
z&ELCIcola%JpHJ=sAp%BM1hOcjidg|$$P_vx$J_T8@|XNT(SC7*~2L>paqHo>QTTVGAoW}c4JbbL7UjX~b;ui%=y(=&ygS%1;zZ@+y_}E6Z`C{ywxXtdo@|l&Vl|v&IKT^BU9ijCtc@??O
z##)0n>6OC83r3|!jQl(QFuPoNd#O<Sse-06m!mSejrv>;=SgRcP^w$KHL076-
zw9W&+h1%*kmD~u%q|JG)ryf))KWe?p>cg0HZ-Y74%50+d`!V{8AK4ClAB$biGhH7{
zVO`Eh_MM;SeQkF@baSS;S^ax6!thN$#-O!P$c;Y_0yP
z$0NReLIBx+w0PyfOvd>i@Q{8k8T0FV^M08$(cn$hKYr~R{4s4|WyT>A
zwBX=id}dFz{Q_so-+@~HclfS`hsq!K*H2XTD&01A7v=R|887+n@JJDlKUArl(r8D_
z1(Awp&xU`_H(Y+Ub)VIJYMEPez|iGhR9x
zL%G+hq;j2hqNi$#WZr?SfN^O<&N3eHe1isag~>45FGnjJjI~&Fg4fPnzjUQbe?RR&3oR6Z_9@Gj7@
zn@(Xp_genW&uoMHiC=^hy_@1}S!p+mRd_!y
z0s2k$r|20KUf^T-d|Nv~c*Fi3Z^Hbi>Q0qhGdx|RCn&sbA}{ClqP~Xtog2r#YBim>
z%;{Nk{ptz*Ey5YMRAwA5JJ+j7#OMm{pnMZX7j5*qU8}nE%*@2po~4i@{5vy>i%J_r
zeb=aHehHQww6nX|d|r#ATwlOKt>ro`uS;5IU2Y78(MVgv@_)}D{HaWJ=rLmJ`bwdg
zG|}#7cZy#{-?^y0oap`bx?q<7cR4Ell>+Zc92k|M|NgrFHJA
zw(?a>S#9<+j^-7Tzrf_CRm<^|BRZ3BgFHgcNq=M6FL4)6Xejn&xV~GQtJY-?|K|5s
zj@ek`*PsCVCX49Iz~`5%?$_DIRve`mD&4=aIrvwl$|i>OE>QG<8h9<8)RK;bLaOj
zgI9@86-#mBLA4H=kspPl5}jKHl`mera1jOZRRPP9)MUEue^3>a
zR#WR>I$v;X>b(f7zm*bW&-#7sGxzKgcUZnqq`v*#&@T6-I`5=U>y^f@kA0+=cuMu+
z?L#B3`)&4G6Q~}ZIM3^^`h?bJ9pmle7wKkC9&yS|wmFlgD0)0Pe`HTvc|UoSO9_qW>b2^kDCs|>mx$Hy33#!+D;@Nn?$!|TE^yh?j05a$+L
zcbzt34f9;Eir5nWC@$LI=JH8@rY6xOXMsy`+kOw06iz@jCZInud%olKcz#Wo$Z!0+
zAV&J7EXoASq8i
z-6+WSA28Ao0j|^=YMgQnZihTK@*rsGyS-hz3-sajuA*DStSsF1Pb<%jww-C$tF~xk
zJ`5oeYo%5e1;tKTiDAMl{LdZ{o1YtShirG~^+y@WHZzJ=t4FY+5in~Ph5XP~UQ>nY
z76tI?O+d~`=KyfqVU$>G&w&aM>Ld;m^uSwNpB}rcu$w*LH}GL%9TI{*4ALnU@wQ7x
zh_w$6mR#f#VR=T_CR}hl2=C@e{Jj?h0i;=JtZ>B*6|rMtn5_)VJc4gVI#NTvAy_A2
zeJ(2>eCskMqcp}UY$B7U0E`1CA-z73@%cipa2tZysK+;bU?BmD+|dV$ycKAk=21?NZOzWFSF>i+zVd(ypq)FpvnXlPb0u-UC96a;jo|VcLpK
zyu1mqSKZk@QNLjh^PJS@dQ!mfBB2##|ZWVt7%|MiRv|bOIoLPubZCr>T!HuK3nogBqO75d%d}
zUejsMJrKwMfyUsv^**IMt_wa}{mQ{P(Gckygswa{!hm=5qHFUS`dX((+qP%5`PcP}
z?`s=-g~oMs?SBG_Hm&N^Q|4FM3qyH7ECMLo2=}M_!4Blk*OS_&2l{4F-6)
z5Cl&RHTgxsjsP}IC`8F>hK>M0vY9x2;R|bA1bR{Lp;OZvs-Dkz_U2G&-a65BL1fe$
zh$m?X^eeaeoTYW;N;Ue_E6}Z<)8l)90wdvxwhgj~Ab{@zhM!*qeSQielWYR=ph_}T
zH8eg#+gAIvHl}t2RMAh;a0VEMC;(10cJ16%7C4Bw%NXi8#iUnV_vudDipKAbzBUa7
ze5^qd2^UWS0^jUN2$(UMuN!#%@(Gmky2l5Gg9|#R_Qli!YVNS~;
zuohlmje`&bRnr~_)t?}8JnVZ*D90_EE?(-k5rf@ce6C^T3(Oq^WApjz*ALKqg=(cL
z!3{Kc_%SkuHpr{zbBr=tv!T+2j))NwTJfG?3k+w3#1XPd(p6L0J6J!1C4&3qv5~@%
z8^{)**%Z6hCaM-1hb|OiMZpY)3+$mplag3BP;eq@h2W!4q;QT7-g1auQR)3gyTk+?
zAEE5DECbU5VkFLeWf`OF@GPO7lK^)^A|!D#B4{K?28``8J&qeo2=j|El8C7KK-P&L5>rQLJa9UWIT&a^eh6-<5zc?~G_!JmE?Xf{C*hLt?FHK@mw{AbdVJl(T_@3QIc6Bu
ztaP_AWEG%dI|8+Zl2Q}Z3}hpVI49CqPzjS1AuI5<*I-XI?nSfJ
z92pD`)~ay6DK&e#`O1|~xeI2l&uSl)3|t57h&C|-ex7$TKmHxm)ZKF3L!Jvab?4th
zwRz#<@uAD{o&EjWFx;1)`9*sAFK26=OBbJzZb{|%wKKOxyptcyQ94hllzr6jP;#y(*FV9toxGCW)nMsw`4
z`1NEcWqmybo7*=FK%K+WL)Ad>b8QA?4l1-X#ngxv3i!JLy2J!8mF?&Jek>0f*qP>LXc-+
z=Gbk>0!lLvF!`xozWlcYJJ0dsTAMtR5))Ge*#m~#?8PEX3p6Wqk1V=LL90lnHKQ90
z;;N}H^!HqC4Z^&Np|52F>w@qFVp^_fKO6nl^=n}`PfTp5oe;@u#A*r-Fw^!-JMH7+
z+shts9t;UyC=9FvDjQ!jq{A?}Q3$u{R>)x>rmV$xDJ)@=%yS0q)JvOA?BU@F3JrCV
zHRJ{=To6Ece5V|wwtlW`tJ+c0Y+x9=EV68-@v6BttNAm-IxlH-GfdUdFO4Gb;roqz
zPW7~(UhLR1I%{@quq%m5gVu*z$qY!y(KZ@BFd*MOlz38vKd
zhKGj}l9Tsrxfjj50Xj{rCjCmJ*+Hcrp`lRl$BBVi{ZbeQ^k%vKz3R>2N-8+-5i`774$Lq5Sl;G}S^r?&VDADttP!
z0#B_?ZK(!_if50_19!uFvb*s@(K;8$;fJ3o(>(%~V|uvmd4fbq_Zv4;rS>z(wXsmk
zkA*t?w94z4w{0Jv0Xup{GYc9T!fZQ+K7DHU)mr=FMcm`pcgDePk>jlyG_eg|d$LtV
zVo%OIZ!q{0Fqet-0Ul?1;R)XGPfkO`Ef^4E#f^Lqb$Ds;a~-x#{{Lfu2IKqbg;GtX4*2p2X9%xUR@_grWEn8`jbJ>^0D*ixMH5_
z{|fF5q0;RE46l-sXO8=nN+aa~w~zb>sUOv#R!yOb6F6I2m!
zXlC1X1U}|{e+43U*agkC6fWOx8O9~wMkn~QHnTkc*RNmecOtI2Kp9WE>)~7dK>Z+m
zJ6YkLbOf`w_5Av-5Qz=D+w3*8nAXsVv=?zKPtXv;61oa9@J|JVD;d`go`?uZke_Y!
zfDu?q!MqXFt)H20O(JNKX}2h{4&yCQGUM=smEFr1FTBZthc3l13{+wuQ@=^~UP{hS
zRx@;s=x?g&ws-~)C_j`ccXU?fTQu!jZ&0|vxSouXg;Rw9ysVE?EGFqJktwOfpgbKz
zOVP+>id2!9&x%5>M+uUX4AtyGVphB=d_IPD^=v5HSm5~MSJ;Vc&|&apF!3)z`z<%f
zXjF(G8%OAm*Q=?i{X&T}0XYw$_K|uKzbMdt|B)~enKGoP$jr%sj!Fvx3Zz9nG*Yva
zS)Fd;P`5O;u-ucK9m%L8j$-JJZKjHWN}UBo6k#7nseee#c2T+g4(qIk*wk&||B?5n
zQ9bYN8$WEGN!UtMq@8&vGbIvInQcQdWe8D8l28aqN|~cXWS){VkfansG89Fl6wxS(
zhWmBe`}(c>$^GPh`2X*apQ8JLUL@W3Lh>t8DdKsU>P-XWLT@&K8uSUhkK8U^}%>FS@&D8lsWFiqi6dVN2tP1#~B?bvRF
zm<(7wfftUTGmM~?6Q7Oa-%g-d#TeibSL_|CU?yHjF?f)~GBlXLjL*pTJ_m;XU=kpS
zV}2h!`Xr`uXjRPDJ^bsvQ{hz@`7en*_RhV>1r(#jUnU!nzRU3uI6(g
z73I+I#t2~|%@Wx;3b$m9{dW8uJo&`0axnuNNT#IS<1Wj0G;7og<*l5xd5EqMB{4t6
z&b}C4dlDPZzu(`Hl%MN0stDyT09ukpDA##ZU%<<`4
z`funM_Q9bu^DtWSKRR=y0peZ3*BOf|0OnKqjDt|^9z1d+9y{assm^8XYtjx4cXN
zsdW>THe$(gEV4?o-PFItM5CHo|7!9u2F6~U&RoFgPoL{|9}u(fIq-GqEC=Rkb
z9;QL)R`y8@#7ClIrU+YjgD-#nP03?{8-n~c>D1cL#%wUJTU^{hiK7+lO7{4!MaaQn(w}OL$pSh1`ly^n4>|
zHJ5>Fh$ef>ug~WhEI`Ft^)AUdo)Lw#twYPIw&-G7Dl$G)MD?~VG7T8*FPVl(EGYL@
zO^9m@$K^52aqh+qZ)WnumsRZ0^sden%$i#=E!(<1}1|Js`>L(k1iF-$JQ91l=Qc
zCL&jUQ{><|p*xQXf8`RcObD)aTVEuC8b$EjKO=SZs1cQ;Sg2#SYJ`mbn?v~-^_o36
z5xfes$!t^e36MnUJpvK4U|rSr12}XVVW&y5eKT`;M|4Avy6-?n=Jq$jqbJDcU;9y2qWnhJ`q5z92QNPi$IryF@Uy}wn&t_GTJ117-rTVpw~j=
zL3zuuOp^ErTy#!f$#VH}ZD#Cg#GlMgty@50StGpcXQQ0QIJb&62b=W|MuOLWh!nO&H_|QXXDZ=k3PjaZh
zKJiDEJ@W3xD1yw3iZiE_ngXn$hz5#Vih5WsB!hy72@7B9Z<7j^>g6Z31bq-Evco8)>y4ry01
zK2c?lrZ!_TwiDxGG&I0elIO2GSM*^9K&13!1(~I6)kNgx{2E#wc~7XhV=;58@C%YX
zu?pB+aQ@#@HHj-ESwyl6<_UWrTF49D*JZ>E_0Sba-z)3{7(uI4k3%I*uiaYm^7{?70{(NamOY
zKVqaM9N<g_KBJa9b70x{2~Bp5|a-Lil9Hqvsg?Qr002E|{6SWcxU
zll?oCYlFECrYC;Xg>1}NGTnbwU7hKY0@Yc2jsBW8viD@e4rk(b=xHSnIj6kf;01TB
z&T}T4t{d|1*ri?$2QN&Y^tEwZhcl<%2ERBI*wsk=*VBRJzhevij-Eb#^LK5=f_tfX
z>UPil%5{@AeffE>xLB_pM!o5Mm^FWg0CQ1(!1QC4<#3>G{OZ%1q@*TOn{8HL{Pkt5qFDNW=DwsRM^
zy!9AV`1$#jl$CvXdBLIl(`28wx@`T%FdN6o_a8nye)0r2OYzEUqM+9I$LU2bHHYQW
z&|!FN&3yUtfP5&Xx-MVtbMoX#mOo?8h|!MBgRXtFgI`*bYm
zJEqaSd+@DW9~n3hr=YK2-|x0xd%alvXoydMt%R2N4AicD2u#87@A1xedbvuEI{
z;;xpFagv~m_0{+XTM+VM;lGn7k1ZxUKN>AuxbXeGttU9})921L!U=fgwusF?`|}4r
zQ3vAw=fkVST8x=Vy#Mwx5K+HwoRLE3p{<4u8^${GsbKa;jvUeO!R&s-hA$oHoK#a%
zQq1o-cowE!mr)U2UEOe(y3qtsR#_`^?ADoP-r2aHDdMc+;;Hubx55`9(k`J4WdH8M
z>Y5rE?#CSp`{G?3lqHK7kKy<8rmxO6A*SP>4fS-CD9F<7seIsLrduR9)A)f>wC~*6
zWaY}9b`gG93ES5E+Q4r&%#EIKMs^eAP%z{E(T+dEK8q$znqc>GjDf=gh{jp5K`~nS
zOzpS~Xkfocckz$S-Hp3GeOkdT41*Ob&aL$RQC4Pge_Qv^MA_iCx`pYW8{i&yv{P?lpR&MxBs?Ql4C19^26S78MoY
z(tVPcwRGjmx2yWI4qS`HN_?~TcQ>^kHEI-wb(8q2n2+E&WBcWGFXlF%993VT~gM
zEoRg=LPF$FlA}V1gIBIzb@%Y-&JO$T-Mb^c9>FzpaByI;(cbmWfF{iCKX~!N8>`F3
zD_0ufi%+}6ci72eTWoFp97X~*OLl6E*E;BP?ARmOWl>%p`|e%DxT(%me@?DSEcjZz
z`U&xT3YNgNwY97i`frAk5^qA#jCFZW{z99NpU*jFfa2l|DR=O$eKE)aC_yK(HqiS?}DfT>xxVZ*nVC9}=VpE6xd*!mlPoA1?Ajf`Y6jnm@ZXp@1#j)J)Y
zJ+Q85ptiPb$H8ley?LA~*Me2}l|Ld=y0Zii2TOJJfGOQuGI=_VFU@)7$XHh&Bizukh;ta$
zxqA()2jrF`-8)_av`i;B6I_S=h8o!v_$=w5eNo5s!(&$OJg#^(R)peZ^y!n9a~(cV
zB|KlgQ)|8me%ozRGbn#cIoTQ+;O!-*7^tl5`?sQ3wC7}uBn_@Om$;I!(K^b$+a
z36OaP{cHKKn}~?BgGDs`s?E{D>9omAlIHOohL0HG$|Y11cu((D
z9KjNfm?uy6$~X~m(!jugxG0a5DnbkdU%Y;8$mzzG4y$h4+UiYMrW(RC;S!Yd+brNG
ze?g|v`33Rs-uaRpJS<=E26BpurjTH07~8O){LwNUpsYV`v$nQuifhCQLFZqedoUYU
z^8NdoIlFIn{!p12j!}u(@R8na&>yCJd`x%f3VmctCvPi2=S${Bg)2V2CS;V&8FV
zReOHz3epBq*@6}b;e#tUq7ToxZ{NP*8wxwByHsmqzVL}x4f5ymdDgXw%|h3%S#y@>
zN~tq%|L_`oz=RH!f{I8Vk8S_OSu)l&FW90n`+h7@Uzi>r+?+E6e@;XXaY+DW
z5+E59^kN?_mKdDLY5)B5w^NL8uvi|hS+j-%x|qYQG3f`Bo_o8MvM|6Br%-~D{pW0)
z86N}m;C7WShhyYO9Z)J=J-vt1tj8LNIiW^GuY-@nN#TNK5s|y&3N>JWprOLg(Zg&h
ziD}xZ%WzyM+fz^(ve;v8{*eRI3_7td=&|&3SFh%QwOTTQfE^%}NIcPw0j0mh6@@Ut
z7C>q_Q(P&|pK!qPAB1N6`SU%7S-;2j`