Merge branch 'main' into vp-csp-auto2

.openpublishing.redirection.json

@@ -20295,6 +20295,101 @@
       "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": 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": 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": 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": 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": 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": 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": 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": 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
+    },
+    {
+      "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base.md",
+      "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso",
+      "redirect_document_id": true
+    },
+    {
+      "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-prereqs.md",
+      "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust",
+      "redirect_document_id": true
+    },
+    {
+      "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-cert-new-install.md",
+      "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-devreg.md",
+      "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings.md",
+      "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-ad.md",
+      "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-dir-sync.md",
+      "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-pki.md",
+      "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-validate-pki",
+      "redirect_document_id": true
+    },
+    {
+      "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-policy.md",
+      "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-provision",
+      "redirect_document_id": true
+    },
     {
       "source_path": "windows/configuration/provisioning-packages/provision-pcs-with-apps-and-certificates.md",
       "redirect_url": "/windows/configuration/provisioning-packages/provision-pcs-with-apps",

windows/client-management/mdm/policy-csp-admx-smartcard.md

@@ -4,7 +4,7 @@ description: Learn more about the ADMX_Smartcard Area in Policy CSP.
 author: vinaypamnani-msft
 manager: aaroncz
 ms.author: vinpa
-ms.date: 01/09/2023
+ms.date: 01/23/2023
 ms.localizationpriority: medium
 ms.prod: windows-client
 ms.technology: itpro-manage
@@ -44,12 +44,12 @@ ms.topic: reference
 <!-- Description-Source-ADMX -->
 This policy setting lets you allow certificates without an Extended Key Usage (EKU) set to be used for logon.
 
-In versions of Windows prior to Windows Vista, smart card certificates that are used for logon require an enhanced key usage (EKU) extension with a smart card logon object identifier. This policy setting can be used to modify that restriction.
+In versions of Windows prior to Windows Vista, smart card certificates that are used for logon require an extended key usage (EKU) extension with a smart card logon object identifier. This policy setting can be used to modify that restriction.
 
 - If you enable this policy setting, certificates with the following attributes can also be used to log on with a smart card:
-- Certificates with no EKU
+  - Certificates with no EKU
-- Certificates with an All Purpose EKU
+  - Certificates with an All Purpose EKU
-- Certificates with a Client Authentication EKU
+  - Certificates with a Client Authentication EKU
 
 - If you disable or do not configure this policy setting, only certificates that contain the smart card logon object identifier can be used to log on with a smart card.
 <!-- AllowCertificatesWithNoEKU-Description-End -->
@@ -410,7 +410,7 @@ This policy setting allows you to manage the clean up behavior of root certifica
 <!-- Description-Source-ADMX -->
 This policy setting allows you to manage the root certificate propagation that occurs when a smart card is inserted.
 
-- If you enable or do not configure this policy setting then root certificate propagation will occur when you insert your smart card
+- If you enable or do not configure this policy setting then root certificate propagation will occur when you insert your smart card.
 
 > [!NOTE]
 > For this policy setting to work the following policy setting must also be enabled Turn on certificate propagation from smart card.
@@ -603,7 +603,7 @@ This policy settings lets you configure if all your valid logon certificates are
 
 During the certificate renewal period, a user can have multiple valid logon certificates issued from the same certificate template. This can cause confusion as to which certificate to select for logon. The common case for this behavior is when a certificate is renewed and the old one has not yet expired. Two certificates are determined to be the same if they are issued from the same template with the same major version and they are for the same user (determined by their UPN).
 
-If there are two or more of the "same" certificate on a smart card and this policy is enabled then the certificate that is used for logon on Windows 2000, Windows XP, and Windows 2003 Server will be shown, otherwise the the certificate with the expiration time furthest in the future will be shown
+If there are two or more of the "same" certificate on a smart card and this policy is enabled then the certificate that is used for logon on Windows 2000, Windows XP, and Windows 2003 Server will be shown, otherwise the the certificate with the expiration time furthest in the future will be shown.
 
 > [!NOTE]
 > This setting will be applied after the following policy "Allow time invalid certificates"
@@ -730,7 +730,7 @@ During logon Windows will by default only read the default certificate from the
 <!-- Description-Source-ADMX -->
 This policy setting allows you to manage the displayed message when a smart card is blocked.
 
-- If you enable this policy setting, the specified message will be displayed to the user when the smart card is blocked
+- If you enable this policy setting, the specified message will be displayed to the user when the smart card is blocked.
 
 > [!NOTE]
 > The following policy setting must be enabled - Allow Integrated Unblock screen to be displayed at the time of logon.

windows/security/TOC.yml

@@ -310,7 +310,7 @@
       href: identity-protection/windows-credential-theft-mitigation-guide-abstract.md
     - name: Passwordless
       items:
-      - name: Windows Hello for Business
+      - name: Windows Hello for Business ⇒
         href: identity-protection/hello-for-business/index.yml
       - name: FIDO 2 security keys
         href: /azure/active-directory/authentication/howto-authentication-passwordless-security-key?context=/windows/security/context/context

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
 

windows/security/identity-protection/hello-for-business/hello-cert-trust-adfs.md

@@ -1,6 +1,6 @@
 ---
-title: Prepare and deploy Active Directory Federation Services in an on-premises certificate trust
+title: Prepare and deploy Active Directory Federation Services in an on-premises certificate trust model
-description: Learn how to configure Active Directory Federation Services to support the Windows Hello for Business certificate trust model.
+description: Learn how to configure Active Directory Federation Services to support the Windows Hello for Business on-premises certificate trust model.
 ms.date: 12/12/2022
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
@@ -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*.
 
@@ -179,11 +179,11 @@ Sign-in the AD FS server with *domain administrator* equivalent credentials.
 
 Open a **Windows PowerShell** prompt and type the following command:
 
-   ```PowerShell
+```PowerShell
-   Set-AdfsCertificateAuthority -EnrollmentAgent -EnrollmentAgentCertificateTemplate WHFBEnrollmentAgent -WindowsHelloCertificateTemplate WHFBAuthentication
+Set-AdfsCertificateAuthority -EnrollmentAgent -EnrollmentAgentCertificateTemplate WHFBEnrollmentAgent -WindowsHelloCertificateTemplate WHFBAuthentication
    ```
-   >[!NOTE]
+>[!NOTE]
-   > If you gave your Windows Hello for Business Enrollment Agent and Windows Hello for Business Authentication certificate templates different names, then replace *WHFBEnrollmentAgent* and *WHFBAuthentication* in the above command with the name of your certificate templates.
+> If you gave your Windows Hello for Business Enrollment Agent and Windows Hello for Business Authentication certificate templates different names, then replace *WHFBEnrollmentAgent* and *WHFBAuthentication* in the above command with the name of your certificate templates. It's important that you use the template name rather than the template display name.  You can view the template name on the **General** tab of the certificate template by using the **Certificate Template** management console (certtmpl.msc). Or, you can view the template name by using the `Get-CATemplate` PowerShell cmdlet on a CA.
 
 ### Enrollment agent certificate enrollment
 

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

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.
 

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:
 
@@ -20,9 +20,9 @@ Windows Hello for Business requires users perform multi-factor authentication (M
 > [!IMPORTANT]
 > As of July 1, 2019, Microsoft will no longer offer MFA Server for new deployments. New customers who would like to require multi-factor authentication from their users should use cloud-based Azure AD Multi-Factor Authentication. Existing customers who have activated MFA Server prior to July 1 will be able to download the latest version, future updates and generate activation credentials as usual.
 
-For information on available third-party authentication methods see [Configure Additional Authentication Methods for AD FS](/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs). For creating a custom authentication method see [Build a Custom Authentication Method for AD FS in Windows Server](/windows-server/identity/ad-fs/development/ad-fs-build-custom-auth-method)
+For information about third-party authentication methods, see [Configure Additional Authentication Methods for AD FS](/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs). To create a custom authentication method, see [Build a Custom Authentication Method for AD FS in Windows Server](/windows-server/identity/ad-fs/development/ad-fs-build-custom-auth-method).
 
-Follow the integration and deployment guide for the authentication provider you select to integrate and deploy it to AD FS. Make sure that the authentication provider is selected as a multi-factor authentication option in the AD FS authentication policy. For information on configuring AD FS authentication policies see [Configure Authentication Policies](/windows-server/identity/ad-fs/operations/configure-authentication-policies).
+Follow the integration and deployment guide for the authentication provider you plan to integrate to AD FS. Make sure that the authentication provider is selected as a multi-factor authentication option in the AD FS authentication policy. For information on configuring AD FS authentication policies, see [Configure Authentication Policies](/windows-server/identity/ad-fs/operations/configure-authentication-policies).
 
 > [!div class="nextstepaction"]
 > [Next: configure Windows Hello for Business Policy settings](hello-cert-trust-policy-settings.md)

windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-pki.md

@@ -9,261 +9,27 @@ 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.
 
-## Deploy an enterprise certification authority
+[!INCLUDE [lab-based-pki-deploy](includes/lab-based-pki-deploy.md)]
 
-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.
+## Configure the enterprise PKI
 
-### Lab-based PKI
+[!INCLUDE [dc-certificate-template](includes/dc-certificate-template.md)]
 
-The following instructions may be used to deploy simple public key infrastructure that is suitable **for a lab environment**.
+[!INCLUDE [dc-certificate-template-supersede](includes/dc-certificate-supersede.md)]
 
-Sign in using *Enterprise Administrator* equivalent credentials on a Windows Server where you want the certification authority (CA) installed.
+[!INCLUDE [web-server-certificate-template](includes/web-server-certificate-template.md)]
 
->[!NOTE]
+[!INCLUDE [enrollment-agent-certificate-template](includes/enrollment-agent-certificate-template.md)]
->Never install a certification authority on a domain controller in a production environment.
 
-1. Open an elevated Windows PowerShell prompt
+[!INCLUDE [auth-certificate-template](includes/auth-certificate-template.md)]
-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
+[!INCLUDE [unpublish-superseded-templates](includes/unpublish-superseded-templates.md)]
 
-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.
+### Publish certificate templates to the CA
-
-Expand the following sections to configure the PKI for Windows Hello for Business.
-
-<br>
-<details>
-<summary><b>Configure domain controller certificates</b></summary>
-
-Clients must trust the domain controllers, and 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
-
-</details>
-
-<br>
-<details>
-<summary><b>Supersede existing domain controller certificates</b></summary>
-
-The domain controllers may have an existing domain controller certificate. The Active Directory Certificate Services provides a default certificate template for domain controllers called *domain controller certificate*. Later releases of Windows Server provided a new certificate template called *domain controller authentication certificate*. These certificate templates were provided prior to the update of the Kerberos specification that stated Key Distribution Centers (KDCs) performing certificate authentication needed to include the *KDC Authentication* extension. 
-
-The *Kerberos Authentication* certificate template is the most current certificate template designated for domain controllers, and should be the one you deploy to all your domain controllers.\
-The *autoenrollment* feature allows you to replace the domain controller certificates. Use the following configuration to replace older domain controller certificates with new ones, using the *Kerberos Authentication* certificate template.
-
-Sign in to a CA or management workstations with *Enterprise Administrator* equivalent credentials.
-
-1. Open the **Certification Authority** management console
-1. Right-click **Certificate Templates > Manage**
-1. In the **Certificate Template Console**, right-click the *Domain Controller Authentication (Kerberos)* (or the name of the certificate template you created in the previous section) template in the details pane and select **Properties**
-1. Select the **Superseded Templates** tab. Select **Add**
-1. From the **Add Superseded Template** dialog, select the *Domain Controller* certificate template and select **OK > Add**
-1. From the **Add Superseded Template** dialog, select the *Domain Controller Authentication* certificate template and select **OK**
-1. From the **Add Superseded Template** dialog, select the *Kerberos Authentication* certificate template and select **OK**
-1. Add any other enterprise certificate templates that were previously configured for domain controllers to the **Superseded Templates** tab
-1. Select **OK** and close the **Certificate Templates** console
-
-The certificate template is configured to supersede all the certificate templates provided in the certificate templates superseded templates list. However, the certificate template and the superseding of certificate templates isn't active until the certificate template is published to one or more certificate authorities.
-
-</details>
-
-<br>
-<details>
-<summary><b>Configure an internal web server certificate template</b></summary>
-
-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
-
-</details>
-
-<br>
-<details>
-<summary><b>Configure a certificate registration authority template</b></summary>
-
-A certificate registration authority (CRA) is a trusted authority that validates certificate request. Once it validates the request, it presents the request to the certification authority (CA) for issuance. The CA issues the certificate, returns it to the CRA, which returns the certificate to the requesting user. The Windows Hello for Business on-premises certificate-based deployment uses AD FS as the CRA.
-
-The CRA enrolls for an *enrollment agent* certificate. Once the CRA verifies the certificate request, it signs the certificate request using its enrollment agent certificate and sends it to the CA. The Windows Hello for Business Authentication certificate template is configured to only issue certificates to certificate requests that have been signed with an enrollment agent certificate. The CA only issues a certificate for that template if the registration authority signs the certificate request.
-
-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 on the **Exchange Enrollment Agent (Offline request)** template 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 *WHFB Enrollment Agent* in **Template display name**
-   - Adjust the validity and renewal period to meet your enterprise's needs
-1. On the **Subject** tab, select the **Supply in the request** button if it is not already selected
-
-   > [!NOTE]
-   > Group Managed Service Accounts (GMSA) do not support the *Build from this Active Directory information* option and will result in the AD FS server failing to enroll the enrollment agent certificate. You must configure the certificate template with *Supply in the request* to ensure that AD FS servers can perform the automatic enrollment and renewal of the enrollment agent certificate.
-
-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. On the **Security** tab, select **Add**
-1. Select **Object Types** and select the **Service Accounts** check box. Select **OK**
-1. Type *adfssvc* in the **Enter the object names to select** text box and select **OK**
-1. Select the **adfssvc** from the **Group or users names** list. In the **Permissions for adfssvc** section:
-   - In the **Permissions for adfssvc** section, select the **Allow** check box for the **Enroll** permission
-   - Excluding the **adfssvc** user, clear the **Allow** check box for the **Enroll** and **Autoenroll** permissions for all other items in the **Group or users names** list if the check boxes are not already cleared
-   - Select **OK**
-1. Close the console
-
-</details>
-
-<br>
-<details>
-<summary><b>Configure a Windows Hello for Business authentication certificate template</b></summary>
-
-During Windows Hello for Business provisioning, Windows clients request an authentication certificate from AD FS, which requests the authentication certificate on behalf of the user. This task configures the Windows Hello for Business authentication 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** and select **Manage**
-1. Right-click the **Smartcard Logon** template and choose **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 *WHFB Authentication* 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 deployment.
-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. On the **Extensions** tab, verify the **Application Policies** extension includes **Smart Card Logon**
-1. On the **Issuance Requirements** tab, 
-   - Select the **This number of authorized signatures** check box. Type *1* in the text box
-   - Select **Application policy** from the **Policy type required in signature**
-   - Select **Certificate Request Agent** from in the **Application policy** list
-   - Select the **Valid existing certificate** option
-1. On the **Subject** tab, 
-   - Select the **Build from this Active Directory information** button
-   - Select **Fully distinguished name** from the **Subject name format** list
-   - Select the **User Principal Name (UPN)** check box under **Include this information in alternative subject name**
-1. On the **Request Handling** tab, select the **Renew with same key** check box
-1. On the **Security** tab, select **Add**. Type *Window Hello for Business Users* in the **Enter the object names to select** text box and select **OK**
-1. Select the **Windows Hello for Business Users** from the **Group or users names** list. In the **Permissions for Windows Hello for Business Users** section:
-   - Select the **Allow** check box for the **Enroll** permission
-   - Excluding the **Windows Hello for Business Users** group, clear the **Allow** check box for the **Enroll** and **Autoenroll** permissions for all other entries in the **Group or users names** section if the check boxes are not already cleared
-   - Select **OK**
-1. If you previously issued Windows Hello for Business sign-in certificates using Configuration Manger and are switching to an AD FS registration authority, then on the **Superseded Templates** tab, add the previously used **Windows Hello for Business Authentication** template(s), so they will be superseded by this template for the users that have Enroll permission for this template
-1. Select on the **Apply** to save changes and close the console
-
-#### Mark the template as the Windows Hello Sign-in template
-
-Sign in to a CA or management workstations with *Enterprise Administrator* equivalent credentials
-
-Open an elevated command prompt end execute the following command
-
-```cmd
-certutil.exe -dsTemplate WHFBAuthentication msPKI-Private-Key-Flag +CTPRIVATEKEY_FLAG_HELLO_LOGON_KEY
-```
-
->[!NOTE]
->If you gave your Windows Hello for Business Authentication certificate template a different name, then replace *WHFBAuthentication* in the above command with the name of your certificate template. It's important that you use the template name rather than the template display name. You can view the template name on the **General** tab of the certificate template using the Certificate Template management console (certtmpl.msc). Or, you can view the template name using the **Get-CATemplate** ADCS Administration Windows PowerShell cmdlet on your certification authority.
-
-
-</details>
-
-<br>
-<details>
-<summary><b>Unpublish Superseded Certificate Templates</b></summary>
-
-The certification authority only issues certificates based on published certificate templates. For security, it's a good practice to unpublish certificate templates that the CA isn't configured to issue. This includes the pre-published certificate template from the role installation and any superseded certificate templates.
-
-The newly created *domain controller authentication* certificate template supersedes previous domain controller certificate templates. Therefore, you need to unpublish these certificate templates from all issuing certificate authorities.
-
-Sign in to the CA or management workstation with *Enterprise Administrator* equivalent credentials.
-
-1. Open the **Certification Authority** management console
-1. Expand the parent node from the navigation pane > **Certificate Templates**
-1. Right-click the *Domain Controller* certificate template and select **Delete**. Select **Yes** on the **Disable certificate templates** window
-1. Repeat step 3 for the *Domain Controller Authentication* and *Kerberos Authentication* certificate templates
-
-</details>
-
-<br>
-<details>
-<summary><b>Publish certificate templates to the CA</b></summary>
 
 A certification authority can only issue certificates for certificate templates that are published to it. If you have more than one CA, and you want more CAs to issue certificates based on the certificate template, then you must publish the certificate template to them.
 
@@ -278,71 +44,13 @@ Sign in to the CA or management workstations with **Enterprise Admin** equivalen
    - To unpublish a certificate template, right-click the certificate template you want to unpublish and select **Delete**. Select **Yes** to confirm the operation
 1. Close the console
 
-</details>
+## Configure and deploy certificates to domain controllers
 
-### Configure automatic certificate enrollment for the domain controllers
+[!INCLUDE [dc-certificate-deployment](includes/dc-certificate-deployment.md)]
-
-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.
+[!INCLUDE [dc-certificate-validate](includes/dc-certificate-validate.md)]
-
-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-cert-trust-adfs.md)

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:
 

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::
 

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)]
+- **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)]
+- **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)]
+- **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:
@@ -30,11 +30,7 @@ Windows Hello for Business supports using a certificate as the supplied credenti
 
 To deploy certificates using an on-premises Active Directory Certificate Services enrollment policy, you must first create a *certificate template*, and then deploy certificates based on that template.
 
-Expand the following sections to learn more about the process.
+### Create a Windows Hello for Business certificate template
-
-<br>
-<details>
-<summary><b>Create a Windows Hello for Business certificate template</b></summary>
 
 Follow these steps to create a certificate template:
 
@@ -81,11 +77,7 @@ Follow these steps to create a certificate template:
 1. From the list of templates, select the template you previously created (**WHFB Certificate Authentication**) and select **OK**. It can take some time for the template to replicate to all servers and become available in this list
 1. After the template replicates, in the MMC, right-click in the Certification Authority list, select **All Tasks > Stop Service**. Right-click the name of the CA again, select **All Tasks > Start Service**
 
-</details>
+### Request a certificate
-
-<br>
-<details>
-<summary><b>Request a certificate</b></summary>
 
 1. Sign in to a client that is hybrid Azure AD joined, ensuring that the client has line of sight to a domain controller and the issuing CA
 1. Open the **Certificates - Current User** Microsoft Management Console (MMC). To do so, you can execute the command `certmgr.msc`
@@ -95,8 +87,6 @@ Follow these steps to create a certificate template:
 1. Under *Request Certificates*, select the check-box for the certificate template you created in the previous section (*WHfB Certificate Authentication*) and then select **Enroll**
 1. After a successful certificate request, select **Finish** on the Certificate Installation Results screen
 
-</details>
-
 ## Deploy certificates via Intune
 
 > [!NOTE]
@@ -111,9 +101,7 @@ Next, you should deploy the root CA certificate (and any other intermediate cert
 
 Once these requirements are met, a policy can be configured in Intune that provisions certificates for the users on the targeted device.
 
-<br>
+### Create a policy in Intune
-<details>
-<summary><b>Create a policy in Intune</b></summary>
 
 This section describes how to configure a SCEP policy in Intune. Similar steps can be followed to configure a PKCS policy.
 
@@ -147,11 +135,8 @@ This section describes how to configure a SCEP policy in Intune. Similar steps c
 For more information how to configure SCEP policies, see [Configure SCEP certificate profiles in Intune][MEM-3].
 To configure PKCS policies, see [Configure and use PKCS certificate with Intune][MEM-4].
 
-</details>
+### Request a certificate for Intune clients
 
-<br>
-<details>
-<summary><b>Request a certificate</b></summary>
 Once the Intune policy is created, targeted clients will request a certificate during their next policy refresh cycle. To validate that the certificate is present in the user store, follow these steps:
 
 1. Sign in to a client targeted by the Intune policy
@@ -159,8 +144,6 @@ Once the Intune policy is created, targeted clients will request a certificate d
 1. In the left pane of the MMC, expand **Personal** and select **Certificates**
 1. In the right-hand pane of the MMC, check for the new certificate
 
-</details>
-
 ## Use third-party certification authorities
 
 If you're using a non-Microsoft PKI, the certificate templates published to the on-premises Active Directory may not be available. For guidance with integration of Intune/SCEP with non-Microsoft PKI deployments, refer to [Use third-party certification authorities (CA) with SCEP in Microsoft Intune][MEM-6].

windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base.md

@@ -1,336 +0,0 @@
----
-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.
-ms.date: 01/14/2021
-appliesto: 
-- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
-ms.topic: article
----
-# 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)]
-
-## Prerequisites
-
-Before adding Azure Active Directory (Azure AD) joined devices to your existing hybrid deployment, you need to verify the existing deployment can support Azure AD-joined devices.  Unlike hybrid Azure AD-joined devices, Azure AD-joined devices don't have a relationship with your Active Directory domain.  This factor changes the way in which users authenticate to Active Directory.  Validate the following configurations to ensure they support Azure AD-joined devices.
-
-- Azure Active Directory Connect synchronization
-- Device Registration
-- Certificate Revocation List (CRL) Distribution Point (CDP)
-- 2016 Domain Controllers
-- Domain Controller certificate
-- Network infrastructure in place to reach your on-premises domain controller. If the machines are external, you can use any VPN solution.
-
-### Azure Active Directory Connect synchronization
-Azure AD join, and hybrid Azure AD join devices register the user's Windows Hello for Business credential with Azure.  To enable on-premises authentication, the credential must be synchronized to the on-premises Active Directory, regardless whether you're using a key or a certificate.  Ensure you have Azure AD Connect installed and functioning properly.  To learn more about Azure AD Connect, read [Integrate your on-premises directories with Azure Active Directory](/azure/active-directory/connect/active-directory-aadconnect).
-
-If you upgraded your Active Directory schema to the Windows Server 2016 schema after installing Azure AD Connect, run Azure AD Connect and run **Refresh directory schema** from the list of tasks.
-![Azure AD Connect Schema Refresh.](images/aadj/aadconnectschema.png)
-
-### Azure Active Directory Device Registration
-A fundamental prerequisite of all cloud and hybrid Windows Hello for Business deployments is device registration.  A user can't provision Windows Hello for Business unless the device from which they're trying to provision has registered with Azure Active Directory.  For more information about device registration, read [Introduction to device management in Azure Active Directory](/azure/active-directory/devices/overview).
-
-You can use the **dsregcmd.exe** command to determine if your device is registered to Azure Active Directory.
-![dsregcmd output.](images/aadj/dsregcmd.png)
-
-### CRL Distribution Point (CDP)
-
-Certificates issued by a certificate authority can be revoked.  When a certificate authority revokes as certificate, it writes information about the certificate into a revocation list.  During certificate validation, Windows consults the CRL distribution point within the certificate to get a list of revoked certificates.  Validation compares the current certificate with information in the certificate revocation list to determine if the certificate remains valid.  
-
-![Domain Controller Certificate with LDAP CDP.](images/aadj/Certificate-CDP.png)
-
-The preceding domain controller certificate shows a CRL distribution path (CDP) using Active Directory. The value in the URL begins with **ldap**.  Using Active Directory for domain joined devices provides a highly available CRL distribution point.  However, Azure Active Directory-joined devices and users on Azure Active Directory-joined devices can't read data from Active Directory, and certificate validation doesn't provide an opportunity to authenticate prior to reading the certificate revocation list.  The authentication becomes a circular problem. The user is attempting to authenticate, but must read Active Directory to complete the authentication, but the user can't read Active Directory because they haven't authenticated.
-
-To resolve this issue, the CRL distribution point must be a location that is accessible by Azure Active Directory-joined devices that doesn't require authentication.  The easiest solution is to publish the CRL distribution point on a web server that uses HTTP (not HTTPS).
-
-If your CRL distribution point doesn't list an HTTP distribution point, then you need to reconfigure the issuing certificate authority to include an HTTP CRL distribution point, preferably first in the list of distribution points.
-
-> [!NOTE]
-> If your CA has published both the Base and the Delta CRL, please make sure you have included publishing the Delta CRL in the HTTP path. Include web server to fetch the Delta CRL by allowing double escaping in the (IIS) web server.
-
-### Windows Server 2016 Domain Controllers
-
-If you're interested in configuring your environment to use the Windows Hello for Business key rather than a certificate, then your environment must have an adequate number of Windows Server 2016 domain controllers.  Only Windows Server 2016 domain controllers are capable of authenticating user with a Windows Hello for Business key.  What do we mean by adequate?  We're glad you asked.  Read [Planning an adequate number of Windows Server 2016 Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) to learn more.
-
-If you're interested in configuring your environment to use the Windows Hello for Business certificate rather than key, then you're the right place.  The same certificate configuration on the domain controllers is needed, whether you're using Windows Server 2016 domain controllers or domain controllers running earlier versions of Windows Server.  You can ignore the Windows Server 2016 domain controller requirement.  
-
-### Domain Controller Certificates
-
-Certificate authorities write CRL distribution points in certificates as they're issued.  If the distribution point changes, then previously issued certificates must be reissued for the certificate authority to include the new CRL distribution point.  The domain controller certificate is one the critical components of Azure AD-joined devices authenticating to Active Directory
-
-#### Why does Windows need to validate the domain controller certificate?
-
-Windows Hello for Business enforces the strict KDC validation security feature when authenticating from an Azure AD joined device to a domain. This enforcement imposes more restrictive criteria that must be met by the Key Distribution Center (KDC). When authenticating using Windows Hello for Business on an Azure AD joined device, the Windows client validates the reply from the domain controller by ensuring all of the following are met:
-
-- The domain controller has the private key for the certificate provided.
-- The root CA that issued the domain controller's certificate is in the device's **Trusted Root Certificate Authorities**.
-- Use the **Kerberos Authentication certificate template** instead of any other older template.
-- The domain controller's certificate has the **KDC Authentication** enhanced key usage (EKU).
-- The domain controller's certificate's subject alternate name has a DNS Name that matches the name of the domain.
-- The domain controller's certificate's signature hash algorithm is **sha256**.
-- The domain controller's certificate's public key is **RSA (2048 Bits)**.
-
-Authenticating from a Hybrid Azure AD joined device to a domain using Windows Hello for Business doesn't enforce that the domain controller certificate includes the **KDC Authentication** EKU. If you're adding Azure AD-joined devices to an existing domain environment, make sure to verify that your domain controller certificate has been updated to include the **KDC Authentication** EKU. If you need to update your domain controller certificate to include the **KDC Authentication** EKU, follow the instructions in [Configure Hybrid Windows Hello for Business: Public Key Infrastructure](hello-hybrid-key-whfb-settings-pki.md)
-
-> [!Tip]
-> If you are using Windows Server 2008, **Kerberos Authentication** is not the default template, so make sure to use the correct template when issuing or re-issuing the certificate.
-
-## Configuring a CRL Distribution Point for an issuing certificate authority
-
-Use this set of procedures to update your certificate authority that issues your domain controller certificates to include an http-based CRL distribution point. 
-
-Steps you'll perform include:
-
-- [Configure Internet Information Services to host CRL distribution point](#configure-internet-information-services-to-host-crl-distribution-point) 
-- [Prepare a file share to host the certificate revocation list](#prepare-a-file-share-to-host-the-certificate-revocation-list)
-- [Configure the new CRL distribution point and Publishing location in the issuing certificate authority](#configure-the-new-crl-distribution-point-and-publishing-location-in-the-issuing-certificate-authority)
-- [Publish CRL](#publish-a-new-crl)
-- [Reissue domain controller certificates](#reissue-domain-controller-certificates)
-
-
-### Configure Internet Information Services to host CRL distribution point
-
-You need to host your new certificate revocation list of a web server so Azure AD-joined devices can easily validate certificates without authentication.  You can host these files on web servers many ways.  The following steps are just one and may be useful for admins unfamiliar with adding a new CRL distribution point.
-
-> [!IMPORTANT]
-> Do not configure the IIS server hosting your CRL distribution point to use https or a server authentication certificate.  Clients should access the distribution point using http. 
-
-#### Installing the Web Server
-
-1. Sign-in to your server as a local administrator and start **Server Manager** if it didn't start during your sign in. 
-2. Select the **Local Server** node in the navigation pane.  Select **Manage** and select **Add Roles and Features**.
-3. In the **Add Role and Features Wizard**, select **Server Selection**.  Verify the selected server is the local server.  Select **Server Roles**.  Select the check box next to **Web Server (IIS)**.
-4. Select **Next** through the remaining options in the wizard, accepting the defaults, and install the Web Server role.
- 
-#### Configure the Web Server
-
-1. From **Windows Administrative Tools**, Open **Internet Information Services (IIS) Manager**.
-2. Expand the navigation pane to show **Default Web Site**.  Select and then right-click **Default Web site** and select **Add Virtual Directory...**.
-3. In the **Add Virtual Directory** dialog box, type **cdp** in **alias**.  For physical path, type or browse for the physical file location where you'll host the certificate revocation list.  For this example, the path **c:\cdp** is used. Select **OK**.
-   ![Add Virtual Directory.](images/aadj/iis-add-virtual-directory.png) 
-   > [!NOTE]
-   > Make note of this path as you will use it later to configure share and file permissions.
-
-4. Select **CDP** under **Default Web Site** in the navigation pane.  Double-click **Directory Browsing** in the content pane.  Select **Enable** in the details pane.
-5. Select **CDP** under **Default Web Site** in the navigation pane.  Double-click **Configuration Editor**.
-6. In the **Section** list, navigate to **system.webServer/security/requestFiltering**.
-   ![IIS Configuration Editor requestFiltering.](images/aadj/iis-config-editor-requestFiltering.png)   
-   In the list of named value-pairs in the content pane, configure **allowDoubleEscaping** to **True**.  Select **Apply** in the actions pane.
-   ![IIS Configuration Editor double escaping.](images/aadj/iis-config-editor-allowDoubleEscaping.png)
-7. Close **Internet Information Services (IIS) Manager**. 
-
-#### Create a DNS resource record for the CRL distribution point URL 
-
-1. On your DNS server or from an administrative workstation, open **DNS Manager** from **Administrative Tools**.
-2. Expand **Forward Lookup Zones** to show the DNS zone for your domain.  Right-click your domain name in the navigation pane and select **New Host (A or AAAA)...**.
-3. In the **New Host** dialog box, type **crl** in **Name**.  Type the IP address of the web server you configured in **IP Address**. Select **Add Host**.  Select **OK** to close the **DNS** dialog box.  Select **Done**.
-![Create DNS host record.](images/aadj/dns-new-host-dialog.png)
-4. Close the **DNS Manager**. 
-
-### Prepare a file share to host the certificate revocation list
-
-These procedures configure NTFS and share permissions on the web server to allow the certificate authority to automatically publish the certificate revocation list.
-
-#### Configure the CDP file share
-
-1. On the web server, open **Windows Explorer** and navigate to the **cdp** folder you created in step 3 of [Configure the Web Server](#configure-the-web-server).
-2. Right-click the **cdp** folder and select **Properties**.  Select the **Sharing** tab.  Select **Advanced Sharing**.
-3. Select **Share this folder**. Type **cdp$** in **Share name**. Select **Permissions**.
-![cdp sharing.](images/aadj/cdp-sharing.png)
-4. In the **Permissions for cdp$** dialog box, select **Add**.
-5. In the **Select Users, Computers, Service Accounts, or Groups** dialog box, select **Object Types**.  In the **Object Types** dialog box, select **Computers**, and then select **OK**.
-7. In the **Select Users, Computers, Service Accounts, or Groups** dialog box, in **Enter the object names to select**, type the name of the server running the certificate authority issuing the certificate revocation list, and then select **Check Names**. Select **OK**.
-8. In the **Permissions for cdp$** dialog box, select the certificate authority from the **Group or user names list**. In the **Permissions for** section, select **Allow** for **Full control**. Select **OK**.
-![CDP Share Permissions.](images/aadj/cdp-share-permissions.png)
-9. In the **Advanced Sharing** dialog box, select **OK**.
-
-> [!Tip]
-> Make sure that users can access **\\\Server FQDN\sharename**.
-
-#### Disable Caching 
-1. On the web server, open **Windows Explorer** and navigate to the **cdp** folder you created in step 3 of [Configure the Web Server](#configure-the-web-server).
-2. Right-click the **cdp** folder and select **Properties**.  Select the **Sharing** tab.  Select **Advanced Sharing**.
-3. Select **Caching**. Select **No files or programs from the shared folder are available offline**.
-![CDP disable caching.](images/aadj/cdp-disable-caching.png)
-4. Select **OK**. 
-
-#### Configure NTFS permission for the CDP folder
-
-1. On the web server, open **Windows Explorer** and navigate to the **cdp** folder you created in step 3 of [Configure the Web Server](#configure-the-web-server).
-2. Right-click the **cdp** folder and select **Properties**.  Select the **Security** tab.
-3. On the **Security** tab, select Edit.
-5. In the **Permissions for cdp** dialog box, select **Add**.
-![CDP NTFS Permissions.](images/aadj/cdp-ntfs-permissions.png)
-6. In the **Select Users, Computers, Service Accounts, or Groups** dialog box, select **Object Types**.  In the **Object Types** dialog box, select **Computers**. Select **OK**.
-7. In the **Select Users, Computers, Service Accounts, or Groups** dialog box, in **Enter the object names to select**, type the name of the certificate authority, and then select **Check Names**. Select **OK**.
-8. In the **Permissions for cdp** dialog box, select the name of the certificate authority from the **Group or user names** list. In the **Permissions for** section, select **Allow** for **Full control**. Select **OK**.
-9. Select **Close** in the **cdp Properties** dialog box.
-
-
-### Configure the new CRL distribution point and Publishing location in the issuing certificate authority
-
-The web server is ready to host the CRL distribution point.  Now, configure the issuing certificate authority to publish the CRL at the new location and to include the new CRL distribution point
-
-
-#### Configure the CRL distribution Point
-1. On the issuing certificate authority, sign-in as a local administrator.  Start the **Certificate Authority** console from **Administrative Tools**. 
-2. In the navigation pane, right-click the name of the certificate authority and select **Properties**
-3. Select **Extensions**.  On the **Extensions** tab, select **CRL Distribution Point (CDP)** from the **Select extension** list.
-4. On the **Extensions** tab, select **Add**. Type <b>http://crl.[domainname]/cdp/</b> in **location**.  For example, `<http://crl.corp.contoso.com/cdp/>` or `<http://crl.contoso.com/cdp/>` (don't forget the trailing forward slash). 
-   ![CDP New Location dialog box.](images/aadj/cdp-extension-new-location.png)
-5. Select **\<CaName>** from the **Variable** list and select **Insert**.  Select **\<CRLNameSuffix>** from the **Variable** list and select **Insert**.  Select **\<DeltaCRLAllowed>** from the **Variable** list and select **Insert**.
-6. Type **.crl** at the end of the text in **Location**. Select **OK**.
-7. Select the CDP you just created.
-   ![CDP complete http.](images/aadj/cdp-extension-complete-http.png)
-8. Select **Include in CRLs.  Clients use this to find Delta CRL locations**.
-9. Select **Include in the CDP extension of issued certificates**.
-10. Select **Apply** save your selections.  Select **No** when ask to restart the service.
-
-> [!NOTE]
-> Optionally, you can remove unused CRL distribution points and publishing locations.
-
-#### Configure the CRL publishing location
-
-1. On the issuing certificate authority, sign-in as a local administrator.  Start the **Certificate Authority** console from **Administrative Tools**. 
-2. In the navigation pane, right-click the name of the certificate authority and select **Properties**
-3. Select **Extensions**.  On the **Extensions** tab, select **CRL Distribution Point (CDP)** from the **Select extension** list.
-4. On the **Extensions** tab, select **Add**.  Type the computer and share name you create for your CRL distribution point in [Configure the CDP file share](#configure-the-cdp-file-share).  For example, **\\\app\cdp$\\** (don't forget the trailing backwards slash).
-5. Select **\<CaName>** from the **Variable** list and select **Insert**.  Select **\<CRLNameSuffix>** from the **Variable** list and select **Insert**.  Select **\<DeltaCRLAllowed>** from the **Variable** list and select **Insert**.
-6. Type **.crl** at the end of the text in **Location**. Select **OK**.
-7. Select the CDP you just created. <br/>
-   ![CDP publishing location.](images/aadj/cdp-extension-complete-unc.png)
-8. Select **Publish CRLs to this location**.
-9. Select **Publish Delta CRLs to this location**.
-10. Select **Apply** save your selections.  Select **Yes** when ask to restart the service.  Select **OK** to close the properties dialog box.
-
-### Publish a new CRL
-
-1. On the issuing certificate authority, sign-in as a local administrator.  Start the **Certificate Authority** console from **Administrative Tools**.
-2. In the navigation pane, right-click **Revoked Certificates**, hover over **All Tasks**, and select **Publish**
-![Publish a New CRL.](images/aadj/publish-new-crl.png)
-3. In the **Publish CRL** dialog box, select **New CRL** and select **OK**.
-
-#### Validate CDP Publishing
-
-Validate your new CRL distribution point is working. 
-
-1. Open a web browser. Navigate to `http://crl.[yourdomain].com/cdp`.  You should see two files created from publishing your new CRL.
-   ![Validate the new CRL.](images/aadj/validate-cdp-using-browser.png)
-
-### Reissue domain controller certificates
-
-With the CA properly configured with a valid HTTP-based CRL distribution point, you need to reissue certificates to domain controllers as the old certificate doesn't have the updated CRL distribution point. 
-
-1. Sign-in a domain controller using administrative credentials.
-2. Open the **Run** dialog box.  Type **certlm.msc** to open the **Certificate Manager** for the local computer.
-3. In the navigation pane, expand **Personal**.  Select **Certificates**.  In the details pane, select the existing domain controller certificate includes **KDC Authentication** in the list of **Intended Purposes**.
-![Certificate Manager Personal store.](images/aadj/certlm-personal-store.png)
-4. Right-click the selected certificate.  Hover over **All Tasks** and then select **Renew Certificate with New Key...**.  In the **Certificate Enrollment** wizard, select **Next**.
-![Renew with New key.](images/aadj/certlm-renew-with-new-key.png) 
-5. In the **Request Certificates** page of the wizard, verify the selected certificate has the correct certificate template and ensure the status is available.  Select **Enroll**.
-6. After the enrollment completes, select **Finish** to close the wizard. 
-7. Repeat this procedure on all your domain controllers.
-
-> [!NOTE]
-> You can configure domain controllers to automatically enroll and renew their certificates.  Automatic certificate enrollment helps prevent authentication outages due to expired certificates.  Refer to the [Windows Hello Deployment Guides](./hello-deployment-guide.md) to learn how to deploy automatic certificate enrollment for domain controllers. 
-
-> [!IMPORTANT]
-> If you are not using automatic certificate enrollment, create a calendar reminder to alert you two months before the certificate expiration date. Send the reminder to multiple people in the organization to ensure more than one or two people know when these certificates expire.
-
-#### Validate CDP in the new certificate
-
-1. Sign-in a domain controller using administrative credentials.
-2. Open the **Run** dialog box.  Type **certlm.msc** to open the **Certificate Manager** for the local computer.
-3. In the navigation pane, expand **Personal**.  Select **Certificates**.  In the details pane, double-click the existing domain controller certificate includes **KDC Authentication** in the list of **Intended Purposes**.
-4. Select the **Details** tab.  Scroll down the list until **CRL Distribution Points** is visible in the **Field** column of the list.  Select **CRL Distribution Point**.
-5. Review the information below the list of fields to confirm the new URL for the CRL distribution point is present in the certificate.  Select **OK**.</br>
-![New Certificate with updated CDP.](images/aadj/dc-cert-with-new-cdp.png)
-
-## Configure and Assign a Trusted Certificate Device Configuration Profile
-
-Your domain controllers have new certificates that include the new CRL distribution point.  Next, you need your enterprise root certificate so you can deploy it to Azure AD-joined devices. When you deploy the enterprise root certificates to the device, it ensures the device trusts any certificates issued by the certificate authority.  Without the certificate, Azure AD-joined devices don't trust domain controller certificates and authentication fails. 
-
-Steps you'll perform include:
-- [Export Enterprise Root certificate](#export-enterprise-root-certificate)
-- [Create and Assign a Trust Certificate Device Configuration Profile](#create-and-assign-a-trust-certificate-device-configuration-profile)
-
-### Export Enterprise Root certificate
-
-1. Sign-in a domain controller using administrative credentials.
-2. Open the **Run** dialog box.  Type **certlm.msc** to open the **Certificate Manager** for the local computer.
-3. In the navigation pane, expand **Personal**.  Select **Certificates**.  In the details pane, double-click the existing domain controller certificate includes **KDC Authentication** in the list of **Intended Purposes**.
-4. Select the **Certification Path** tab.  In the **Certification path** view, select the topmost node and select **View Certificate**.
-![Certificate Path.](images/aadj/certlm-cert-path-tab.png)
-5. In the new **Certificate** dialog box, select the **Details** tab. Select **Copy to File**.
-![Details tab and copy to file.](images/aadj/certlm-root-cert-details-tab.png)
-6. In the **Certificate Export Wizard**, select **Next**.  
-7. On the **Export File Format** page of the wizard, select **Next**.  
-8. On the **File to Export** page in the wizard, type the name and location of the root certificate and select **Next**. Select **Finish** and then select **OK** to close the success dialog box. <br>
-![Export root certificate.](images/aadj/certlm-export-root-certificate.png)
-9. Select **OK**  two times to return to the **Certificate Manager** for the local computer.  Close the **Certificate Manager**.
-
-### Create and Assign a Trust Certificate Device Configuration Profile
-
-A **Trusted Certificate** device configuration profile is how you deploy trusted certificates to Azure AD-joined devices.
-
-1. Sign-in to the [Microsoft Azure portal](https://portal.azure.com) and select **Microsoft Intune**.
-2. Select **Device configuration**.  In the **Device Configuration** blade, select **Create profile**.
-![Intune Create Profile.](images/aadj/intune-create-device-config-profile.png)
-3. In the **Create profile** blade, type **Enterprise Root Certificate** in **Name**.  Provide a description.  Select **Windows 10 and later** from the **Platform** list.  Select **Trusted certificate** from the **Profile type** list.  Select **Configure**.
-4. In the **Trusted Certificate** blade, use the folder icon to browse for the location of the enterprise root certificate file you created in step 8 of [Export Enterprise Root certificate](#export-enterprise-root-certificate).  Select **OK**.  Select **Create**.
-![Intune Trusted Certificate Profile.](images/aadj/intune-create-trusted-certificate-profile.png)
-5. In the **Enterprise Root Certificate** blade, select **Assignments**.  In the **Include** tab, select **All Devices** from the **Assign to** list.  Select **Save**.
-![Intune Profile assignment.](images/aadj/intune-device-config-enterprise-root-assignment.png)
-6. Sign out of the Microsoft Azure portal.
-> [!NOTE]
-> After the creation, the **supported platform** parameter of the profile will contain the value "Windows 8.1 and later", as the certificate configuration for Windows 8.1 and Windows 10 is the same.
-
-## Configure Windows Hello for Business Device Enrollment
-
-Sign-in a workstation with access equivalent to a _domain user_.
-
-1. Sign in to the [Microsoft Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
-2. Select **Devices**.
-3. Choose **Enroll devices**.
-4. Select **Windows enrollment**.
-5. Under **Windows enrollment**, select **Windows Hello for Business**.
-   ![Create Windows Hello for Business Policy.](images/aadj/MEM.png)
-6. Select **Enabled** from the **Configure Windows Hello for Business** list.
-7. Select **Required** next to **Use a Trusted Platform Module (TPM)**. By default, Windows Hello for Business prefers TPM 2.0 or falls backs to software. Choosing **Required** forces Windows Hello for Business to only use TPM 2.0 or TPM 1.2 and doesn't allow fall back to software-based keys.
-8. Enter the desired **Minimum PIN length** and **Maximum PIN length**.
-    > [!IMPORTANT]
-    > The default minimum PIN length for Windows Hello for Business on Windows 10 and Windows 11 is six.  Microsoft Intune defaults the minimum PIN length to four, which reduces the security of the user's PIN.  If you do not have a desired PIN length, set the minimum PIN length to six.
-
-9. Select the appropriate configuration for the following settings:
-    * **Lowercase letters in PIN**
-    * **Uppercase letters in PIN**
-    * **Special characters in PIN**
-    * **PIN expiration (days)**
-    * **Remember PIN history**
-    
-    > [!NOTE]
-    > The Windows Hello for Business PIN is not a symmetric key (a password).  A copy of the current PIN is not stored locally or on a server like in the case of passwords.  Making the PIN as complex and changed frequently as a password increases the likelihood of forgotten PINs.  Additionally, enabling PIN history is the only scenario that requires Windows to store older PIN combinations (protected to the current PIN). Windows Hello for Business combined with a TPM provides anti-hammering functionality that prevents brute force attacks of the user's PIN.  If you are concerned with user-to-user shoulder surfacing, rather that forcing complex PIN that change frequently, consider using the [Multifactor Unlock](feature-multifactor-unlock.md) feature.
-
-10. Select **Yes** next to **Allow biometric authentication** if you want to allow users to use biometrics (fingerprint and/or facial recognition) to unlock the device. To further secure the use of biometrics, select **Yes** to **Use enhanced anti-spoofing, when available**.
-11. Select **No** to **Allow phone sign-in**. This feature has been deprecated.
-12. Choose **Save**.
-13. Sign out of the Microsoft Endpoint Manager admin center.
-
-> [!IMPORTANT]
-> For more details about the actual experience after everything has been configured, please see [Windows Hello for Business and Authentication](./hello-how-it-works-authentication.md).
-
-> [!NOTE]
-> For access issues in the context of VPN, make sure to check the resolution and workaround described in [Workaround for user security context and access control](/troubleshoot/windows-client/group-policy/group-membership-changes-not-updating-over-some-vpn-connections#workarounds).
-
-## Section Review
-> [!div class="checklist"]
-> * Configure Internet Information Services to host CRL distribution point
-> * Prepare a file share to host the certificate revocation list
-> * Configure the new CRL distribution point in the issuing certificate authority
-> * Publish CRL
-> * Reissue domain controller certificates
-> * Export Enterprise Root certificate
-> * Create and Assign a Trust Certificate Device Configuration Profile
-> * Configure Windows Hello for Business Device Enrollment
-
-If you plan on using certificates for on-premises single-sign on, perform the additional steps in [Using Certificates for On-premises Single-sign On](hello-hybrid-aadj-sso-cert.md). 

windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md

@@ -4,12 +4,12 @@ description: If you want to use certificates for on-premises single-sign on for
 ms.date: 08/19/2018
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
-ms.topic: article
+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.
 

windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso.md

@@ -1,37 +1,255 @@
 ---
-title: Azure AD Join Single Sign-on Deployment
+title: Configure single sign-on (SSO) for Azure AD joined devices
-description: Learn how to provide single sign-on to your on-premises resources for Azure Active Directory-joined devices, using Windows Hello for Business.
+description: Learn how to configure single sign-on to on-premises resources for Azure AD-joined devices, using Windows Hello for Business.
-ms.date: 08/19/2018
+ms.date: 12/30/2022
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
 ms.topic: article
 ---
-# Azure AD Join Single Sign-on Deployment
+# Configure single sign-on for Azure AD joined devices
 
-[!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.
+Windows Hello for Business combined with Azure AD-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 the hybrid deployment, you can provide single sign-on to on-premises resources for Azure AD-joined devices using Windows Hello for Business, using a key or a certificate.
 
-## Key vs. Certificate
+> [!NOTE]
+> These steps are not needed when using the cloud Kerberos trust model.
 
-Enterprises can use either a key or a certificate to provide single-sign on for on-premises resources.  Both types of authentication provide the same security; one is not more secure than the other.  
+## Prerequisites
 
-When using a key, the on-premises environment needs an adequate distribution of Windows Server 2016 domain controllers relative to your existing authentication and the number of users included in your Windows Hello for Business deployment.  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.
+Unlike hybrid Azure AD-joined devices, Azure AD-joined devices don't have a relationship with your Active Directory domain. This factor changes the way in which users authenticate to Active Directory. Validate the following configurations to ensure they support Azure AD-joined devices:
 
-When using a certificate, the on-premises environment can use Windows Server 2008 R2 and later domain controllers, which removes the Windows Server 2016 domain controller requirement.  However, single-sign on using a certificate requires additional infrastructure to issue a certificate when the user enrolls for Windows Hello for Business.  Azure AD-joined devices enroll certificates using Microsoft Intune or a compatible Mobile Device Management (MDM).  Microsoft Intune and Windows Hello for Business use the Network Device Enrollment Services (NDES) role and support Microsoft Intune connector.
+> [!div class="checklist"]
+> - Certificate Revocation List (CRL) Distribution Point
+> - Domain controller certificates
+> - Network infrastructure in place to reach the on-premises domain controllers. If the machines are external, you can use any VPN solution
 
-To deploy single sign-on for Azure AD-joined devices using keys, read and follow [Configure Azure AD-joined devices for On-premises Single-Sign On using Windows Hello for Business](hello-hybrid-aadj-sso-base.md).
+### CRL Distribution Point (CDP)
-To deploy single sign-on for Azure AD-joined devices using certificates, read and follow [Configure Azure AD-joined devices for On-premises Single-Sign On using Windows Hello for Business](hello-hybrid-aadj-sso-base.md) and then [Using Certificates for Azure Active Directory-joined On-premises Single-sign On](hello-hybrid-aadj-sso-cert.md).
 
-## Related topics
+Certificates issued by a certificate authority can be revoked. When a certificate authority revokes as certificate, it writes information about the certificate into a *certificate revocation list* (CRL).\
+During certificate validation, Windows compares the current certificate with information in the CRL to determine if the certificate is valid.
 
-- [Windows Hello for Business](hello-identity-verification.md)
+![Domain Controller Certificate with LDAP CDP.](images/aadj/Certificate-CDP.png)
-- [How Windows Hello for Business works](hello-how-it-works.md)
-- [Manage Windows Hello for Business in your organization](hello-manage-in-organization.md)
-- [Why a PIN is better than a password](hello-why-pin-is-better-than-password.md)
-- [Prepare people to use Windows Hello](hello-prepare-people-to-use.md)
-- [Windows Hello errors during PIN creation](hello-errors-during-pin-creation.md)
-- [Event ID 300 - Windows Hello successfully created](hello-event-300.md)
-- [Windows Hello biometrics in the enterprise](hello-biometrics-in-enterprise.md)
 
+The preceding domain controller certificate shows a *CRL distribution point* (CDP) in Active Directory. The value in the URL begins with *ldap*. Using Active Directory for domain joined devices provides a highly available CRL distribution point. However, Azure AD joined devices can't read data from Active Directory, and certificate validation doesn't provide an opportunity to authenticate prior to reading the CRL. The authentication becomes a circular problem: the user is attempting to authenticate, but must read Active Directory to complete the authentication, but the user can't read Active Directory because they haven't authenticated.
 
+To resolve this issue, the CRL distribution point must be a location accessible by Azure AD joined devices that doesn't require authentication. The easiest solution is to publish the CRL distribution point on a web server that uses HTTP (not HTTPS).
+
+If your CRL distribution point doesn't list an HTTP distribution point, then you need to reconfigure the issuing certificate authority to include an HTTP CRL distribution point, preferably first, in the list of distribution points.
+
+> [!NOTE]
+> If your CA has published both the *Base* and the *Delta CRL*, make sure to publish the *Delta CRL* in the HTTP path. Include web server to fetch the *Delta CRL* by allowing **double escaping** in the (IIS) web server.
+
+### Domain controller certificates
+
+Certificate authorities write CDP information in certificates as they're issued. If the distribution point changes, then previously issued certificates must be reissued for the certificate authority to include the new CDP. The domain controller certificate is one the critical components of Azure AD-joined devices authenticating to Active Directory.
+
+#### Why does Windows need to validate the domain controller certificate?
+
+Windows Hello for Business enforces the strict KDC validation security feature when authenticating from an Azure AD joined device to a domain. This enforcement imposes more restrictive criteria that must be met by the Key Distribution Center (KDC). When authenticating using Windows Hello for Business on an Azure AD joined device, the Windows client validates the reply from the domain controller by ensuring all of the following are met:
+
+- The domain controller has the private key for the certificate provided
+- The root CA that issued the domain controller's certificate is in the device's *Trusted Root Certificate Authorities*
+- Use the *Kerberos Authentication certificate template* instead of any other older template
+- The domain controller's certificate has the *KDC Authentication* extended key usage (EKU)
+- The domain controller's certificate's subject alternate name has a DNS Name that matches the name of the domain
+- The domain controller's certificate's signature hash algorithm is **sha256**
+- The domain controller's certificate's public key is **RSA (2048 Bits)**
+
+Authenticating from a Hybrid Azure AD joined device to a domain using Windows Hello for Business doesn't enforce that the domain controller certificate includes the *KDC Authentication* EKU. If you're adding Azure AD-joined devices to an existing domain environment, make sure to verify that your domain controller certificate has been updated to include the *KDC Authentication* EKU.
+
+## Configure a CRL distribution point for an issuing CA
+
+Use this set of procedures to update the CA that issues domain controller certificates to include an http-based CRL distribution point.
+
+### Configure Internet Information Services to host CRL distribution point
+
+You need to host your new certificate revocation list on a web server so Azure AD-joined devices can easily validate certificates without authentication. You can host these files on web servers many ways. The following steps are just one and may be useful for admins unfamiliar with adding a new CRL distribution point.
+
+> [!IMPORTANT]
+> Do not configure the IIS server hosting your CRL distribution point to use https or a server authentication certificate. Clients should access the distribution point using http. 
+
+### Install the web server
+
+1. Sign-in to your server as a local administrator and start **Server Manager** if it didn't start during your sign in
+1. Select the **Local Server** node in the navigation pane. Select **Manage** and select **Add Roles and Features**
+1. In the **Add Role and Features Wizard**, select **Server Selection**. Verify the selected server is the local server. Select **Server Roles**. Select the check box next to **Web Server (IIS)**
+1. Select **Next** through the remaining options in the wizard, accepting the defaults, and install the Web Server role
+
+### Configure the web server
+
+1. From **Windows Administrative Tools**, Open **Internet Information Services (IIS) Manager**
+1. Expand the navigation pane to show **Default Web Site**. Select and then right-click **Default Web site** and select **Add Virtual Directory...**
+1. In the **Add Virtual Directory** dialog box, type **cdp** in **alias**. For physical path, type or browse for the physical file location where you'll host the certificate revocation list. For this example, the path `c:\cdp` is used. Select **OK**
+    ![Add Virtual Directory.](images/aadj/iis-add-virtual-directory.png)
+   > [!NOTE]
+   > Make note of this path as you will use it later to configure share and file permissions.
+
+1. Select **CDP** under **Default Web Site** in the navigation pane. Open **Directory Browsing** in the content pane. Select **Enable** in the details pane
+1. Select **CDP** under **Default Web Site** in the navigation pane. Open **Configuration Editor**
+1. In the **Section** list, navigate to **system.webServer/security/requestFiltering**
+     ![IIS Configuration Editor requestFiltering.](images/aadj/iis-config-editor-requestFiltering.png)
+1. In the list of named value-pairs in the content pane, configure **allowDoubleEscaping** to **True**. Select **Apply** in the actions pane
+     ![IIS Configuration Editor double escaping.](images/aadj/iis-config-editor-allowDoubleEscaping.png)
+1. Close **Internet Information Services (IIS) Manager**
+
+### Create a DNS resource record for the CRL distribution point URL
+
+1. On your DNS server or from an administrative workstation, open **DNS Manager** from **Administrative Tools**
+1. Expand **Forward Lookup Zones** to show the DNS zone for your domain. Right-click your domain name in the navigation pane and select **New Host (A or AAAA)...**
+1. In the **New Host** dialog box, type **crl** in **Name**. Type the IP address of the web server you configured in **IP Address**. Select **Add Host**. Select **OK** to close the **DNS** dialog box. Select **Done**
+    ![Create DNS host record.](images/aadj/dns-new-host-dialog.png)
+1. Close the **DNS Manager**
+
+### Prepare a file share to host the certificate revocation list
+
+These procedures configure NTFS and share permissions on the web server to allow the certificate authority to automatically publish the certificate revocation list.
+
+### Configure the CDP file share
+
+1. On the web server, open **Windows Explorer** and navigate to the **cdp** folder you created in step 3 of [Configure the Web Server](#configure-the-web-server)
+1. Right-click the **cdp** folder and select **Properties**. Select the **Sharing** tab. Select **Advanced Sharing**
+1. Select **Share this folder**. Type **cdp$** in **Share name**. Select **Permissions**
+    ![cdp sharing.](images/aadj/cdp-sharing.png)
+1. In the **Permissions for cdp$** dialog box, select **Add**
+1. In the **Select Users, Computers, Service Accounts, or Groups** dialog box, select **Object Types**. In the **Object Types** dialog box, select **Computers**, and then select **OK**
+1. In the **Select Users, Computers, Service Accounts, or Groups** dialog box, in **Enter the object names to select**, type the name of the server running the certificate authority issuing the certificate revocation list, and then select **Check Names**. Select **OK**
+1. In the **Permissions for cdp$** dialog box, select the certificate authority from the **Group or user names list**. In the **Permissions for** section, select **Allow** for **Full control**. Select **OK**
+    ![CDP Share Permissions.](images/aadj/cdp-share-permissions.png)
+1. In the **Advanced Sharing** dialog box, select **OK**
+
+> [!Tip]
+> Make sure that users can access **\\\Server FQDN\sharename**.
+
+### Disable Caching 
+1. On the web server, open **Windows Explorer** and navigate to the **cdp** folder you created in step 3 of [Configure the Web Server](#configure-the-web-server)
+1. Right-click the **cdp** folder and select **Properties**. Select the **Sharing** tab. Select **Advanced Sharing**
+1. Select **Caching**. Select **No files or programs from the shared folder are available offline**
+    ![CDP disable caching.](images/aadj/cdp-disable-caching.png)
+1. Select **OK**
+
+### Configure NTFS permission for the CDP folder
+
+1. On the web server, open **Windows Explorer** and navigate to the **cdp** folder you created in step 3 of [Configure the Web Server](#configure-the-web-server)
+1. Right-click the **cdp** folder and select **Properties**. Select the **Security** tab
+1. On the **Security** tab, select Edit
+1. In the **Permissions for cdp** dialog box, select **Add**
+    ![CDP NTFS Permissions.](images/aadj/cdp-ntfs-permissions.png)
+1. In the **Select Users, Computers, Service Accounts, or Groups** dialog box, select **Object Types**. In the **Object Types** dialog box, select **Computers**. Select **OK**
+1. In the **Select Users, Computers, Service Accounts, or Groups** dialog box, in **Enter the object names to select**, type the name of the certificate authority, and then select **Check Names**. Select **OK**
+1. In the **Permissions for cdp** dialog box, select the name of the certificate authority from the **Group or user names** list. In the **Permissions for** section, select **Allow** for **Full control**. Select **OK**
+1. Select **Close** in the **cdp Properties** dialog box
+
+### Configure the new CDP and publishing location in the issuing CA
+
+The web server is ready to host the CRL distribution point. Now, configure the issuing certificate authority to publish the CRL at the new location and to include the new CRL distribution point.
+
+#### Configure the CRL distribution Point
+
+1. On the issuing certificate authority, sign-in as a local administrator. Start the **Certification Authority** console from **Administrative Tools**
+1. In the navigation pane, right-click the name of the certificate authority and select **Properties**
+1. Select **Extensions**. On the **Extensions** tab, select **CRL Distribution Point (CDP)** from the **Select extension** list
+1. On the **Extensions** tab, select **Add**. Type <b>http://crl.[domainname]/cdp/</b> in **location**. For example, `<http://crl.corp.contoso.com/cdp/>` or `<http://crl.contoso.com/cdp/>` (don't forget the trailing forward slash)
+    ![CDP New Location dialog box.](images/aadj/cdp-extension-new-location.png)
+1. Select **\<CaName>** from the **Variable** list and select **Insert**. Select **\<CRLNameSuffix>** from the **Variable** list and select **Insert**. Select **\<DeltaCRLAllowed>** from the **Variable** list and select **Insert**
+1. Type **.crl** at the end of the text in **Location**. Select **OK**
+1. Select the CDP you just created
+    ![CDP complete http.](images/aadj/cdp-extension-complete-http.png)
+1. Select **Include in CRLs. Clients use this to find Delta CRL locations**
+1. Select **Include in the CDP extension of issued certificates**
+1. Select **Apply** save your selections. Select **No** when ask to restart the service
+
+> [!NOTE]
+> Optionally, you can remove unused CRL distribution points and publishing locations.
+
+#### Configure the CRL publishing location
+
+1. On the issuing certificate authority, sign-in as a local administrator. Start the **Certificate Authority** console from **Administrative Tools**
+1. In the navigation pane, right-click the name of the certificate authority and select **Properties**
+1. Select **Extensions**. On the **Extensions** tab, select **CRL Distribution Point (CDP)** from the **Select extension** list
+1. On the **Extensions** tab, select **Add**. Type the computer and share name you create for your CRL distribution point in [Configure the CDP file share](#configure-the-cdp-file-share). For example, **\\\app\cdp$\\** (don't forget the trailing backwards slash)
+1. Select **\<CaName>** from the **Variable** list and select **Insert**. Select **\<CRLNameSuffix>** from the **Variable** list and select **Insert**. Select **\<DeltaCRLAllowed>** from the **Variable** list and select **Insert**
+1. Type **.crl** at the end of the text in **Location**. Select **OK**
+1. Select the CDP you just created
+    ![CDP publishing location.](images/aadj/cdp-extension-complete-unc.png)
+1. Select **Publish CRLs to this location**
+1. Select **Publish Delta CRLs to this location**
+1. Select **Apply** save your selections. Select **Yes** when ask to restart the service. Select **OK** to close the properties dialog box
+
+#### Publish a new CRL
+
+1. On the issuing certificate authority, sign-in as a local administrator. Start the **Certificate Authority** console from **Administrative Tools**
+1. In the navigation pane, right-click **Revoked Certificates**, hover over **All Tasks**, and select **Publish**
+    ![Publish a New CRL.](images/aadj/publish-new-crl.png)
+1. In the **Publish CRL** dialog box, select **New CRL** and select **OK**
+
+#### Validate CDP Publishing
+
+Validate the new CRL distribution point is working.
+
+1. Open a web browser. Navigate to `http://crl.[yourdomain].com/cdp`. You should see two files created from publishing the new CRL
+    ![Validate the new CRL.](images/aadj/validate-cdp-using-browser.png)
+
+#### Reissue domain controller certificates
+
+With the CA properly configured with a valid HTTP-based CRL distribution point, you need to reissue certificates to domain controllers as the old certificate doesn't have the updated CRL distribution point. 
+
+1. Sign-in a domain controller using administrative credentials
+1. Open the **Run** dialog box. Type **certlm.msc** to open the **Certificate Manager** for the local computer
+1. In the navigation pane, expand **Personal**. Select **Certificates**. In the details pane, select the existing domain controller certificate that includes **KDC Authentication** in the list of **Intended Purposes**
+    ![Certificate Manager Personal store.](images/aadj/certlm-personal-store.png)
+1. Right-click the selected certificate. Hover over **All Tasks** and then select **Renew Certificate with New Key...**. In the **Certificate Enrollment** wizard, select **Next**
+    ![Renew with New key.](images/aadj/certlm-renew-with-new-key.png)
+1. In the **Request Certificates** page of the wizard, verify the selected certificate has the correct certificate template and ensure the status is available. Select **Enroll**
+1. After the enrollment completes, select **Finish** to close the wizard
+1. Repeat this procedure on all your domain controllers
+
+> [!NOTE]
+> You can configure domain controllers to automatically enroll and renew their certificates. Automatic certificate enrollment helps prevent authentication outages due to expired certificates. Refer to the [Windows Hello Deployment Guides](./hello-deployment-guide.md) to learn how to deploy automatic certificate enrollment for domain controllers.
+
+> [!IMPORTANT]
+> If you are not using automatic certificate enrollment, create a calendar reminder to alert you two months before the certificate expiration date. Send the reminder to multiple people in the organization to ensure more than one or two people know when these certificates expire.
+
+#### Validate CDP in the new certificate
+
+1. Sign-in a domain controller using administrative credentials
+1. Open the **Run** dialog box. Type **certlm.msc** to open the **Certificate Manager** for the local computer
+1. In the navigation pane, expand **Personal**. Select **Certificates**. In the details pane, double-click the existing domain controller certificate includes **KDC Authentication** in the list of **Intended Purposes**
+1. Select the **Details** tab. Scroll down the list until **CRL Distribution Points** is visible in the **Field** column of the list. Select **CRL Distribution Point**
+1. Review the information below the list of fields to confirm the new URL for the CRL distribution point is present in the certificate. Select **OK**
+    ![New Certificate with updated CDP.](images/aadj/dc-cert-with-new-cdp.png)
+
+## Deploy the root CA certificate to Azure AD-joined devices
+
+The domain controllers have a certificate that includes the new CRL distribution point. Next, you need the enterprise root certificate so you can deploy it to Azure AD-joined devices. When you deploy the enterprise root certificates to a device, it ensures the device trusts any certificates issued by the certificate authority. Without the certificate, Azure AD-joined devices don't trust domain controller certificates and authentication fails.
+
+### Export the enterprise root certificate
+
+1. Sign-in a domain controller using administrative credentials
+1. Open the **Run** dialog box. Type **certlm.msc** to open the **Certificate Manager** for the local computer
+1. In the navigation pane, expand **Personal**. Select **Certificates**. In the details pane, double-click the existing domain controller certificate includes **KDC Authentication** in the list of **Intended Purposes**
+1. Select the **Certification Path** tab. In the **Certification path** view, select the topmost node and select **View Certificate**
+    ![Certificate Path.](images/aadj/certlm-cert-path-tab.png)
+1. In the new **Certificate** dialog box, select the **Details** tab. Select **Copy to File**
+    ![Details tab and copy to file.](images/aadj/certlm-root-cert-details-tab.png)
+1. In the **Certificate Export Wizard**, select **Next**
+1. On the **Export File Format** page of the wizard, select **Next**
+1. On the **File to Export** page in the wizard, type the name and location of the root certificate and select **Next**. Select **Finish** and then select **OK** to close the success dialog box
+    ![Export root certificate.](images/aadj/certlm-export-root-certificate.png)
+1. Select **OK**  two times to return to the **Certificate Manager** for the local computer. Close the **Certificate Manager**
+
+### Deploy the certificate via Intune
+
+To configure devices with Microsoft Intune, use a custom policy:
+
+1. Go to the <a href="https://go.microsoft.com/fwlink/?linkid=2109431" target="_blank"><b>Microsoft Endpoint Manager admin center</b></a>
+1. Select **Devices > Configuration profiles > Create profile**
+1. Select **Platform > Windows 8.1 and later** and **Profile type > Trusted certificate**
+1. Select **Create**
+1. In **Configuration settings**, select the folder icon and browse for the enterprise root certificate file. Once the file is selected, select **Open** to upload it to Intune
+1. Under **Destination store** dropdown, select **Computer certificate store - Root**
+1. Select **Next**
+1. Under **Assignment**, select a security group that contains as members the devices or users that you want to configure > **Next**
+1. Review the policy configuration and select **Create**
+
+If you plan on using certificates for on-premises single-sign on, perform the additional steps in [Using Certificates for On-premises Single-sign On](hello-hybrid-aadj-sso-cert.md). Otherwise, you can sign in to an Azure AD joined device with Windows Hello for Business and test SSO to an on-premises resource.

windows/security/identity-protection/hello-for-business/hello-hybrid-cert-new-install.md

@@ -1,138 +0,0 @@
----
-title: Hybrid Azure AD joined Windows Hello for Business Trust New Installation (Windows Hello for Business)
-description: Learn about new installations for Windows Hello for Business certificate trust and the various technologies hybrid certificate trust deployments rely on.
-ms.date: 4/30/2021
-appliesto: 
-- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
-ms.topic: article
----
-# Hybrid Azure AD joined Windows Hello for Business Certificate Trust New Installation
-
-[!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
-
-- [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 Azure Device Registration](hello-hybrid-cert-trust-devreg.md) section to prepare your Windows Hello for Business deployment by configuring Azure device registration.
-
-The new installation baseline begins with a basic Active Directory deployment and enterprise PKI.  This document expects you have Active Directory deployed using Windows Server 2008 R2 or later domain controllers.
-
-## Active Directory ##   
-
-Production environments should follow Active Directory best practices regarding the number and placement of domain controllers to ensure adequate authentication throughout the organization.
-  
-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"]
-> * Minimum Windows Server 2008 R2 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.  The certificate trust model extends certificate issuance to client computers.  During Windows Hello for Business provisioning, the user receives a sign-in certificate.
-
-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.
-
-For more details about configuring a Windows enterprise public key infrastructure and installing Active Directory Certificate Services, see [Follow the Windows Hello for Business hybrid key trust deployment guide](/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-pki#follow-the-windows-hello-for-business-hybrid-key-trust-deployment-guide) and [Install the Certification Authority](/windows-server/networking/core-network-guide/cncg/server-certs/install-the-certification-authority).
-
-> [!NOTE]
-> Never install a certificate authority on a domain controller in a production environment.
-
-### 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.
-
-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 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.
-
-### Section Review ###
-
-> [!div class="checklist"]
-> *  Minimum Windows Server 2012 Certificate Authority.
-> *  Enterprise Certificate Authority.
-> *  Functioning public key infrastructure.
-  
-## 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 multi-factor authentication during provisioning and during user initiated PIN reset scenarios, such as when a user forgets their PIN.  There are two preferred multi-factor authentication configurations with hybrid deployments—Azure MFA and AD FS using Azure MFA
-
-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. 
-
-#### Azure MFA Provider #### 
-If your organization uses Azure MFA on a per-consumption model (no licenses), then review the [Create a Multifactor Authentication Provider](/azure/multi-factor-authentication/multi-factor-authentication-get-started-auth-provider) section to create an Azure MFA Authentication provider and associate it with your Azure tenant. 
-
-#### Configure Azure MFA Settings ####
-Once you have created your Azure MFA authentication provider and associated it with an Azure tenant, you need to configure the multi-factor authentication 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 configure [User States](/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 2016 ###
-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 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 2016 Active Directory Federation Services, if necessary.
-
-> [!div class="nextstepaction"]
-> [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md)
-
-<br><br>
-
-<hr>
-
-## Follow the Windows Hello for Business hybrid certificate trust deployment guide
-1. [Overview](hello-hybrid-cert-trust.md)
-2. [Prerequisites](hello-hybrid-cert-trust-prereqs.md)
-3. New Installation Baseline (*You are here*)
-4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md)
-5. [Configure Windows Hello for Business settings](hello-hybrid-cert-whfb-settings.md)
-6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md)

windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-devreg.md

@@ -1,553 +0,0 @@
----
-title: Configure Device Registration for Hybrid Azure AD joined Windows Hello for Business
-description: Azure Device Registration for Hybrid Certificate Trust Deployment (Windows Hello for Business)
-ms.date: 4/30/2021
-appliesto: 
-- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
-ms.topic: article
----
-# Configure Device Registration for Hybrid Azure AD joined Windows Hello for Business
-
-[!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.  
-
-> [!IMPORTANT]
-> If your environment is not federated, review the [New Installation baseline](hello-hybrid-cert-new-install.md) section of this deployment document to learn how to federate your environment for your Windows Hello for Business deployment. 
-
->[!TIP]
->Refer to the [Tutorial: Configure hybrid Azure Active Directory join for federated domains](/azure/active-directory/devices/hybrid-azuread-join-federated-domains) to learn more about setting up Azure Active Directory Connect for a simplified join flow for Azure AD device registration.
-
-Use this three-phased approach for configuring device registration.
-
-1. [Configure devices to register in Azure](#configure-hybrid-azure-ad-join)
-2. [Synchronize devices to on-premises Active Directory](#configure-active-directory-to-support-azure-device-synchronization)
-3. [Configure AD FS to use cloud devices](#configure-ad-fs-to-use-azure-registered-devices)
-
-> [!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 [Introduction to Device Management in Azure Active Directory.](/azure/active-directory/device-management-introduction)
-
->[!IMPORTANT]
-> To use hybrid identity with Azure Active Directory and device WriteBack features, you must use the built-in GUI with the [latest updates for ADConnect](https://www.microsoft.com/download/details.aspx?id=47594).
-
-## Configure Hybrid Azure AD join
-
-To support hybrid Windows Hello for Business, configure hybrid Azure AD join.
-
-Follow the guidance on [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.
-
-## Configure Active Directory to support Azure device synchronization
-
-Azure Active Directory is now configured for device registration. Next, you need to configure the on-premises Active Directory to support synchronizing hybrid Azure AD-joined devices. Begin with upgrading the Active Directory Schema 
-
-### Upgrading Active Directory to the Windows Server 2016 or later Schema 
-
-To use Windows Hello for Business with Hybrid Azure AD-joined devices, you must first upgrade your Active Directory schema to Windows Server 2016 or later.
-
-> [!IMPORTANT]
-> If you already have a Windows Server 2016 or later domain controller in your forest, you can skip **Upgrading Active Directory to the Windows Server 2016 or later Schema** (this section).
-
-#### Identify the schema role domain controller
-
-To locate the schema master role holder, open and command prompt and type:
-
-```Netdom query fsmo | findstr -i schema```
-
-![Netdom example output.](images/hello-cmd-netdom.png)
-
-The command should return the name of the domain controller where you need to run adprep.exe.  Update the schema locally on the domain controller hosting the Schema master role.
-
-#### Updating the Schema
-
-Windows Hello for Business uses asymmetric keys as user credentials (rather than passwords).  During enrollment, the public key is registered in an attribute on the user object in Active Directory.  The schema update adds this new attribute to Active Directory.  
-
-Manually updating Active Directory uses the command-line utility **adprep.exe** located at **\<drive>:\support\adprep** on the Windows Server 2016 or later DVD or ISO.  Before running adprep.exe, you must identify the domain controller hosting the schema master role.
-
-Sign-in to the domain controller hosting the schema master operational role using enterprise administrator equivalent credentials.
-
-1. Open an elevated command prompt.
-2. Type ```cd /d x:\support\adprep``` where *x* is the drive letter of the DVD or mounted ISO.
-3. To update the schema, type ```adprep /forestprep```.
-4. Read the Adprep Warning.  Type the letter **C*** and press **Enter** to update the schema.
-5. Close the Command Prompt and sign out.
-
-> [!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.
-
-### Setup Active Directory Federation Services
-
-If you're new to AD FS and federation services, you should review [Understanding Key AD FS Concepts](/windows-server/identity/ad-fs/technical-reference/understanding-key-ad-fs-concepts) to prior to designing and deploying your federation service.
-Review the [AD FS Design guide](/windows-server/identity/ad-fs/design/ad-fs-design-guide-in-windows-server-2012-r2) to plan your federation service.
-
-Once you have your AD FS design ready, review [Deploying a Federation Server farm](/windows-server/identity/ad-fs/deployment/deploying-a-federation-server-farm) to configure AD FS in your environment.
-> [!IMPORTANT]
-> During your AD FS deployment, skip the **Configure a federation server with Device Registration Service** and the **Configure Corporate DNS for the Federation Service and DRS** procedures.
-
-The AD FS farm used with Windows Hello for Business must be Windows Server 2016 with minimum update of [KB4088889 (14393.2155)](https://support.microsoft.com/help/4088889).  If your AD FS farm is not running the AD FS role with updates from Windows Server 2016, then read [Upgrading to AD FS in Windows Server 2016](/windows-server/identity/ad-fs/deployment/upgrading-to-ad-fs-in-windows-server-2016)
-
-#### ADFS Web Proxy ###
-
-Federation server proxies are computers that run AD FS software that have been configured manually to act in the proxy role. You can use federation server proxies in your organization to provide intermediary services between an Internet client and a federation server that is behind a firewall on your corporate network.
-Use the [Setting of a Federation Proxy](/windows-server/identity/ad-fs/deployment/checklist--setting-up-a-federation-server-proxy) checklist to configure AD FS proxy servers in your environment.
-
-### 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).
-
-When you're ready to install, follow the **Configuring federation with AD FS** section of [Custom installation of Azure AD Connect](/azure/active-directory/connect/active-directory-aadconnect-get-started-custom).  Select the **Federation with AD FS** option on the **User sign-in** page.  At the **AD FS Farm** page, select the use an existing option and click **Next**.  
-
-### Create AD objects for AD FS Device Authentication
-
-If your AD FS farm isn't already configured for Device Authentication (you can see this in the AD FS Management console under Service -> Device Registration), use the following steps to create the correct AD DS objects and configuration.
-![Device Registration: AD FS](images/hybridct/device1.png)
-
-> [!NOTE]
-> The below commands require Active Directory administration tools, so if your federation server is not also a domain controller, first install the tools using step 1 below.  Otherwise you can skip step 1.  
-
-1. Run the **Add Roles & Features** wizard and select feature **Remote Server Administration Tools** -> **Role Administration Tools** -> **AD DS and AD LDS Tools** -> Choose both the **Active Directory module for Windows PowerShell** and the **AD DS Tools**.
-    ![Device Registration: Overview](images/hybridct/device2.png)
-2. On your AD FS primary server, ensure you're logged in as AD DS user with enterprise administrator privileges and open an elevated Windows PowerShell prompt.  Then, run the following commands:  
-   `Import-module activedirectory`  
-   `PS C:\> Initialize-ADDeviceRegistration -ServiceAccountName "<your service account>"` 
-3. On the pop-up window, click **Yes**.
-
-   > [!NOTE]
-   > If your AD FS service is configured to use a GMSA account, enter the account name in the format "domain\accountname$"
-
-   ![Device Registration: Domain](images/hybridct/device3.png)  
-   The above PSH creates the following objects:  
-
-   - RegisteredDevices container under the AD domain partition  
-   - Device Registration Service container and object under Configuration --> Services --> Device Registration Configuration  
-   - Device Registration Service DKM container and object under Configuration --> Services --> Device Registration Configuration  
-
-   ![Device Registration: Tests](images/hybridct/device4.png) <br>
-4. Once this is done, you'll see a successful completion message.
-
-   ![Device Registration: Completion](images/hybridct/device5.png) 
-
-### Create Service Connection Point (SCP) in Active Directory  
-If you plan to use Windows domain join (with automatic registration to Azure AD) as described here, execute the following commands to create a service connection point in AD DS  
-
-1. Open Windows PowerShell and execute the following:
-
-    `PS C:>Import-Module -Name "C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1"` 
-
-   > [!NOTE]
-   > If necessary, copy the AdSyncPrep.psm1 file from your Azure AD Connect server.  This file is located in Program Files\Microsoft Azure Active Directory Connect\AdPrep
-
-   ![Device Registration AdPrep](images/hybridct/device6.png)
-2. Provide your Azure AD global administrator credentials  
-
-   `PS C:>$aadAdminCred = Get-Credential`
-
-   ![Device Registration: Credential](images/hybridct/device7.png) 
-3. Run the following PowerShell command 
-
-   `PS C:>Initialize-ADSyncDomainJoinedComputerSync -AdConnectorAccount [AD connector account name] -AzureADCredentials $aadAdminCred` 
-
-   Where the [AD connector account name] is the name of the account you configured in Azure AD Connect when adding your on-premises AD DS directory.
-
-The above commands enable Windows clients to find the correct Azure AD domain to join by creating the serviceConnectionpoint object in AD DS.  
-
-### Prepare AD for Device Write Back   
-To ensure AD DS objects and containers are in the correct state for write back of devices from Azure AD, do the following.
-
-1. Open Windows PowerShell and execute the following:  
-
-    `PS C:>Initialize-ADSyncDeviceWriteBack -DomainName <AD DS domain name> -AdConnectorAccount [AD connector account name]` 
-
-   Where the [AD connector account name] is the name of the account you configured in Azure AD Connect when adding your on-premises AD DS directory in domain\accountname format  
-
-The above command creates the following objects for device write back to AD DS, if they don't exist already, and allows access to the specified AD connector account name  
-
-- RegisteredDevices container in the AD domain partition  
-- Device Registration Service container and object under Configuration --> Services --> Device Registration Configuration  
-
-### Enable Device Write Back in Azure AD Connect
-
-If you haven't done so before, enable device write back in Azure AD Connect by running the wizard a second time and selecting **"Customize Synchronization Options"**, then checking the box for device write back and selecting the forest in which you have run the above cmdlets  
-
-## Configure AD FS to use Azure registered devices
-
-### Configure issuance of claims
-
-In a federated Azure AD configuration, devices rely on Active Directory Federation Services (AD FS) or a third party on-premises federation service to authenticate to Azure AD. Devices authenticate to get an access token to register against the Azure Active Directory Device Registration Service (Azure DRS).
-
-Windows current devices authenticate using Integrated Windows Authentication to an active WS-Trust endpoint (either 1.3 or 2005 versions) hosted by the on-premises federation service.
-
-When you're using AD FS, you need to enable the following WS-Trust endpoints:
-`/adfs/services/trust/2005/windowstransport` 
-`/adfs/services/trust/13/windowstransport` 
-`/adfs/services/trust/2005/usernamemixed`
-`/adfs/services/trust/13/usernamemixed`
-`/adfs/services/trust/2005/certificatemixed`
-`/adfs/services/trust/13/certificatemixed`
-
-> [!WARNING]
-> Both **adfs/services/trust/2005/windowstransport** and **adfs/services/trust/13/windowstransport** should be enabled as intranet facing endpoints only and must NOT be exposed as extranet facing endpoints through the Web Application Proxy. To learn more on how to disable WS-Trust Windows endpoints, see [Disable WS-Trust Windows endpoints on the proxy](/windows-server/identity/ad-fs/deployment/best-practices-securing-ad-fs#disable-ws-trust-windows-endpoints-on-the-proxy-ie-from-extranet). You can see what endpoints are enabled through the AD FS management console under **Service** > **Endpoints**.
-
-> [!NOTE]
->If you don’t have AD FS as your on-premises federation service, follow the instructions from your vendor to make sure they support WS-Trust 1.3 or 2005 endpoints and that these are published through the Metadata Exchange file (MEX).
-
-The following claims must exist in the token received by Azure DRS for device registration to complete. Azure DRS will create a device object in Azure AD with some of this information that is then used by Azure AD Connect to associate the newly created device object with the computer account on-premises.
-
-- `http://schemas.microsoft.com/ws/2012/01/accounttype`
-- `http://schemas.microsoft.com/identity/claims/onpremobjectguid`
-- `http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid`
-
-If you've more than one verified domain name, you need to provide the following claim for computers:
-
-- `http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid`
-
-If you're already issuing an ImmutableID claim (for example, alternate sign in ID) you need to provide one corresponding claim for computers:
-
-- `http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID`
-
-In the following sections, you find information about:
-
-- The values each claim should have
-- How a definition would look like in AD FS
-
-The definition helps you to verify whether the values are present or if you need to create them.
-
-> [!NOTE]
-> If you don't use AD FS for your on-premises federation server, follow your vendor's instructions to create the appropriate configuration to issue these claims.
-
-#### Issue account type claim
-
-**`http://schemas.microsoft.com/ws/2012/01/accounttype`** - This claim must contain a value of **DJ**, which identifies the device as a domain-joined computer. In AD FS, you can add an issuance transform rule that looks like this:
-
-```powershell
-
-    @RuleName = "Issue account type for domain-joined computers"
-    c:[
-        Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
-        Value =~ "-515$", 
-        Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
-    ]
-    => issue(
-        Type = "http://schemas.microsoft.com/ws/2012/01/accounttype", 
-        Value = "DJ"
-    );
-```
-
-#### Issue objectGUID of the computer account on-premises
-
-**`http://schemas.microsoft.com/identity/claims/onpremobjectguid`** - This claim must contain the **objectGUID** value of the on-premises computer account. In AD FS, you can add an issuance transform rule that looks like this:
-
-```powershell
-
-    @RuleName = "Issue object GUID for domain-joined computers"
-    c1:[
-        Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
-        Value =~ "-515$", 
-        Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
-    ]
-    && 
-    c2:[
-        Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", 
-        Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
-    ]
-    => issue(
-        store = "Active Directory", 
-        types = ("http://schemas.microsoft.com/identity/claims/onpremobjectguid"), 
-        query = ";objectguid;{0}", 
-        param = c2.Value
-    );
-```
-
-#### Issue objectSID of the computer account on-premises
-
-**`http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid`** - This claim must contain the **objectSid** value of the on-premises computer account. In AD FS, you can add an issuance transform rule that looks like this:
-
-```powershell
-
-    @RuleName = "Issue objectSID for domain-joined computers"
-    c1:[
-        Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
-        Value =~ "-515$", 
-        Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
-    ]
-    && 
-    c2:[
-        Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid", 
-        Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
-    ]
-    => issue(claim = c2);
-```
-
-#### Issue issuerID for computer when multiple verified domain names in Azure AD
-
-**`http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid`** - This claim must contain the Uniform Resource Identifier (URI) of any of the verified domain names that connect with the on-premises federation service (AD FS or third party) issuing the token. In AD FS, you can add issuance transform rules that look like the ones below in that specific order after the ones above. Note that one rule to explicitly issue the rule for users is necessary. In the rules below, a first rule identifying user vs. computer authentication is added.
-
-```powershell
-
-    @RuleName = "Issue account type with the value User when it is not a computer"
-
-    NOT EXISTS(
-    [
-        Type == "http://schemas.microsoft.com/ws/2012/01/accounttype", 
-        Value == "DJ"
-    ]
-    )
-    => add(
-        Type = "http://schemas.microsoft.com/ws/2012/01/accounttype", 
-        Value = "User"
-    );
-
-    @RuleName = "Capture UPN when AccountType is User and issue the IssuerID"
-    c1:[
-        Type == "http://schemas.xmlsoap.org/claims/UPN"
-    ]
-    && 
-    c2:[
-        Type == "http://schemas.microsoft.com/ws/2012/01/accounttype", 
-        Value == "User"
-    ]
-    => issue(
-        Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", 
-        Value = regexreplace(
-        c1.Value, 
-        ".+@(?<domain>.+)", 
-        "http://${domain}/adfs/services/trust/"
-        )
-    );
-
-    @RuleName = "Issue issuerID for domain-joined computers"
-    c:[
-        Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
-        Value =~ "-515$", 
-        Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
-    ]
-    => issue(
-        Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", 
-        Value = "http://<verified-domain-name>/adfs/services/trust/"
-    );
-```
-
-In the claim above,
-
-- `$<domain>` is the AD FS service URL
-- `<verified-domain-name>` is a placeholder you need to replace with one of your verified domain names in Azure AD
-
-For more information about verified domain names, see [Add a custom domain name to Azure Active Directory](/azure/active-directory/active-directory-add-domain).  
-To get a list of your verified company domains, you can use the [Get-MsolDomain](/powershell/module/msonline/get-msoldomain?view=azureadps-1.0&preserve-view=true) cmdlet.
-
-#### Issue ImmutableID for computer when one for users exist (for example, alternate login ID is set)
-
-**`http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID`** - This claim must contain a valid value for computers. In AD FS, you can create an issuance transform rule as follows:
-
-```powershell
-
-    @RuleName = "Issue ImmutableID for computers"
-    c1:[
-        Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
-        Value =~ "-515$", 
-        Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
-    ] 
-    && 
-    c2:[
-        Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", 
-        Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
-    ]
-    => issue(
-        store = "Active Directory", 
-        types = ("http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"), 
-        query = ";objectguid;{0}", 
-        param = c2.Value
-    );
-```
-
-#### Helper script to create the AD FS issuance transform rules
-
-The following script helps you with the creation of the issuance transform rules described above.
-
-```powershell
-
-    $multipleVerifiedDomainNames = $false
-    $immutableIDAlreadyIssuedforUsers = $false
-    $oneOfVerifiedDomainNames = 'example.com'   # Replace example.com with one of your verified domains
-
-    $rule1 = '@RuleName = "Issue account type for domain-joined computers"
-    c:[
-        Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
-        Value =~ "-515$", 
-        Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
-    ]
-    => issue(
-        Type = "http://schemas.microsoft.com/ws/2012/01/accounttype", 
-        Value = "DJ"
-    );'
-
-    $rule2 = '@RuleName = "Issue object GUID for domain-joined computers"
-    c1:[
-        Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
-        Value =~ "-515$", 
-        Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
-    ]
-    && 
-    c2:[
-        Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", 
-        Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
-    ]
-    => issue(
-        store = "Active Directory", 
-        types = ("http://schemas.microsoft.com/identity/claims/onpremobjectguid"), 
-        query = ";objectguid;{0}", 
-        param = c2.Value
-    );'
-
-    $rule3 = '@RuleName = "Issue objectSID for domain-joined computers"
-    c1:[
-        Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
-        Value =~ "-515$", 
-        Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
-    ]
-    && 
-    c2:[
-        Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid", 
-        Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
-    ]
-    => issue(claim = c2);'
-
-    $rule4 = ''
-    if ($multipleVerifiedDomainNames -eq $true) {
-    $rule4 = '@RuleName = "Issue account type with the value User when it is not a computer"
-    NOT EXISTS(
-    [
-        Type == "http://schemas.microsoft.com/ws/2012/01/accounttype", 
-        Value == "DJ"
-    ]
-    )
-    => add(
-        Type = "http://schemas.microsoft.com/ws/2012/01/accounttype", 
-        Value = "User"
-    );
-
-    @RuleName = "Capture UPN when AccountType is User and issue the IssuerID"
-    c1:[
-        Type == "http://schemas.xmlsoap.org/claims/UPN"
-    ]
-    && 
-    c2:[
-        Type == "http://schemas.microsoft.com/ws/2012/01/accounttype", 
-        Value == "User"
-    ]
-    => issue(
-        Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", 
-        Value = regexreplace(
-        c1.Value, 
-        ".+@(?<domain>.+)", 
-        "http://${domain}/adfs/services/trust/"
-        )
-    );
-
-    @RuleName = "Issue issuerID for domain-joined computers"
-    c:[
-        Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
-        Value =~ "-515$", 
-        Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
-    ]
-    => issue(
-        Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", 
-        Value = "http://' + $oneOfVerifiedDomainNames + '/adfs/services/trust/"
-    );'
-    }
-
-    $rule5 = ''
-    if ($immutableIDAlreadyIssuedforUsers -eq $true) {
-    $rule5 = '@RuleName = "Issue ImmutableID for computers"
-    c1:[
-        Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
-        Value =~ "-515$", 
-        Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
-    ] 
-    && 
-    c2:[
-        Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", 
-        Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
-    ]
-    => issue(
-        store = "Active Directory", 
-        types = ("http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"), 
-        query = ";objectguid;{0}", 
-        param = c2.Value
-    );'
-    }
-
-    $existingRules = (Get-ADFSRelyingPartyTrust -Identifier urn:federation:MicrosoftOnline).IssuanceTransformRules 
-
-    $updatedRules = $existingRules + $rule1 + $rule2 + $rule3 + $rule4 + $rule5
-
-    $crSet = New-ADFSClaimRuleSet -ClaimRule $updatedRules 
-
-    Set-AdfsRelyingPartyTrust -TargetIdentifier urn:federation:MicrosoftOnline -IssuanceTransformRules $crSet.ClaimRulesString 
-```
-
-#### Remarks
-
-- This script appends the rules to the existing rules. Don't run the script twice because the set of rules would be added twice. Make sure that no corresponding rules exist for these claims (under the corresponding conditions) before running the script again.
-
-- If you have multiple verified domain names (as shown in the Azure AD portal or via the Get-MsolDomains cmdlet), set the value of **$multipleVerifiedDomainNames** in the script to **$true**. Also make sure that you remove any existing issuerid claim that might have been created by Azure AD Connect or via other means. Here's an example for this rule:
-
-  ```Claims Rule Language
-    c:[Type == "http://schemas.xmlsoap.org/claims/UPN"]
-    => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value = regexreplace(c.Value, ".+@(?<domain>.+)",  "http://${domain}/adfs/services/trust/")); 
-  ```
-
-- If you've already issued an **ImmutableID** claim  for user accounts, set the value of **$immutableIDAlreadyIssuedforUsers** in the script to **$true**.
-
-#### Configure Device Authentication in AD FS 
-
-Using an elevated PowerShell command window, configure AD FS policy by executing the following command  
-
-`PS C:>Set-AdfsGlobalAuthenticationPolicy -DeviceAuthenticationEnabled $true -DeviceAuthenticationMethod SignedToken` 
-
-#### Check your configuration
-
-For your reference, below is a comprehensive list of the AD DS devices, containers and permissions required for device write-back and authentication to work
-
-- object of type ms-DS-DeviceContainer at CN=RegisteredDevices,DC=&lt;domain&gt;        
-    - read access to the AD FS service account   
-    - read/write access to the Azure AD Connect sync AD connector account
-- Container CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=&lt;domain&gt;
-- Container Device Registration Service DKM under the above container
-
-   ![Device Registration: Container](images/hybridct/device8.png) 
-
-- object of type serviceConnectionpoint at CN=&lt;guid&gt;, CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=&lt;domain&gt;  
-  - read/write access to the specified AD connector account name on the new object 
-- object of type msDS-DeviceRegistrationServiceContainer at CN=Device Registration Services,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=&lt;domain&gt;
-- object of type msDS-DeviceRegistrationService in the above container
-
-> [!div class="nextstepaction"]
-> [Configure Windows Hello for Business settings](hello-hybrid-cert-whfb-settings.md)
-
-<br>
-<hr>
-
-## Follow the Windows Hello for Business hybrid certificate trust deployment guide
-
-1. [Overview](hello-hybrid-cert-trust.md)
-2. [Prerequisites](hello-hybrid-cert-trust-prereqs.md)
-3. [New Installation Baseline](hello-hybrid-cert-new-install.md)
-4. Configure Azure Device Registration (*You are here*)
-5. [Configure Windows Hello for Business settings](hello-hybrid-cert-whfb-settings.md)
-6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md)

windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-prereqs.md

@@ -1,157 +0,0 @@
----
-title: Hybrid Azure AD joined Windows Hello for Business Prerequisites
-description: Learn these prerequisites for hybrid Windows Hello for Business deployments using certificate trust.
-ms.date: 4/30/2021
-appliesto: 
-- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
-ms.topic: article
----
-# Hybrid Azure AD joined Windows Hello for Business Prerequisites
-
-[!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.
-
-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:
-
-- [Directories](#directories)
-- [Public Key Infrastructure](#public-key-infrastructure)
-- [Directory Synchronization](#directory-synchronization)
-- [Federation](#federation)
-- [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.  The minimum required domain controller, domain functional level, and forest functional level for Windows Hello for Business deployment is Windows Server 2008 R2.
-
-A hybrid Windows Hello for Business deployment needs an Azure Active Directory subscription.  Different deployment configurations are supported by different Azure subscriptions.  The hybrid-certificate trust deployment needs an Azure Active Directory premium subscription because it uses the device write-back synchronization feature.  Other deployments, such as the hybrid key-trust deployment, may not require Azure Active Directory premium subscription.
-
-Windows Hello for Business can be deployed in any environment with Windows Server 2012 or later domain controllers.  Azure device registration and Windows Hello for Business require the Windows Server 2016 Active Directory or later schema.
-
-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
-> * Windows Server 2016 or later Schema 
-> * Azure Active Directory subscription
-> * Correct subscription for desired features and outcomes  
-
-<br>
-
-## 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.
-
-Certificate trust deployments need an enterprise public key infrastructure and a certificate registration authority to issue authentication certificates to users.  When using Group Policy, hybrid certificate trust deployment uses the Windows Server 2016 Active Directory Federation Server (AD FS) as a certificate registration authority.
-
-The minimum required enterprise certificate authority that can be used with Windows Hello for Business is Windows Server 2012.
-
-### Section Review
-
-> [!div class="checklist"]  
-> * Windows Server 2012 Issuing Certificate Authority
-> * Windows Server 2016 Active Directory Federation Services
-
-<br>
-
-## 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.
-  
-Organizations using older directory synchronization technology, such as DirSync or Azure AD sync, need to upgrade to Azure AD Connect. In case the schema of your local AD DS was changed since the last directory synchronization, you may need to [refresh directory schema](/azure/active-directory/hybrid/how-to-connect-installation-wizard#refresh-directory-schema).
-
-> [!NOTE]
-> User accounts enrolling for Windows Hello for Business in a Hybrid Certificate Trust scenario must have a UPN matching a verified domain name in Azure AD. For more details, see [Troubleshoot Post-Join issues](/azure/active-directory/devices/troubleshoot-hybrid-join-windows-current#troubleshoot-post-join-issues).
-
-> [!NOTE]
-> Windows Hello for Business is tied between a user and a device. Both the user and device need to be synchronized between Azure Active Directory and Active Directory.
-
-### Section Review
-
-> [!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)
-
-<br>
-
-## Federation ##
-
-Windows Hello for Business hybrid certificate trust requires Active Directory being federated with Azure Active Directory and needs Windows Server 2016 Active Directory Federation Services or newer. Windows Hello for Business hybrid certificate trust doesn’t support Managed Azure Active Directory using Pass-through authentication or password hash sync. All nodes in the AD FS farm must run the same version of AD FS. Additionally, you need to configure your AD FS farm to support Azure registered devices.
-
-The AD FS farm used with Windows Hello for Business must be Windows Server 2016 with minimum update of [KB4088889 (14393.2155)](https://support.microsoft.com/help/4088889).  If your AD FS farm is not running the AD FS role with updates from Windows Server 2016, then read [Upgrading to AD FS in Windows Server 2016](/windows-server/identity/ad-fs/deployment/upgrading-to-ad-fs-in-windows-server-2016)
-
-### Section Review ###
-
-> [!div class="checklist"]
-> * Windows Server 2016 Active Directory Federation Services
-> * Minimum update of [KB4088889 (14393.2155)](https://support.microsoft.com/help/4088889)
-
-<br>
-
-## 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 username and password as one factor. but needs a second factor of authentication.
-
-Hybrid Windows Hello for Business deployments can use Azure’s Multifactor Authentication service, or they can use multifactor authentication provides by Windows Server 2016 Active Directory Federation Services, which includes an adapter model that enables third parties to integrate their multifactor authentication into AD FS.
-
-### Section Review
-
-> [!div class="checklist"]
-> * Azure MFA Service
-> * Windows Server 2016 AD FS and Azure
-> * Windows Server 2016 AD FS and third party MFA Adapter
-
-<br>
-
-## Device Registration ##
-
-Organizations wanting to deploy hybrid certificate 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. 
- 
-Hybrid certificate trust deployments need the device write back feature.  Authentication to the Windows Server 2016 Active Directory Federation Services needs both the user and the computer to authenticate. Typically the users are synchronized, but not devices.  This prevents AD FS from authenticating the computer and results in Windows Hello for Business certificate enrollment failures.  For this reason, Windows Hello for Business deployments need device writeback, which is an Azure Active Directory premium feature.
-
-> [!NOTE]
-> Windows Hello for Business is tied between a user and a device. Both the user and device need to be synchronized between Azure Active Directory and Active Directory, and therefore the device writeback is used to update the msDS-KeyCredentialLink on the computer object.
-
-## 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 ###
-
-> [!div class="checklist"]
-> * Azure Active Directory Device writeback
-> * Azure Active Directory Premium subscription
-
-<br>
-
-### Next Steps ###
-Follow the Windows Hello for Business hybrid certificate trust deployment guide.  For proof-of-concepts, labs, and new installations, choose the **New Installation Baseline**.  
-
-If your environment is already federated, but does not include Azure device registration, choose **Configure Azure Device Registration**. 
-
-If your environment is already federated and supports Azure device registration, choose **Configure Windows Hello for Business settings**.
-
-> [!div class="op_single_selector"]
-> - [New Installation Baseline](hello-hybrid-cert-new-install.md)
-> - [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md)
-> - [Configure Windows Hello for Business settings](hello-hybrid-cert-whfb-settings.md)
-
-<br><br>
-
-<hr>
-
-## Follow the Windows Hello for Business hybrid certificate trust deployment guide
-
-1. [Overview](hello-hybrid-cert-trust.md)
-2. Prerequisites (*You are here*)
-3. [New Installation Baseline](hello-hybrid-cert-new-install.md)
-4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md)
-5. [Configure Windows Hello for Business settings](hello-hybrid-cert-whfb-settings.md)
-6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md)

windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-validate-pki.md

@@ -0,0 +1,82 @@
+---
+title: Configure and validate the Public Key Infrastructure in an hybrid certificate trust model
+description: Configure and validate the Public Key Infrastructure when deploying Windows Hello for Business in a hybrid certificate trust model.
+ms.date: 01/03/2023
+appliesto: 
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
+ms.topic: tutorial
+---
+# Configure and validate the Public Key Infrastructure - hybrid certificate trust
+
+[!INCLUDE [hello-hybrid-cert-trust](./includes/hello-hybrid-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.
+
+Hybrid certificate trust deployments issue users a sign-in certificate, enabling them to authenticate to Active Directory using Windows Hello for Business credentials. Additionally, hybrid certificate trust deployments issue certificates to registration authorities to provide defense-in-depth security when issuing user authentication certificates.
+
+[!INCLUDE [lab-based-pki-deploy](includes/lab-based-pki-deploy.md)]
+
+## Configure the enterprise PKI
+
+[!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.
+
+> [!IMPORTANT]
+> 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
+
+[!INCLUDE [dc-certificate-template-supersede](includes/dc-certificate-supersede.md)]
+
+[!INCLUDE [enrollment-agent-certificate-template](includes/enrollment-agent-certificate-template.md)]
+
+[!INCLUDE [auth-certificate-template](includes/auth-certificate-template.md)]
+
+[!INCLUDE [unpublish-superseded-templates](includes/unpublish-superseded-templates.md)]
+
+### Publish the 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)*, *WHFB Enrollment Agent*  and *WHFB Authentication* templates you created in the previous steps > select **OK**
+1. Close the console
+
+> [!IMPORTANT]
+> If you plan to deploy **Azure AD joined** devices, and require single sign-on (SSO) to on-premises resources when signing in with Windows Hello for Business, follow the procedures to [update your CA to include an http-based CRL distribution point](hello-hybrid-aadj-sso.md).
+
+## Configure and deploy certificates to domain controllers
+
+[!INCLUDE [dc-certificate-deployment](includes/dc-certificate-deployment.md)]
+
+## Validate the configuration
+
+[!INCLUDE [dc-certificate-validate](includes/dc-certificate-validate.md)]
+
+## Section review and next steps
+
+Before moving to the next section, ensure the following steps are complete:
+
+> [!div class="checklist"]
+> - Configure domain controller certificates
+> - Supersede existing domain controller certificates
+> - Unpublish superseded certificate templates
+> - Configure an enrollment agent certificate template
+> - Configure an authentication certificate template
+> - Publish the certificate templates to the CA
+> - Deploy certificates to the domain controllers
+> - Validate the domain controllers configuration
+
+> [!div class="nextstepaction"]
+> [Next: configure AD FS >](hello-hybrid-cert-whfb-settings-adfs.md)
+
+<!--links-->
+[SERV-1]: /troubleshoot/windows-server/windows-security/requirements-domain-controller

windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust.md

@@ -1,45 +1,132 @@
 ---
-title: Hybrid Certificate Trust Deployment (Windows Hello for Business)
+title: Windows Hello for Business hybrid certificate trust deployment
-description: Learn the information you need to successfully deploy Windows Hello for Business in a hybrid certificate trust scenario.
+description: Learn how to deploy Windows Hello for Business in a hybrid certificate trust scenario.
-ms.date: 09/08/2017
+ms.date: 12/28/2022
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
-ms.topic: article
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
+ms.topic: how-to
 ---
-# Hybrid Azure AD joined Certificate Trust Deployment
 
-[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-cert-trust.md)]
+# Hybrid certificate trust deployment
 
-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.
+[!INCLUDE [hello-hybrid-cert-trust](./includes/hello-hybrid-cert-trust.md)]
 
-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-protected 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.
+This deployment guide describes how to deploy Windows Hello for Business in a hybrid certificate trust scenario.
 
-## New Deployment Baseline
+> [!IMPORTANT]
+> Windows Hello for Business *cloud Kerberos trust* is the recommended deployment model when compared to the *key trust model*. It is also the recommended deployment model if you don't need to deploy certificates to the end users. For more information, see [cloud Kerberos trust deployment](hello-hybrid-cloud-kerberos-trust.md).
 
-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.
+It is recommended that you review the [Windows Hello for Business planning guide](hello-planning-guide.md) 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.
 
-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.
+## Prerequisites
+The following prerequisites must be met for a hybrid certificate trust deployment:
 
-## Federated Baseline
+> [!div class="checklist"]
+> * Directories and directory synchronization
+> * Federated authentication to Azure AD
+> * Device registration
+> * Public Key Infrastructure
+> * Multi-factor authentication
+> * Device management
 
-The federated baseline helps organizations that have completed their federation with Azure Active Directory and enables them to introduce Windows Hello for Business into their hybrid environment.  This baseline exclusively focuses on the procedures needed to add Azure Device Registration and Windows Hello for Business to an existing hybrid deployment.
+### Directories and directory synchronization
 
-Regardless of the baseline you choose, 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.
+Hybrid Windows Hello for Business needs two directories:
+
+- An on-premises Active Directory
+- An Azure Active Directory tenant with an Azure AD Premium subscription
+
+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.
+The hybrid-certificate trust deployment needs an *Azure Active Directory Premium* subscription because it uses the device write-back synchronization feature.
+
+> [!NOTE]
+> Windows Hello for Business hybrid certificate trust is not supported if the users' on-premises UPN suffix cannot be added as a verified domain in Azure AD.
+
+> [!IMPORTANT]
+> Windows Hello for Business is tied between a user and a device. Both the user and device object must be synchronized between Azure Active Directory and Active Directory.
+
+### Federated authentication to Azure AD
+
+Windows Hello for Business hybrid certificate trust doesn't support Azure AD *Pass-through Authentication* (PTA) or *password hash sync* (PHS).\
+Windows Hello for Business hybrid certificate trust requires Active Directory to be federated with Azure Active Directory using AD FS. Additionally, you need to configure your AD FS farm to support Azure registered devices.
+
+If you're new to AD FS and federation services:
+
+- Review [key AD FS concepts][SER-3] prior to deploying the AD FS farm
+- Review the [AD FS design guide][SER-4] to design and plan your federation service
+
+Once you have your AD FS design ready:
+
+- Review [deploying a federation server farm][SER-2] to configure AD FS in your environment
+
+The AD FS farm used with Windows Hello for Business must be Windows Server 2016 with minimum update of [KB4088889 (14393.2155)](https://support.microsoft.com/help/4088889).
+
+### Device registration
+
+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.
+
+Hybrid certificate trust deployments need the device write back feature. Authentication to AD FS needs both the user and the computer to authenticate. Typically the users are synchronized, but not devices. This prevents AD FS from authenticating the computer and results in Windows Hello for Business certificate enrollment failures. For this reason, Windows Hello for Business deployments need device write-back.
+
+> [!NOTE]
+> Windows Hello for Business is tied between a user and a device. Both the user and device need to be synchronized between Azure Active Directory and Active Directory. Device write-back is used to update the msDS-KeyCredentialLink attribute on the computer object.
+
+Refer to the [configure hybrid Azure Active Directory join for federated domains][AZ-10] guide to learn more about setting up Azure AD Connect Sync to support Azure AD device registration.
+For a manual configuration of your AD FS farm to support device registration, review the [Configure AD FS for Azure AD device registration][AZ-11] guide.
+
+### Public Key Infrastructure
+
+An enterprise public key infrastructure (PKI) is required as *trust anchor* for authentication. Domain controllers require a certificate for Windows clients to trust them.\
+The enterprise PKI and a certificate registration authority (CRA) are required to issue authentication certificates to users. Hybrid certificate trust deployment uses AD FS as a CRA.
+
+During Windows Hello for Business provisioning, users receive a sign-in certificate through the CRA.
+
+### 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][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][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
+
+To configure Windows Hello for Business, devices can be configured through a mobile device management (MDM) solution like Intune, or via group policy.
+
+## Next steps
+
+Once the prerequisites are met, deploying Windows Hello for Business with a hybrid key trust model consists of the following steps:
+
+> [!div class="checklist"]
+> * Configure and validate the PKI
+> * Configure AD FS
+> * Configure Windows Hello for Business settings
+> * Provision Windows Hello for Business on Windows clients
+> * Configure single sign-on (SSO) for Azure AD joined devices
 
 > [!div class="nextstepaction"]
-> [Prerequisites](hello-hybrid-cert-trust-prereqs.md)
+> [Next: configure and validate the Public Key Infrastructure >](hello-hybrid-cert-trust-validate-pki.md)
 
-<br><br>
+<!--links-->
+[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
+[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
+[AZ-9]: /azure/active-directory/devices/hybrid-azuread-join-federated-domains
+[AZ-10]: /azure/active-directory/devices/howto-hybrid-azure-ad-join#federated-domains
+[AZ-11]: /azure/active-directory/devices/hybrid-azuread-join-manual
 
-<hr>
+[SER-1]: /windows-server/identity/ad-fs/operations/configure-ad-fs-2016-and-azure-mfa
-
+[SER-2]: /windows-server/identity/ad-fs/deployment/deploying-a-federation-server-farm
-## Follow the Windows Hello for Business hybrid certificate trust deployment guide
+[SER-3]: /windows-server/identity/ad-fs/technical-reference/understanding-key-ad-fs-concepts
-
+[SER-4]: /windows-server/identity/ad-fs/design/ad-fs-design-guide-in-windows-server-2012-r2
-1. Overview (*You are here*)
-2. [Prerequisites](hello-hybrid-cert-trust-prereqs.md)
-3. [New Installation Baseline](hello-hybrid-cert-new-install.md)
-4. [Device Registration](hello-hybrid-cert-trust-devreg.md)
-5. [Configure Windows Hello for Business settings](hello-hybrid-cert-whfb-settings.md)
-6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md)

windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-provision.md

@@ -1,43 +1,173 @@
 ---
-title: Hybrid Azure AD joined Windows Hello for Business Certificate Trust Provisioning (Windows Hello for Business)
+title: Windows Hello for Business hybrid certificate trust clients configuration and enrollment
-description: In this article, learn about provisioning for hybrid certificate trust deployments of Windows Hello for Business.
+description: Learn how to configure devices and enroll them in Windows Hello for Business in a hybrid certificate trust scenario.
-ms.date: 4/30/2021
+ms.date: 01/03/2023
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
-ms.topic: article
+ms.topic: tutorial
 ---
-# Hybrid Azure AD joined Windows Hello for Business Certificate Trust Provisioning
 
-[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-cert-trust.md)]
+# Configure and provision Windows Hello for Business - hybrid certificate trust
 
-## Provisioning
+[!INCLUDE [hello-hybrid-certificate-trust](./includes/hello-hybrid-cert-trust.md)]
 
-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**.
+## Policy Configuration
 
-![Event358 from User Device Registration log showing Windows Hello for Business prerequisite check result.](images/Event358.png)
+After the prerequisites are met and the PKI and AD FS configurations are 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).
 
-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**.
+#### [:::image type="icon" source="../../images/icons/group-policy.svg"::: **GPO**](#tab/gpo)
 
-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**.
+> [!IMPORTANT]
+> The information in this section applies to hybrid Azure AD joined devices only.
 
-![Setup a PIN Provisioning.](images/setupapin.png)
+For hybrid Azure AD joined devices, you can use group policies to configure Windows Hello for Business.
+It is suggested to create a security group (for example, *Windows Hello for Business Users*) to make it easy to deploy Windows Hello for Business in phases. You assign the **Group Policy** and **Certificate template permissions** to this group to simplify the deployment by 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 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.
+### Enable Windows Hello for Business group policy setting
-  
-![MFA prompt during provisioning.](images/mfa.png)
 
-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 *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* setting for computer or users:
 
-![Create a PIN during provisioning.](images/createPin.png)
+- Deploying this policy setting to computers (or group of 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 (or group of users), results in only that user attempting a Windows Hello for Business enrollment
 
-The provisioning flow has all the information it needs to complete the Windows Hello for Business enrollment.
+If both user and computer policy settings are deployed, the user policy setting has precedence.
 
-- A successful single factor authentication (username and password at sign-in)
+### Use certificate for on-premises authentication group policy setting
-- 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.  Azure Active Directory Connect synchronizes the user's key to the on-premises Active Directory.
+The *Use certificate for on-premises authentication* group policy setting determines if the deployment uses the *key-trust* or *certificate trust* authentication model. You must configure this Group Policy setting to configure Windows to enroll for a Windows Hello for Business authentication certificate. If you do not configure this policy setting, Windows considers the deployment to use key-trust authentication.
+
+### Enable automatic enrollment of certificates group policy setting
+
+Windows Hello for Business provisioning performs the initial enrollment of the Windows Hello for Business authentication certificate. This certificate expires based on the duration configured in the Windows Hello for Business *authentication certificate* template.
+
+The process requires no user interaction, provided the user signs-in using Windows Hello for Business. The certificate is renewed in the background before it expires.
+
+### Enable and configure Windows Hello for Business
+
+Sign-in a domain controller or management workstations with *Domain Admin* equivalent credentials.
+
+1. Start 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 *Enable Windows Hello for Business* in the name box and select **OK**
+1. In the content pane, right-click the **Enable Windows Hello for Business** group policy object and select **Edit**
+1. In the navigation pane, expand **Policies** under **User Configuration**
+1. Expand **Administrative Templates > Windows Component**, and select **Windows Hello for Business**
+1. In the content pane, open **Use Windows Hello for Business**. Select **Enable > OK**
+1. Open **Use certificate for on-premises authentication**. Select **Enable > OK**
+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 boxes
+1. Select the **Update certificates that use certificate templates** check box
+1. Select **OK**
+1. Close the **Group Policy Management Editor**
+
+> [!NOTE]
+> Windows Hello for Business can be configured using different policies. These policies are optional to configure, but it's recommended to enable *Use a hardware security device*.
+> 
+> For more information about these policies, see [Group Policy settings for Windows Hello for Business](hello-manage-in-organization.md#group-policy-settings-for-windows-hello-for-business).
+
+### Configure security for GPO
+
+The best way to deploy the Windows Hello for Business GPO is to use security group filtering. Only members of the targeted security group will provision Windows Hello for Business, enabling a phased rollout.
+
+1. Start the **Group Policy Management Console** (gpmc.msc)
+1. Expand the domain and select the **Group Policy Object** node in the navigation pane
+1. Open the **Enable Windows Hello for Business** GPO
+1. In the **Security Filtering** section of the content pane, select **Add**.  Type the name of the security group you previously created (for example, *Windows Hello for Business Users*) and select **OK**
+1. Select the **Delegation** tab. Select **Authenticated Users > Advanced**
+1. 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. Select **OK**
+
+### Deploy the Windows Hello for Business Group Policy object
+
+The application of Group Policy object uses security group filtering. This solution allows linking the GPO to the domain, ensuring the GPO is scoped to all users. The security group filtering ensures that only the members of the *Windows Hello for Business Users* global group receive and apply the GPO, which results in the provisioning of Windows Hello for Business.
+
+1. Start the **Group Policy Management Console** (gpmc.msc)
+1. In the navigation pane, expand the domain and right-click the node that has your Active Directory domain name and select **Link an existing GPO**
+1. 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 select **OK**
+
+### Add members to the targeted group
+
+Users (or devices) 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 members to the *Windows Hello for Business Users* group. Users and groups who aren't members of this group won't attempt to enroll for Windows Hello for Business.
+
+#### [:::image type="icon" source="../../images/icons/intune.svg"::: **Intune**](#tab/intune)
+
+## Configure Windows Hello for Business using Microsoft Intune
+
+> [!IMPORTANT]
+> The information in this section applies to Azure AD joined devices managed by Intune. Before proceeding, ensure that you completed the steps described in:
+> - [Configure single sign-on for Azure AD joined devices](hello-hybrid-aadj-sso.md)
+> - [Using Certificates for AADJ On-premises Single-sign On](hello-hybrid-aadj-sso-cert.md)
+
+For Azure AD joined devices enrolled in Intune, you can use Intune policies to manage Windows Hello for Business.
+
+There are different ways to enable and configure Windows Hello for Business in Intune:
+
+- Using a policy applied at the tenant level. The tenant policy:
+  - Is only applied at enrollment time, and any changes to its configuration won't apply to devices already enrolled in Intune
+  - It applies to *all devices* getting enrolled in Intune. For this reason, the policy is usually disabled and Windows Hello for Business is enabled using a policy targeted to a security group
+- A device configuration policy that is applied *after* device enrollment. Any changes to the policy will be applied to the devices during regular policy refresh intervals. Chose from the following policy types:
+  - [Settings catalog][MEM-1]
+  - [Security baselines][MEM-2]
+  - [Custom policy][MEM-3], via the [PassportForWork CSP][MEM-4]
+  - [Account protection policy][MEM-5]
+  - [Identity protection policy template][MEM-6]
+
+### Verify the tenant-wide policy
+
+To check the Windows Hello for Business policy applied at enrollment time:
+
+1. Sign in to the <a href="https://endpoint.microsoft.com/" target="_blank"><b>Microsoft Endpoint Manager admin center</b></a>
+1. Select **Devices** > **Windows** > **Windows Enrollment**
+1. Select **Windows Hello for Business**
+1. Verify the status of **Configure Windows Hello for Business** and any settings that may be configured
+
+:::image type="content" source="images/whfb-intune-disable.png" alt-text="Disablement of Windows Hello for Business from Microsoft Endpoint Manager admin center." border="true" lightbox="images/whfb-intune-disable.png":::
+
+If the tenant-wide policy is enabled and configured to your needs, you can skip to [Enroll in Windows Hello for Business](#enroll-in-windows-hello-for-business). Otherwise, follow the instructions below to create a policy using an *account protection* policy.
+
+### Enable and configure Windows Hello for Business
+
+To configure Windows Hello for Business using an *account protection* policy:
+
+1. Go to the <a href="https://go.microsoft.com/fwlink/?linkid=2109431" target="_blank"><b>Microsoft Endpoint Manager admin center</b></a>
+1. Select **Endpoint security** > **Account protection**
+1. Select **+ Create Policy**
+1. For *Platform**, select **Windows 10 and later** and for *Profile* select **Account protection**
+1. Select **Create**
+1. Specify a **Name** and, optionally, a **Description** > **Next**
+1. Under *Block Windows Hello for Business*, select **Disabled** and multiple policies become available
+    - These policies are optional to configure, but it's recommended to configure *Enable to use a Trusted Platform Module (TPM)* to **Yes**
+    - For more information about these policies, see [MDM policy settings for Windows Hello for Business](hello-manage-in-organization.md#mdm-policy-settings-for-windows-hello-for-business)
+1. Under *Enable to certificate for on-premises resources*, select **Disabled** and multiple policies become available
+1. Select **Next**
+1. Optionally, add *scope tags* > **Next**
+1. Assign the policy to a security group that contains as members the devices or users that you want to configure > **Next**
+1. Review the policy configuration and select **Create**
+
+:::image type="content" source="images/whfb-intune-account-protection-cert-enable.png" alt-text="Enablement of Windows Hello for Business from Microsoft Endpoint Manager admin center using an account protection policy." border="true" lightbox="images/whfb-intune-account-protection-cert-enable.png":::
+
+---
+
+## Enroll in 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 following is the enrollment behavior prior to Windows Server 2016 update [KB4088889 (14393.2155)](https://support.microsoft.com/help/4088889).
@@ -48,25 +178,23 @@ The remainder of the provisioning includes Windows Hello for Business requesting
 >
 > [!NOTE]
 > Windows Server 2016 update [KB4088889 (14393.2155)](https://support.microsoft.com/help/4088889) provides synchronous certificate enrollment during hybrid certificate trust provisioning.  With this update, users no longer need to wait for Azure AD Connect to sync their  public key on-premises.  Users enroll their certificate during provisioning and can use the certificate for sign-in immediately after completing the provisioning. The update needs to be installed on the federation servers.
-  
+
 After a successful key registration, Windows creates a certificate request using the same key pair to request a certificate.  Windows send the certificate request to the AD FS server for certificate enrollment.
-  
+
 The AD FS registration authority verifies the key used in the certificate request matches the key that was previously registered. On a successful match, the AD FS registration authority signs the certificate request using its enrollment agent certificate and sends it to the certificate authority.
 
 > [!NOTE]
 > In order for AD FS to verify the key used in the certificate request, it needs to be able to access the ```https://enterpriseregistration.windows.net``` endpoint.
 
-The certificate authority validates the certificate was signed by the registration authority. On successful validation of the signature, it issues a certificate based on the request and returns the certificate to the AD FS registration authority.  The registration authority returns the certificate to Windows where it then installs the certificate in the current user’s certificate store.  Once this process completes, the Windows Hello for Business provisioning workflow informs the user that they can use their PIN to sign-in through the Windows Action Center.
+The certificate authority validates the certificate was signed by the registration authority. On successful validation of the signature, it issues a certificate based on the request and returns the certificate to the AD FS registration authority.  The registration authority returns the certificate to Windows where it then installs the certificate in the current user's certificate store.  Once this process completes, the Windows Hello for Business provisioning workflow informs the user that they can use their PIN to sign-in through the Windows Action Center.
 
-<br><br>
+<!--links-->
+[AZ-4]: /azure/active-directory/devices/troubleshoot-device-dsregcmd
+[AZ-5]: /azure/active-directory/connect/active-directory-aadconnectsync-feature-scheduler
 
-<hr>
+[MEM-1]: /mem/intune/configuration/settings-catalog
-
+[MEM-2]: /mem/intune/protect/security-baselines
-## Follow the Windows Hello for Business hybrid certificate trust deployment guide
+[MEM-3]: /mem/intune/configuration/custom-settings-configure
-
+[MEM-4]: /windows/client-management/mdm/passportforwork-csp
-1. [Overview](hello-hybrid-cert-trust.md)
+[MEM-5]: /mem/intune/protect/endpoint-security-account-protection-policy
-2. [Prerequisites](hello-hybrid-cert-trust-prereqs.md)
+[MEM-6]: /mem/intune/protect/identity-protection-configure
-3. [New Installation Baseline](hello-hybrid-cert-new-install.md)
-4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md)
-5. [Configure Windows Hello for Business policy settings](hello-hybrid-cert-whfb-settings-policy.md)
-6. Sign-in and Provision (*You are here*)

windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-ad.md

@@ -1,68 +0,0 @@
----
-title: Configure Hybrid Azure AD joined Windows Hello for Business - Active Directory (AD)
-description: Discussing the configuration of Active Directory (AD) in a Hybrid deployment of Windows Hello for Business
-ms.date: 4/30/2021
-appliesto: 
-- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
-ms.topic: article
----
-# Configure Hybrid Azure AD joined Windows Hello for Business: Active Directory
-
-[!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. 
-
-### Creating Security Groups
-
-Windows Hello for Business uses several security groups to simplify the deployment and management.
-
-> [!Important]
-> If your environment has one or more Windows Server 2016 domain controllers in the domain to which you are deploying Windows Hello for Business, then skip the **Create the KeyCredentials Admins Security Group**.  Domains that include Windows Server 2016 domain controllers use the KeyAdmins group, which is created during the installation of the first Windows Server 2016 domain controller.
-
-#### Create the KeyCredential Admins Security Group
-
-Azure Active Directory Connect synchronizes the public key on the user object created during provisioning.  You assign write and read permission to this group to the Active Directory attribute to ensure the Azure AD Connect service can add and remove keys as part of its normal workflow.
-
-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 **Advance Features**.
-3. Expand the domain node from the navigation pane.
-4. Right-click the **Users** container. Click **New**. Click **Group**.
-5. Type **KeyCredential Admins** in the **Group Name** text box.
-6. Click **OK**.
-
-#### 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 KeyCredential Admins Security group (optional)
-> * Create the Windows Hello for Business Users group
-> 
-> [!div class="step-by-step"]
-> [< Configure Windows Hello for Business](hello-hybrid-cert-whfb-settings.md)
-> [Configure Azure AD Connect >](hello-hybrid-cert-whfb-settings-dir-sync.md)
-
-<br><br>
-
-<hr>
-
-## Follow the Windows Hello for Business hybrid certificate trust deployment guide
-1. [Overview](hello-hybrid-cert-trust.md)
-2. [Prerequisites](hello-hybrid-cert-trust-prereqs.md)
-3. [New Installation Baseline](hello-hybrid-cert-new-install.md)
-4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md)
-5. Configure Windows Hello for Business settings: Active Directory (*You are here*)
-6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md)

windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-adfs.md

@@ -1,90 +1,80 @@
 ---
-title: Configuring Hybrid Azure AD joined Windows Hello for Business - Active Directory Federation Services (ADFS)
+title: Configure Active Directory Federation Services in a hybrid certificate trust model
-description: Discussing the configuration of Active Directory Federation Services (ADFS) in a Hybrid deployment of Windows Hello for Business
+description: Learn how to configure Active Directory Federation Services to support the Windows Hello for Business hybrid certificate trust model.
-ms.date: 4/30/2021
+ms.date: 01/03/2023
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
-ms.topic: article
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
+ms.topic: tutorial
 ---
-# Configure Hybrid Azure AD joined Windows Hello for Business: Active Directory Federation Services
+# Configure Active Directory Federation Services - hybrid certificate trust
 
-[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-cert-trust.md)]
+[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-cert-trust.md)]
 
-## Federation Services
+The Windows Hello for Business certificate-based deployments use AD FS as the certificate registration authority (CRA).
-
+The CRA is responsible for issuing and revoking certificates to users. Once the registration authority verifies the certificate request, it signs the certificate request using its enrollment agent certificate and sends it to the certificate authority.\
-The Windows Server 2016 Active Directory Federation Server Certificate Registration Authority (AD FS RA) enrolls for an enrollment agent certificate. Once the registration authority verifies the certificate request, it signs the certificate request using its enrollment agent certificate and sends it to the certificate authority.
+The CRA enrolls for an *enrollment agent certificate*, and the Windows Hello for Business *authentication certificate template* is configured to only issue certificates to certificate requests that have been signed with an enrollment agent certificate.
-
-The Windows Hello for Business Authentication certificate template is configured to only issue certificates to certificate requests that have been signed with an enrollment agent certificate.
 
 > [!NOTE]
-> In order for AD FS to verify user certificate requests for Windows Hello for Business, it needs to be able to access the ```https://enterpriseregistration.windows.net``` endpoint.
+> In order for AD FS to verify user certificate requests for Windows Hello for Business, it needs to be able to access the `https://enterpriseregistration.windows.net` endpoint.
 
-### Configure the Registration Authority
+## Configure the certificate registration authority
 
-Sign-in the AD FS server with *Domain Admin* equivalent credentials.
+Sign-in the AD FS server with *domain administrator* equivalent credentials.
 
-1. Open a **Windows PowerShell** prompt.
+Open a **Windows PowerShell** prompt and type the following command:
-2. Enter the following command:
   
-    ```PowerShell
+```PowerShell
-    Set-AdfsCertificateAuthority -EnrollmentAgent -EnrollmentAgentCertificateTemplate WHFBEnrollmentAgent -WindowsHelloCertificateTemplate WHFBAuthentication -WindowsHelloCertificateProxyEnabled $true
+Set-AdfsCertificateAuthority -EnrollmentAgent -EnrollmentAgentCertificateTemplate WHFBEnrollmentAgent -WindowsHelloCertificateTemplate WHFBAuthentication -WindowsHelloCertificateProxyEnabled $true
-    ```
+```
 
-    >[!NOTE]
+>[!NOTE]
-    > If you gave your Windows Hello for Business Enrollment Agent and Windows Hello for Business Authentication certificate templates different names, then replace **WHFBEnrollmentAgent** and WHFBAuthentication in the preceding command with the name of your certificate templates.  It's important that you use the template name rather than the template display name.  You can view the template name on the **General** tab of the certificate template by using the **Certificate Template** management console (certtmpl.msc).  Or, you can view the template name by using the **Get-CATemplate** ADCS Administration Windows PowerShell cmdlet on a Windows Server 2012 or later certificate authority.
+> If you gave your Windows Hello for Business Enrollment Agent and Windows Hello for Business Authentication certificate templates different names, then replace *WHFBEnrollmentAgent* and *WHFBAuthentication* in the above command with the name of your certificate templates. It's important that you use the template name rather than the template display name.  You can view the template name on the **General** tab of the certificate template by using the **Certificate Template** management console (certtmpl.msc). Or, you can view the template name by using the `Get-CATemplate` PowerShell cmdlet on a CA.
 
-### Group Memberships for the AD FS Service Account
+## Enrollment agent certificate enrollment
 
-The Windows Hello for Business group provides the AD FS service with the permissions needed to enroll a Windows Hello for Business authentication certificate on behalf of the provisioning user.
+AD FS performs its own certificate lifecycle management. Once the registration authority is configured with the proper certificate template, the AD FS server attempts to enroll the certificate on the first certificate request or when the service first starts.
+
+Approximately 60 days prior to enrollment agent certificate's expiration, the AD FS service attempts to renew the certificate until it is successful. If the certificate fails to renew, and the certificate expires, the AD FS server will request a new enrollment agent certificate. You can view the AD FS event logs to determine the status of the enrollment agent certificate.
+
+### Group Memberships for the AD FS service account
+
+The AD FS service account must be member of the security group targeted by the authentication certificate template auto-enrollment (e.g. *Window Hello for Business Users*). The security group provides the AD FS service with the permissions needed to enroll a Windows Hello for Business authentication certificate on behalf of the provisioning user.
 
 > [!TIP]
 > The adfssvc account is the AD FS service account.
 
 Sign-in a domain controller or management workstation with _Domain Admin_ equivalent credentials.
 
-1. Open **Active Directory Users and Computers**.
+1. Open **Active Directory Users and Computers**
-2. Click the **Users** container in the navigation pane.
+1. Search for the security group targeted by the authentication certificate template auto-enrollment (e.g. *Window Hello for Business Users*)
-3. Right-click **Windows Hello for Business Users** group.
+1. Select the **Members** tab and select **Add**
-4. Click the **Members** tab and click **Add**.
+1. In the **Enter the object names to select** text box, type **adfssvc** or substitute the name of the AD FS service account in your AD FS deployment > **OK**
-5. In the **Enter the object names to select** text box, type **adfssvc** or substitute the name of the AD FS service account in your AD FS deployment.  Click **OK**.
+1. Select **OK** to return to **Active Directory Users and Computers**
-6. Click **OK** to return to **Active Directory Users and Computers**.
+1. Restart the AD FS server
-7. Restart the AD FS server.
 
-> [!NOTE] 
+> [!NOTE]
-> For AD FS 2019, if Windows Hello for Business with a Hybrid Certificate trust is performed, a known PRT issue exists. You may encounter this error in ADFS Admin event logs: Received invalid Oauth request. The client 'NAME' is forbidden to access the resource with scope 'ugs'. To remediate this error:
+> For AD FS 2019 in a hybrid certificate trust model, a PRT issue exists. You may encounter this error in the AD FS Admin event logs: *Received invalid Oauth request. The client 'NAME' is forbidden to access the resource with scope 'ugs'*. To remediate this error:
 >
-> 1. Launch AD FS management console. Browse to "Services > Scope Descriptions".
+> 1. Launch AD FS management console and browse to **Services > Scope Descriptions**
-> 2. Right click "Scope Descriptions" and select "Add Scope Description".
+> 1. Right click **Scope Descriptions** and select **Add Scope Description**
-> 3. Under name type "ugs" and Click Apply > OK.
+> 1. Under name type `ugs` and select **Apply > OK**
-> 4. Launch PowerShell as an administrator.
+> 1. Launch PowerShell as an administrator
-> 5. Get the ObjectIdentifier of the application permission with the ClientRoleIdentifier parameter equal to "38aa3b87-a06d-4817-b275-7a316988d93b":
+> 1. Obtain the *ObjectIdentifier* of the application permission with the `ClientRoleIdentifier` parameter equal to `38aa3b87-a06d-4817-b275-7a316988d93b`:
 > ```PowerShell
 > (Get-AdfsApplicationPermission -ServerRoleIdentifiers 'http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope' | ?{ $_.ClientRoleIdentifier -eq '38aa3b87-a06d-4817-b275-7a316988d93b' }).ObjectIdentifier
 > ```
-> 6. Execute the command `Set-AdfsApplicationPermission -TargetIdentifier <ObjectIdentifier from step 5> -AddScope 'ugs'`.
+> 1. Execute the command `Set-AdfsApplicationPermission -TargetIdentifier <ObjectIdentifier from step 5> -AddScope 'ugs'`.
-> 7. Restart the AD FS service.
+> 1. Restart the AD FS service
-> 8. On the client: Restart the client. User should be prompted to provision Windows Hello for Business.
+> 1. On the client: Restart the client. User should be prompted to provision Windows Hello for Business
 
-### Section Review
+## Section review and next steps
+
+Before moving to the next section, ensure the following steps are complete:
 
 > [!div class="checklist"]
-> * Configure the registration authority.
+> - Configure the certificate registration authority
-> * Update group memberships for the AD FS service account.
+> - Update group memberships for the AD FS service account
-> 
-> 
-> [!div class="step-by-step"]
-> [< Configure PKI >](hello-hybrid-cert-whfb-settings-pki.md)
-> [Configure policy settings >](hello-hybrid-cert-whfb-settings-policy.md)
-
-<br><br>
-
-<hr>
-
-## Follow the Windows Hello for Business hybrid certificate trust deployment guide
-1. [Overview](hello-hybrid-cert-trust.md)
-2. [Prerequisites](hello-hybrid-cert-trust-prereqs.md)
-3. [New Installation Baseline](hello-hybrid-cert-new-install.md)
-4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md)
-5. Configure Windows Hello for Business settings: AD FS (*You are here*)
-6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md)
 
+> [!div class="nextstepaction"]
+> [Next: configure policy settings >](hello-hybrid-cert-whfb-settings-policy.md)

windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-dir-sync.md

@@ -1,77 +0,0 @@
----
-title: Configure Hybrid Azure AD joined Windows Hello for Business Directory Synch
-description: Discussing Directory Synchronization in a Hybrid deployment of Windows Hello for Business
-ms.date: 4/30/2021
-appliesto: 
-- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
-ms.topic: article
----
-
-# Configure Hybrid Azure AD joined Windows Hello for Business- Directory Synchronization
-
-[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-cert-trust.md)]
-
-## Directory Synchronization
-
-In hybrid deployments, users register the public portion of their Windows Hello for Business credential with Azure.  Azure AD Connect synchronizes the Windows Hello for Business public key to Active Directory.
-
-The key-trust model needs Windows Server 2016 domain controllers, which configure the key registration permissions automatically; however, the certificate-trust model does not and requires you to add the permissions manually.
-
-> [!IMPORTANT]
-> If you already have a Windows Server 2016 domain controller in your domain, you can skip **Configure Permissions for Key Synchronization**. In this case, you should use the pre-created group KeyAdmins in step 3 of the "Group Memberships for the Azure AD Connect Service Account" section of this article.
-
-### Configure Permissions for Key Synchronization
-
-Sign-in a domain controller or management workstations with *Domain Admin* equivalent credentials.
-
-1. Open **Active Directory Users and Computers**.
-2. Right-click your domain name from the navigation pane and click **Properties**.
-3. Click **Security** (if the Security tab is missing, turn on Advanced Features from the View menu).
-4. Click **Advanced**. Click **Add**. Click **Select a principal**.
-5. The **Select User, Computer, Service Account, or Group** dialog box appears. In the **Enter the object name to select** text box, type **KeyCredential Admins**.  Click **OK**.
-6. In the **Applies to** list box, select **Descendant User objects**.
-7. Using the scroll bar, scroll to the bottom of the page and click **Clear all**.
-8. In the **Properties** section, select **Read msDS-KeyCredentialLink** and **Write msDS-KeyCredentialLink**.
-9. Click **OK** three times to complete the task.
-
-
-### Group Memberships for the Azure AD Connect Service Account
-
-The KeyAdmins or KeyCredential Admins 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 either the **KeyAdmins** or **KeyCredential 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 Azure AD Connect service account.  Click **OK**.
-6. Click **OK** to return to **Active Directory Users and Computers**.
-
-> [!NOTE]
-> If your AD forest has multiple domains, make sure you add the ADConnect sync service account (ie. MSOL_12121212) into "Enterprise Key Admins" group to gain permission across the domains in the forest.
-
-> [!NOTE]
-> Transfer the PDC emulator FSMO role to a domain controller running Windows Server 2016 (or later) to be able to search the Key Admins and Enterprise Key Admins groups (domain controllers running previous versions of Windows Server cannot translate the security identifier to a name for these groups).
-
-### Section Review
-
-> [!div class="checklist"]
-> * Configure Permissions for Key Synchronization
-> * Configure group membership for Azure AD Connect
->
-> [!div class="step-by-step"]
-> [< Configure Active Directory](hello-hybrid-cert-whfb-settings-ad.md)
-> [Configure PKI >](hello-hybrid-cert-whfb-settings-pki.md)
-
-<br><br>
-
-<hr>
-
-## Follow the Windows Hello for Business hybrid certificate trust deployment guide
-1. [Overview](hello-hybrid-cert-trust.md)
-2. [Prerequisites](hello-hybrid-cert-trust-prereqs.md)
-3. [New Installation Baseline](hello-hybrid-cert-new-install.md)
-4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md)
-5. Configure Windows Hello for Business settings: Directory Synchronization (*You are here*)
-6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md)

windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-pki.md

@@ -1,289 +0,0 @@
----
-title: Configuring Hybrid Azure AD joined Windows Hello for Business - Public Key Infrastructure (PKI)
-description: Discussing the configuration of the Public Key Infrastructure (PKI) in a Hybrid deployment of Windows Hello for Business
-ms.date: 4/30/2021
-appliesto: 
-- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
-ms.topic: article
----
-
-# Configure Hybrid Azure AD joined Windows Hello for Business - Public Key Infrastructure
-
-[!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.
-
-All deployments use enterprise issued certificates for domain controllers as a root of trust. Hybrid certificate trust deployments issue users with a sign-in certificate that enables them to authenticate using Windows Hello for Business credentials to non-Windows Server 2016 domain controllers. Additionally, hybrid certificate trust deployments issue certificates to registration authorities to provide defense-in-depth security when issuing user authentication certificates.
-
-## Certificate Templates
-
-This section has you configure certificate templates on your Windows Server 2012 (or later) Active Directory Certificate Services 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 *Create a Domain Controller Authentication (Kerberos) Certificate Template* and *Configure Certificate Superseding for the Domain Controller Authentication (Kerberos) Certificate Template* to include the **KDC Authentication** OID in the domain controller certificate 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 as 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 **Certification 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** 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.
-
-#### Configure Certificate Superseding for the Domain Controller Authentication (Kerberos) Certificate Template
-
-Many domain controllers may have an existing domain controller certificate. 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 auto-enrollment 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 based on the Kerberos Authentication certificate template.
-
-Sign-in a certificate authority or management workstations with _Enterprise Admin_ equivalent credentials.
-
-1. Open the **Certification 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 listed in the 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]
-> A domain controller's certificate must chain to a certificate in the NTAuth store in Active Directory. By default, online "Enterprise" Active Directory Certificate Authority certificates are added to the NTAuth store at installation time. If you are using a third-party CA, this is not done by default. If the domain controller certificate does not chain to a trusted CA in the NTAuth store, user authentication will fail. 
-> You can view an AD forest's NTAuth store (NTAuthCertificates) using PKIVIEW.MSC from an ADCS CA. Open PKIView.msc, then click the Action menu -> Manage AD Containers.
-
-### Enrollment Agent certificate template
-
-Active Directory Federation Server used for Windows Hello for Business certificate enrollment performs its own certificate lifecycle management. Once the registration authority is configured with the proper certificate template, the AD FS server attempts to enroll the certificate on the first certificate request, or when the service first starts.
-
-Approximately 60 days prior to the enrollment agent certificate's expiration, the AD FS service attempts to renew the certificate until it is successful. If the certificate fails to renew and expires, the AD FS server will request a new enrollment agent certificate. You can view the AD FS event logs to determine the status of the enrollment agent certificate.
-
-> [!IMPORTANT]
-> Follow the procedures below based on the AD FS service account used in your environment.
-
-#### Creating an Enrollment Agent certificate for Group Managed Service Accounts
-
-Sign-in to a certificate authority or management workstation with _Domain Admin_ equivalent credentials.
-
-1. Open the **Certification Authority Management** console.
-
-2. Right-click **Certificate Templates** and click **Manage**.
-
-3. In the **Certificate Template Console**, right click on the **Exchange Enrollment Agent (Offline request)** template details pane and click **Duplicate Template**.
-
-4. On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Authority** list. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certificate Recipient** list.
-
-5. On the **General** tab, type **WHFB Enrollment Agent** in **Template display name**.  Adjust the validity and renewal period to meet your enterprise's needs.
-
-6. On the **Subject** tab, select the **Supply in the request** button if it is not already selected.
-
-   > [!NOTE]
-   > The preceding step is very important. Group Managed Service Accounts (GMSA) do not support the _Build from this Active Directory information_ option, which will result in the AD FS server failing to enroll the enrollment agent certificate. You must configure the certificate template with _Supply in the request_ to ensure that AD FS servers can perform the automatic enrollment and renewal of the enrollment agent certificate.
-
-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.
-
-8. On the **Security** tab, click **Add**.
-
-9. Click **Object Types**.  Select the **Service Accounts** check box and click **OK**.
-
-10. Type **adfssvc** in the **Enter the object names to select** text box and click **OK**.
-
-11. Click the **adfssvc** from the **Group or users names** list. In the **Permissions for adfssvc** section, select the **Allow** check box for the **Enroll** permission. Excluding the **adfssvc** user, clear the **Allow** check box for the **Enroll** and **Autoenroll** permissions for all other items in the **Group or users names** list if the check boxes are not already cleared. Click **OK**.
-
-12. Close the console.
-
-#### Creating an Enrollment Agent certificate for typical Service Accounts
-
-Sign-in to a certificate authority or management workstation with *Domain Admin* equivalent credentials.
-
-1. Open the **Certification Authority** management console.
-
-2. Right-click **Certificate Templates** and click **Manage**.
-
-3. In the **Certificate Template** console, right-click the **Exchange Enrollment Agent (Offline request)** template in the details pane and click **Duplicate Template**.
-
-4. On the **Compatibility** tab, clear the **Show resulting changes** check box.  Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Authority** list. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certificate Recipient** list.
-
-5. On the **General** tab, type **WHFB Enrollment Agent** in **Template display name**.  Adjust the validity and renewal period to meet your enterprise's needs.
-
-6. On the **Subject** tab, select the **Build from this Active Directory information** button if it is not already selected. Select **Fully distinguished name** from the **Subject name format** list if **Fully distinguished name** is not already selected.  Select the **User Principal Name (UPN)** check box under **Include this information in alternative subject name**.
-
-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.
-
-8. On the **Security** tab, click **Add**. Type **adfssvc** in the **Enter the object names to select text box** and click **OK**.
-
-9. Click the **adfssvc** from the **Group or users names** list. In the **Permissions for adfssvc** section, select the **Allow** check box for the **Enroll** permission. Excluding the **adfssvc** user, clear the **Allow** check boxes for the **Enroll** and **Autoenroll** permissions for all other items in the **Group or users names** list if the check boxes are not already cleared. Click **OK**.
-
-10. Close the console.
-
-### Creating Windows Hello for Business authentication certificate template
-
-During Windows Hello for Business provisioning, a Windows client requests an authentication certificate from the Active Directory Federation Service, which requests an authentication certificate on behalf of the user. This task configures the Windows Hello for Business authentication certificate template. You set the name of the certificate template when configuring it.
-
-Sign-in to a certificate authority or management workstation with _Domain Admin equivalent_ credentials.
-
-1. Open the **Certification Authority** management console.
-
-2. Right-click **Certificate Templates** and click **Manage**.
-
-3. Right-click the **Smartcard Logon** template and choose **Duplicate Template**.
-
-4. On the **Compatibility** tab, clear the **Show resulting changes** check box.  Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Authority** list. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certificate Recipient** list.
-
-5. On the **General** tab, type **WHFB Authentication** or your choice of template name in **Template display name**. Note the short template name for later use with CertUtil. 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 the relevant portions of the deployment. 
-
-6. 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.
-
-7. On the **Extensions** tab, verify the **Application Policies** extension includes **Smart Card Logon**.
-
-8. On the **Issuance Requirements** tab, select the **This number of authorized signatures** check box.  Type **1** in the text box.   
-
-   Select **Application policy** from the **Policy type required in signature**. Select **Certificate Request Agent** from in the **Application policy** list. Select the **Valid existing certificate** option.
-
-9. On the **Subject** tab, select the **Build from this Active Directory information** button if it is not already selected. Select **Fully distinguished name** from the **Subject name format** list if **Fully distinguished name** is not already selected. Select the **User Principal Name (UPN)** check box under **Include this information in alternative subject name**.
-
-10. On the **Request Handling** tab, select the **Renew with same key** check box.
-
-11. On the **Security** tab, click **Add**. Type **Windows Hello for Business Users** in the **Enter the object names to select** text box and click **OK**.
-
-12. Click the **Windows Hello for Business Users** from the **Group or users names** list. In the **Permissions for Windows Hello for Business Users** section, select the **Allow** check box for the **Read**, **Enroll**, and **AutoEnroll** permissions. Excluding the **Windows Hello for Business Users** group, clear the **Allow** check box for the **Enroll** and **Autoenroll** permissions for all other entries in the **Group or users names** section if the check boxes are not already cleared. Click **OK**. 
-
-13. If you previously issued Windows Hello for Business sign-in certificates using Configuration Manger and are switching to an AD FS registration authority, then on the **Superseded Templates** tab, add the previously used **Windows Hello for Business Authentication** template(s), so they will be superseded by this template for the users that have Enroll permission for this template.
-
-14. Click on the **Apply** to save changes and close the console.
-
-#### Mark the template as the Windows Hello Sign-in template
-
-Sign-in to an **AD FS Windows Server 2016** computer with _Enterprise Admin_ equivalent credentials.
-
-1. Open an elevated command prompt.
-
-2. Run `certutil -dsTemplate WHFBAuthentication msPKI-Private-Key-Flag +CTPRIVATEKEY_FLAG_HELLO_LOGON_KEY`
-
-If the template was changed successfully, the output of the command will contain old and new values of the template parameters. The new value must contain the **CTPRIVATEKEY_FLAG_HELLO_LOGON_KEY** parameter. Example:
-
-```console
-CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=[yourdomain]:WHFBAuthentication
-
-Old Value:
-msPKI-Private-Key-Flag REG_DWORD = 5050080 (84213888)
-CTPRIVATEKEY_FLAG_REQUIRE_SAME_KEY_RENEWAL -- 80 (128)
-CTPRIVATEKEY_FLAG_ATTEST_NONE -- 0
-TEMPLATE_SERVER_VER_WINBLUE<<CTPRIVATEKEY_FLAG_SERVERVERSION_SHIFT -- 50000 (327680)
-TEMPLATE_CLIENT_VER_WINBLUE<<CTPRIVATEKEY_FLAG_CLIENTVERSION_SHIFT -- 5000000 (83886080)
-
-New Value:
-msPKI-Private-Key-Flag REG_DWORD = 5250080 (86311040)
-CTPRIVATEKEY_FLAG_REQUIRE_SAME_KEY_RENEWAL -- 80 (128)
-CTPRIVATEKEY_FLAG_ATTEST_NONE -- 0
-TEMPLATE_SERVER_VER_WINBLUE<<CTPRIVATEKEY_FLAG_SERVERVERSION_SHIFT -- 50000 (327680)
-CTPRIVATEKEY_FLAG_HELLO_LOGON_KEY -- 200000 (2097152)
-TEMPLATE_CLIENT_VER_WINBLUE<<CTPRIVATEKEY_FLAG_CLIENTVERSION_SHIFT -- 5000000 (83886080)
-CertUtil: -dsTemplate command completed successfully."
-```
-
-> [!NOTE]
-> If you gave your Windows Hello for Business Authentication certificate template a different name, then replace **WHFBAuthentication** in the above command with the name of your certificate template. It's important that you use the template name rather than the template display name. You can view the template name on the **General** tab of the certificate template using the Certificate Template management console (certtmpl.msc). Or, you can view the template name using the **Get-CATemplate** ADCS Administration Windows PowerShell cmdlet on a Windows Server 2012 or later certificate authority.
-
-## Publish Templates
-
-### Publish Certificate Templates to a Certificate Authority
-
-The certificate authority only issues certificates for certificate templates which are published by 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.
-
-#### Publish Certificate Templates to the Certificate Authority
-
-Sign-in to the certificate authority or management workstations with an _Enterprise Admin_ equivalent credentials.
-
-1. Open the **Certification 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, Ctrl-select the **Domain Controller Authentication (Kerberos)**, **WHFB Enrollment Agent** and **WHFB Authentication** templates you created in the previous steps. Click **OK** to publish the selected certificate templates to the certificate authority.
-
-6. 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 any pre-published certificate templates from the role installation and any superseded certificate templates.
-
-The newly-created Kerberos authentication-based Domain Controller certificate template supersedes any previous domain controller certificate templates. Therefore, you should unpublish these certificate templates from all issuing certificate authorities.
-
-Sign-in to each certificate authority, or a management workstation with _Enterprise Admin_ equivalent credentials.
-
-1. Open the **Certification 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
-> * Enrollment Agent certificate template
-> * Windows Hello for Business Authentication certificate template
-> * Mark the certificate template as Windows Hello for Business sign-in template
-> * Publish Certificate templates to certificate authorities
-> * Unpublish superseded certificate templates
-> 
-> [!div class="step-by-step"]
-> [< Configure Azure AD Connect](hello-hybrid-cert-whfb-settings-dir-sync.md)
-> [Configure AD FS >](hello-hybrid-cert-whfb-settings-adfs.md)
-
-<br><br>
-
-<hr>
-
-## Follow the Windows Hello for Business hybrid certificate trust deployment guide
-
-1. [Overview](hello-hybrid-cert-trust.md)
-2. [Prerequisites](hello-hybrid-cert-trust-prereqs.md)
-3. [New Installation Baseline](hello-hybrid-cert-new-install.md)
-4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md)
-5. Configure Windows Hello for Business settings: PKI (*You are here*)
-6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md)

windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-policy.md

@@ -1,192 +0,0 @@
----
-title: Configuring Hybrid Azure AD joined Windows Hello for Business - Group Policy
-description: Discussing the configuration of Group Policy in a Hybrid deployment of Windows Hello for Business
-ms.date: 4/30/2021
-appliesto: 
-- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
-ms.topic: article
----
-# Configure Hybrid Azure AD joined Windows Hello for Business - Group Policy
-
-[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-cert-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.  
-
-Domain joined clients of hybrid certificate-based deployments of Windows Hello for Business needs three Group Policy settings:
-
-- Enable Windows Hello for Business
-- Use certificate for on-premises authentication
-- Enable automatic enrollment of certificates
-
-### 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**.
-
-### 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
-
-#### 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 be 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.
-
-#### Use certificate for on-premises authentication
-
-The Use certificate for on-premises authentication Group Policy setting determines if the on-premises deployment uses the key-trust or certificate trust on-premises authentication model.  You must configure this Group Policy setting to configure Windows to enroll for a Windows Hello for Business authentication certificate. If you do not configure this policy setting, Windows considers the deployment to use key-trust on-premises authentication, which requires a sufficient number of Windows Server 2016 domain controllers to handle the Windows Hello for Business key-trust authentication requests.
-
-You can configure this Group Policy setting for computer or users. Deploying this policy setting to computers results in ALL users requesting a Windows Hello for Business authentication certificate.  Deploying this policy setting to a user results in only that user requesting a Windows Hello for Business authentication certificate. Additionally, you can deploy the policy setting to a group of users so only those users request a Windows Hello for Business authentication certificate. If both user and computer policy settings are deployed, the user policy setting has precedence.
-
-#### Enable automatic enrollment of certificates
-
-Windows Hello for Business provisioning performs the initial enrollment of the Windows Hello for Business authentication certificate. This certificate expires based on the duration configured in the Windows Hello for Business authentication certificate template. The Windows 10, version 1703 certificate auto enrollment was updated to renew these certificates before they expire, which significantly reduces user authentication failures from expired user certificates. 
-
-The process requires no user interaction provided the user signs-in using Windows Hello for Business.  The certificate is renewed in the background before it expires.
-
-#### Create the Windows Hello for Business Group Policy object
-
-The Group Policy object contains the policy settings needed to trigger Windows Hello for Business provisioning and to ensure Windows Hello for Business authentication certificates are automatically renewed.
-
-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**.
-9. Double-click **Use certificate for on-premises authentication**. Click **Enable** and click **OK**.  Close the **Group Policy Management Editor**.
-
-#### Configure Automatic Certificate Enrollment
-
-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 the **Enable Windows Hello for Business** Group Policy object and click **Edit**.
-4. In the navigation pane, expand **Policies** under **User Configuration**.
-5. Expand **Windows Settings > Security Settings**, and click **Public Key Policies**.
-6. In the details pane, right-click **Certificate Services Client - Auto-Enrollment** and select **Properties**.
-7. Select **Enabled** from the **Configuration Model** list.
-8. Select the **Renew expired certificates**, **update pending certificates**, and **remove revoked certificates** check box.
-9. Select the **Update certificates that use certificate templates** check box.
-10. 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. Therefore, some organization 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, simply 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 does not provide granular policy setting that enable you to disable specific modalities of biometrics such as allow facial recognition, but disallow fingerprint.
-
-### 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. 
-
-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
-
-Starting with 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.
-
-## 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 enroll for the Windows Hello for Business Authentication certificate. You can provide users with these settings and permissions by adding the group used synchronize users 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.
-> * Enable the Use certificate for on-premises authentication policy setting.
-> * Enable user automatic certificate enrollment.
-> * Add users or groups to the Windows Hello for Business group
-> 
-> 
-> [!div class="nextstepaction"]
-> [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md)
-
-<br><br>
-
-<hr>
-
-## Follow the Windows Hello for Business hybrid certificate trust deployment guide
-1. [Overview](hello-hybrid-cert-trust.md)
-2. [Prerequisites](hello-hybrid-cert-trust-prereqs.md)
-3. [New Installation Baseline](hello-hybrid-cert-new-install.md)
-4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md)
-5. Configure Windows Hello for Business policy settings (*You are here*)
-6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md)

windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings.md

@@ -1,39 +0,0 @@
----
-title: Configure Hybrid Windows Hello for Business Settings (Windows Hello for Business)
-description: Learn how to configure Windows Hello for Business settings in hybrid certificate trust deployment.
-ms.date: 4/30/2021
-appliesto: 
-- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
-ms.topic: article
----
-# Configure Hybrid Azure AD joined Windows Hello for Business
-
-[!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]
-> If your environment is not federated, review the [New Installation baseline](hello-hybrid-cert-new-install.md) section of this deployment document to learn how to federate 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-cert-whfb-settings-ad.md)
-- [Public Key Infrastructure](hello-hybrid-cert-whfb-settings-pki.md)
-- [Active Directory Federation Services](hello-hybrid-cert-whfb-settings-adfs.md)
-- [Group Policy](hello-hybrid-cert-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-cert-whfb-settings-ad.md)
-
-<br><br>
-
-<hr>
-
-## Follow the Windows Hello for Business hybrid certificate trust deployment guide
-1. [Overview](hello-hybrid-cert-trust.md)
-2. [Prerequisites](hello-hybrid-cert-trust-prereqs.md)
-3. [New Installation Baseline](hello-hybrid-cert-new-install.md)
-4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md)
-5. Configure Windows Hello for Business settings (*You are here*)
-6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md)

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: 
@@ -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.
 
@@ -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.
 
----
+<!--links-->
 
 [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

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

@@ -1,144 +0,0 @@
----
-title: Windows Hello for Business Hybrid Azure AD joined Key Trust New Installation
-description: Learn how to configure a hybrid key trust deployment of Windows Hello for Business for systems with no previous installations.
-ms.date: 4/30/2021
-appliesto: 
-- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
-ms.topic: article
----
-# Windows Hello for Business Hybrid Azure AD joined Key Trust New Installation
-
-[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-key-trust.md)]
-
-Windows Hello for Business involves configuring distributed technologies that may or may not exist in your current infrastructure.  Hybrid key trust deployments of Windows Hello for Business rely on these technologies
-
-- [Active Directory](#active-directory)
-- [Public Key Infrastructure](#public-key-infrastructure)
-- [Azure Active Directory](#azure-active-directory)
-- [Multifactor Authentication Services](#multifactor-authentication-services)
-
-New installations are considerably more involved than existing implementations because you are building the entire infrastructure.  Microsoft recommends you review the new installation baseline to validate your existing environment has all the needed configurations to support your hybrid certificate trust Windows Hello for Business deployment.  If your environment meets these needs, you can read the [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md) section to prepare your Windows Hello for Business deployment by configuring directory synchronization.
-
-The new installation baseline begins with a basic Active Directory deployment and enterprise PKI.  
-
-## Active Directory
-This document expects you have Active Directory deployed with an _adequate_ number of Windows Server 2016 or later domain controllers for each site.  Read the [Planning an adequate number of Windows Server 2016 Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) to learn more.
-
-> [!NOTE]
->There was an issue with key trust authentication on Windows Server 2019. If you are planning to use Windows Server 2019 domain controllers refer to [KB4487044](https://support.microsoft.com/en-us/help/4487044/windows-10-update-kb4487044) to fix this issue.
- 
-Lab environments and isolated proof of concepts may want to limit the number of domain controllers.  The purpose of these environments is to experiment and learn.  Reducing the number of domain controllers can prevent troubleshooting issue, such as Active Directory replication, which is unrelated to activity's goal.
-
-### Section Review
-
-> [!div class="checklist"]
-> * An adequate number of Windows Server 2016 domain controllers
-> * Minimum Windows Server 2008 R2 domain and forest functional level
-> * Functional networking, name resolution, and Active Directory replication
- 
-## Public Key Infrastructure
-
-Windows Hello for Business must have a public key infrastructure regardless of the deployment or trust model.  All trust models depend on the domain controllers having a certificate.  The certificate serves as a root of trust for clients to ensure they are not communicating with a rogue domain controller.
-
-This guide assumes most enterprises have an existing public key infrastructure.  Windows Hello for Business depends on a Windows enterprise public key infrastructure running the Active Directory Certificate Services role from Windows Server 2012 or later.
-
-### Lab-based public key infrastructure
-
-The following instructions may be used to deploy simple public key infrastructure that is suitable for a lab environment.
-
-Sign-in using _Enterprise Admin_ equivalent credentials on Windows Server 2012 or later server where you want the certificate authority installed.
-
->[!NOTE]
->Never install a certificate authority on a domain controller in a production environment.
-
-1. Open an elevated Windows PowerShell prompt.
-2. Use the following command to install the Active Directory Certificate Services role.   
-    ```PowerShell
-    add-windowsfeature adcs-cert-authority -IncludeManagementTools
-    ```
-
-3. Use the following command to configure the Certificate Authority using a basic certificate authority configuration.   
-    ```PowerShell
-    Install-AdcsCertificationAuthority
-    ```   
-    
-## Configure a Production Public Key Infrastructure
-
-If you do not have an existing public key infrastructure, please review [Certification Authority Guidance](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831574(v=ws.11)) from Microsoft TechNet to properly design your infrastructure.   Then, consult the [Test Lab Guide: Deploying an AD CS Two-Tier PKI Hierarchy](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831348(v=ws.11)) for instructions on how to configure your public key infrastructure using the information from your design session.
-
-> [!IMPORTANT]
-> For Azure AD joined device to authenticate to and use on-premises resources, ensure you:
-> * Install the root certificate authority certificate for your organization in the user's trusted root certificate store.
-> * Publish your certificate revocation list to a location that is available to Azure AD-joined devices, such as a web-based URL.
-
-### Section Review
-
-> [!div class="checklist"]
-> *  Minimum Windows Server 2012 Certificate Authority.
-> *  Enterprise Certificate Authority.
-> *  Functioning public key infrastructure.
-> *  Root certificate authority certificate (Azure AD Joined devices).
-> *  Highly available certificate revocation list (Azure AD Joined devices).
-  
-## Azure Active Directory
-You've prepared your Active Directory.  Hybrid Windows Hello for Business deployment needs Azure Active Directory to host your cloud-based identities. 
-
-The next step of the deployment is to follow the [Creating an Azure AD tenant](/azure/active-directory/develop/active-directory-howto-tenant) process to provision an Azure tenant for your organization.
-
-### Section Review
-
-> [!div class="checklist"]
-> * Review the different ways to establish an Azure Active Directory tenant.
-> * Create an Azure Active Directory Tenant.
-> * Purchase the appropriate Azure Active Directory subscription or licenses, if necessary.
-   
-## Multifactor Authentication Services
-Windows Hello for Business uses multifactor authentication during provisioning and during user initiated PIN reset scenarios, such as when a user forgets their PIN.  There are two preferred multifactor authentication configurations with hybrid deployments—Azure MFA and AD FS using Azure MFA or a third-party MFA adapter
-
-Review the [What is Azure AD Multi-Factor Authentication](/azure/multi-factor-authentication/multi-factor-authentication) topic to familiarize yourself its purpose and how it works.
-
-### Azure AD Multi-Factor Authentication (MFA) Cloud
-
-> [!IMPORTANT]
-> As long as your users have licenses that include Azure AD Multi-Factor Authentication, there's nothing that you need to do to turn on Azure MFA. You can start requiring two-step verification on an individual user basis. The licenses that enable Azure MFA are:
-> * Azure AD Multi-Factor Authentication
-> * Azure Active Directory Premium
-> * Enterprise Mobility + Security
-> 
-> If you have one of these subscriptions or licenses, skip the Azure MFA Adapter section. 
-
-
-#### Configure Azure MFA Settings
-Review the [Configure Azure AD Multi-Factor Authentication settings](/azure/multi-factor-authentication/multi-factor-authentication-whats-next) section to configure your settings.
-
-#### Azure MFA User States
-After you have completed configuring your Azure MFA settings, you want to review [How to require two-step verification for a user](/azure/multi-factor-authentication/multi-factor-authentication-get-started-user-states) to understand user states. User states determine how you enable Azure MFA for your users.
-
-### Azure MFA via ADFS
-Alternatively, you can configure Windows Server 2016 Active Directory Federation Services (AD FS) to provide additional multi-factor authentication. To configure, read the [Configure AD FS 2016 and Azure MFA](/windows-server/identity/ad-fs/operations/configure-ad-fs-2016-and-azure-mfa) section.
-
-### Section Review
-
-> [!div class="checklist"]
-> * Review the overview and uses of Azure AD Multi-Factor Authentication.
-> * Review your Azure Active Directory subscription for Azure AD Multi-Factor Authentication.
-> * Create an Azure AD Multi-Factor Authentication Provider, if necessary.
-> * Configure Azure AD Multi-Factor Authentication features and settings.
-> * Understand the different User States and their effect on Azure AD Multi-Factor Authentication.
-> * Consider using Azure AD Multi-Factor Authentication or a third-party multifactor authentication provider with Windows Server Active Directory Federation Services, if necessary.
-
-> [!div class="nextstepaction"]
-> [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md)
-
-<br><br>
-
-<hr>
-
-## Follow the Windows Hello for Business hybrid key trust deployment guide
-1. [Overview](hello-hybrid-key-trust.md)
-2. [Prerequisites](hello-hybrid-key-trust-prereqs.md)
-3. New Installation Baseline (*You are here*)
-4. [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md)
-5. [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md)
-6. [Configure Windows Hello for Business settings](hello-hybrid-key-whfb-settings.md)
-7. [Sign-in and Provision](hello-hybrid-key-whfb-provision.md)

windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-devreg.md

@@ -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: 
-- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
-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)

windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-dirsync.md

@@ -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: 
-- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
-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.
-
-<br>
-
-If the user principal name (UPN) in your on-premises Active Directory is different from the UPN in Azure AD, you also need to complete the following steps:
-- Configure Azure AD Connect to sync the user's on-premises UPN to the onPremisesUserPrincipalName attribute in Azure AD.
-- Add the domain name of the on-premises UPN as a [verified domain](/azure/active-directory/fundamentals/add-custom-domain) in Azure AD. 
-
-> [!NOTE]
-> Windows Hello for Business Hybrid key trust is not supported if your users' on-premises domain cannot be added as a verified domain in Azure AD.
-
-<hr>
-
-## Follow the Windows Hello for Business hybrid key trust deployment guide
-
-1. [Overview](hello-hybrid-key-trust.md)
-2. [Prerequisites](hello-hybrid-key-trust-prereqs.md)
-3. [New Installation Baseline](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)

windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-prereqs.md

@@ -1,159 +0,0 @@
----
-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
-appliesto: 
-- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
-ms.topic: article
----
-# Hybrid Azure AD joined Key trust Windows Hello for Business Prerequisites
-
-[!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:
-
-- [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.  The minimum required domain functional and forest functional levels for Windows Hello for Business deployment is Windows Server 2008 R2.  
-
-A hybrid Windows Hello for Business deployment requires Azure Active Directory. The hybrid key trust deployment does not need a premium Azure Active Directory subscription.
-
-You can deploy Windows Hello for Business in any environment with Windows Server 2008 R2 or later domain controllers.  
-If using the key trust deployment model, you MUST ensure that you have adequate (1 or more, depending on your authentication load) Windows Server 2016 or later Domain Controllers in each Active Directory site where users will be authenticating for Windows Hello for Business.  
-Read the [Planning an adequate number of Windows Server 2016 or later Domain Controllers for Windows Hello for Business deployments](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  
-
-<br>
-
-## Public Key Infrastructure
-
-The Windows Hello for Business deployment depends on an enterprise public key infrastructure as trust anchor for authentication. Domain controllers for hybrid deployments need a certificate in order for Windows devices to trust the domain controller.
-
-Key trust deployments do not need client issued certificates for on-premises authentication.  Active Directory user accounts are automatically configured for public key mapping by Azure AD Connect synchronizing the public key of the registered Windows Hello for Business credential to an attribute on the user's Active Directory object.
-
-The minimum required Enterprise certificate authority that can be used with Windows Hello for Business is Windows Server 2012, but you can also use a third-party Enterprise certification authority. The requirements for the domain controller certificate are shown below. For more details, see [Requirements for domain controller certificates from a third-party CA](/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.
-
-### Section Review
-> [!div class="checklist"]  
-> * Windows Server 2012 Issuing Certificate Authority
-
-<br>
-
-## 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.
-  
-Organizations using older directory synchronization technology, such as DirSync or Azure AD sync, need to upgrade to Azure AD Connect.
- 
-### Section Review
-
-> [!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)
-
-<br>
-
-## 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 
-
-<br>
-
-## 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)
-
-<br>
-
-## 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.
-
-### Section Checklist
-
-> [!div class="checklist"]
-> * Device Registration with Azure Device Registration 
-
-<br>
-
-### 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)
-
-<br><br>
-
-<hr>
-
-## 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)

windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-provision.md

@@ -0,0 +1,167 @@
+---
+title: Windows Hello for Business hybrid key trust clients configuration and enrollment
+description: Learn how to configure devices and enroll them in Windows Hello for Business in a hybrid key trust scenario.
+ms.date: 01/03/2023
+appliesto: 
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
+ms.topic: tutorial
+---
+
+# Configure and enroll in Windows Hello for Business - hybrid key trust
+
+[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-key-trust.md)]
+
+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).
+
+#### [:::image type="icon" source="../../images/icons/intune.svg"::: **Intune**](#tab/intune)
+
+## Configure Windows Hello for Business using Microsoft 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.
+
+There are different ways to enable and configure Windows Hello for Business in Intune:
+
+- Using a policy applied at the tenant level. The tenant policy:
+  - Is only applied at enrollment time, and any changes to its configuration won't apply to devices already enrolled in Intune
+  - It applies to *all devices* getting enrolled in Intune. For this reason, the policy is usually disabled and Windows Hello for Business is enabled using a policy targeted to a security group
+- A device configuration policy that is applied *after* device enrollment. Any changes to the policy will be applied to the devices during regular policy refresh intervals. There are different policy types to choose from:
+  - [Settings catalog][MEM-1]
+  - [Security baselines][MEM-2]
+  - [Custom policy][MEM-3], via the [PassportForWork CSP][MEM-4]
+  - [Account protection policy][MEM-5]
+  - [Identity protection policy template][MEM-6]
+
+### Verify the tenant-wide policy
+
+To check the Windows Hello for Business policy applied at enrollment time:
+
+1. Sign in to the <a href="https://endpoint.microsoft.com/" target="_blank"><b>Microsoft Endpoint Manager admin center</b></a>
+1. Select **Devices** > **Windows** > **Windows Enrollment**
+1. Select **Windows Hello for Business**
+1. Verify the status of **Configure Windows Hello for Business** and any settings that may be configured
+
+:::image type="content" source="images/whfb-intune-disable.png" alt-text="Disablement of Windows Hello for Business from Microsoft Endpoint Manager admin center." border="true" lightbox="images/whfb-intune-disable.png":::
+
+If the tenant-wide policy is enabled and configured to your needs, you can skip to [Enroll in Windows Hello for Business](#enroll-in-windows-hello-for-business). Otherwise, follow the instructions below to create a policy using an *account protection* policy.
+
+### Enable and configure Windows Hello for Business
+
+To configure Windows Hello for Business using an *account protection* policy:
+
+1. Go to the <a href="https://go.microsoft.com/fwlink/?linkid=2109431" target="_blank"><b>Microsoft Endpoint Manager admin center</b></a>
+1. Select **Endpoint security** > **Account protection**
+1. Select **+ Create Policy**
+1. For *Platform**, select **Windows 10 and later** and for *Profile* select **Account protection**
+1. Select **Create**
+1. Specify a **Name** and, optionally, a **Description** > **Next**
+1. Under *Block Windows Hello for Business*, select **Disabled** and multiple policies become available
+    - These policies are optional to configure, but it's recommended to configure *Enable to use a Trusted Platform Module (TPM)* to **Yes**
+    - For more information about these policies, see [MDM policy settings for Windows Hello for Business](hello-manage-in-organization.md#mdm-policy-settings-for-windows-hello-for-business)
+1. Select **Next**
+1. Optionally, add *scope tags* > **Next**
+1. Assign the policy to a security group that contains as members the devices or users that you want to configure > **Next**
+1. Review the policy configuration and select **Create**
+
+:::image type="content" source="images/whfb-intune-account-protection-enable.png" alt-text="Enablement of Windows Hello for Business from Microsoft Endpoint Manager admin center using an account protection policy." border="true" lightbox="images/whfb-intune-account-protection-enable.png":::
+
+#### [:::image type="icon" source="../../images/icons/group-policy.svg"::: **GPO**](#tab/gpo)
+
+## Configure Windows Hello for Business using group policies
+
+For hybrid Azure AD joined devices, you can use group policies to configure Windows Hello for Business.
+It's suggested to create a security group (for example, *Windows Hello for Business Users*) to make it easy to deploy Windows Hello for Business in phases. You assign **Group Policy permissions** to this group to simplify the deployment by adding the users to the group.
+
+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 Intune, Group Policy settings will take precedence and Intune settings will be ignored. For more information 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 group policy setting
+
+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* setting for computer or users:
+
+- Deploying this policy setting to computers (or group of 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 (or group of users), results in only that user attempting a Windows Hello for Business enrollment
+
+If both user and computer policy settings are deployed, the user policy setting has precedence.
+
+### Enable and configure Windows Hello for Business
+
+Sign-in a domain controller or management workstations with *Domain Admin* equivalent credentials.
+
+1. Start 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 *Enable Windows Hello for Business* in the name box and select **OK**
+1. In the content pane, right-click the **Enable Windows Hello for Business** group policy object and select **Edit**
+1. In the navigation pane, expand **Policies** under **User Configuration**
+1. Expand **Administrative Templates > Windows Component**, and select **Windows Hello for Business**
+1. In the content pane, open **Use Windows Hello for Business**. Select **Enable > OK**
+1. Close the **Group Policy Management Editor**
+
+> [!NOTE]
+> Windows Hello for Business can be configured using different policies. These policies are optional to configure, but it's recommended to enable *Use a hardware security device*.
+> 
+> For more information about these policies, see [Group Policy settings for Windows Hello for Business](hello-manage-in-organization.md#group-policy-settings-for-windows-hello-for-business).
+
+### Configure security for GPO
+
+The best way to deploy the Windows Hello for Business GPO is to use security group filtering. Only members of the targeted security group will provision Windows Hello for Business, enabling a phased rollout.
+
+1. Start the **Group Policy Management Console** (gpmc.msc)
+1. Expand the domain and select the **Group Policy Object** node in the navigation pane
+1. Open the **Enable Windows Hello for Business** GPO
+1. In the **Security Filtering** section of the content pane, select **Add**.  Type the name of the security group you previously created (for example, *Windows Hello for Business Users*) and select **OK**
+1. Select the **Delegation** tab. Select **Authenticated Users > Advanced**
+1. 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. Select **OK**
+
+### Deploy the Windows Hello for Business Group Policy object
+
+The application of Group Policy object uses security group filtering. This solution allows linking the GPO to the domain, ensuring the GPO is scoped to all users. The security group filtering ensures that only the members of the *Windows Hello for Business Users* global group receive and apply the GPO, which results in the provisioning of Windows Hello for Business.
+
+1. Start the **Group Policy Management Console** (gpmc.msc)
+1. In the navigation pane, expand the domain and right-click the node that has your Active Directory domain name and select **Link an existing GPO**
+1. 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 select **OK**
+
+### Add members to the targeted group
+
+Users (or devices) 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 members to the *Windows Hello for Business Users* group. Users and groups who aren't members of this group won't attempt to enroll for Windows Hello for Business.
+
+---
+
+## Enroll in 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].
+
+:::image type="content" source="images/Event358.png" alt-text="Details about event ID 358 showing that the device is ready to enroll in Windows Hello for Business." border="false" lightbox="images/Event358.png":::
+
+### PIN Setup
+
+The following process 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 enrollment flow proceeds to the multi-factor authentication phase. The process informs the user that there's an MFA contact attempt, using the 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.
+
+<!--links-->
+[AZ-4]: /azure/active-directory/devices/troubleshoot-device-dsregcmd
+[AZ-5]: /azure/active-directory/connect/active-directory-aadconnectsync-feature-scheduler
+
+[MEM-1]: /mem/intune/configuration/settings-catalog
+[MEM-2]: /mem/intune/protect/security-baselines
+[MEM-3]: /mem/intune/configuration/custom-settings-configure
+[MEM-4]: /windows/client-management/mdm/passportforwork-csp
+[MEM-5]: /mem/intune/protect/endpoint-security-account-protection-policy
+[MEM-6]: /mem/intune/protect/identity-protection-configure

windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md

@@ -0,0 +1,102 @@
+---
+title: Configure and validate the Public Key Infrastructure in an hybrid key trust model
+description: Configure and validate the Public Key Infrastructure when deploying Windows Hello for Business in an hybrid key trust model.
+ms.date: 01/03/2023
+appliesto: 
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
+ms.topic: tutorial
+---
+# Configure and validate the Public Key Infrastructure - hybrid key trust
+
+[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-key-trust.md)]
+
+Windows Hello for Business must have a Public Key Infrastructure (PKI) when using the *key trust* model. 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 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 (`msDS-KeyCredentialLink`).
+
+A Windows Server-based PKI or a third-party Enterprise certification authority can be used. 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
+
+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.\
+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.
+
+### 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
+    ```
+1. Use the following command to configure the CA using a basic certification authority configuration
+    ```PowerShell
+    Install-AdcsCertificationAuthority
+    ```
+
+## Configure the enterprise PKI
+
+[!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.
+
+> [!IMPORTANT]
+> 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
+
+[!INCLUDE [dc-certificate-template-supersede](includes/dc-certificate-supersede.md)]
+
+[!INCLUDE [unpublish-superseded-templates](includes/unpublish-superseded-templates.md)]
+
+### Publish the 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.
+
+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)* template you created in the previous steps > select **OK**
+1. Close the console
+
+> [!IMPORTANT]
+> If you plan to deploy **Azure AD joined** devices, and require single sign-on (SSO) to on-premises resources when signing in with Windows Hello for Business, follow the procedures to [update your CA to include an http-based CRL distribution point](hello-hybrid-aadj-sso.md).
+
+## Configure and deploy certificates to domain controllers
+
+[!INCLUDE [dc-certificate-deployment](includes/dc-certificate-deployment.md)]
+
+## Validate the configuration
+
+[!INCLUDE [dc-certificate-validate](includes/dc-certificate-validate.md)]
+
+## Section review and next steps
+
+Before moving to the next section, ensure the following steps are complete:
+
+> [!div class="checklist"]
+> - Configure domain controller certificates
+> - Supersede existing domain controller certificates
+> - Unpublish superseded certificate templates
+> - Publish the certificate template to the CA
+> - Deploy certificates to the domain controllers
+> - Validate the domain controllers configuration
+
+> [!div class="nextstepaction"]
+> [Next: configure and provision Windows Hello for Business >](hello-hybrid-key-trust-provision.md)
+
+<!--links-->
+[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)

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

@@ -1,40 +1,102 @@
 ---
-title: Hybrid Key Trust Deployment (Windows Hello for Business)
+title: Windows Hello for Business hybrid key trust deployment
-description: Review this deployment guide to successfully deploy Windows Hello for Business in a hybrid key trust scenario.
+description: Learn how to deploy Windows Hello for Business in a hybrid key trust scenario.
-ms.date: 08/20/2018
+ms.date: 12/28/2022
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
-ms.topic: article
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
+ms.topic: how-to
 ---
-# Hybrid Azure AD joined Key Trust Deployment
+# Hybrid key trust deployment
 
-[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-key-trust.md)]
+[!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.
+Hybrid environments are distributed systems that enable organizations to use on-premises and Azure AD-protected 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.
 
-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).
+This deployment guide describes how to deploy Windows Hello for Business in a hybrid key trust scenario.
 
-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.
+> [!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).
 
-## New Deployment Baseline ##
+It is recommended that you review the [Windows Hello for Business planning guide](hello-planning-guide.md) 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.
 
-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.
+## Prerequisites
 
-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.
+The following prerequisites must be met for a hybrid key trust deployment:
 
-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.
+> [!div class="checklist"]
+> * Directories and directory synchronization
+> * Authentication to Azure AD
+> * Device registration
+> * Public Key Infrastructure
+> * Multi-factor authentication
+> * Device management
+
+### 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 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 UPN suffix cannot be added as a verified domain in Azure AD.
+
+### Authentication to Azure AD
+
+Authentication to Azure AD can be configured with or without federation:
+
+- [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 a third-party federation service is required for federated environments
+
+### Device registration
+
+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
+
+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][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][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
+
+To configure Windows Hello for Business, devices can be configured through a mobile device management (MDM) solution like Intune, or via group policy.
+
+## Next steps
+
+Once the prerequisites are met, deploying Windows Hello for Business with a hybrid key trust model consists of the following steps:
+
+> [!div class="checklist"]
+> * Configure and validate the PKI
+> * Configure Windows Hello for Business settings
+> * Provision Windows Hello for Business on Windows clients
+> * Configure single sign-on (SSO) for Azure AD joined devices
 
 > [!div class="nextstepaction"]
-> [Prerequisites](hello-hybrid-key-trust-prereqs.md)
+> [Next: configure and validate the Public Key Infrastructure >](hello-hybrid-key-trust-validate-pki.md)
 
-<br><br>
+<!--links-->
+[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
+[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
 
-## Follow the Windows Hello for Business hybrid key trust deployment guide
+[SER-1]: /windows-server/identity/ad-fs/operations/configure-ad-fs-2016-and-azure-mfa
-
-1. Overview (*You are here*)
-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](hello-hybrid-key-whfb-provision.md)

windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-provision.md

@@ -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: 
-- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
-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**.
-
-![Event358.](images/Event358-2.png)
-
-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**.
-
-![Setup a PIN Provisioning.](images/setupapin.png)
-
-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.
-  
-![MFA prompt during provisioning.](images/mfa.png)
-
-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.
-
-![Create a PIN during provisioning.](images/createPin.png)
-
-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.
-
-<br><br>
-
-<hr>
-
-## Follow the Windows Hello for Business hybrid key trust deployment guide
-
-1. [Overview](hello-hybrid-key-trust.md)
-2. [Prerequisites](hello-hybrid-key-trust-prereqs.md)
-3. [New Installation Baseline](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*)

windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-ad.md

@@ -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: 
-- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
-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)
-
-<br><br>
-
-<hr>
-
-## 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)

windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-dir-sync.md

@@ -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: 
-- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
-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)  
-
-<hr>
-
-## 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)

windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-pki.md

@@ -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: 
-- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
-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)
-
-<br><br>
-
-<hr>
-
-## 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)

windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-policy.md

@@ -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: 
-- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
-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 <20> Auto-Enrollment** and select **Properties**.
-9. Select **Enabled** from the **Configuration Model** list.
-10. Select the **Renew expired certificates**, **update pending certificates**, and **remove revoked certificates** check box.
-11. Select the **Update certificates that use certificate templates** check box.
-12. Click **OK**. Close the **Group Policy Management Editor**.
-
-#### Deploy the Domain Controller Auto Certificate Enrollment Group Policy Object
-
-Sign-in a domain controller or management workstations with _Domain Admin_ equivalent credentials.
-
-1. Start the **Group Policy Management Console** (gpmc.msc)
-2. In the navigation pane, expand the domain and expand the node that has your Active Directory domain name.  Right-click the **Domain Controllers** organizational unit and click **Link an existing GPO<50>**
-3. In the **Select GPO** dialog box, select **Domain Controller Auto Certificate Enrollment** or the name of the domain controller certificate enrollment Group Policy object you previously created and click **OK**.
-
->[!IMPORTANT]
->If you don't find options in GPO, you have to load the [PolicyDefinitions folder](/troubleshoot/windows-client/group-policy/create-and-manage-central-store). 
-
-### Windows Hello for Business Group Policy
-
-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)
-
-<br><br>
-
-<hr>
-
-## 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)

windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings.md

@@ -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: 
-- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
-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)

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*.
 

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.

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.
 

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:
 

windows/security/identity-protection/hello-for-business/hello-key-trust-validate-pki.md

@@ -9,161 +9,23 @@ 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.
 
-## Deploy an enterprise certification authority
+[!INCLUDE [lab-based-pki-deploy](includes/lab-based-pki-deploy.md)]
 
-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.
+## Configure the enterprise PKI
 
-### Lab-based PKI
+[!INCLUDE [dc-certificate-template](includes/dc-certificate-template.md)]
 
-The following instructions may be used to deploy simple public key infrastructure that is suitable **for a lab environment**.
+[!INCLUDE [dc-certificate-template-supersede](includes/dc-certificate-supersede.md)]
 
-Sign in using *Enterprise Administrator* equivalent credentials on a Windows Server where you want the certification authority (CA) installed.
+[!INCLUDE [web-server-certificate-template](includes/web-server-certificate-template.md)]
 
->[!NOTE]
+[!INCLUDE [unpublish-superseded-templates](includes/unpublish-superseded-templates.md)]
->Never install a certification authority on a domain controller in a production environment.
 
-1. Open an elevated Windows PowerShell prompt
+### Publish certificate templates to the CA
-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 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.
-
-<br>
-<details>
-<summary><b>Configure domain controller certificates</b></summary>
-
-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
-
-</details>
-
-
-<br>
-<details>
-<summary><b>Supersede existing domain controller certificates</b></summary>
-
-The domain controllers may have an existing domain controller certificate. The Active Directory Certificate Services provides a default certificate template for domain controllers called *domain controller certificate*. Later releases of Windows Server provided a new certificate template called *domain controller authentication certificate*. These certificate templates were provided prior to the update of the Kerberos specification that stated Key Distribution Centers (KDCs) performing certificate authentication needed to include the *KDC Authentication* extension. 
-
-The *Kerberos Authentication* certificate template is the most current certificate template designated for domain controllers, and should be the one you deploy to all your domain controllers.\
-The *autoenrollment* feature allows you to replace the domain controller certificates. Use the following configuration to replace older domain controller certificates with new ones, using the *Kerberos Authentication* certificate template.
-
-Sign in to a CA or management workstations with *Enterprise Administrator* equivalent credentials.
-
-1. Open the **Certification Authority** management console
-1. Right-click **Certificate Templates > Manage**
-1. In the **Certificate Template Console**, right-click the *Domain Controller Authentication (Kerberos)* (or the name of the certificate template you created in the previous section) template in the details pane and select **Properties**
-1. Select the **Superseded Templates** tab. Select **Add**
-1. From the **Add Superseded Template** dialog, select the *Domain Controller* certificate template and select **OK > Add**
-1. From the **Add Superseded Template** dialog, select the *Domain Controller Authentication* certificate template and select **OK**
-1. From the **Add Superseded Template** dialog, select the *Kerberos Authentication* certificate template and select **OK**
-1. Add any other enterprise certificate templates that were previously configured for domain controllers to the **Superseded Templates** tab
-1. Select **OK** and close the **Certificate Templates** console
-
-The certificate template is configured to supersede all the certificate templates provided in the certificate templates superseded templates list. However, the certificate template and the superseding of certificate templates isn't active until the certificate template is published to one or more certificate authorities.
-
-</details>
-
-<br>
-<details>
-<summary><b>Configure an internal web server certificate template</b></summary>
-
-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
-
-</details>
-
-<br>
-<details>
-<summary><b>Unpublish Superseded Certificate Templates</b></summary>
-
-The certification authority only issues certificates based on published certificate templates. For security, it's a good practice to unpublish certificate templates that the CA isn't configured to issue. This includes the pre-published certificate template from the role installation and any superseded certificate templates.
-
-The newly created *domain controller authentication* certificate template supersedes previous domain controller certificate templates. Therefore, you need to unpublish these certificate templates from all issuing certificate authorities.
-
-Sign in to the CA or management workstation with *Enterprise Administrator* equivalent credentials.
-
-1. Open the **Certification Authority** management console
-1. Expand the parent node from the navigation pane > **Certificate Templates**
-1. Right-click the *Domain Controller* certificate template and select **Delete**. Select **Yes** on the **Disable certificate templates** window
-1. Repeat step 3 for the *Domain Controller Authentication* and *Kerberos Authentication* certificate templates
-
-</details>
-
-<br>
-<details>
-<summary><b>Publish certificate templates to the CA</b></summary>
 
 A certification authority can only issue certificates for certificate templates that are published to it. If you have more than one CA, and you want more CAs to issue certificates based on the certificate template, then you must publish the certificate template to them.
 
@@ -178,71 +40,13 @@ Sign in to the CA or management workstations with **Enterprise Admin** equivalen
    - To unpublish a certificate template, right-click the certificate template you want to unpublish and select **Delete**. Select **Yes** to confirm the operation
 1. Close the console
 
-</details>
+## Configure and deploy certificates to domain controllers
 
-### Configure automatic certificate enrollment for the domain controllers
+[!INCLUDE [dc-certificate-deployment](includes/dc-certificate-deployment.md)]
-
-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.
+[!INCLUDE [dc-certificate-validate](includes/dc-certificate-validate.md)]
-
-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)

windows/security/identity-protection/hello-for-business/hello-manage-in-organization.md

@@ -131,28 +131,4 @@ All PIN complexity policies are grouped separately from feature enablement and a
 >- MinimumPINLength - 8
 >- Digits - 1
 >- LowercaseLetters - 1
->- SpecialCharacters - 1
+>- SpecialCharacters - 1
-
-<!--
-## How to use Windows Hello for Business with Azure Active Directory
-
-There are three scenarios for using Windows Hello for Business in Azure AD-only organizations:
-
-- **Organizations that use the version of Azure AD included with Office 365**. For these organizations, no additional work is necessary. When Windows 10 was released to general availability, Microsoft changed the behavior of the Office 365 Azure AD stack. When a user selects the option to join a work or school network, the device is automatically joined to the Office 365 tenant's directory partition, a certificate is issued for the device, and it becomes eligible for Office 365 MDM if the tenant has subscribed to that feature. In addition, the user will be prompted to log on and, if MFA is enabled, to enter an MFA proof that Azure AD sends to his or her phone.
-- **Organizations that use the free tier of Azure AD**. For these organizations, Microsoft has not enabled automatic domain join to Azure AD. Organizations that have signed up for the free tier have the option to enable or disable this feature, so automatic domain join won't be enabled unless and until the organization's administrators decide to enable it. When that feature is enabled, devices that join the Azure AD domain by using the Connect to work or school dialog box will be automatically registered with Windows Hello for Business support, but previously joined devices will not be registered. 
-- **Organizations that have subscribed to Azure AD Premium** have access to the full set of Azure AD MDM features. These features include controls to manage Windows Hello for Business. You can set policies to disable or force the use of Windows Hello for Business, require the use of a TPM, and control the length and strength of PINs set on the device.
-
-If you want to use Windows Hello for Business with certificates, you'll need a device registration system. That means that you set up Configuration Manager, Microsoft Intune, or a compatible non-Microsoft MDM system and enable it to enroll devices. This is a prerequisite step to use Windows Hello for Business with certificates, no matter the IDP, because the enrollment system is responsible for provisioning the devices with the necessary certificates.
-
-## Related topics
-
-- [Windows Hello for Business](hello-identity-verification.md)
-- [How Windows Hello for Business works](hello-how-it-works.md)
-- [Why a PIN is better than a password](hello-why-pin-is-better-than-password.md)
-- [Prepare people to use Windows Hello](hello-prepare-people-to-use.md)
-- [Windows Hello and password changes](hello-and-password-changes.md)
-- [Windows Hello errors during PIN creation](hello-errors-during-pin-creation.md)
-- [Event ID 300 - Windows Hello successfully created](hello-event-300.md)
-- [Windows Hello biometrics in the enterprise](hello-biometrics-in-enterprise.md)
-
--->

windows/security/identity-protection/hello-for-business/includes/auth-certificate-template.md

@@ -0,0 +1,83 @@
+---
+ms.date: 12/28/2022
+ms.topic: include
+---
+
+### Configure a Windows Hello for Business authentication certificate template
+
+During Windows Hello for Business provisioning, Windows clients request an authentication certificate from AD FS, which requests the authentication certificate on behalf of the user. This task configures the Windows Hello for Business authentication 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** and select **Manage**
+1. Right-click the **Smartcard Logon** template and choose **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 *WHFB Authentication* 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 deployment.
+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. On the **Extensions** tab, verify the **Application Policies** extension includes **Smart Card Logon**
+1. On the **Issuance Requirements** tab, 
+   - Select the **This number of authorized signatures** check box. Type *1* in the text box
+   - Select **Application policy** from the **Policy type required in signature**
+   - Select **Certificate Request Agent** from in the **Application policy** list
+   - Select the **Valid existing certificate** option
+1. On the **Subject** tab, 
+   - Select the **Build from this Active Directory information** button
+   - Select **Fully distinguished name** from the **Subject name format** list
+   - Select the **User Principal Name (UPN)** check box under **Include this information in alternative subject name**
+1. On the **Request Handling** tab, select the **Renew with same key** check box
+1. On the **Security** tab, select **Add**. Target an Active Directory security group that contains the users that you want to enroll in Windows Hello for Business. For example, if you have a group called *Window Hello for Business Users*, type it in the **Enter the object names to select** text box and select **OK**
+1. Select the **Windows Hello for Business Users** from the **Group or users names** list. In the **Permissions for Windows Hello for Business Users** section:
+   - Select the **Allow** check box for the **Enroll** permission
+   - Excluding the group above (for example, *Window Hello for Business Users*), clear the **Allow** check box for the **Enroll** and **Autoenroll** permissions for all other entries in the **Group or users names** section if the check boxes aren't already cleared
+   - Select **OK**
+1. If you previously issued Windows Hello for Business sign-in certificates using Configuration Manger and are switching to an AD FS registration authority, then on the **Superseded Templates** tab, add the previously used **Windows Hello for Business Authentication** template(s), so they'll be superseded by this template for the users that have Enroll permission for this template
+1. Select on the **Apply** to save changes and close the console
+
+#### Mark the template as the Windows Hello Sign-in template
+
+Sign in to a CA or management workstations with *Enterprise Administrator* equivalent credentials
+
+Open an elevated command prompt end execute the following command
+
+```cmd
+certutil.exe -dsTemplate WHFBAuthentication msPKI-Private-Key-Flag +CTPRIVATEKEY_FLAG_HELLO_LOGON_KEY
+```
+
+If the template was changed successfully, the output of the command will contain old and new values of the template parameters. The new value must contain the `CTPRIVATEKEY_FLAG_HELLO_LOGON_KEY` parameter. Example:
+
+```cmd
+CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=[yourdomain]:WHFBAuthentication
+
+Old Value:
+msPKI-Private-Key-Flag REG_DWORD = 5050080 (84213888)
+CTPRIVATEKEY_FLAG_REQUIRE_SAME_KEY_RENEWAL -- 80 (128)
+CTPRIVATEKEY_FLAG_ATTEST_NONE -- 0
+TEMPLATE_SERVER_VER_WINBLUE<<CTPRIVATEKEY_FLAG_SERVERVERSION_SHIFT -- 50000 (327680)
+TEMPLATE_CLIENT_VER_WINBLUE<<CTPRIVATEKEY_FLAG_CLIENTVERSION_SHIFT -- 5000000 (83886080)
+
+New Value:
+msPKI-Private-Key-Flag REG_DWORD = 5250080 (86311040)
+CTPRIVATEKEY_FLAG_REQUIRE_SAME_KEY_RENEWAL -- 80 (128)
+CTPRIVATEKEY_FLAG_ATTEST_NONE -- 0
+TEMPLATE_SERVER_VER_WINBLUE<<CTPRIVATEKEY_FLAG_SERVERVERSION_SHIFT -- 50000 (327680)
+CTPRIVATEKEY_FLAG_HELLO_LOGON_KEY -- 200000 (2097152)
+TEMPLATE_CLIENT_VER_WINBLUE<<CTPRIVATEKEY_FLAG_CLIENTVERSION_SHIFT -- 5000000 (83886080)
+CertUtil: -dsTemplate command completed successfully."
+```
+
+>[!NOTE]
+>If you gave your Windows Hello for Business Authentication certificate template a different name, then replace `WHFBAuthentication` in the above command with the name of your certificate template. It's important that you use the template name rather than the template display name. You can view the template name on the **General** tab of the certificate template using the Certificate Template management console (certtmpl.msc). Or, you can view the template name using the `Get-CATemplate` ADCS Administration Windows PowerShell cmdlet on your certification authority.
+
+</details>

windows/security/identity-protection/hello-for-business/includes/dc-certificate-deployment.md

@@ -0,0 +1,32 @@
+---
+ms.date: 12/28/2022
+ms.topic: include
+---
+
+### 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. For domain controllers to automatically enroll and renew of certificates, configure a GPO for automatic certificate enrollment, and link it to the *Domain Controllers* 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**
+

windows/security/identity-protection/hello-for-business/includes/dc-certificate-supersede.md

@@ -0,0 +1,33 @@
+---
+ms.date: 12/28/2022
+ms.topic: include
+---
+
+### 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 *superseded templates* list.\
+However, the certificate template and the superseding of certificate templates isn't active until the 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`
+

windows/security/identity-protection/hello-for-business/includes/dc-certificate-template.md

@@ -0,0 +1,51 @@
+---
+ms.date: 12/28/2022
+ms.topic: include
+---
+
+### Configure domain controller certificates
+
+Clients must trust the domain controllers, and the best way to enable the trust is to ensure that 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. The 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.
+
+> [!IMPORTANT]
+> The certificates issued to the domain controllers must meet the following requirements:
+> - The *Certificate Revocation List (CRL) distribution point* extension must point 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 *extended 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
+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
+

windows/security/identity-protection/hello-for-business/includes/dc-certificate-validate.md

@@ -0,0 +1,39 @@
+---
+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 deployment is to validate phases of work prior to moving to the next phase.
+
+Confirm your domain controllers enroll the correct certificates and not any superseded certificate templates. Check that each domain controller completed the certificate autoenrollment.
+
+### 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.

windows/security/identity-protection/hello-for-business/includes/enrollment-agent-certificate-template.md

@@ -0,0 +1,79 @@
+---
+ms.date: 01/03/2022
+ms.topic: include
+---
+
+### Configure an enrollment agent certificate template
+
+A certificate registration authority (CRA) is a trusted authority that validates certificate request. Once it validates the request, it presents the request to the certification authority (CA) for issuance. The CA issues the certificate, returns it to the CRA, which returns the certificate to the requesting user. Windows Hello for Business certificate trust deployments use AD FS as the CRA.
+
+The CRA enrolls for an *enrollment agent certificate*. Once the CRA verifies the certificate request, it signs the certificate request using its enrollment agent certificate and sends it to the CA. The Windows Hello for Business Authentication certificate template is configured to only issue certificates to certificate requests that have been signed with an enrollment agent certificate. The CA only issues a certificate for that template if the registration authority signs the certificate request.
+
+> [!IMPORTANT]
+> Follow the procedures below based on the AD FS service account used in your environment.
+
+#### Create an enrollment agent certificate for Group Managed Service Accounts (GMSA)
+
+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 on the **Exchange Enrollment Agent (Offline request)** template 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 *WHFB Enrollment Agent* in **Template display name**
+   - Adjust the validity and renewal period to meet your enterprise's needs
+1. On the **Subject** tab, select the **Supply in the request** button if it isn't already selected
+
+   > [!NOTE]
+   > Group Managed Service Accounts (GMSA) do not support the *Build from this Active Directory information* option and will result in the AD FS server failing to enroll the enrollment agent certificate. You must configure the certificate template with *Supply in the request* to ensure that AD FS servers can perform the automatic enrollment and renewal of the enrollment agent certificate.
+
+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. On the **Security** tab, select **Add**
+1. Select **Object Types** and select the **Service Accounts** check box. Select **OK**
+1. Type *adfssvc* in the **Enter the object names to select** text box and select **OK**
+1. Select the **adfssvc** from the **Group or users names** list. In the **Permissions for adfssvc** section:
+   - In the **Permissions for adfssvc** section, select the **Allow** check box for the **Enroll** permission
+   - Excluding the **adfssvc** user, clear the **Allow** check box for the **Enroll** and **Autoenroll** permissions for all other items in the **Group or users names** list
+   - Select **OK**
+1. Close the console
+
+#### Create an enrollment agent certificate for a standard service account
+
+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 on the **Exchange Enrollment Agent (Offline request)** template 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 *WHFB Enrollment Agent* in **Template display name**
+   - Adjust the validity and renewal period to meet your enterprise's needs
+1. On the **Subject** tab:
+   - Select the **Build from this Active Directory information** button
+   - Select **Fully distinguished name** from the **Subject name format**
+   - Select the **User Principal Name (UPN)** check box under **Include this information in alternative subject name**
+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. On the **Security** tab, select **Add**
+1. Select **Object Types** and select the **Service Accounts** check box. Select **OK**
+1. Type *adfssvc* in the **Enter the object names to select** text box and select **OK**
+1. Select the **adfssvc** from the **Group or users names** list. In the **Permissions for adfssvc** section:
+   - In the **Permissions for adfssvc** section, select the **Allow** check box for the **Enroll** permission
+   - Excluding the **adfssvc** user, clear the **Allow** check box for the **Enroll** and **Autoenroll** permissions for all other items in the **Group or users names** list
+   - Select **OK**
+1. Close the console
+

windows/security/identity-protection/hello-for-business/includes/hello-cloud.md

@@ -1,6 +1,4 @@
 ---
-author: paolomatarazzo
-ms.author: paoloma
 ms.date: 12/08/2022
 ms.topic: include
 ---

windows/security/identity-protection/hello-for-business/includes/hello-deployment-cloud.md

@@ -0,0 +1,6 @@
+---
+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")

windows/security/identity-protection/hello-for-business/includes/hello-deployment-hybrid.md

@@ -0,0 +1,6 @@
+---
+ms.date: 12/08/2022
+ms.topic: include
+---
+
+[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")

windows/security/identity-protection/hello-for-business/includes/hello-deployment-onpremises.md

@@ -0,0 +1,6 @@
+---
+ms.date: 12/08/2022
+ms.topic: include
+---
+
+[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")

windows/security/identity-protection/hello-for-business/includes/hello-hybrid-cert-trust-aad.md

@@ -1,6 +1,4 @@
 ---
-author: paolomatarazzo
-ms.author: paoloma
 ms.date: 12/08/2022
 ms.topic: include
 ---

windows/security/identity-protection/hello-for-business/includes/hello-hybrid-cert-trust-ad.md

@@ -1,6 +1,4 @@
 ---
-author: paolomatarazzo
-ms.author: paoloma
 ms.date: 12/08/2022
 ms.topic: include
 ---

windows/security/identity-protection/hello-for-business/includes/hello-hybrid-cert-trust.md

@@ -1,6 +1,4 @@
 ---
-author: paolomatarazzo
-ms.author: paoloma
 ms.date: 12/08/2022
 ms.topic: include
 ---

windows/security/identity-protection/hello-for-business/includes/hello-hybrid-cloudkerb-trust.md

@@ -1,6 +1,4 @@
 ---
-author: paolomatarazzo
-ms.author: paoloma
 ms.date: 12/08/2022
 ms.topic: include
 ---

windows/security/identity-protection/hello-for-business/includes/hello-hybrid-key-trust-ad.md

@@ -1,6 +1,4 @@
 ---
-author: paolomatarazzo
-ms.author: paoloma
 ms.date: 12/08/2022
 ms.topic: include
 ---

windows/security/identity-protection/hello-for-business/includes/hello-hybrid-key-trust.md

@@ -1,6 +1,4 @@
 ---
-author: paolomatarazzo
-ms.author: paoloma
 ms.date: 12/08/2022
 ms.topic: include
 ---

windows/security/identity-protection/hello-for-business/includes/hello-hybrid-keycert-trust-aad.md

@@ -1,6 +1,4 @@
 ---
-author: paolomatarazzo
-ms.author: paoloma
 ms.date: 12/08/2022
 ms.topic: include
 ---

windows/security/identity-protection/hello-for-business/includes/hello-intro.md

@@ -1,6 +1,4 @@
 ---
-author: paolomatarazzo
-ms.author: paoloma
 ms.date: 12/08/2022
 ms.topic: include
 ---

windows/security/identity-protection/hello-for-business/includes/hello-join-aad.md

@@ -0,0 +1,6 @@
+---
+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")

windows/security/identity-protection/hello-for-business/includes/hello-join-domain.md

@@ -0,0 +1,6 @@
+---
+ms.date: 12/08/2022
+ms.topic: include
+---
+
+[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")

windows/security/identity-protection/hello-for-business/includes/hello-join-hybrid.md

@@ -0,0 +1,6 @@
+---
+ms.date: 12/08/2022
+ms.topic: include
+---
+
+[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")

windows/security/identity-protection/hello-for-business/includes/hello-on-premises-cert-trust.md

@@ -1,6 +1,4 @@
 ---
-author: paolomatarazzo
-ms.author: paoloma
 ms.date: 12/08/2022
 ms.topic: include
 ---

windows/security/identity-protection/hello-for-business/includes/hello-on-premises-key-trust.md

@@ -1,6 +1,4 @@
 ---
-author: paolomatarazzo
-ms.author: paoloma
 ms.date: 12/08/2022
 ms.topic: include
 ---

windows/security/identity-protection/hello-for-business/includes/hello-trust-certificate.md

@@ -0,0 +1,6 @@
+---
+ms.date: 12/08/2022
+ms.topic: include
+---
+
+[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")

windows/security/identity-protection/hello-for-business/includes/hello-trust-cloud-kerberos.md

@@ -0,0 +1,6 @@
+---
+ms.date: 12/08/2022
+ms.topic: include
+---
+
+[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")

windows/security/identity-protection/hello-for-business/includes/hello-trust-key.md

@@ -0,0 +1,6 @@
+---
+ms.date: 12/08/2022
+ms.topic: include
+---
+
+[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")

windows/security/identity-protection/hello-for-business/includes/lab-based-pki-deploy.md

@@ -0,0 +1,32 @@
+---
+ms.date: 01/03/2023
+ms.topic: include
+---
+
+## 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.\
+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.
+
+### 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
+    ```
+
+<!--links-->
+[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)

windows/security/identity-protection/hello-for-business/includes/unpublish-superseded-templates.md

@@ -0,0 +1,18 @@
+---
+ms.date: 12/28/2022
+ms.topic: include
+---
+
+### 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, including the pre-published templates from the role installation and any superseded 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
+

windows/security/identity-protection/hello-for-business/includes/web-server-certificate-template.md

@@ -0,0 +1,38 @@
+---
+ms.date: 01/23/2023
+ms.topic: include
+---
+
+### Configure an internal web server certificate template
+
+Windows clients communicate with AD FS via HTTPS. To meet this need, a *server authentication* certificate must be issued to all the nodes in the AD FS farm. On-premises deployments can use a *server authentication* certificate issued by the enterprise PKI. A *server authentication* certificate template must be configured, so the AD FS nodes can request a 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
+

windows/security/identity-protection/hello-for-business/toc.yml

@@ -31,66 +31,26 @@
       items: 
       - name: Overview
         href: hello-hybrid-key-trust.md
-      - name: Prerequisites
+      - name: Configure and validate the PKI
-        href: hello-hybrid-key-trust-prereqs.md
+        href: hello-hybrid-key-trust-validate-pki.md
-      - name: New installation baseline
+      - name: Configure and provision Windows Hello for Business
-        href: hello-hybrid-key-new-install.md
+        href: hello-hybrid-key-trust-provision.md
-      - name: Configure directory synchronization
+      - name: Configure SSO for Azure AD joined devices
-        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
     - name: Certificate trust deployment
       items: 
       - name: Overview
         href: hello-hybrid-cert-trust.md
-      - name: Prerequisites
+      - name: Configure and validate the PKI
-        href: hello-hybrid-cert-trust-prereqs.md
+        href: hello-hybrid-cert-trust-validate-pki.md
-      - name: New installation baseline
+      - name: Configure AD FS
-        href: hello-hybrid-cert-new-install.md
+        href: hello-hybrid-cert-whfb-settings-adfs.md
-      - name: Configure Azure AD device registration
+      - name: Configure and provision Windows Hello for Business
-        href: hello-hybrid-cert-trust-devreg.md
-      - name: Configure Windows Hello for Business settings
-        items:
-        - name: Overview
-          href: hello-hybrid-cert-whfb-settings.md
-        - name: Configure Active Directory
-          href: hello-hybrid-cert-whfb-settings-ad.md
-        - name: Configure Azure AD Connect Sync
-          href: hello-hybrid-cert-whfb-settings-dir-sync.md
-        - name: Configure PKI
-          href: hello-hybrid-cert-whfb-settings-pki.md
-        - name: Configure AD FS
-          href: hello-hybrid-cert-whfb-settings-adfs.md
-        - name: Configure Group Policy settings
-          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
+      - name: Configure SSO for Azure AD joined devices
         href: hello-hybrid-aadj-sso.md
-      - name: Configure Azure AD joined devices for on-premises SSO
+      - name: Deploy certificates to Azure AD joined devices
-        href: hello-hybrid-aadj-sso-base.md
-      - name: Using certificates for on-premises SSO
         href: hello-hybrid-aadj-sso-cert.md
-    - name: Planning for Domain Controller load
-      href: hello-adequate-domain-controllers.md
   - name: On-premises deployments
     items:
     - name: Key trust deployment
@@ -99,7 +59,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
@@ -121,8 +81,8 @@
         href: hello-cert-trust-validate-deploy-mfa.md
       - name: Configure Windows Hello for Business policy settings
         href: hello-cert-trust-policy-settings.md
-    - name: Planning for Domain Controller load
+  - name: Planning for Domain Controller load
-      href: hello-adequate-domain-controllers.md
+    href: hello-adequate-domain-controllers.md
   - name: Deploy certificates for remote desktop (RDP) sign-in
     href: hello-deployment-rdp-certs.md
 - name: How-to Guides

windows/security/identity-protection/smart-cards/smart-card-certificate-requirements-and-enumeration.md

@@ -66,7 +66,7 @@ When a smart card is inserted, the following steps are performed.
 
 Although versions of Windows earlier than Windows Vista include support for smart cards, the types of certificates that smart cards can contain are limited. The limitations are:
 
--   Each certificate must have a user principal name (UPN) and the smart card sign-in object identifier (also known as OID) in the enhanced key usage (EKU) attribute field. There is a Group Policy setting, Allow ECC certificates to be used for logon and authentication, to make the EKU optional.
+-   Each certificate must have a user principal name (UPN) and the smart card sign-in object identifier (also known as OID) in the extended key usage (EKU) attribute field. There is a Group Policy setting, Allow ECC certificates to be used for logon and authentication, to make the EKU optional.
 
 -   Each certificate must be stored in the AT\_KEYEXCHANGE portion of the default CryptoAPI container, and non-default CryptoAPI containers are not supported.
 
@@ -190,7 +190,7 @@ The smart card certificate has specific format requirements when it is used with
 |   CRL distribution point location    |                                                                                               Not required                                                                                               |             The location must be specified, online, and available, for example:<br>\[1\]CRL Distribution Point<br>Distribution Point Name:<br>Full Name:<br>URL=`<https://server1.contoso.com/CertEnroll/caname.crl>`             |
 |              Key usage               |                                                                                            Digital signature                                                                                             |                                                                                                       Digital signature                                                                                                        |
 |          Basic constraints           |                                                                                               Not required                                                                                               |                                                                              \[Subject Type=End Entity, Path Length Constraint=None\] (Optional)                                                                               |
-|       Enhanced key usage (EKU)       | The smart card sign-in object identifier is not required.<br><br>**Note**&nbsp;&nbsp;If an EKU is present, it must contain the smart card sign-in EKU. Certificates with no EKU can be used for sign-in. |      -   Client Authentication (1.3.6.1.5.5.7.3.2)<br>The client authentication object identifier is required only if a certificate is used for SSL authentication.<br><br>- Smart Card Sign-in (1.3.6.1.4.1.311.20.2.2)       |
+|       extended key usage (EKU)       | The smart card sign-in object identifier is not required.<br><br>**Note**&nbsp;&nbsp;If an EKU is present, it must contain the smart card sign-in EKU. Certificates with no EKU can be used for sign-in. |      -   Client Authentication (1.3.6.1.5.5.7.3.2)<br>The client authentication object identifier is required only if a certificate is used for SSL authentication.<br><br>- Smart Card Sign-in (1.3.6.1.4.1.311.20.2.2)       |
 |       Subject alternative name       |                                                                            E-mail ID is not required for smart card sign-in.                                                                             |           Other Name: Principal Name=(UPN), for example:<br>UPN=user1@contoso.com<br>The UPN OtherName object identifier is 1.3.6.1.4.1.311.20.2.3.<br>The UPN OtherName value must be an ASN1-encoded UTF8 string.            |
 |               Subject                |                                                                                               Not required                                                                                               |                                                         Distinguished name of user. This field is a mandatory extension, but the population of this field is optional.                                                         |
 | Key exchange (AT\_KEYEXCHANGE field) |                               Not required for smart card sign-in certificates if a Group Policy setting is enabled. (By default, Group Policy settings are not enabled.)                                |                                                                                                          Not required                                                                                                          |

windows/security/identity-protection/smart-cards/smart-card-group-policy-and-registry-settings.md

@@ -93,10 +93,10 @@ The following table lists the default values for these GPO settings. Variations
 
 ### Allow certificates with no extended key usage certificate attribute
 
-You can use this policy setting to allow certificates without an enhanced key usage (EKU) set to be used for sign-in.
+You can use this policy setting to allow certificates without an extended key usage (EKU) set to be used for sign-in.
 
 > [!NOTE]
-> Enhanced key usage certificate attribute is also known as extended key usage.
+> extended key usage certificate attribute is also known as extended key usage.
 > 
 > In versions of Windows before Windows Vista, smart card certificates that are used to sign in require an EKU extension with a smart card logon object identifier. This policy setting can be used to modify that restriction.
 

windows/security/identity-protection/vpn/vpn-authentication.md

@@ -34,7 +34,7 @@ Windows supports a number of EAP authentication methods.
 
   - Certificate filtering:
     - Certificate filtering can be enabled to search for a particular certificate to use to authenticate with
-    - Filtering can be Issuer-based or Enhanced Key Usage (EKU)-based
+    - Filtering can be Issuer-based or extended key usage (EKU)-based
 
   - Server validation - with TLS, server validation can be toggled on or off:
     - Server name - specify the server to validate
@@ -88,7 +88,7 @@ See [EAP configuration](/windows/client-management/mdm/eap-configuration) for EA
 
 The following image shows the field for EAP XML in a Microsoft Intune VPN profile. The EAP XML field only appears when you select a built-in connection type (automatic, IKEv2, L2TP, PPTP).
 
-![EAP XML configuration in Intune profile.](images/vpn-eap-xml.png)
+:::image type="content" source="images/vpn-eap-xml.png" alt-text="EAP XML configuration in Intune profile.":::
 
 ## Related topics
 

windows/security/identity-protection/vpn/vpn-conditional-access.md

@@ -68,7 +68,7 @@ Two client-side configuration service providers are leveraged for VPN device com
    - **Sso**: entries under SSO should be used to direct the VPN client to use a certificate other than the VPN authentication certificate when accessing resources that require Kerberos authentication.
    - **Sso/Enabled**: if this field is set to **true**, the VPN client looks for a separate certificate for Kerberos authentication.
    - **Sso/IssuerHash**: hashes for the VPN client to look for the correct certificate for Kerberos authentication.
-   - **Sso/Eku**: comma-separated list of Enhanced Key Usage (EKU) extensions for the VPN client to look for the correct certificate for Kerberos authentication.
+   - **Sso/Eku**: comma-separated list of extended key usage (EKU) extensions for the VPN client to look for the correct certificate for Kerberos authentication.
    
 - HealthAttestation CSP (not a requirement) - functions performed by the HealthAttestation CSP include:
 

windows/security/includes/hello-deployment-cloud.md

@@ -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")

windows/security/includes/hello-deployment-hybrid.md

@@ -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")

windows/security/includes/hello-deployment-onpremises.md

@@ -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")

windows/security/includes/hello-join-aad.md

@@ -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")

windows/security/includes/hello-join-domain.md

@@ -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")

windows/security/includes/hello-join-hybrid.md

@@ -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")

windows/security/includes/hello-trust-certificate.md

@@ -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")

windows/security/includes/hello-trust-cloud-kerberos.md

@@ -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")

windows/security/includes/hello-trust-key.md

@@ -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")

windows/security/includes/intune-custom-settings-info.md

@@ -0,0 +1,8 @@
+---
+author: paolomatarazzo
+ms.author: paoloma
+ms.date: 01/03/2022
+ms.topic: include
+---
+
+For more information about how to create custom settings using Intune, see [Use custom settings for Windows devices in Intune](/mem/intune/configuration/custom-settings-windows-10).

windows/security/includes/intune-settings-catalog-1.md

@@ -0,0 +1,18 @@
+---
+author: paolomatarazzo
+ms.author: paoloma
+ms.date: 01/03/2022
+ms.topic: include
+---
+
+To configure devices with Microsoft Intune, use the settings catalog:
+
+  > [!TIP]
+  > If you're browsing with an account that can create Intune policies, you can skip to step 5 by using this direct link to <a href="https://go.microsoft.com/fwlink/?linkid=2109431#view/Microsoft_Intune_Workflows/SettingsCatalogWizardBlade/mode/create/platform/Windows%2010%20and%20later/policyType/SettingsCatalogWindows10" target="_blank"><b>create a Settings catalog policy</b></a> (opens in a new tab).
+
+1. Go to the <a href="https://go.microsoft.com/fwlink/?linkid=2109431" target="_blank"><b>Microsoft Endpoint Manager admin center</b></a>
+2. Select **Devices > Configuration profiles > Create profile**
+3. Select **Platform > Windows 10 and later** and **Profile type > Settings catalog**
+4. Select **Create**
+5. Specify a **Name** and, optionally, a **Description** > **Next**
+6. In the settings picker, add the following settings: