diff --git a/.openpublishing.redirection.json b/.openpublishing.redirection.json
index ae5ef4686a..5ac855eded 100644
--- a/.openpublishing.redirection.json
+++ b/.openpublishing.redirection.json
@@ -20279,6 +20279,11 @@
"source_path": "windows/deployment/windows-autopatch/operate/windows-autopatch-wqu-unsupported-policies.md",
"redirect_url": "/windows/deployment/windows-autopatch/references/windows-autopatch-wqu-unsupported-policies",
"redirect_document_id": true
+ },
+ {
+ "source_path": "windows/deployment/windows-autopatch/references/windows-autopatch-preview-addendum.md",
+ "redirect_url": "/windows/deployment/windows-autopatch/overview/windows-autopatch-overview",
+ "redirect_document_id": true
}
]
}
diff --git a/browsers/edge/breadcrumb/toc.yml b/browsers/edge/breadcrumb/toc.yml
index f417737985..83065b36a9 100644
--- a/browsers/edge/breadcrumb/toc.yml
+++ b/browsers/edge/breadcrumb/toc.yml
@@ -1,7 +1,3 @@
-- name: Docs
- tocHref: /
- topicHref: /
- items:
- - name: Microsoft Edge deployment
- tocHref: /microsoft-edge/deploy
- topicHref: /microsoft-edge/deploy/index
\ No newline at end of file
+- name: Microsoft Edge
+ tocHref: /microsoft-edge/
+ topicHref: /microsoft-edge/index
diff --git a/browsers/edge/docfx.json b/browsers/edge/docfx.json
index d786e0bbfb..d36533a87e 100644
--- a/browsers/edge/docfx.json
+++ b/browsers/edge/docfx.json
@@ -28,7 +28,7 @@
],
"globalMetadata": {
"recommendations": true,
- "breadcrumb_path": "/microsoft-edge/deploy/breadcrumb/toc.json",
+ "breadcrumb_path": "/microsoft-edge/breadcrumbs/toc.json",
"ROBOTS": "INDEX, FOLLOW",
"ms.technology": "microsoft-edge",
"audience": "ITPro",
diff --git a/education/windows/edu-stickers.md b/education/windows/edu-stickers.md
index ab2424149b..023393a04f 100644
--- a/education/windows/edu-stickers.md
+++ b/education/windows/edu-stickers.md
@@ -42,7 +42,7 @@ Stickers aren't enabled by default. Follow the instructions below to configure y
[!INCLUDE [intune-custom-settings-info](includes/intune-custom-settings-info.md)]
> [!TIP]
-> Use the following Graph call to automatically create the custom policy in your tenant without assignments nor scope tags.
+> Use the following Graph call to automatically create the custom policy in your tenant without assignments nor scope tags. [1](#footnote1)
```msgraph-interactive
POST https://graph.microsoft.com/beta/deviceManagement/deviceConfigurations
@@ -51,6 +51,8 @@ Content-Type: application/json
{"id":"00-0000-0000-0000-000000000000","displayName":"_MSLearn_Stickers","roleScopeTagIds":["0"],"@odata.type":"#microsoft.graph.windows10CustomConfiguration","omaSettings":[{"omaUri":"./Vendor/MSFT/Policy/Config/Stickers/EnableStickers","displayName":"EnableStickers","@odata.type":"#microsoft.graph.omaSettingInteger","value":1}]}
```
+1 When using this call, authenticate to your tenant in the Graph Explorer window. If it's the first time using Graph Explorer, you may need to authorize the application to access your tenant or to modify the existing permissions. This graph call requires *DeviceManagementConfiguration.ReadWrite.All* permissions.
+
#### [:::image type="icon" source="images/icons/provisioning-package.svg"::: **PPKG**](#tab/ppkg)
To configure devices using a provisioning package, [create a provisioning package][WIN-1] using Windows Configuration Designer (WCD) with the following settings:
@@ -78,8 +80,6 @@ Multiple stickers can be added from the picker by selecting them. The stickers c
Select the *X button* at the top of the screen to save your progress and close the sticker editor.
------------
-
[MEM-1]: /mem/intune/configuration/custom-settings-windows-10
[WIN-1]: /windows/configuration/provisioning-packages/provisioning-create-package
diff --git a/education/windows/windows-11-se-overview.md b/education/windows/windows-11-se-overview.md
index 654b8d7eca..efb6644b18 100644
--- a/education/windows/windows-11-se-overview.md
+++ b/education/windows/windows-11-se-overview.md
@@ -82,6 +82,7 @@ The following applications can also run on Windows 11 SE, and can be deployed us
| Application | Supported version | App Type | Vendor |
|-----------------------------------------|-------------------|----------|------------------------------|
| 3d builder | 15.2.10821.1070 | Win32 | Microsoft |
+|Absolute Software Endpoint Agent | 7.20.0.1 | Win32 | Absolute Software Corporation|
| AirSecure | 8.0.0 | Win32 | AIR |
| Alertus Desktop | 5.4.44.0 | Win32 | Alertus technologies |
| Brave Browser | 106.0.5249.65 | Win32 | Brave |
@@ -96,7 +97,7 @@ The following applications can also run on Windows 11 SE, and can be deployed us
| DRC INSIGHT Online Assessments | 12.0.0.0 | Store | Data recognition Corporation |
| Duo from Cisco | 2.25.0 | Win32 | Cisco |
| e-Speaking Voice and Speech recognition | 4.4.0.8 | Win32 | e-speaking |
-|Epson iProjection | 3.31 | Win32 | Epson |
+| Epson iProjection | 3.31 | Win32 | Epson |
| eTests | 4.0.25 | Win32 | CASAS |
| FortiClient | 7.2.0.4034+ | Win32 | Fortinet |
| Free NaturalReader | 16.1.2 | Win32 | Natural Soft |
@@ -106,9 +107,9 @@ The following applications can also run on Windows 11 SE, and can be deployed us
| Illuminate Lockdown Browser | 2.0.5 | Win32 | Illuminate Education |
| Immunet | 7.5.0.20795 | Win32 | Immunet |
| Impero Backdrop Client | 4.4.86 | Win32 | Impero Software |
-| Inspiration 10 | 10.11 | Win32 | Inspiration Software, Inc. |
+| Inspiration 10 | 10.11 | Win32 | TechEdology Ltd |
| JAWS for Windows | 2022.2112.24 | Win32 | Freedom Scientific |
-| Kite Student Portal | 8.0.3.0 | Win32 | Dynamic Learning Maps |
+| Kite Student Portal | 9.0.0.0 | Win32 | Dynamic Learning Maps |
| Kortext | 2.3.433.0 | Store | Kortext |
| Kurzweil 3000 Assistive Learning | 20.13.0000 | Win32 | Kurzweil Educational Systems |
| LanSchool Classic | 9.1.0.46 | Win32 | Stoneware, Inc. |
@@ -134,6 +135,7 @@ The following applications can also run on Windows 11 SE, and can be deployed us
| Respondus Lockdown Browser | 2.0.9.00 | Win32 | Respondus |
| Safe Exam Browser | 3.3.2.413 | Win32 | Safe Exam Browser |
| Senso.Cloud | 2021.11.15.0 | Win32 | Senso.Cloud |
+| Smoothwall Monitor | 2.8.0 | Win32 | Smoothwall Ltd
| SuperNova Magnifier & Screen Reader | 21.02 | Win32 | Dolphin Computer Access |
| SuperNova Magnifier & Speech | 21.02 | Win32 | Dolphin Computer Access |
| VitalSourceBookShelf | 10.2.26.0 | Win32 | VitalSource Technologies Inc |
diff --git a/windows/deployment/s-mode.md b/windows/deployment/s-mode.md
index 3fc8a55190..6263da1c9b 100644
--- a/windows/deployment/s-mode.md
+++ b/windows/deployment/s-mode.md
@@ -51,4 +51,4 @@ The [MSIX Packaging Tool](/windows/application-management/msix-app-packaging-too
- [Consumer applications for S mode](https://www.microsoft.com/windows/s-mode)
- [S mode devices](https://www.microsoft.com/windows/view-all-devices)
- [Windows Defender Application Control deployment guide](/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-deployment-guide)
-- [Microsoft Defender for Endpoint](/microsoft-365/windows/microsoft-defender-atp)
+- [Microsoft Defender for Endpoint documentation](/microsoft-365/security/defender-endpoint/)
diff --git a/windows/deployment/windows-autopatch/TOC.yml b/windows/deployment/windows-autopatch/TOC.yml
index bc71c6def8..e5dc7cb910 100644
--- a/windows/deployment/windows-autopatch/TOC.yml
+++ b/windows/deployment/windows-autopatch/TOC.yml
@@ -100,8 +100,6 @@
href: references/windows-autopatch-changes-to-tenant.md
- name: Privacy
href: references/windows-autopatch-privacy.md
- - name: Windows Autopatch preview addendum
- href: references/windows-autopatch-preview-addendum.md
- name: What's new
href:
items:
diff --git a/windows/deployment/windows-autopatch/operate/windows-autopatch-fu-overview.md b/windows/deployment/windows-autopatch/operate/windows-autopatch-fu-overview.md
index fbf827b7a7..6f8dfbcded 100644
--- a/windows/deployment/windows-autopatch/operate/windows-autopatch-fu-overview.md
+++ b/windows/deployment/windows-autopatch/operate/windows-autopatch-fu-overview.md
@@ -63,10 +63,10 @@ When releasing a feature update, there are two policies that are configured by t
| Ring | Target version (DSS) Policy | Feature update deferral | Feature update deadline | Feature update grace period |
| ----- | ----- | ----- | ----- | ----- |
-| Test | 21H2 | 0 | 5 | 0 |
-| First | 21H2 | 0 | 5 | 2 |
-| Fast | 21H2 | 0 | 5 | 2 |
-| Broad | 21H2 | 0 | 5 | 2 |
+| Test | 20H2 | 0 | 5 | 0 |
+| First | 20H2 | 0 | 5 | 2 |
+| Fast | 20H2 | 0 | 5 | 2 |
+| Broad | 20H2 | 0 | 5 | 2 |
> [!NOTE]
> Customers are not able to select a target version for their tenant.
diff --git a/windows/deployment/windows-autopatch/operate/windows-autopatch-wqu-overview.md b/windows/deployment/windows-autopatch/operate/windows-autopatch-wqu-overview.md
index f2d4f477af..718e1126b8 100644
--- a/windows/deployment/windows-autopatch/operate/windows-autopatch-wqu-overview.md
+++ b/windows/deployment/windows-autopatch/operate/windows-autopatch-wqu-overview.md
@@ -1,7 +1,7 @@
---
title: Windows quality updates
description: This article explains how Windows quality updates are managed in Autopatch
-ms.date: 08/08/2022
+ms.date: 12/15/2022
ms.prod: windows-client
ms.technology: itpro-updates
ms.topic: conceptual
@@ -63,16 +63,37 @@ When running an expedited release, the regular goal of 95% of devices in 21 days
| Standard release | Test
First
Fast
Broad | 0
1
6
9 | 0
2
2
5 | 0
2
2
2 |
| Expedited release | All devices | 0 | 1 | 1 |
+### Turn off service-driven expedited quality update releases
+
+Windows Autopatch provides the option to turn off of service-driven expedited quality updates.
+
+**To turn off service-driven expedited quality updates:**
+
+1. Go to **[Microsoft Endpoint Manager portal](https://go.microsoft.com/fwlink/?linkid=2109431)** > **Devices**.
+2. Under **Windows Autopatch** > **Release management**, go to the **Release settings** tab and turn off the **Expedited Quality Updates** setting.
+
> [!NOTE]
> Windows Autopatch doesn't allow customers to request expedited releases.
+## Out of Band releases
+
+Windows Autopatch schedules and deploys required Out of Band (OOB) updates released outside of the normal schedule. You can view the deployed OOB quality updates in the **Release Management** blade in the **[Microsoft Endpoint Manager portal](https://go.microsoft.com/fwlink/?linkid=2109431)**.
+
+**To view deployed Out of Band quality updates:**
+
+1. Go to [Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431) > **Devices** > **Windows Autopatch** > **Release management**.
+2. Under the **Release Announcements** tab, you can view the knowledge base (KB) articles corresponding to deployed OOB and regular Windows quality updates.
+
+> [!NOTE]
+> Announcements will be **removed** from the Release announcements tab when the next quality update is released. Further, if quality updates are paused for a deployment ring, the OOB updates will also be paused.
+
## Pausing and resuming a release
If Windows Autopatch detects a [significant issue with a release](../operate/windows-autopatch-wqu-signals.md), we may decide to pause that release.
If we pause the release, a policy will be deployed which prevents devices from updating while the issue is investigated. Once the issue is resolved, the release will be resumed.
-You can pause or resume a Windows quality update from the Release management tab in the [Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
+You can pause or resume a Windows quality update from the **Release management** tab in the [Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
## Incidents and outages
diff --git a/windows/deployment/windows-autopatch/overview/windows-autopatch-faq.yml b/windows/deployment/windows-autopatch/overview/windows-autopatch-faq.yml
index b9f94b3dc8..85717b347c 100644
--- a/windows/deployment/windows-autopatch/overview/windows-autopatch-faq.yml
+++ b/windows/deployment/windows-autopatch/overview/windows-autopatch-faq.yml
@@ -45,7 +45,9 @@ sections:
- [Azure Active Directory (Azure AD) Premium](/azure/active-directory/fundamentals/active-directory-whatis#what-are-the-azure-ad-licenses)
- [Hybrid Azure AD-Joined](/azure/active-directory/devices/concept-azure-ad-join-hybrid) or [Azure AD-joined only](/azure/active-directory/devices/concept-azure-ad-join-hybrid)
- [Microsoft Intune](https://www.microsoft.com/cloud-platform/microsoft-intune)
- Additional pre-requisites for devices managed by Configuration Manager:
+
+ Additional prerequisites for devices managed by Configuration Manager:
+
- [Configuration Manager Co-management requirements](../prepare/windows-autopatch-prerequisites.md#configuration-manager-co-management-requirements)
- [A supported version of Configuration Manager](/mem/configmgr/core/servers/manage/updates#supported-versions)
- [Switch workloads for device configuration, Windows Update and Microsoft 365 Apps from Configuration Manager to Intune](/mem/configmgr/comanage/how-to-switch-workloads) (minimum Pilot Intune. Pilot collection must contain the devices you want to register into Autopatch.)
diff --git a/windows/deployment/windows-autopatch/references/windows-autopatch-preview-addendum.md b/windows/deployment/windows-autopatch/references/windows-autopatch-preview-addendum.md
deleted file mode 100644
index d0f3e5acba..0000000000
--- a/windows/deployment/windows-autopatch/references/windows-autopatch-preview-addendum.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-title: Windows Autopatch Preview Addendum
-description: This article explains the Autopatch preview addendum
-ms.date: 05/30/2022
-ms.prod: windows-client
-ms.technology: itpro-updates
-ms.topic: reference
-ms.localizationpriority: medium
-author: tiaraquan
-ms.author: tiaraquan
-manager: dougeby
-msreviewer: hathind
----
-
-# Windows Autopatch Preview Addendum
-
-**This Windows Autopatch - Preview Addendum ("Addendum") to the Microsoft Product Terms** (as provided at: (the "**Product Terms**")) is entered into between Microsoft Corporation, a Washington corporation having its principal place of business at One Microsoft Way, Redmond, Washington, USA 98052-6399 (or based on where Customer lives, one of Microsoft's affiliates) ("**Microsoft**"), and you ("**Customer**").
-
-## Background
-
-Microsoft desires to preview the Windows Autopatch service it is developing ("**Windows Autopatch Preview**") in order to evaluate it. Customer would like to particulate this Windows Autopatch Preview under the terms of the Product Terms and this Addendum. Windows Autopatch Preview consists of features and services that are in preview, beta, or other pre-release form. Windows Autopatch Preview is subject to the "preview" terms set forth in the Online Service sections of Product Terms.
-
-For good and valuable consideration, the receipt and sufficiency of which is acknowledged, the parties agree as follows:
-
-## Agreement
-
-### Definitions
-
-Capitalized terms used but not defined herein have the meanings given in the Product Terms.
-
-### Data Handling
-
-Windows Autopatch Preview integrates Customer Data from other Products, including Windows, Microsoft Intune, Azure Active Directory, and Office (collectively for purposes of this provision "Windows Autopatch Input Services"). Once Customer Data from Windows Autopatch Input Services is integrated into Windows Autopatch Preview, only the Product Terms and [DPA provisions)](https://www.microsoft.com/licensing/terms/product/Glossary/all) applicable to Windows Autopatch Preview apply to that data.
diff --git a/windows/deployment/windows-autopatch/whats-new/windows-autopatch-whats-new-2022.md b/windows/deployment/windows-autopatch/whats-new/windows-autopatch-whats-new-2022.md
index ee1eb75dce..469396130d 100644
--- a/windows/deployment/windows-autopatch/whats-new/windows-autopatch-whats-new-2022.md
+++ b/windows/deployment/windows-autopatch/whats-new/windows-autopatch-whats-new-2022.md
@@ -24,6 +24,7 @@ Minor corrections such as typos, style, or formatting issues aren't listed.
| Article | Description |
| ----- | ----- |
+| [Windows quality updates](../operate/windows-autopatch-wqu-overview.md) | Added information about:
Turning off service-driven expedited quality update releases
|
| [Roles and responsibilities](../overview/windows-autopatch-roles-responsibilities.md) | Added Roles and responsibilities article |
| [Prerequisites](../prepare/windows-autopatch-prerequisites.md) | Added more licenses to the More about licenses section
[MC452168](https://admin.microsoft.com/adminportal/home#/MessageCenter) |
| [Unsupported policies](../operate/windows-autopatch-wqu-unsupported-policies.md) | Updated to include other policy managers in the Group policy section |
diff --git a/windows/security/identity-protection/access-control/access-control.md b/windows/security/identity-protection/access-control/access-control.md
index deea4c3766..0f1ca8d5c4 100644
--- a/windows/security/identity-protection/access-control/access-control.md
+++ b/windows/security/identity-protection/access-control/access-control.md
@@ -6,7 +6,7 @@ ms.topic: article
ms.date: 11/22/2022
appliesto:
- ✅ Windows 10 and later
-- ✅ Windows Server 2016 and later
+- ✅ Windows Server 2016 and later
ms.technology: itpro-security
---
diff --git a/windows/security/identity-protection/access-control/local-accounts.md b/windows/security/identity-protection/access-control/local-accounts.md
index eebf25ce06..5a35d2853f 100644
--- a/windows/security/identity-protection/access-control/local-accounts.md
+++ b/windows/security/identity-protection/access-control/local-accounts.md
@@ -7,7 +7,7 @@ ms.collection:
ms.topic: article
appliesto:
- ✅ Windows 10 and later
-- ✅ Windows Server 2016 and later
+- ✅ Windows Server 2016 and later
ms.technology: itpro-security
---
diff --git a/windows/security/identity-protection/credential-guard/additional-mitigations.md b/windows/security/identity-protection/credential-guard/additional-mitigations.md
index 88e440512c..c8ed1adc92 100644
--- a/windows/security/identity-protection/credential-guard/additional-mitigations.md
+++ b/windows/security/identity-protection/credential-guard/additional-mitigations.md
@@ -5,7 +5,7 @@ ms.date: 08/17/2017
ms.topic: article
appliesto:
- ✅ Windows 10 and later
-- ✅ Windows Server 2016 and later
+- ✅ Windows Server 2016 and later
---
# Additional mitigations
diff --git a/windows/security/identity-protection/credential-guard/credential-guard-considerations.md b/windows/security/identity-protection/credential-guard/credential-guard-considerations.md
index ba0779a58a..236d6dd432 100644
--- a/windows/security/identity-protection/credential-guard/credential-guard-considerations.md
+++ b/windows/security/identity-protection/credential-guard/credential-guard-considerations.md
@@ -5,7 +5,7 @@ ms.date: 08/31/2017
ms.topic: article
appliesto:
- ✅ Windows 10 and later
-- ✅ Windows Server 2016 and later
+- ✅ Windows Server 2016 and later
---
# Considerations when using Windows Defender Credential Guard
diff --git a/windows/security/identity-protection/credential-guard/credential-guard-how-it-works.md b/windows/security/identity-protection/credential-guard/credential-guard-how-it-works.md
index 3286ad1879..c9ed9e42c7 100644
--- a/windows/security/identity-protection/credential-guard/credential-guard-how-it-works.md
+++ b/windows/security/identity-protection/credential-guard/credential-guard-how-it-works.md
@@ -5,7 +5,7 @@ ms.date: 08/17/2017
ms.topic: conceptual
appliesto:
- ✅ Windows 10 and later
-- ✅ Windows Server 2016 and later
+- ✅ Windows Server 2016 and later
---
# How Windows Defender Credential Guard works
diff --git a/windows/security/identity-protection/credential-guard/credential-guard-known-issues.md b/windows/security/identity-protection/credential-guard/credential-guard-known-issues.md
index 5711e1d525..07d9647887 100644
--- a/windows/security/identity-protection/credential-guard/credential-guard-known-issues.md
+++ b/windows/security/identity-protection/credential-guard/credential-guard-known-issues.md
@@ -5,7 +5,7 @@ ms.topic: article
ms.date: 11/28/2022
appliesto:
- ✅ Windows 10 and later
-- ✅ Windows Server 2016 and later
+- ✅ Windows Server 2016 and later
---
# Windows Defender Credential Guard: Known issues
diff --git a/windows/security/identity-protection/credential-guard/credential-guard-manage.md b/windows/security/identity-protection/credential-guard/credential-guard-manage.md
index d148156622..e4eb399ed3 100644
--- a/windows/security/identity-protection/credential-guard/credential-guard-manage.md
+++ b/windows/security/identity-protection/credential-guard/credential-guard-manage.md
@@ -7,7 +7,7 @@ ms.collection:
ms.topic: article
appliesto:
- ✅ Windows 10 and later
-- ✅ Windows Server 2016 and later
+- ✅ Windows Server 2016 and later
---
# Manage Windows Defender Credential Guard
diff --git a/windows/security/identity-protection/credential-guard/credential-guard-not-protected-scenarios.md b/windows/security/identity-protection/credential-guard/credential-guard-not-protected-scenarios.md
index d5c0af8d7c..86b9533f7a 100644
--- a/windows/security/identity-protection/credential-guard/credential-guard-not-protected-scenarios.md
+++ b/windows/security/identity-protection/credential-guard/credential-guard-not-protected-scenarios.md
@@ -5,7 +5,7 @@ ms.topic: article
ms.date: 08/17/2017
appliesto:
- ✅ Windows 10 and later
-- ✅ Windows Server 2016 and later
+- ✅ Windows Server 2016 and later
---
# Windows Defender Credential Guard protection limits and mitigations
diff --git a/windows/security/identity-protection/credential-guard/credential-guard-protection-limits.md b/windows/security/identity-protection/credential-guard/credential-guard-protection-limits.md
index 79de8e7f00..42fbe2a663 100644
--- a/windows/security/identity-protection/credential-guard/credential-guard-protection-limits.md
+++ b/windows/security/identity-protection/credential-guard/credential-guard-protection-limits.md
@@ -5,7 +5,7 @@ ms.date: 08/17/2017
ms.topic: article
appliesto:
- ✅ Windows 10 and later
-- ✅ Windows Server 2016 and later
+- ✅ Windows Server 2016 and later
---
# Windows Defender Credential Guard protection limits
diff --git a/windows/security/identity-protection/credential-guard/credential-guard-requirements.md b/windows/security/identity-protection/credential-guard/credential-guard-requirements.md
index 6112d90366..164f0f776e 100644
--- a/windows/security/identity-protection/credential-guard/credential-guard-requirements.md
+++ b/windows/security/identity-protection/credential-guard/credential-guard-requirements.md
@@ -5,7 +5,7 @@ ms.date: 12/27/2021
ms.topic: article
appliesto:
- ✅ Windows 10 and later
-- ✅ Windows Server 2016 and later
+- ✅ Windows Server 2016 and later
---
# Windows Defender Credential Guard requirements
diff --git a/windows/security/identity-protection/credential-guard/credential-guard-scripts.md b/windows/security/identity-protection/credential-guard/credential-guard-scripts.md
index 867ad14148..5051ce94cd 100644
--- a/windows/security/identity-protection/credential-guard/credential-guard-scripts.md
+++ b/windows/security/identity-protection/credential-guard/credential-guard-scripts.md
@@ -5,7 +5,7 @@ ms.date: 11/22/2022
ms.topic: reference
appliesto:
- ✅ Windows 10 and later
-- ✅ Windows Server 2016 and later
+- ✅ Windows Server 2016 and later
---
# Windows Defender Credential Guard: scripts for certificate authority issuance policies
diff --git a/windows/security/identity-protection/credential-guard/credential-guard.md b/windows/security/identity-protection/credential-guard/credential-guard.md
index cc86aff4a8..6548d02f17 100644
--- a/windows/security/identity-protection/credential-guard/credential-guard.md
+++ b/windows/security/identity-protection/credential-guard/credential-guard.md
@@ -7,7 +7,7 @@ ms.collection:
- highpri
appliesto:
- ✅ Windows 10 and later
-- ✅ Windows Server 2016 and later
+- ✅ Windows Server 2016 and later
---
# Protect derived domain credentials with Windows Defender Credential Guard
diff --git a/windows/security/identity-protection/credential-guard/dg-readiness-tool.md b/windows/security/identity-protection/credential-guard/dg-readiness-tool.md
index b4e156aa00..d834db9710 100644
--- a/windows/security/identity-protection/credential-guard/dg-readiness-tool.md
+++ b/windows/security/identity-protection/credential-guard/dg-readiness-tool.md
@@ -5,7 +5,7 @@ ms.date: 11/22/2022
ms.topic: reference
appliesto:
- ✅ Windows 10 and later
-- ✅ Windows Server 2016 and later
+- ✅ Windows Server 2016 and later
---
# Windows Defender Device Guard and Windows Defender Credential Guard hardware readiness tool
diff --git a/windows/security/identity-protection/hello-for-business/hello-aad-join-cloud-only-deploy.md b/windows/security/identity-protection/hello-for-business/hello-aad-join-cloud-only-deploy.md
index 721ddca258..004083bb85 100644
--- a/windows/security/identity-protection/hello-for-business/hello-aad-join-cloud-only-deploy.md
+++ b/windows/security/identity-protection/hello-for-business/hello-aad-join-cloud-only-deploy.md
@@ -1,12 +1,12 @@
---
-title: Azure Active Directory join cloud only deployment
-description: Use this deployment guide to successfully use Azure Active Directory to join a Windows 10 or Windows 11 device.
+title: Windows Hello for Business cloud-only deployment
+description: Learn how to configure Windows Hello for Business in a cloud-only deployment scenario.
ms.date: 06/23/2021
appliesto:
- ✅ Windows 10 and later
ms.topic: article
---
-# Azure Active Directory join cloud only deployment
+# Cloud-only deployment
[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-cloud.md)]
@@ -17,7 +17,7 @@ When you Azure Active Directory (Azure AD) join a Windows device, the system pro
You may wish to disable the automatic Windows Hello for Business enrollment prompts if you aren't ready to use it in your environment. Instructions on how to disable Windows Hello for Business enrollment in a cloud only environment are included below.
> [!NOTE]
-> During the out-of-box experience (OOBE) flow of an Azure AD join, you will see a provisioning PIN when you don’t have Intune. You can always cancel the PIN screen and set this cancellation with registry keys to prevent future prompts.
+> During the out-of-box experience (OOBE) flow of an Azure AD join, you will see a provisioning PIN when you don't have Intune. You can always cancel the PIN screen and set this cancellation with registry keys to prevent future prompts.
## Prerequisites
@@ -25,7 +25,7 @@ Cloud only deployments will use Azure AD multi-factor authentication (MFA) durin
The necessary Windows Hello for Business prerequisites are located at [Cloud Only Deployment](hello-identity-verification.md#azure-ad-cloud-only-deployment).
-Also note that it's possible for federated domains to enable the “Supports MFA” flag in your federated domain settings. This flag tells Azure AD that the federated IDP will perform the MFA challenge.
+Also note that it's possible for federated domains to enable the *Supports MFA* flag in your federated domain settings. This flag tells Azure AD that the federated IDP will perform the MFA challenge.
Check and view this setting with the following MSOnline PowerShell command:
diff --git a/windows/security/identity-protection/hello-for-business/hello-adequate-domain-controllers.md b/windows/security/identity-protection/hello-for-business/hello-adequate-domain-controllers.md
index 485f602211..32dc3ba63e 100644
--- a/windows/security/identity-protection/hello-for-business/hello-adequate-domain-controllers.md
+++ b/windows/security/identity-protection/hello-for-business/hello-adequate-domain-controllers.md
@@ -4,7 +4,7 @@ description: Guide for planning to have an adequate number of Windows Server 201
ms.date: 08/20/2018
appliesto:
- ✅ Windows 10 and later
-- ✅ Windows Server 2016 and later
+- ✅ Windows Server 2016 and later
ms.topic: article
---
# Planning an adequate number of Windows Server 2016 or later Domain Controllers for Windows Hello for Business deployments
diff --git a/windows/security/identity-protection/hello-for-business/hello-cert-trust-adfs.md b/windows/security/identity-protection/hello-for-business/hello-cert-trust-adfs.md
index 3486c444df..d258d207f7 100644
--- a/windows/security/identity-protection/hello-for-business/hello-cert-trust-adfs.md
+++ b/windows/security/identity-protection/hello-for-business/hello-cert-trust-adfs.md
@@ -1,566 +1,318 @@
---
-title: Prepare and Deploy Windows AD FS certificate trust (Windows Hello for Business)
-description: Learn how to Prepare and Deploy Windows Server 2016 Active Directory Federation Services (AD FS) for Windows Hello for Business, using certificate trust.
-ms.date: 01/14/2021
+title: Prepare and deploy Active Directory Federation Services in an on-premises certificate trust
+description: Learn how to configure Active Directory Federation Services to support the Windows Hello for Business certificate trust model.
+ms.date: 12/12/2022
appliesto:
- ✅ Windows 10 and later
-- ✅ Windows Server 2016 and later
-ms.topic: article
+- ✅ Windows Server 2016 and later
+ms.topic: tutorial
---
-# Prepare and Deploy Active Directory Federation Services (AD FS)
-
-Windows Hello for Business works exclusively with the Active Directory Federation Service (AD FS). The on-premises certificate trust deployment uses Active Directory Federation Services roles for key registration, device registration, and as a certificate registration authority.
-
-The following guidance describes deploying a new instance of Active Directory Federation Services 2016 using the Windows Information Database as the configuration database, which is ideal for environments with no more than 30 federation servers and no more than 100 relying party trusts.
-
-If your environment exceeds either of these factors or needs to provide SAML artifact resolution, token replay detection, or needs Active Directory Federation Services to operate in a federated provider role, then your deployment needs to use a SQL for your configuration database. To deploy the Active Directory Federation Services using SQL as its configuration database, please review the [Deploying a Federation Server Farm](/windows-server/identity/ad-fs/deployment/deploying-a-federation-server-farm) checklist.
-
-If your environment has an existing instance of Active Directory Federation Services, then you’ll need to upgrade all nodes in the farm to Windows Server 2016 along with the Windows Server 2016 update. If your environment uses Windows Internal Database (WID) for the configuration database, please read [Upgrading to AD FS in Windows Server 2016 using a WID database](/windows-server/identity/ad-fs/deployment/upgrading-to-ad-fs-in-windows-server-2016) to upgrade your environment. If your environment uses SQL for the configuration database, please read [Upgrading to AD FS in Windows Server 2016 with SQL Server](/windows-server/identity/ad-fs/deployment/upgrading-to-ad-fs-in-windows-server-2016-sql) to upgrade your environment.
-
-Ensure you apply the Windows Server 2016 Update to all nodes in the farm after you have successfully completed the upgrade.
-
-A new Active Directory Federation Services farm should have a minimum of two federation servers for proper load balancing, which can be accomplished with an external networking peripherals, or with using the Network Load Balancing Role included in Windows Server.
-
-Prepare the Active Directory Federation Services deployment by installing and updating two Windows Server 2016 Servers. Ensure the update listed below is applied to each server before continuing.
-
-> [!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:
->
-> 1. Launch AD FS management console. Browse to "Services > Scope Descriptions".
-> 2. Right click "Scope Descriptions" and select "Add Scope Description".
-> 3. Under name type "ugs" and Click Apply > OK.
-> 4. Launch PowerShell as an administrator.
-> 5. Get 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 -AddScope 'ugs'`.
-> 7. Restart the AD FS service.
-> 8. On the client: Restart the client. User should be prompted to provision Windows Hello for Business.
-
-## Update Windows Server 2016
-
-Sign-in the federation server with _local admin_ equivalent credentials.
-1. Ensure Windows Server 2016 is current by running **Windows Update** from **Settings**. Continue this process until no further updates are needed. If you’re not using Windows Update for updates, please advise the [Windows Server 2016 update history page](https://support.microsoft.com/help/4000825/windows-10-windows-server-2016-update-history) to make sure you have the latest updates available installed.
-2. Ensure the latest server updates to the federation server includes [KB4088889 (14393.2155)](https://support.microsoft.com/help/4088889).
-
->[!IMPORTANT]
->The above referenced updates are mandatory for Windows Hello for Business all on-premises deployment and hybrid certificate trust deployments for domain joined computers.
-
-## Enroll for a TLS Server Authentication Certificate
-
-Windows Hello for Business on-premises deployments require a federation server for device registration, key registration, and authentication certificate enrollment. Typically, a federation service is an edge facing role. However, the federation services and instance used with the on-premises deployment of Windows Hello for Business does not need Internet connectivity.
-
-The AD FS role needs a server authentication certificate for the federation services, but you can use a certificate issued by your enterprise (internal) certificate authority. The server authentication certificate should have the following names included in the certificate if you are requesting an individual certificate for each node in the federation farm:
-
-- Subject Name: The internal FQDN of the federation server (the name of the computer running AD FS)
-- Subject Alternate Name: Your federation service name, such as *fs.corp.contoso.com* (or an appropriate wildcard entry such as *.corp.contoso.com)
-- Subject Alternate Name: Your device registration service name, such as *enterpriseregistration.contoso.com*
-
-You configure your federation service name when you configure the AD FS role. You can choose any name, but that name must be different than the name of the server or host. For example, you can name the host server **adfs** and the federation service **fs**. The FQDN of the host is adfs.corp.contoso.com and the FQDN of the federation service is fs.corp.contoso.com.
-
-You can; however, issue one certificate for all hosts in the farm. If you chose this option, then leave the subject name blank, and include all the names in the subject alternate name when creating the certificate request. All names should include the FQDN of each host in the farm and the federation service name.
-
-It’s recommended that you mark the private key as exportable so that the same certificate can be deployed across each federation server and web application proxy within your AD FS farm. Note that the certificate must be trusted (chain to a trusted root CA). Once you have successfully requested and enrolled the server authentication certificate on one node, you can export the certificate and private key to a PFX file using the Certificate Manager console. You can then import the certificate on the remaining nodes in the AD FS farm.
-
-Be sure to enroll or import the certificate into the AD FS server’s computer certificate store. Also, ensure all nodes in the farm have the proper TLS server authentication certificate.
-
-### Internal Web Server Authentication Certificate Enrollment
-
-Sign-in the federation server with domain administrator equivalent credentials.
-
-1. Start the Local Computer **Certificate Manager** (certlm.msc).
-2. Expand the **Personal** node in the navigation pane.
-3. Right-click **Personal**. Select **All Tasks** and **Request New Certificate**.
-4. Click **Next** on the **Before You Begin** page.
-5. Click **Next** on the **Select Certificate Enrollment Policy** page.
-6. On the **Request Certificates** page, Select the **Internal Web Server** check box.
-7. Click the **More information is required to enroll for this certificate. Click here to configure settings** link
- 
-8. Under **Subject name**, select **Common Name** from the **Type** list. Type the FQDN of the computer hosting the Active Directory Federation Services role and then click **Add**.
-9. Under **Alternative name**, select **DNS** from the **Type** list. Type the FQDN of the name you will use for your federation services (fs.corp.contoso.com). The name you use here MUST match the name you use when configuring the Active Directory Federation Services server role. Click **Add**. Repeat the same to add device registration service name (*enterpriseregistration.contoso.com*) as another alternative name. Click **OK** when finished.
-10. Click **Enroll**.
-
-A server authentication certificate should appear in the computer’s Personal certificate store.
-
-## Deploy the Active Directory Federation Service Role
-
-The Active Directory Federation Service (AD FS) role provides the following services to support Windows Hello for Business on-premises deployments:
-
-- Device registration
-- Key registration
-- Certificate registration authority (certificate trust deployments)
-
->[!IMPORTANT]
-> Finish the entire AD FS configuration on the first server in the farm before adding the second server to the AD FS farm. Once complete, the second server receives the configuration through the shared configuration database when it is added the AD FS farm.
-
-Windows Hello for Business depends on proper device registration. For on-premises deployments, Windows Server 2016 AD FS handles device registration.
-
-Sign-in the federation server with _Enterprise Admin_ equivalent credentials.
-
-1. Start **Server Manager**. Click **Local Server** in the navigation pane.
-2. Click **Manage** and then click **Add Roles and Features**.
-3. Click **Next** on the **Before you begin** page.
-4. On the **Select installation type** page, select **Role-based or feature-based installation** and click **Next**.
-5. On the **Select destination server** page, choose **Select a server from the server pool**. Select the federation server from the **Server Pool** list. Click **Next**.
-6. On the **Select server roles** page, select **Active Directory Federation Services**. Click **Next**.
-7. Click **Next** on the **Select features** page.
-8. Click **Next** on the **Active Directory Federation Service** page.
-9. Click **Install** to start the role installation.
-
-## Review & validate
+# Prepare and deploy Active Directory Federation Services - on-premises certificate trust
[!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*.
+
+The following guidance describes the deployment of a new instance of AD FS using the Windows Information Database (WID) as the configuration database.\
+WID is ideal for environments with no more than **30 federation servers** and no more than **100 relying party trusts**. If your environment exceeds either of these factors, or needs to provide *SAML artifact resolution*, *token replay detection*, or needs AD FS to operate as a federated provider role, then the deployment requires the use of SQL as a configuration database.\
+To deploy AD FS using SQL as its configuration database, review the [Deploying a Federation Server Farm](/windows-server/identity/ad-fs/deployment/deploying-a-federation-server-farm) checklist.
+
+A new AD FS farm should have a minimum of two federation servers for proper load balancing, which can be accomplished with external networking peripherals, or with using the Network Load Balancing Role included in Windows Server.
+
+Prepare the AD FS deployment by installing and **updating** two Windows Servers.
+
+## Enroll for a TLS server authentication certificate
+
+Typically, a federation service is an edge facing role. However, the federation services and instance used with the on-premises deployment of Windows Hello for Business does not need Internet connectivity.
+
+The AD FS role needs a *server authentication* certificate for the federation services, and you can use a certificate issued by your enterprise (internal) CA. The server authentication certificate should have the following names included in the certificate, if you are requesting an individual certificate for each node in the federation farm:
+ - **Subject Name**: the internal FQDN of the federation server
+ - **Subject Alternate Name**: the federation service name (e.g. *sts.corp.contoso.com*) or an appropriate wildcard entry (e.g. *\*.corp.contoso.com*)
+
+The federation service name is set when the AD FS role is configured. You can choose any name, but that name must be different than the name of the server or host. For example, you can name the host server *adfs* and the federation service *sts*. In this example, the FQDN of the host is *adfs.corp.contoso.com* and the FQDN of the federation service is *sts.corp.contoso.com*.
+
+You can also issue one certificate for all hosts in the farm. If you chose this option, leave the subject name *blank*, and include all the names in the subject alternate name when creating the certificate request. All names should include the FQDN of each host in the farm and the federation service name.
+
+When creating a wildcard certificate, mark the private key as exportable, so that the same certificate can be deployed across each federation server and web application proxy within the AD FS farm. Note that the certificate must be trusted (chain to a trusted root CA). Once you have successfully requested and enrolled the server authentication certificate on one node, you can export the certificate and private key to a PFX file using the Certificate Manager console. You can then import the certificate on the remaining nodes in the AD FS farm.
+
+Be sure to enroll or import the certificate into the AD FS server's computer certificate store. Also, ensure all nodes in the farm have the proper TLS server authentication certificate.
+### AD FS authentication certificate enrollment
+
+Sign-in the federation server with *domain administrator* equivalent credentials.
+
+1. Start the Local Computer **Certificate Manager** (certlm.msc)
+1. Expand the **Personal** node in the navigation pane
+1. Right-click **Personal**. Select **All Tasks > Request New Certificate**
+1. Select **Next** on the **Before You Begin** page
+1. Select **Next** on the **Select Certificate Enrollment Policy** page
+1. On the **Request Certificates** page, select the **Internal Web Server** check box
+1. Select the **⚠️ More information is required to enroll for this certificate. Click here to configure settings** link
+ :::image type="content" source="images/hello-internal-web-server-cert.png" lightbox="images/hello-internal-web-server-cert.png" alt-text="Example of Certificate Properties Subject Tab - This is what shows when you select the above link.":::
+1. Under **Subject name**, select **Common Name** from the **Type** list. Type the FQDN of the computer hosting the AD FS role and then select **Add**
+1. Under **Alternative name**, select **DNS** from the **Type** list. Type the FQDN of the name that you will use for your federation services (*sts.corp.contoso.com*). The name you use here MUST match the name you use when configuring the AD FS server role. Select **Add** and **OK** when finished
+1. Select **Enroll**
+
+A server authentication certificate should appear in the computer's personal certificate store.
+
+## Deploy the AD FS role
+
+AD FS provides the following services to support Windows Hello for Business on-premises deployments in a certificate trust model:
+
+- Device registration
+- Key registration
+- Certificate registration authority (CRA)
+
+>[!IMPORTANT]
+> Finish the entire AD FS configuration on the first server in the farm before adding the second server to the AD FS farm. Once complete, the second server receives the configuration through the shared configuration database when it is added the AD FS farm.
+
+Sign-in the federation server with *Enterprise Administrator* equivalent credentials.
+
+1. Start **Server Manager**. Select **Local Server** in the navigation pane
+1. Select **Manage > Add Roles and Features**
+1. Select **Next** on the **Before you begin** page
+1. On the **Select installation type** page, select **Role-based or feature-based installation > Next**
+1. On the **Select destination server** page, choose **Select a server from the server pool**. Select the federation server from the **Server Pool** list and **Next**
+1. On the **Select server roles** page, select **Active Directory Federation Services** and **Next**
+1. Select **Next** on the **Select features** page
+1. Select **Next** on the **Active Directory Federation Service** page
+1. Select **Install** to start the role installation
+
+## Review to validate the AD FS deployment
+
Before you continue with the deployment, validate your deployment progress by reviewing the following items:
-- Confirm the AD FS farm uses the correct database configuration.
-- Confirm the AD FS farm has an adequate number of nodes and is properly load balanced for the anticipated load.
-- Confirm **all** AD FS servers in the farm have the latest updates.
-- Confirm all AD FS servers have a valid server authentication certificate.
- - The subject of the certificate is the common name (FQDN) of the host or a wildcard name.
- - The alternate name of the certificate contains a wildcard or the FQDN of the federation service.
+> [!div class="checklist"]
+> * Confirm the AD FS farm uses the correct database configuration
+> * Confirm the AD FS farm has an adequate number of nodes and is properly load balanced for the anticipated load
+> * Confirm **all** AD FS servers in the farm have the latest updates installed
+> * Confirm all AD FS servers have a valid server authentication certificate
-## Device Registration Service Account Prerequisite
+## Device registration service account prerequisites
-The service account used for the device registration server depends on the domain controllers in the environment.
+The use of Group Managed Service Accounts (GMSA) is the preferred way to deploy service accounts for services that support them. GMSAs have security advantages over normal user accounts because Windows handles password management. This means the password is long, complex, and changes periodically. AD FS supports GMSAs, and it should be configured using them for additional security.
->[!NOTE]
-> Follow the procedures below based on the domain controllers deployed in your environment. If the domain controller is not listed below, then it is not supported for Windows Hello for Business.
+GSMA uses the *Microsoft Key Distribution Service* that is located on the domain controllers. Before you can create a GSMA, you must first create a root key for the service. You can skip this if your environment already uses GSMA.
-### Windows Server 2012 or later Domain Controllers
+### Create KDS Root Key
-Windows Server 2012 or later domain controllers support Group Managed Service Accounts—the preferred way to deploy service accounts for services that support them. Group Managed Service Accounts, or GMSA have security advantages over normal user accounts because Windows handles password management. This means the password is long, complex, and changes periodically. The best part of GMSA is all this happens automatically. AD FS supports GMSA and should be configured using them for additional defense in depth security.
+Sign-in a domain controller with *Enterprise Administrator* equivalent credentials.
-GMSA uses the Microsoft Key Distribution Service that is located on Windows Server 2012 or later domain controllers. Windows uses the Microsoft Key Distribution Service to protect secrets stored and used by the GMSA. Before you can create a GMSA, you must first create a root key for the service. You can skip this if your environment already uses GMSA.
-
->[!NOTE]
-> If the [default object creation quota for security principles](/openspecs/windows_protocols/ms-adts/d55ca655-109b-4175-902a-3e9d60833012) is set, you will need to change it for the Group Managed Service Account in order to be able to register new devices.
-
-#### Create KDS Root Key
-
-Sign-in a domain controller with _Enterprise Admin_ equivalent credentials.
-
-1. Start an elevated Windows PowerShell console.
-2. Type `Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)`.
-
-### Windows Server 2008 or 2008 R2 Domain Controllers
-
-Windows Server 2008 and 2008 R2 domain controllers do not host the Microsoft Key Distribution Service, nor do they support Group Managed Service Accounts. Therefore, you must use create a normal user account as a service account where you are responsible for changing the password on a regular basis.
-
-#### Create an AD FS Service Account
-
-Sign-in a domain controller or management workstation with _Domain Admin_ equivalent credentials.
-
-1. Open **Active Directory Users and Computers**.
-2. Right-click the **Users** container, Click **New**. Click **User**.
-3. In the **New Object – User** window, type **adfssvc** in the **Full name** text box. Type **adfssvc** in the **User logon name** text box. Click **Next**.
-4. Enter and confirm a password for the **adfssvc** user. Clear the **User must change password at next logon** check box.
-5. Click **Next** and then click **Finish**.
+Start an elevated PowerShell console and execute the following command:
+```PowerShell
+Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)
+```
## Configure the Active Directory Federation Service Role
->[!IMPORTANT]
-> Follow the procedures below based on the domain controllers deployed in your environment. If the domain controller is not listed below, then it is not supported for Windows Hello for Business.
+Use the following procedures to configure AD FS.
-### Windows Server 2012 or later Domain Controllers
+Sign-in to the federation server with *Domain Administrator* equivalent credentials. These procedures assume you are configuring the first federation server in a federation server farm.
-Use the following procedures to configure AD FS when your environment uses **Windows Server 2012 or later Domain Controllers**. If you are not using Windows Server 2012 or later Domain Controllers, follow the procedures under the [Configure the Active Directory Federation Service Role (Windows Server 2008 or 2008R2 Domain Controllers)](#windows-server-2008-or-2008-r2-domain-controllers) section.
-
-Sign-in the federation server with _domain administrator_ equivalent credentials. These procedures assume you are configuring the first federation server in a federation server farm.
-
-1. Start **Server Manager**.
-2. Click the notification flag in the upper right corner. Click **Configure federation services on this server**.
-
-3. On the **Welcome** page, click **Create the first federation server farm** and click **Next**.
-4. Click **Next** on the **Connect to Active Directory Domain Services** page.
-5. On the **Specify Service Properties** page, select the recently enrolled or imported certificate from the **SSL Certificate** list. The certificate is likely named after your federation service, such as *fs.corp.contoso.com* or *fs.contoso.com*.
-6. Select the federation service name from the **Federation Service Name** list.
-7. Type the Federation Service Display Name in the text box. This is the name users see when signing in. Click **Next**.
-8. On the **Specify Service Account** page, select **Create a Group Managed Service Account**. In the **Account Name** box, type **adfssvc**.
-9. On the **Specify Configuration Database** page, select **Create a database on this server using Windows Internal Database** and click **Next**.
-10. On the **Review Options** page, click **Next**.
-11. On the **Pre-requisite Checks** page, click **Configure**.
-12. When the process completes, click **Close**.
-
-### Windows Server 2008 or 2008 R2 Domain Controllers
-
-Use the following procedures to configure AD FS when your environment uses **Windows Server 2008 or 2008 R2 Domain Controllers**. If you are not using Windows Server 2008 or 2008 R2 Domain Controllers, follow the procedures under the [Configure the Active Directory Federation Service Role (Windows Server 2012 or later Domain Controllers)](#windows-server-2012-or-later-domain-controllers) section.
-
-Sign-in the federation server with _domain administrator_ equivalent credentials. These instructions assume you are configuring the first federation server in a federation server farm.
-
-1. Start **Server Manager**.
-2. Click the notification flag in the upper right corner. Click **Configure federation services on this server**.
-
-3. On the **Welcome** page, click **Create the first federation server farm** and click **Next**.
-4. Click **Next** on the **Connect to Active Directory Domain Services** page.
-5. On the **Specify Service Properties** page, select the recently enrolled or imported certificate from the **SSL Certificate** list. The certificate is likely named after your federation service, such as fs.corp.mstepdemo.net or fs.mstepdemo.net.
-6. Select the federation service name from the **Federation Service Name** list.
-7. Type the Federation Service Display Name in the text box. This is the name users see when signing in. Click **Next**.
-8. On the **Specify Service Account** page, Select **Use an existing domain user account or group Managed Service Account** and click **Select**. In the **Select User or Service Account** dialog box, type the name of the previously created AD FS service account (example adfssvc) and click **OK**. Type the password for the AD FS service account and click **Next**.
-9. On the **Specify Configuration Database** page, select **Create a database on this server using Windows Internal Database** and click **Next**.
-10. On the **Review Options** page, click **Next**.
-11. On the **Pre-requisite Checks** page, click **Configure**.
-12. When the process completes, click **Close**.
-13. Do not restart the AD FS server. You will do this later.
-
-### Add the AD FS Service account to the KeyCredential Admin group and the Windows Hello for Business Users group
+1. Start **Server Manager**
+1. Select the notification flag in the upper right corner and select **Configure the federation services on this server**
+1. On the **Welcome** page, select **Create the first federation server farm > Next**
+1. On the **Connect to Active Directory Domain Services** page, select **Next**
+1. On the **Specify Service Properties** page, select the recently enrolled or imported certificate from the **SSL Certificate** list. The certificate is likely named after your federation service, such as *sts.corp.contoso.com*
+1. Select the federation service name from the **Federation Service Name** list
+1. Type the *Federation Service Display Name* in the text box. This is the name users see when signing in. Select **Next**
+1. On the **Specify Service Account** page, select **Create a Group Managed Service Account**. In the **Account Name** box, type *adfssvc*
+1. On the **Specify Configuration Database** page, select **Create a database on this server using Windows Internal Database** and select **Next**
+1. On the **Review Options** page, select **Next**
+1. On the **Pre-requisite Checks** page, select **Configure**
+1. When the process completes, select **Close**
> [!NOTE]
-> If you have a Windows Server 2016 domain controller in your domain, you can use the **Key Admins** group instead of **KeyCredential Administrators** and skip the **Configure Permissions for Key Registration** step.
+> For AD FS 2019 and later in a certificate trust model, a known PRT issue exists. You may encounter this error in 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**
+> 2. Right-click **Scope Descriptions** and select **Add Scope Description**
+> 3. Under name type *ugs* and select **Apply > OK**
+> 4. Launch PowerShell as an administrator and execute the following commands:
+> ```PowerShell
+> $id = (Get-AdfsApplicationPermission -ServerRoleIdentifiers 'http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope' | ?{ $_.ClientRoleIdentifier -eq '38aa3b87-a06d-4817-b275-7a316988d93b' }).ObjectIdentifier
+> Set-AdfsApplicationPermission -TargetIdentifier $id -AddScope 'ugs'
+> ```
+> 7. Restart the AD FS service
+> 8. Restart the client. User should be prompted to provision Windows Hello for Business
-The **KeyCredential Administrators** global group provides the AD FS service with the permissions needed to perform key registration. 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.
+### Add the AD FS service account to the *Key Admins* group
-Sign-in a domain controller or management workstation with _Domain Admin_ equivalent credentials.
+During Windows Hello for Business enrollment, the public key is registered in an attribute of the user object in Active Directory. To ensure that the AD FS service can add and remove keys are part of its normal workflow, it must be a member of the *Key Admins* global group.
-1. Open **Active Directory Users and Computers**.
-2. Click the **Users** container in the navigation pane.
-3. Right-click **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 **adfssvc**. Click **OK**.
-6. Click **OK** to return to **Active Directory Users and Computers**.
-7. Right-click **Windows Hello for Business Users** group
-8. Click the **Members** tab and click **Add…**
-9. In the **Enter the object names to select** text box, type **adfssvc**. Click **OK**.
-10. Click **OK** to return to **Active Directory Users and Computers**.
-11. Change to server hosting the AD FS role and restart it.
+Sign-in to a domain controller or management workstation with *Domain Administrator* equivalent credentials.
-### Configure Permissions for Key Registration
+1. Open **Active Directory Users and Computers**
+1. Select the **Users** container in the navigation pane
+1. Right-click **Key Admins** in the details pane and select **Properties**
+1. Select the **Members > Add…**
+1. In the **Enter the object names to select** text box, type *adfssvc*. Select **OK**
+1. Select **OK** to return to **Active Directory Users and Computers**
+1. Change to server hosting the AD FS role and restart it
-Key Registration stores the Windows Hello for Business public key in Active Directory. With on-premises deployments, the Windows Server 2016 AD FS server registers the public key with the on-premises Active Directory.
+Sign-in to the federation server with *Enterprise Administrator* equivalent credentials. These instructions assume you are configuring the first federation server in a federation server farm.
-The key-trust model needs Windows Server 2016 domain controllers, which configures the key registration permissions automatically; however, the certificate-trust model does not and requires you to add the permissions manually.
+1. Open the **AD FS management** console
+1. In the navigation pane, expand **Service**. Select **Device Registration**
+1. In the details pane, select **Configure device registration**
+1. In the **Configure Device Registration** dialog, Select **OK**
-Sign-in a domain controller or management workstations with _Domain Admin_ equivalent credentials.
+:::image type="content" source="images/adfs-device-registration.png" lightbox="images/adfs-device-registration.png" alt-text="AD FS device registration: configuration of the service connection point.":::
-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-KeyCrendentialLink**.
-9. Click **OK** three times to complete the task.
+Triggering device registration from AD FS, creates the service connection point (SCP) in the Active Directory configuration partition. The SCP is used to store the device registration information that Windows clients will automatically discover.
-## Configure the Device Registration Service
+:::image type="content" source="images/adfs-scp.png" lightbox="images/adfs-scp.png" alt-text="AD FS device registration: service connection point object created by AD FS.":::
-Sign-in the federation server with _Enterprise Admin_ equivalent credentials. These instructions assume you are configuring the first federation server in a federation server farm.
-
-1. Open the **AD FS management** console.
-2. In the navigation pane, expand **Service**. Click **Device Registration**.
-3. In the details pane, click **Configure Device Registration**.
-4. In the **Configure Device Registration** dialog, click **OK**.
-
-## Review to validate
+## Review to validate the AD FS and Active Directory configuration
Before you continue with the deployment, validate your deployment progress by reviewing the following items:
-* Confirm you followed the correct procedures based on the domain controllers used in your deployment.
- * Windows Server 2012 or Windows Server 2012 R2
- * Windows Server 2008 or Windows Server 2008 R2
-* Confirm you have the correct service account based on your domain controller version.
-* Confirm you properly installed the AD FS role on your Windows Server 2016 based on the proper sizing of your federation, the number of relying parties, and database needs.
-* Confirm you used a certificate with the correct names as the server authentication certificate.
- * Record the expiration date of the certificate and set a renewal reminder at least six weeks before it expires that includes the:
- * Certificate serial number
- * Certificate thumbprint
- * Common name of the certificate
- * Subject alternate name of the certificate
- * Name of the physical host server
- * The issued date
- * The expiration date
- * Issuing CA Vendor (if a third-party certificate)
-* Confirm you granted the AD FS service allow read and write permissions to the ms-DSKeyCredentialLink Active Directory attribute.
-* Confirm you enabled the Device Registration service.
-## Prepare and Deploy AD FS Registration Authority
+> [!div class="checklist"]
+> * Record the information about the AD FS certificate, and set a renewal reminder at least six weeks before it expires. Relevant information includes: certificate serial number, thumbprint, common name, subject alternate name, name of the physical host server, the issued date, the expiration date, and issuing CA vendor (if a third-party certificate)
+> * Confirm you added the AD FS service account to the KeyAdmins group
+> * Confirm you enabled the Device Registration service
-A registration authority is a trusted authority that validates certificate request. Once it validates the request, it presents the request to the certificate authority for issuance. The certificate authority issues the certificate, returns it to the registration authority, which returns the certificate to the requesting user. The Windows Hello for Business on-premises certificate-based deployment uses the Active Directory Federation Server (AD FS) as the certificate registration authority.
+## Configure the certificate registration authority
-### Configure Registration Authority template
+The Windows Hello for Business on-premises certificate-based deployment uses AD FS as the certificate registration authority (CRA). The registration authority is responsible for issuing certificates to users and devices. The registration authority is also responsible for revoking certificates when users or devices are removed from the environment.
-The certificate registration authority 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 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 certificate authority only issues a certificate for that template if the registration authority signs the certificate request.
+Sign-in the AD FS server with *domain administrator* equivalent credentials.
-The registration authority template you configure depends on the AD FS service configuration, which depends on the domain controllers the environment uses for authentication.
+Open a **Windows PowerShell** prompt and type the following command:
->[!IMPORTANT]
->Follow the procedures below based on the domain controllers deployed in your environment. If the domain controller is not listed below, then it is not supported for Windows Hello for Business.
-
-#### Windows 2012 or later domain controllers
-
-Sign-in a certificate authority or management workstations with _domain administrator_ 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 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 **Certification 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 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.
-
-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, 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.
-
-#### Windows 2008 or 2008R2 domain controllers
-
-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 **Exchange Enrollment Agent** 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 **Certification 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.
-
-### Configure the Windows Hello for Business Authentication Certificate template
-
-During Windows Hello for Business provisioning, the Windows 10, version 1703 client requests an authentication certificate from the Active Directory Federation Service, which requests the authentication certificate on behalf of the user. This task configures the Windows Hello for Business authentication certificate template. You use the name of the certificate template when configuring.
-
-Sign-in a certificate authority or management workstations with _domain administrator equivalent_ credentials.
-
-1. Open the **Certificate 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 **Certification Recipient** list.
-5. 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.
-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 T**his 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 **Window 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 **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. 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 administrator_ equivalent credentials.
-
-1. Open an elevated command prompt.
-2. Run `certutil –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 our Windows Server 2012 or later certificate authority.
-
-### Publish Enrollment Agent and Windows Hello For Business Authentication templates to the Certificate Authority
-
-Sign-in a certificate authority or management workstations 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 **Certificate Templates** node. Click **New**, and click **Certificate Template to issue**.
-5. In the **Enable Certificates Templates** window, select the **WHFB Enrollment Agent** template you created in the previous steps. Click **OK** to publish the selected certificate templates to the certificate authority.
-6. Publish the **WHFB Authentication** certificate template using step 5.
-7. Close the console.
-
-### Configure the Registration Authority
-
-Sign-in the AD FS server with domain administrator equivalent credentials.
-
-1. Open a **Windows PowerShell** prompt.
-2. Type the following command
-
```PowerShell
Set-AdfsCertificateAuthority -EnrollmentAgent -EnrollmentAgentCertificateTemplate WHFBEnrollmentAgent -WindowsHelloCertificateTemplate WHFBAuthentication
```
>[!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. 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.
+ > 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.
-### Enrollment Agent Certificate Enrollment
+### Enrollment agent certificate enrollment
-Active Directory Federation Server used for Windows Hello for Business certificate enrollment perform their 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.
+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.
+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.
-### Service Connection Point (SCP) in Active Directory for ADFS Device Registration Service
+## Additional federation servers
-> [!NOTE]
-> Normally this script is not needed, as enabling Device Registration via the ADFS Management console already creates the objects. You can validate the SCP using the script below. For detailed information about the Device Registration Service, see [Configuring Device Registration](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn614658(v=ws.11)).
+Organizations should deploy more than one federation server in their federation farm for high-availability. You should have a minimum of two federation services in your AD FS farm, however most organizations are likely to have more. This largely depends on the number of devices and users using the services provided by the AD FS farm.
-Now you will add the Service connection Point to ADFS device registration Service for your Active directory by running the following script:
+### Server authentication certificate
-> [!TIP]
-> Make sure to change the $enrollmentService and $configNC variables before running the script.
+Each server you add to the AD FS farm must have a proper server authentication certificate. Refer to the [Enroll for a TLS Server Authentication Certificate](#enroll-for-a-tls-server-authentication-certificate) section of this document to determine the requirements for your server authentication certificate. As previously stated, AD FS servers used exclusively for on-premises deployments of Windows Hello for Business can use enterprise server authentication certificates rather than server authentication certificates issued by public certificate authorities.
-```powershell
-# Replace this with your Device Registration Service endpoint
-$enrollmentService = "enterpriseregistration.contoso.com"
-# Replace this with your Active Directory configuration naming context
-$configNC = "CN=Configuration,DC=corp,DC=contoso,DC=org"
-
-$de = New-Object System.DirectoryServices.DirectoryEntry
-$de.Path = "LDAP://CN=Device Registration Configuration,CN=Services," + $configNC
-
-$deSCP = $de.Children.Add("CN=62a0ff2e-97b9-4513-943f-0d221bd30080", "serviceConnectionPoint")
-$deSCP.Properties["keywords"].Add("enterpriseDrsName:" + $enrollmentService)
-$deSCP.CommitChanges()
-```
-
->[!NOTE]
-> You can save the modified script in notepad and save them as "add-scpadfs.ps1" and the way to run it is just navigating into the script path folder and running .\add-scpAdfs.ps1.
->
-
-## Additional Federation Servers
-
-Organizations should deploy more than one federation server in their federation farm for high-availability. You should have a minimum of two federation services in your AD FS farm, however most organizations are likely to have more. This largely depends on the number of devices and users using the services provided by the AD FS farm.
-
-### Server Authentication Certificate
-
-Each server you add to the AD FS farm must have a proper server authentication certificate. Refer to the [Enroll for a TLS Server Authentication Certificate](#enroll-for-a-tls-server-authentication-certificate) section of this document to determine the requirements for your server authentication certificate. As previously stated, AD FS servers used exclusively for on-premises deployments of Windows Hello for Business can use enterprise server authentication certificates rather than server authentication certificates issued by public certificate authorities.
-
-### Install Additional Servers
+### Install additional servers
Adding federation servers to the existing AD FS farm begins with ensuring the server are fully patched, to include Windows Server 2016 Update needed to support Windows Hello for Business deployments (https://aka.ms/whfbadfs1703). Next, install the Active Directory Federation Service role on the additional servers and then configure the server as an additional server in an existing farm.
-## Load Balance AD FS Federation Servers
+## Load balance AD FS
-Many environments load balance using hardware devices. Environments without hardware load-balancing capabilities can take advantage the network load-balancing feature included in Windows Server to load balance the AD FS servers in the federation farm. Install the Windows Network Load Balancing feature on all nodes participating in the AD FS farm that should be load balanced.
+Many environments load balance using hardware devices. Environments without hardware load-balancing capabilities can take advantage the network load-balancing feature included in Windows Server to load balance the AD FS servers in the federation farm. Install the Windows Network Load Balancing feature on all nodes participating in the AD FS farm that should be load balanced.
### Install Network Load Balancing Feature on AD FS Servers
-Sign-in the federation server with _Enterprise Admin_ equivalent credentials.
+Sign-in the federation server with *Enterprise Administrator* equivalent credentials.
-1. Start **Server Manager**. Click **Local Server** in the navigation pane.
-2. Click **Manage** and then click **Add Roles and Features**.
-3. Click **Next** On the **Before you begin** page.
-4. On the **Select installation type** page, select **Role-based or feature-based installation** and click **Next**.
-5. On the **Select destination server** page, choose **Select a server from the server pool**. Select the federation server from the **Server Pool** list. Click **Next**.
-6. On the **Select server roles** page, click **Next**.
-7. Select **Network Load Balancing** on the **Select features** page.
-8. Click **Install** to start the feature installation.
- 
+1. Start **Server Manager**. Select **Local Server** in the navigation pane
+1. Select **Manage** and then select **Add Roles and Features**
+1. Select **Next** On the **Before you begin** page
+1. On the **Select installation type** page, select **Role-based or feature-based installation** and select **Next**
+1. On the **Select destination server** page, choose **Select a server from the server pool**. Select the federation server from the **Server Pool** list. Select **Next**
+1. On the **Select server roles** page, select **Next**
+1. Select **Network Load Balancing** on the **Select features** page
+1. Select **Install** to start the feature installation
### Configure Network Load Balancing for AD FS
-Before you can load balance all the nodes in the AD FS farm, you must first create a new load balance cluster. Once you have created the cluster, then you can add new nodes to that cluster.
+Before you can load balance all the nodes in the AD FS farm, you must first create a new load balance cluster. Once you have created the cluster, then you can add new nodes to that cluster.
-Sign-in a node of the federation farm with _Admin_ equivalent credentials.
+Sign-in a node of the federation farm with *Administrator* equivalent credentials.
-1. Open **Network Load Balancing Manager** from **Administrative Tools**.
- 
-2. Right-click **Network Load Balancing Clusters**, and then click **New Cluster**.
-3. To connect to the host that is to be a part of the new cluster, in the **Host** text box, type the name of the host, and then click **Connect**.
- 
-4. Select the interface that you want to use with the cluster, and then click **Next**. (The interface hosts the virtual IP address and receives the client traffic to load balance.)
-5. In **Host Parameters**, select a value in **Priority (Unique host identifier)**. This parameter specifies a unique ID for each host. The host with the lowest numerical priority among the current members of the cluster handles all of the cluster's network traffic that is not covered by a port rule. Click **Next**.
-6. In **Cluster IP Addresses**, click **Add** and type the cluster IP address that is shared by every host in the cluster. NLB adds this IP address to the TCP/IP stack on the selected interface of all hosts that are chosen to be part of the cluster. Click **Next**.
- 
-7. In **Cluster Parameters**, select values in **IP Address** and **Subnet mask** (for IPv6 addresses, a subnet mask value is not needed). Type the full Internet name that users will use to access this NLB cluster.
- 
-8. In **Cluster operation mode**, click **Unicast** to specify that a unicast media access control (MAC) address should be used for cluster operations. In unicast mode, the MAC address of the cluster is assigned to the network adapter of the computer, and the built-in MAC address of the network adapter is not used. We recommend that you accept the unicast default settings. Click **Next**.
-9. In Port Rules, click Edit to modify the default port rules to use port 443.
- 
+1. Open **Network Load Balancing Manager** from **Administrative Tools**
+1. Right-click **Network Load Balancing Clusters**, and then select **New Cluster**
+1. To connect to the host that is to be a part of the new cluster, in the **Host** text box, type the name of the host, and then select **Connect**
+1. Select the interface that you want to use with the cluster, and then select **Next** (the interface hosts the virtual IP address and receives the client traffic to load balance)
+1. In **Host Parameters**, select a value in **Priority (Unique host identifier)**. This parameter specifies a unique ID for each host. The host with the lowest numerical priority among the current members of the cluster handles all of the cluster's network traffic that is not covered by a port rule. Select **Next**
+1. In **Cluster IP Addresses**, select **Add** and type the cluster IP address that is shared by every host in the cluster. NLB adds this IP address to the TCP/IP stack on the selected interface of all hosts that are chosen to be part of the cluster. Select **Next**
+1. In **Cluster Parameters**, select values in **IP Address** and **Subnet mask** (for IPv6 addresses, a subnet mask value is not needed). Type the full Internet name that users will use to access this NLB cluster
+1. In **Cluster operation mode**, select **Unicast** to specify that a unicast media access control (MAC) address should be used for cluster operations. In unicast mode, the MAC address of the cluster is assigned to the network adapter of the computer, and the built-in MAC address of the network adapter is not used. We recommend that you accept the unicast default settings. Select **Next**
+1. In Port Rules, select Edit to modify the default port rules to use port 443
### Additional AD FS Servers
-1. To add more hosts to the cluster, right-click the new cluster, and then click **Add Host to Cluster**.
-2. Configure the host parameters (including host priority, dedicated IP addresses, and load weight) for the additional hosts by following the same instructions that you used to configure the initial host. Because you are adding hosts to an already configured cluster, all the cluster-wide parameters remain the same.
- 
+1. To add more hosts to the cluster, right-click the new cluster, and then select **Add Host to Cluster**
+1. Configure the host parameters (including host priority, dedicated IP addresses, and load weight) for the additional hosts by following the same instructions that you used to configure the initial host. Because you are adding hosts to an already configured cluster, all the cluster-wide parameters remain the same
## Configure DNS for Device Registration
-Sign-in the domain controller or administrative workstation with domain administrator equivalent credentials. You’ll need the Federation service name to complete this task. You can view the federation service name by clicking **Edit Federation Service Properties** from the **Action** pan of the **AD FS** management console, or by using `(Get-AdfsProperties).Hostname.` (PowerShell) on the AD FS server.
+Sign-in the domain controller or administrative workstation with domain administrator equivalent credentials.\
+You'll need the *federation service* name to complete this task. You can view the federation service name by selecting **Edit Federation Service Properties** from the **Action** pan of the **AD FS** management console, or by using `(Get-AdfsProperties).Hostname.` (PowerShell) on the AD FS server.
-1. Open the **DNS Management** console.
-2. In the navigation pane, expand the domain controller name node and **Forward Lookup Zones**.
-3. In the navigation pane, select the node that has the name of your internal Active Directory domain name.
-4. In the navigation pane, right-click the domain name node and click **New Host (A or AAAA)**.
-5. In the **name** box, type the name of the federation service. In the **IP address** box, type the IP address of your federation server. Click **Add Host**.
-6. Close the DNS Management console.
+1. Open the **DNS Management** console
+1. In the navigation pane, expand the domain controller name node and **Forward Lookup Zones**
+1. In the navigation pane, select the node that has the name of your internal Active Directory domain name
+1. In the navigation pane, right-click the domain name node and select **New Host (A or AAAA)**
+1. In the **name** box, type the name of the federation service. In the **IP address** box, type the IP address of your federation server. Select **Add Host**
+1. Right-click the `` node and select **New Alias (CNAME)**
+1. In the **New Resource Record** dialog box, type `enterpriseregistration` in the **Alias** name box
+1. In the **fully qualified domain name (FQDN)** of the target host box, type `federation_service_farm_name. [!NOTE]
+> If your forest has multiple UPN suffixes, please make sure that `enterpriseregistration.` is present for each suffix.
## Configure the Intranet Zone to include the federation service
-The Windows Hello provisioning presents web pages from the federation service. Configuring the intranet zone to include the federation service enables the user to authenticate to the federation service using integrated authentication. Without this setting, the connection to the federation service during Windows Hello provisioning prompts the user for authentication.
+The Windows Hello provisioning presents web pages from the federation service. Configuring the intranet zone to include the federation service enables the user to authenticate to the federation service using integrated authentication. Without this setting, the connection to the federation service during Windows Hello provisioning prompts the user for authentication.
### Create an Intranet Zone Group Policy
-Sign-in the domain controller or administrative workstation 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 **Intranet Zone Settings** in the name box and click **OK**.
-5. In the content pane, right-click the **Intranet Zone Settings** Group Policy object and click **Edit**.
-6. In the navigation pane, expand **Policies** under **Computer Configuration**.
-7. Expand **Administrative Templates > Windows Component > Internet Explorer > Internet Control Panel**, and select **Security Page**.
-8. In the content pane, double-click **Site to Zone Assignment List**. Click **Enable**.
-9. Click **Show**. In the **Value Name** column, type the url of the federation service beginning with https. In the **Value** column, type the number **1**. Click OK twice, then close the Group Policy Management Editor.
+Sign-in the domain controller or administrative workstation 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 **Intranet Zone Settings** in the name box and select **OK**
+1. In the content pane, right-click the **Intranet Zone Settings** Group Policy object and select **Edit**
+1. In the navigation pane, expand **Policies** under **Computer Configuration**
+1. Expand **Administrative Templates > Windows Component > Internet Explorer > Internet Control Panel >Security Page**. Open **Site to Zone Assignment List**
+1. Select **Enable > Show**. In the **Value Name** column, type the url of the federation service beginning with https. In the **Value** column, type the number **1**. Select OK twice, then close the Group Policy Management Editor
### Deploy the Intranet Zone Group Policy object
-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 **Intranet Zone Settings** or the name of the Windows Hello for Business Group Policy object you previously created and click **OK**.
+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 **Intranet Zone Settings** or the name of the Windows Hello for Business Group Policy object you previously created and select **OK**
-## Review
+## Review to validate the configuration
Before you continue with the deployment, validate your deployment progress by reviewing the following items:
-* Confirm you configured the correct enrollment agent certificate template based on the type of AD FS service account.
-* Confirm only the AD FS service account has the allow enroll permission for the enrollment agent certificate template.
-* Consider using an HSM to protect the enrollment agent certificate; however, understand the frequency and quantity of signature operations the enrollment agent server makes and understand the impact it has on overall performance.
-* Confirm you properly configured the Windows Hello for Business authentication certificate template—to include:
- * Issuance requirements of an authorized signature from a certificate request agent.
- * The certificate template was properly marked as a Windows Hello for Business certificate template using certutil.exe.
- * The Windows Hello for Business Users group, or equivalent has the allow enroll permissions.
-* Confirm all certificate templates were properly published to the appropriate issuing certificate authorities.
-* Confirm the AD FS service account has the allow enroll permission for the Windows Hello Business authentication certificate template.
-* Confirm the AD FS certificate registration authority is properly configured using the `Get-AdfsCertificateAuthority` Windows PowerShell cmdlet.
-* Confirm you restarted the AD FS service.
-* Confirm you properly configured load-balancing (hardware or software).
-* Confirm you created a DNS A Record for the federation service and the IP address used is the load-balanced IP address
-* Confirm you created and deployed the Intranet Zone settings to prevent double authentication to the federation server.
-## Validating your work
-
-You need to verify the AD FS service has properly enrolled for an enrollment agent certificate template. You can verify this is a variety ways, depending on if your service account is a normal user account or if the service account is a group managed service account.
-
-> [!IMPORTANT]
-> After following the previous steps, if you are unable to validate that the devices are, in fact, being registered automatically, there is a Group Policy at:
-> **Computer Configuration > Policies > Administrative Templates > Windows Components > Device Registration >** "Register Domain Joined Computers As Devices". Set the policy to **Enabled**
-> and the registration will happen automatically.
+> [!div class="checklist"]
+> * Confirm only the AD FS service account has the allow enroll permission for the enrollment agent certificate template
+> * Consider using an HSM to protect the enrollment agent certificate; however, understand the frequency and quantity of signature operations the enrollment agent server makes and understand the impact it has on overall performance
+> * Confirm you properly configured the Windows Hello for Business authentication certificate template
+> * Confirm all certificate templates were properly published to the appropriate issuing certificate authorities
+> * Confirm the AD FS service account has the allow enroll permission for the Windows Hello Business authentication certificate template
+> * Confirm the AD FS certificate registration authority is properly configured using the `Get-AdfsCertificateAuthority` Windows PowerShell cmdlet
+> Confirm you restarted the AD FS service
+> * Confirm you properly configured load-balancing (hardware or software)
+> * Confirm you created a DNS A Record for the federation service and the IP address used is the load-balanced IP address
+> * Confirm you created and deployed the Intranet Zone settings to prevent double authentication to the federation server.
### Event Logs
-Use the event logs on the AD FS service to confirm the service account enrolled for an enrollment agent certificate. First, look for the AD FS event ID 443 that confirms certificate enrollment cycle has finished. Once confirmed the AD FS certificate enrollment cycle completed review the CertificateLifecycle-User event log. In this event log, look for event ID 1006, which indicates a new certificate was installed. Details of the event log should show:
+Use the event logs on the AD FS service to confirm the service account enrolled for an enrollment agent certificate. First, look for the AD FS event ID 443 that confirms certificate enrollment cycle has finished. Once confirmed the AD FS certificate enrollment cycle completed review the *CertificateLifecycle-User* event log. In this event log, look for event ID 1006, which indicates a new certificate was installed. Details of the event log should show:
-* The account name under which the certificate was enrolled.
-* The action, which should read enroll.
-* The thumbprint of the certificate
-* The certificate template used to issue the certificate.
+- The account name under which the certificate was enrolled
+- The action, which should read enroll
+-_ The thumbprint of the certificate
+- The certificate template used to issue the certificate
-### Normal Service Account
+You cannot use the Certificate Manager to view enrolled certificates for group managed service accounts. Use the event log information to confirm the AD FS service account enrolled a certificate. Use certutil.exe to view the details of the certificate shown in the event log.
-When using a normal service account, use the Microsoft Management Console (mmc.exe) and load the Certificate Manager snap-in for the service account and verify.
+Group managed service accounts use user profiles to store user information, which included enrolled certificates. On the AD FS server, use a command prompt and navigate to `%systemdrive%\users\\appdata\roaming\Microsoft\systemcertificates\my\certificates`.
-### Group Managed Service Account
+Each file in this folder represents a certificate in the service account's Personal store (You may need to use `dir.exe /A` to view the files in the folder). Match the thumbprint of the certificate from the event log to one of the files in this folder. That file is the certificate. Use the `Certutil -q ` to view the basic information about the certificate.
-You cannot use the Certificate Manager to view enrolled certificates for group managed service accounts. Use the event log information to confirm the AD FS service account enrolled a certificate. Use certutil.exe to view the details of the certificate now shown in the event log.
+For detailed information about the certificate, use `Certutil -q -v `.
-Group managed service accounts use user profiles to store user information, which included enrolled certificates. On the AD FS server, use a command prompt and navigate to `%systemdrive%\users\\appdata\roaming\Microsoft\systemcertificates\my\certificates` .
-
-Each file in this folder represents a certificate in the service account’s Personal store (You may need to use DIR /A to view the files in the folder). Match the thumbprint of the certificate from the event log to one of the files in this folder. That file is the certificate. Use the `Certutil -q ` to view the basic information about the certificate.
-
-For detailed information about the certificate, use `Certutil -q -v ` .
-
-## Follow the Windows Hello for Business on premises certificate trust deployment guide
-
-1. [Validate Active Directory prerequisites](hello-cert-trust-validate-ad-prereq.md)
-2. [Validate and Configure Public Key Infrastructure](hello-cert-trust-validate-pki.md)
-3. Prepare and Deploy Windows Server 2016 Active Directory Federation Services (*You are here*)
-4. [Validate and Deploy Multifactor Authentication Services (MFA)](hello-cert-trust-validate-deploy-mfa.md)
-5. [Configure Windows Hello for Business Policy settings](hello-cert-trust-policy-settings.md)
\ No newline at end of file
+> [!div class="nextstepaction"]
+> [Next: validate and deploy multi-factor authentication (MFA)](hello-cert-trust-validate-deploy-mfa.md)
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/hello-cert-trust-policy-settings.md b/windows/security/identity-protection/hello-for-business/hello-cert-trust-policy-settings.md
index 6c48751b0b..870fc37596 100644
--- a/windows/security/identity-protection/hello-for-business/hello-cert-trust-policy-settings.md
+++ b/windows/security/identity-protection/hello-for-business/hello-cert-trust-policy-settings.md
@@ -1,148 +1,128 @@
---
-title: Configure Windows Hello for Business Policy settings - certificate trust
-description: Configure Windows Hello for Business Policy settings for Windows Hello for Business. Certificate-based deployments need three group policy settings.
+title: Configure Windows Hello for Business Policy settings in an on-premises certificate trust
+description: Configure Windows Hello for Business Policy settings for Windows Hello for Business in an on-premises certificate trust scenario
ms.collection:
- highpri
-ms.date: 08/20/2018
+ms.date: 12/12/2022
appliesto:
-- ✅ Windows 10 and later
-- ✅ Windows Server 2016 and later
-ms.topic: article
+- ✅ Windows 10 and later
+- ✅ Windows Server 2016 and later
+ms.topic: tutorial
---
-# Configure Windows Hello for Business Policy settings - Certificate Trust
+# 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)]
-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 or later.
+On-premises certificate-based deployments of Windows Hello for Business need three Group Policy settings:
+- Enable Windows Hello for Business
+- Use certificate for on-premises authentication
+- Enable automatic enrollment of certificates
-On-premises 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
+## Enable Windows Hello for Business group policy setting
-## Enable Windows Hello for Business Group Policy
+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.
-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.
+If you configure the group policy for computers, all users that sign-in to those computers will be allowed and prompted to enroll for Windows Hello for Business. If you configure the group policy for users, only those users will be allowed and prompted to enroll for Windows Hello for Business.
-If you configure the Group Policy for computers, all users that sign-in to those computers will be allowed and prompted to enroll for Windows Hello for Business. If you configure the Group Policy for users, only those users will be allowed and prompted to enroll for Windows Hello for Business .
+## Use certificate for on-premises authentication group policy setting
-## Use certificate for on-premises authentication
+The 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.
-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 setting for computer or users. Deploying this 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.
-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 group policy setting
-## 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 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.
-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.
+## Create the GPO
-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.
+Sign in to a domain controller or management workstations with *Domain Administrator* equivalent credentials.
-## 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.
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** (this is the only option for Windows Server 2016, but for Windows Server 2019 and later this step can also be done in **Computer 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**.
+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, select **User Configuration > Policies > Administrative Templates > Windows Component > Windows Hello for Business**
+1. In the content pane, double-click **Use Windows Hello for Business**. Select **Enable** and **OK**
+1. Select **Use certificate for on-premises authentication > Enable > OK**
+1. In the navigation pane, expand **Policies > User 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** and 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** (this is the only option for Windows Server 2016, but for Windows Server 2019 and later this step can also be done in **Computer 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
+## Configure security in the Windows Hello for Business GPO
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.
+
+Sign in to a domain controller or management workstations with *Domain Administrator* 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. 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**.
+1. Expand the domain and select the **Group Policy Object** node in the navigation pane
+1. Double-click the **Enable Windows Hello for Business** Group Policy object
+1. In the **Security Filtering** section of the content pane, select **Add**. Type *Windows Hello for Business Users* or the name of the security group you previously created and select **OK**
+1. Select the **Delegation** tab. Select **Authenticated Users** and **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 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**.
+The application of the Windows Hello for Business Group Policy object uses security group filtering. This solution enables you to link the Group Policy object at the domain level, ensuring the GPO is within scope to all users. However, the security group filtering ensures that 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.
-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.
+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**
## 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.
+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.
+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 want 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.
+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 does not provide granular policy setting that enable you to disable specific modalities of biometrics such as allow facial recognition, but disallow fingerprint.
+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 disables all biometrics. Currently, Windows does not 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.
+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
+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. The policy settings included are:
-In the 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 in the Group Policy editor.
+- Require digits
+- Require lowercase letters
+- Maximum PIN length
+- Minimum PIN length
+- Expiration
+- History
+- Require special characters
+- Require uppercase letters
-## Review
+The settings can be found in *Administrative Templates\System\PIN Complexity*, under both the Computer and User Configuration nodes of the Group Policy editor.
+
+## Review to validate the configuration
Before you continue with the deployment, validate your deployment progress by reviewing the following items:
-* Confirm you authored Group Policy settings using the latest ADMX/ADML files (from the Windows 10 Creators Editions)
-* Confirm you configured the Enable Windows Hello for Business to the scope that matches your deployment (Computer vs. User)
-* Confirm you configure the Use Certificate enrollment for on-premises authentication policy setting.
-* Confirm you configure automatic certificate enrollment to the scope that matches your deployment (Computer vs. User)
-* Confirm you configured the proper security settings for the Group Policy object
- * Removed the allow permission for Apply Group Policy for Domain Users (Domain Users must always have the read permissions)
- * Add the Windows Hello for Business Users group to the Group Policy object and gave the group the allow permission for Apply Group Policy
-
-* Linked the Group Policy object to the correct locations within Active Directory
-* Deploy any additional Windows Hello for Business Group Policy setting is a policy separate from the one that enables it for users
+> [!div class="checklist"]
+> - Confirm you configured the Enable Windows Hello for Business to the scope that matches your deployment (Computer vs. User)
+> - Confirm you configure the Use Certificate enrollment for on-premises authentication policy setting
+> - Confirm you configured the proper security settings for the Group Policy object
+> - Confirm you removed the allow permission for Apply Group Policy for Domain Users (Domain Users must always have the read permissions)
+> - Confirm you added the Windows Hello for Business Users group to the Group Policy object, and gave the group the allow permission to Apply Group Policy
+> - Linked the Group Policy object to the correct locations within Active Directory
+> - Deployed any additional Windows Hello for Business Group Policy settings
## 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 WHFB 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 that are not members of this group will not attempt to enroll for Windows Hello for Business.
-
-
-## Follow the Windows Hello for Business on premises certificate trust deployment guide
-1. [Validate Active Directory prerequisites](hello-cert-trust-validate-ad-prereq.md)
-2. [Validate and Configure Public Key Infrastructure](hello-cert-trust-validate-pki.md)
-3. [Prepare and Deploy Windows Server 2016 Active Directory Federation Services](hello-cert-trust-adfs.md)
-4. [Validate and Deploy Multifactor Authentication Services (MFA)](hello-cert-trust-validate-deploy-mfa.md)
-5. Configure Windows Hello for Business Policy settings (*You are here*)
+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 that are not members of this group will not attempt to enroll for Windows Hello for Business.
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-ad-prereq.md b/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-ad-prereq.md
index af56ffb943..bac1a4e528 100644
--- a/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-ad-prereq.md
+++ b/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-ad-prereq.md
@@ -1,78 +1,30 @@
---
-title: Update Active Directory schema for cert-trust deployment (Windows Hello for Business)
-description: How to Validate Active Directory prerequisites for Windows Hello for Business when deploying with the certificate trust model.
-ms.date: 08/19/2018
+title: Validate Active Directory prerequisites in an on-premises certificate trust
+description: Validate Active Directory prerequisites when deploying Windows Hello for Business in a certificate trust model.
+ms.date: 12/12/2022
appliesto:
- ✅ Windows 10 and later
-- ✅ Windows Server 2016 and later
-ms.topic: article
+- ✅ Windows Server 2016 and later
+ms.topic: tutorial
---
-# Validate Active Directory prerequisites for cert-trust deployment
+# Validate Active Directory prerequisites - on-premises certificate trust
[!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 needs the Windows Server 2016 Active Directory or later schema. The key-trust model receives the schema extension when the first Windows Server 2016 or later domain controller is added to the forest. The certificate trust model requires manually updating the current schema to the Windows Server 2016 or later schema.
+The key registration process for the on-premises deployment of Windows Hello for Business requires the Windows Server 2016 Active Directory or later schema.
-> [!NOTE]
-> If you already have a Windows Server 2016 or later domain controller in your forest, you can skip the "Updating the Schema" and "Create the KeyCredential Admins Security Global Group" steps that follow.
+## Create the Windows Hello for Business Users security group
-Manually updating Active Directory uses the command-line utility **adprep.exe** located at **\:\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.
+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 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.
-## Discovering schema role
+Sign-in to a domain controller or to a management workstation with a *Domain Administrator* equivalent credentials.
-To locate the schema master role holder, open and command prompt and type:
+1. Open **Active Directory Users and Computers**
+1. Select **View > Advanced Features**
+1. Expand the domain node from the navigation pane
+1. Right-click the **Users** container. Select **New > Group**
+1. Type *Windows Hello for Business Users* in the **Group Name**
+1. Select **OK**
-```cmd
-netdom.exe query fsmo | findstr.exe -i "schema"
-```
-
-
-
-The command should return the name of the domain controller where you need to 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.
-
-Sign-in to the domain controller hosting the schema master operational role using enterprise administrator equivalent credentials.
-
-1. Mount the ISO file (or insert the DVD) containing the Windows Server 2016 or later installation media.
-2. Open an elevated command prompt.
-3. Type ```cd /d x:\support\adprep``` where *x* is the drive letter of the DVD or mounted ISO.
-4. To update the schema, type ```adprep /forestprep```.
-5. Read the Adprep Warning. Type the letter **C** and press **Enter** to update the schema.
-6. Close the Command Prompt and sign-out.
-
-## Create the KeyCredential Admins Security Global Group
-
-The Windows Server 2016 Active Directory Federation Services (AD FS) role registers the public key on the user object during provisioning. You assign write and read permission to this group to the Active Directory attribute to ensure the AD FS service can add and remove keys are part of its normal workflow.
-
-Sign-in a domain controller or management workstation with domain administrator 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 Global 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 them the proper permissions to provision Windows Hello for Business and to enroll in the Windows Hello for Business authentication certificate.
-
-Sign into a domain controller or management workstation with domain administrator 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**.
-
-
-## Follow the Windows Hello for Business on premises certificate trust deployment guide
-1. Validate Active Directory prerequisites (*You are here*)
-2. [Validate and Configure Public Key Infrastructure](hello-cert-trust-validate-pki.md)
-3. [Prepare and Deploy Windows Server 2016 Active Directory Federation Services](hello-cert-trust-adfs.md)
-4. [Validate and Deploy Multifactor Authentication Services (MFA)](hello-cert-trust-validate-deploy-mfa.md)
-5. [Configure Windows Hello for Business Policy settings](hello-cert-trust-policy-settings.md)
+> [!div class="nextstepaction"]
+> [Next: validate and configure PKI >](hello-cert-trust-validate-pki.md)
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-deploy-mfa.md b/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-deploy-mfa.md
index 28d010fbd8..e5c4b9a2a4 100644
--- a/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-deploy-mfa.md
+++ b/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-deploy-mfa.md
@@ -1,25 +1,28 @@
---
title: Validate and Deploy MFA for Windows Hello for Business with certificate trust
-description: How to Validate and Deploy Multi-factor Authentication (MFA) Services for Windows Hello for Business with certificate trust
-ms.date: 08/19/2018
+description: Validate and deploy multi-factor authentication (MFA) for Windows Hello for Business in an on-premises certificate trust model.
+ms.date: 12/13/2022
appliesto:
- ✅ Windows 10 and later
-- ✅ Windows Server 2016 and later
-ms.topic: article
+- ✅ Windows Server 2016 and later
+ms.topic: tutorial
---
-# Validate and Deploy Multi-Factor Authentication feature
+
+# Validate and deploy multi-factor authentication - on-premises certificate trust
[!INCLUDE [hello-on-premises-cert-trust](../../includes/hello-on-premises-cert-trust.md)]
-Windows Hello for Business requires all users perform multi-factor authentication prior to creating and registering a Windows Hello for Business credential. On-premises deployments can use certificates, third-party authentication providers for AD FS, or a custom authentication provider for AD FS as an on-premises MFA option.
+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:
-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)
+- third-party authentication providers for AD FS
+- custom authentication provider for AD FS
-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).
+> [!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.
-## Follow the Windows Hello for Business on premises certificate trust deployment guide
-1. [Validate Active Directory prerequisites](hello-cert-trust-validate-ad-prereq.md)
-2. [Validate and Configure Public Key Infrastructure](hello-cert-trust-validate-pki.md)
-3. [Prepare and Deploy Windows Server 2016 Active Directory Federation Services](hello-cert-trust-adfs.md)
-4. Validate and Deploy Multi-factor Authentication Services (MFA) (*You're here*)
-5. [Configure Windows Hello for Business Policy settings](hello-cert-trust-policy-settings.md)
\ No newline at end of file
+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)
+
+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).
+
+> [!div class="nextstepaction"]
+> [Next: configure Windows Hello for Business Policy settings](hello-cert-trust-policy-settings.md)
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-pki.md b/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-pki.md
index 4b692280e1..f543372332 100644
--- a/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-pki.md
+++ b/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-pki.md
@@ -1,190 +1,348 @@
---
-title: Validate Public Key Infrastructure - certificate trust model (Windows Hello for Business)
-description: How to Validate Public Key Infrastructure for Windows Hello for Business, under a certificate trust model.
-ms.date: 08/19/2018
+title: Configure and validate the Public Key Infrastructure in an on-premises certificate trust model
+description: Configure and validate the Public Key Infrastructure the Public Key Infrastructure when deploying Windows Hello for Business in a certificate trust model.
+ms.date: 12/12/2022
appliesto:
- ✅ Windows 10 and later
-- ✅ Windows Server 2016 and later
-ms.topic: article
+- ✅ Windows Server 2016 and later
+ms.topic: tutorial
---
-# Validate and Configure Public Key Infrastructure - Certificate Trust Model
+# Configure and validate the Public Key Infrastructure - on-premises certificate trust
[!INCLUDE [hello-on-premises-cert-trust](../../includes/hello-on-premises-cert-trust.md)]
-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.
+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 certificate authority
+## Deploy an enterprise certification authority
-This guide assumes most enterprise have an existing public key infrastructure. Windows Hello for Business depends on a Windows enterprise public key infrastructure running Active Directory Certificate Services.
+This guide assumes most enterprises have an existing public key infrastructure. Windows Hello for Business depends on an enterprise PKI running the Windows Server *Active Directory Certificate Services* role.
-### Lab-based public key infrastructure
+### Lab-based PKI
-The following instructions may be used to deploy simple public key infrastructure that is suitable for a lab environment.
+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.
+Sign in using *Enterprise Administrator* equivalent credentials on a Windows Server where you want the certification authority (CA) installed.
>[!NOTE]
->Never install a certificate authority on a domain controller in a production environment.
+>Never install a certification 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
+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 Certificate Authority using a basic certificate authority configuration
+3. Use the following command to configure the CA using a basic certification 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.
+## Configure a PKI
-### Configure Domain Controller Certificates
+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.
-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.
+Expand the following sections to configure the PKI for Windows Hello for Business.
-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. Therefore, domain controllers need to request a certificate based on the Kerberos Authentication certificate template.
+
+
+Configure domain controller certificates
-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.
+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*.
-Sign-in to 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 Templates 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 **Certification 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.
+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.
-### Superseding the existing Domain Controller certificate
+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.
-Many domain controllers may have an existing domain controller certificate. The Active Directory Certificate Services provides a default certificate template from 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.
+Sign in to a CA or management workstations with *Domain Administrator* equivalent credentials.
-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.
+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
-Sign-in to 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 Templates 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**. Click **Add**.
-7. From the **Add Superseded Template** dialog, select the **Kerberos Authentication** certificate template and click **OK**. Click **Add**.
-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.
+
+
+Supersede existing domain controller certificates
-### Configure an Internal Web Server Certificate template
+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.
-Windows 10 or Windows 11 clients use the https protocol when communicating with Active Directory Federation Services. To meet this need, you must issue a server authentication certificate to all the nodes in the Active Directory Federation Services 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 the Active Directory Federation Service can request the certificate.
+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 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 Templates Console**, right-click the **Web Server** 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 **Certification Recipient** list.
-5. 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.
-6. On the **Request Handling** tab, select **Allow private key to be exported**.
-7. On the **Subject Name** tab, select the **Supply in the request** button if it is not already selected.
-8. On the **Security** tab, Click **Add**. Type **Domain Computers** in the **Enter the object names to select** box. Click **OK**. Select the **Allow** check box next to the **Enroll** permission.
-9. 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**.
-10. Close the console.
+Sign in to a CA or management workstations with *Enterprise Administrator* equivalent credentials.
-### Unpublish Superseded Certificate Templates
+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 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 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.
-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.
+
+
+Configure an internal web server certificate template
-### Publish Certificate Templates to the Certificate Authority
+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.
-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 a CA or management workstations with *Domain Administrator* equivalent credentials.
-Sign-in to the certificate authority or management workstations with an _enterprise 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
-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)**, and **Internal Web Server** templates 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.
+
-### Configure Domain Controllers for Automatic Certificate Enrollment
+
+
+Configure a certificate registration authority template
-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.
+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
+
+
+
+
+
+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**. 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.
+
+
+
+
+
+
+Unpublish Superseded Certificate Templates
+
+The certification authority only issues certificates based on published certificate templates. For security, it's a good practice to unpublish certificate templates that the CA isn't configured to issue. This includes the pre-published certificate template from the role installation and any superseded certificate templates.
+
+The newly created *domain controller authentication* certificate template supersedes previous domain controller certificate templates. Therefore, you need to unpublish these certificate templates from all issuing certificate authorities.
+
+Sign in to the CA or management workstation with *Enterprise Administrator* equivalent credentials.
+
+1. Open the **Certification Authority** management console
+1. Expand the parent node from the navigation pane > **Certificate Templates**
+1. Right-click the *Domain Controller* certificate template and select **Delete**. Select **Yes** on the **Disable certificate templates** window
+1. Repeat step 3 for the *Domain Controller Authentication* and *Kerberos Authentication* certificate templates
+
+
+
+
+
+Publish certificate templates to the CA
+
+A certification authority can only issue certificates for certificate templates that are published to it. If you have more than one CA, and you want more CAs to issue certificates based on the certificate template, then you must publish the certificate template to them.
+
+Sign in to the CA or management workstations with **Enterprise Admin** equivalent credentials.
+
+1. Open the **Certification Authority** management console
+1. Expand the parent node from the navigation pane
+1. Select **Certificate Templates** in the navigation pane
+1. Right-click the **Certificate Templates** node. Select **New > Certificate Template** to issue
+1. In the **Enable Certificates Templates** window, select the *Domain Controller Authentication (Kerberos)*, *Internal Web Server*, *WHFB Enrollment Agent* and *WHFB Authentication* templates you created in the previous steps. Select **OK** to publish the selected certificate templates to the certification authority
+1. If you published the *Domain Controller Authentication (Kerberos)* certificate template, then unpublish the certificate templates you included in the superseded templates list
+ - To unpublish a certificate template, right-click the certificate template you want to unpublish and select **Delete**. Select **Yes** to confirm the operation
+1. Close the console
+
+
+
+### Configure automatic certificate enrollment for the domain controllers
+
+Domain controllers automatically request a certificate from the *Domain controller certificate* template. However, domain controllers are unaware of newer certificate templates or superseded configurations on certificate templates. To continue automatic enrollment and renewal of domain controller certificates, create and configure a Group Policy Object (GPO) for automatic certificate enrollment, linking the Group Policy object to the *Domain Controllers* Organizational Unit (OU).
+
+1. Open the **Group Policy Management Console** (gpmc.msc)
+1. Expand the domain and select the **Group Policy Object** node in the navigation pane
+1. Right-click **Group Policy object** and select **New**
+1. Type *Domain Controller Auto Certificate Enrollment* in the name box and select **OK**
+1. Right-click the **Domain Controller Auto Certificate Enrollment** Group Policy object and select **Edit**
+1. In the navigation pane, expand **Policies** under **Computer Configuration**
+1. Expand **Windows Settings > Security Settings > Public Key Policies**
+1. In the details pane, right-click **Certificate Services Client - Auto-Enrollment** and select **Properties**
+1. Select **Enabled** from the **Configuration Model** list
+1. Select the **Renew expired certificates, update pending certificates, and remove revoked certificates** check box
+1. Select the **Update certificates that use certificate templates** check box
+1. Select **OK**
+1. Close the **Group Policy Management Editor**
+
+### Deploy the domain controller auto certificate enrollment GPO
+
+Sign in to domain controller or management workstations with *Domain Administrator* equivalent credentials.
1. Start the **Group Policy Management Console** (gpmc.msc)
-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**.
+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**
-### Deploy the Domain Controller Auto Certificate Enrollment Group Policy Object
+## Validate the configuration
-Sign-in to 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 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.
-### Validating your work
+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.
-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.
+### Use the event logs
-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.
+Sign in to domain controller or management workstations with *Domain Administrator* equivalent credentials.
-#### Use the Event Logs
+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
-Windows Server 2012 and later include Certificate Lifecycle events to determine the lifecycles of certificates for both users and computers. Using the Event Viewer, navigate to the **CertificateServicesClient-Lifecycle-System** event log under **Application and Services/Microsoft/Windows**.
+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.
-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.
+### Certificate Manager
-Certificates superseded by your new domain controller certificate generate an archive event in the CertificateServicesClient-Lifecycle-System event. The archive event contains the certificate template name and thumbprint of the certificate that was superseded by the new certificate.
+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
-#### Certificate Manager
+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.
-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 do not appear in Certificate Manager.
+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.
-#### Certutil.exe
+### Troubleshooting
-You can use **certutil.exe** 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 -q -store my` to view locally enrolled certificates.
+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`.
-To view detailed information about each certificate in the store, use `certutil -q -v -store my` to validate automatic certificate enrollment enrolled the proper certificates.
+Alternatively, you can forcefully trigger automatic certificate enrollment using `certreq.exe -autoenroll -q` from an elevated command prompt.
-#### Troubleshooting
+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 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 /force`.
-
-Alternatively, you can forcefully trigger automatic certificate enrollment using `certreq -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 certificate authority and the allow auto enrollment permissions.
-
-
-## Follow the Windows Hello for Business on premises certificate trust deployment guide
-1. [Validate Active Directory prerequisites](hello-cert-trust-validate-ad-prereq.md)
-2. Validate and Configure Public Key Infrastructure (*You are here*)
-3. [Prepare and Deploy Windows Server 2016 Active Directory Federation Services](hello-cert-trust-adfs.md)
-4. [Validate and Deploy Multifactor Authentication Services (MFA)](hello-cert-trust-validate-deploy-mfa.md)
-5. [Configure Windows Hello for Business Policy settings](hello-cert-trust-policy-settings.md)
\ No newline at end of file
+> [!div class="nextstepaction"]
+> [Next: prepare and deploy AD FS >](hello-cert-trust-adfs.md)
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/hello-deployment-cert-trust.md b/windows/security/identity-protection/hello-for-business/hello-deployment-cert-trust.md
index 115a1041e1..d19452cbd8 100644
--- a/windows/security/identity-protection/hello-for-business/hello-deployment-cert-trust.md
+++ b/windows/security/identity-protection/hello-for-business/hello-deployment-cert-trust.md
@@ -1,22 +1,20 @@
---
-title: Windows Hello for Business Deployment Guide - On Premises Certificate Trust Deployment
-description: A guide to on premises, certificate trust Windows Hello for Business deployment.
-ms.date: 08/19/2018
+title: Windows Hello for Business deployment guide for the on-premises certificate trust model
+description: Learn how to deploy Windows Hello for Business in an on-premises, certificate trust model.
+ms.date: 12/12/2022
appliesto:
- ✅ Windows 10 and later
-- ✅ Windows Server 2016 and later
-ms.topic: article
+- ✅ Windows Server 2016 and later
+ms.topic: tutorial
---
-# On Premises Certificate Trust Deployment
+# Deployment guide overview - on-premises certificate trust
[!INCLUDE [hello-on-premises-cert-trust](../../includes/hello-on-premises-cert-trust.md)]
-Windows Hello for Business replaces username and password sign-in to Windows with authentication using an asymmetric key pair. This deployment guide provides the information you'll need to successfully deploy Windows Hello for Business in an existing environment.
-
-Below, you can find all the information needed to deploy Windows Hello for Business in a Certificate Trust Model in your on-premises environment:
+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:
1. [Validate Active Directory prerequisites](hello-cert-trust-validate-ad-prereq.md)
-2. [Validate and Configure Public Key Infrastructure](hello-cert-trust-validate-pki.md)
-3. [Prepare and Deploy Windows Server 2016 Active Directory Federation Services](hello-cert-trust-adfs.md)
-4. [Validate and Deploy Multi-factor Authentication Services (MFA)](hello-cert-trust-validate-deploy-mfa.md)
-5. [Configure Windows Hello for Business Policy settings](hello-cert-trust-policy-settings.md)
+2. [Validate and configure a PKI](hello-cert-trust-validate-pki.md)
+3. [Prepare and deploy AD FS](hello-cert-trust-adfs.md)
+4. [Validate and deploy multi-factor authentication (MFA)](hello-cert-trust-validate-deploy-mfa.md)
+5. [Configure Windows Hello for Business Policy settings](hello-cert-trust-policy-settings.md)
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/hello-deployment-key-trust.md b/windows/security/identity-protection/hello-for-business/hello-deployment-key-trust.md
index 6dfcd9f952..34d860c531 100644
--- a/windows/security/identity-protection/hello-for-business/hello-deployment-key-trust.md
+++ b/windows/security/identity-protection/hello-for-business/hello-deployment-key-trust.md
@@ -1,21 +1,20 @@
---
-title: Windows Hello for Business Deployment Guide - On Premises Key Deployment
-description: A guide to on premises, key trust Windows Hello for Business deployment.
-ms.date: 08/20/2018
+title: Windows Hello for Business deployment guide for the on-premises key trust model
+description: Learn how to deploy Windows Hello for Business in an on-premises, key trust model.
+ms.date: 12/12/2022
appliesto:
- ✅ Windows 10 and later
-ms.topic: article
+- ✅ Windows Server 2016 and later
+ms.topic: tutorial
---
-# On Premises Key Trust Deployment
+# Deployment guide overview - on-premises key trust
[!INCLUDE [hello-on-premises-key-trust](../../includes/hello-on-premises-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 an existing environment.
-
-Below, you can find all the information you need to deploy Windows Hello for Business in a key trust model in your on-premises environment:
+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::
1. [Validate Active Directory prerequisites](hello-key-trust-validate-ad-prereq.md)
-2. [Validate and Configure Public Key Infrastructure](hello-key-trust-validate-pki.md)
-3. [Prepare and Deploy Active Directory Federation Services](hello-key-trust-adfs.md)
-4. [Validate and Deploy Multifactor Authentication Services (MFA)](hello-key-trust-validate-deploy-mfa.md)
-5. [Configure Windows Hello for Business Policy settings](hello-key-trust-policy-settings.md)
+1. [Validate and configure a PKI](hello-key-trust-validate-pki.md)
+1. [Prepare and deploy AD FS](hello-key-trust-adfs.md)
+1. [Validate and deploy multi-factor authentication (MFA)](hello-key-trust-validate-deploy-mfa.md)
+1. [Configure Windows Hello for Business Policy settings](hello-key-trust-policy-settings.md)
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/hello-deployment-rdp-certs.md b/windows/security/identity-protection/hello-for-business/hello-deployment-rdp-certs.md
index af71e186d2..bdfbe3acf9 100644
--- a/windows/security/identity-protection/hello-for-business/hello-deployment-rdp-certs.md
+++ b/windows/security/identity-protection/hello-for-business/hello-deployment-rdp-certs.md
@@ -4,22 +4,17 @@ description: Learn how to deploy certificates to cloud Kerberos trust and key tr
ms.collection:
- ContentEngagementFY23
ms.topic: article
-localizationpriority: medium
ms.date: 11/15/2022
appliesto:
- ✅ Windows 10 and later
-ms.technology: itpro-security
---
# Deploy certificates for remote desktop (RDP) sign-in
This document describes Windows Hello for Business functionalities or scenarios that apply to:\
-✅ **Deployment type:** [hybrid](hello-how-it-works-technology.md#hybrid-deployment)\
-✅ **Trust type:** [cloud Kerberos trust](hello-hybrid-cloud-kerberos-trust.md), [ key trust](hello-how-it-works-technology.md#key-trust)\
-✅ **Device registration type:** [Azure AD join](hello-how-it-works-technology.md#azure-active-directory-join), [Hybrid Azure AD join](hello-how-it-works-technology.md#hybrid-azure-ad-join)
-
-
-
+- **Deployment type:** [!INCLUDE [hybrid](../../includes/hello-deployment-hybrid.md)]
+- **Trust type:** [!INCLUDE [cloud-kerberos](../../includes/hello-trust-cloud-kerberos.md)],[!INCLUDE [key](../../includes/hello-trust-key.md)]
+- **Join type:** [!INCLUDE [hello-join-aadj](../../includes/hello-join-aad.md)], [!INCLUDE [hello-join-hybrid](../../includes/hello-join-hybrid.md)]
---
Windows Hello for Business supports using a certificate as the supplied credential, when establishing a remote desktop connection to another Windows device. This document discusses three approaches for *cloud Kerberos trust* and *key trust* deployments, where authentication certificates can be deployed to an existing Windows Hello for Business user:
diff --git a/windows/security/identity-protection/hello-for-business/hello-feature-pin-reset.md b/windows/security/identity-protection/hello-for-business/hello-feature-pin-reset.md
index 561975c7a9..e1aa2e7acb 100644
--- a/windows/security/identity-protection/hello-for-business/hello-feature-pin-reset.md
+++ b/windows/security/identity-protection/hello-for-business/hello-feature-pin-reset.md
@@ -5,7 +5,7 @@ ms.collection:
- highpri
ms.date: 07/29/2022
appliesto:
-- ✅ Windows 10 and later
+- ✅ Windows 10 and later
ms.topic: article
---
diff --git a/windows/security/identity-protection/hello-for-business/hello-how-it-works-technology.md b/windows/security/identity-protection/hello-for-business/hello-how-it-works-technology.md
index ad5eec8634..7bec9c2543 100644
--- a/windows/security/identity-protection/hello-for-business/hello-how-it-works-technology.md
+++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works-technology.md
@@ -70,6 +70,7 @@ The certificate trust model uses a securely issued certificate based on the user
- [Deployment type](#deployment-type)
- [Hybrid Azure AD join](#hybrid-azure-ad-join)
- [Hybrid deployment](#hybrid-deployment)
+- [Cloud Kerberos trust](#cloud-kerberos-trust)
- [Key trust](#key-trust)
- [On-premises deployment](#on-premises-deployment)
- [Trust type](#trust-type)
@@ -102,6 +103,26 @@ In Windows 10 and Windows 11, cloud experience host is an application used while
[Windows Hello for Business and device registration](./hello-how-it-works-device-registration.md)
+## Cloud Kerberos trust
+
+The cloud Kerberos trust model offers a simplified deployment experience, when compared to the other trust types.\
+With cloud Kerberos trust, there's no need to deploy certificates to the users or to the domain controllers, which is ideal for environments without an existing PKI.
+
+Giving the simplicity offered by this model, cloud Kerberos trust is the recommended model when compared to the key trust model. It is also the preferred deployment model if you do not need to support certificate authentication scenarios.
+
+### Related to cloud Kerberos trust
+
+- [Deployment type](#deployment-type)
+- [Hybrid Azure AD join](#hybrid-azure-ad-join)
+- [Hybrid deployment](#hybrid-deployment)
+- [Key trust](#key-trust)
+- [On-premises deployment](#on-premises-deployment)
+- [Trust type](#trust-type)
+
+### More information about cloud Kerberos trust
+
+[Cloud Kerberos trust deployment](hello-hybrid-cloud-kerberos-trust.md)
+
## Deployment type
Windows Hello for Business has three deployment models to accommodate the needs of different organizations. The three deployment models include:
@@ -223,6 +244,7 @@ The key trust model uses the user's Windows Hello for Business identity to authe
### Related to key trust
+- [Cloud Kerberos trust](#cloud-kerberos-trust)
- [Certificate trust](#certificate-trust)
- [Deployment type](#deployment-type)
- [Hybrid Azure AD join](#hybrid-azure-ad-join)
@@ -314,6 +336,7 @@ The trust type determines how a user authenticates to the Active Directory to ac
### Related to trust type
+- [Cloud Kerberos trust](#cloud-kerberos-trust)
- [Certificate trust](#certificate-trust)
- [Hybrid deployment](#hybrid-deployment)
- [Key trust](#key-trust)
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md
index 1b222da4f8..e8e87a1d23 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md
@@ -297,7 +297,7 @@ Sign in a certificate authority or management workstations with _Domain Admin eq
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 **Certification Recipient** list.
+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 **AADJ WHFB Authentication** in **Template display name**. Adjust the validity and renewal period to meet your enterprise's needs.
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-pki.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-pki.md
index 98725d74b3..2b43ffad0a 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-pki.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-pki.md
@@ -37,7 +37,7 @@ Sign-in a certificate authority or management workstations with _Domain Admin_ e
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 **Certification Recipient** list.
+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.
@@ -103,7 +103,7 @@ Sign-in to a certificate authority or management workstation with _Domain Admin_
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 **Certification Recipient** list.
+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.
@@ -134,7 +134,7 @@ Sign-in to a certificate authority or management workstation with *Domain Admin*
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 **Certification Recipient** list.
+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.
@@ -160,7 +160,7 @@ Sign-in to a certificate authority or management workstation with _Domain Admin
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 **Certification Recipient** list.
+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.
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md
index d8063e6127..ebcff732f3 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md
@@ -1,16 +1,16 @@
---
-title: Hybrid cloud Kerberos trust deployment (Windows Hello for Business)
-description: Learn the information you need to successfully deploy Windows Hello for Business in a hybrid cloud Kerberos trust scenario.
+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:
- ✅ Windows 10, version 21H2 and later
ms.topic: article
---
-# Hybrid cloud Kerberos trust deployment
+# Cloud Kerberos trust deployment
[!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 hybrid cloud Kerberos trust scenario.
+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.
## Introduction to cloud Kerberos trust
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-pki.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-pki.md
index a824e822fe..9e36481b2a 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-pki.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-pki.md
@@ -33,7 +33,7 @@ Sign-in a certificate authority or management workstations with _Domain Admin_ e
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 **Certification Recipient** list.
+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.
diff --git a/windows/security/identity-protection/hello-for-business/hello-identity-verification.md b/windows/security/identity-protection/hello-for-business/hello-identity-verification.md
index fabe42eb18..e1ed3396b6 100644
--- a/windows/security/identity-protection/hello-for-business/hello-identity-verification.md
+++ b/windows/security/identity-protection/hello-for-business/hello-identity-verification.md
@@ -2,10 +2,11 @@
title: Windows Hello for Business Deployment Prerequisite Overview
description: Overview of all the different infrastructure requirements for Windows Hello for Business deployment models
ms.collection:
- - highpri
-ms.date: 2/15/2022
-appliesto:
-- ✅ Windows 10 and later
+- highpri
+ms.date: 12/13/2022
+appliesto:
+- ✅ Windows 10 and later
+- ✅ Windows Server 2016 and later
ms.topic: article
---
@@ -15,11 +16,10 @@ This article lists the infrastructure requirements for the different deployment
## Azure AD Cloud Only Deployment
-* Microsoft Azure Account
-* Azure Active Directory
-* Azure AD Multifactor Authentication
-* Modern Management (Intune or supported third-party MDM), *optional*
-* Azure AD Premium subscription - *optional*, needed for automatic MDM enrollment when the device joins Azure Active Directory
+- Azure Active Directory
+- Azure AD Multifactor Authentication
+- Device management solution (Intune or supported third-party MDM), *optional*
+- Azure AD Premium subscription - *optional*, needed for automatic MDM enrollment when the device joins Azure Active Directory
## Hybrid Deployments
@@ -27,44 +27,26 @@ The table shows the minimum requirements for each deployment. For key trust in a
| Requirement | cloud Kerberos trust Group Policy or Modern managed | Key trust Group Policy or Modern managed | Certificate Trust Mixed managed | Certificate Trust Modern managed |
| --- | --- | --- | --- | --- |
-| **Windows Version** | Windows 10, version 21H2 with KB5010415; Windows 11 with KB5010414; or later | Windows 10, version 1511 or later| **Hybrid Azure AD Joined:** *Minimum:* Windows 10, version 1703 *Best experience:* Windows 10, version 1709 or later (supports synchronous certificate enrollment). **Azure AD Joined:** Windows 10, version 1511 or later| Windows 10, version 1511 or later |
-| **Schema Version** | No specific Schema requirement | Windows Server 2016 or later Schema | Windows Server 2016 or later Schema | Windows Server 2016 or later Schema |
+| **Windows Version** | Any supported Windows client versions| Any supported Windows client versions | Any supported Windows client versions |
+| **Schema Version** | No specific Schema requirement | Windows Server 2016 or later schema | Windows Server 2016 or later schema | Windows Server 2016 or later schema |
| **Domain and Forest Functional Level** | Windows Server 2008 R2 Domain/Forest functional level | Windows Server 2008 R2 Domain/Forest functional level | Windows Server 2008 R2 Domain/Forest functional level |Windows Server 2008 R2 Domain/Forest functional level |
-| **Domain Controller Version** | Windows Server 2016 or later | Windows Server 2016 or later | Windows Server 2008 R2 or later | Windows Server 2008 R2 or later |
-| **Certificate Authority**| N/A | Windows Server 2012 or later Certificate Authority | Windows Server 2012 or later Certificate Authority | Windows Server 2012 or later Certificate Authority |
-| **AD FS Version** | N/A | N/A | Windows Server 2016 AD FS with [KB4088889 update](https://support.microsoft.com/help/4088889) (hybrid Azure AD joined clients managed by Group Policy), and Windows Server 2012 or later Network Device Enrollment Service (hybrid Azure AD joined & Azure AD joined managed by MDM) | Windows Server 2012 or later Network Device Enrollment Service |
-| **MFA Requirement** | Azure MFA tenant, or AD FS w/Azure MFA adapter, or AD FS w/Azure MFA Server adapter, or AD FS w/3rd Party MFA Adapter | Azure MFA tenant, or AD FS w/Azure MFA adapter, or AD FS w/Azure MFA Server adapter, or AD FS w/3rd Party MFA Adapter | Azure MFA tenant, or AD FS w/Azure MFA adapter, or AD FS w/Azure MFA Server adapter, or AD FS w/3rd Party MFA Adapter | Azure MFA tenant, or AD FS w/Azure MFA adapter, or AD FS w/Azure MFA Server adapter, or AD FS w/3rd Party MFA Adapter |
+| **Domain Controller Version** | Any supported Windows Server versions | Any supported Windows Server versions | Any supported Windows Server versions | Any supported Windows Server versions |
+| **Certificate Authority**| N/A |Any supported Windows Server versions | Any supported Windows Server versions | Any supported Windows Server versions |
+| **AD FS Version** | N/A | N/A | Any supported Windows Server versions | Any supported Windows Server versions |
+| **MFA Requirement** | Azure MFA, or AD FS w/Azure MFA adapter, or AD FS w/Azure MFA Server adapter, or AD FS w/3rd Party MFA Adapter | Azure MFA tenant, or AD FS w/Azure MFA adapter, or AD FS w/Azure MFA Server adapter, or AD FS w/3rd Party MFA Adapter | Azure MFA tenant, or AD FS w/Azure MFA adapter, or AD FS w/Azure MFA Server adapter, or AD FS w/3rd Party MFA Adapter | Azure MFA tenant, or AD FS w/Azure MFA adapter, or AD FS w/Azure MFA Server adapter, or AD FS w/3rd Party MFA Adapter |
| **Azure AD Connect** | N/A | Required | Required | Required |
| **Azure AD License** | Azure AD Premium, optional | Azure AD Premium, optional | Azure AD Premium, needed for device write-back | Azure AD Premium, optional. Intune license required |
-> [!Important]
-> - Hybrid deployments support non-destructive PIN reset that works with Certificate Trust, Key Trust and cloud Kerberos trust models.
->
-> **Requirements:**
-> - Microsoft PIN Reset Service - Windows 10, versions 1709 to 1809, Enterprise Edition. There is no licensing requirement for this service since version 1903
-> - Reset above lock screen (_I forgot my PIN_ link) - Windows 10, version 1903
->
-> - On-premises deployments support destructive PIN reset that works with both the certificate trust and the key trust models.
->
-> **Requirements:**
-> - Reset from settings - Windows 10, version 1703, Professional
-> - Reset above lock screen - Windows 10, version 1709, Professional
-> - Reset above lock screen (_I forgot my PIN_ link) - Windows 10, version 1903
-
## On-premises Deployments
The table shows the minimum requirements for each deployment.
| Key trust Group Policy managed | Certificate trust Group Policy managed|
| --- | --- |
-| Windows 10, version 1703 or later | Windows 10, version 1703 or later |
+|Any supported Windows client versions|Any supported Windows client versions|
| Windows Server 2016 Schema | Windows Server 2016 Schema|
| Windows Server 2008 R2 Domain/Forest functional level | Windows Server 2008 R2 Domain/Forest functional level |
-| Windows Server 2016 or later Domain Controllers | Windows Server 2008 R2 or later Domain Controllers |
-| Windows Server 2012 or later Certificate Authority | Windows Server 2012 or later Certificate Authority |
-| Windows Server 2016 AD FS with [KB4088889 update](https://support.microsoft.com/help/4088889) | Windows Server 2016 AD FS with [KB4088889 update](https://support.microsoft.com/help/4088889) |
-| AD FS with 3rd Party MFA Adapter | AD FS with 3rd Party MFA Adapter |
-| Azure Account, optional for Azure MFA billing | Azure Account, optional for Azure MFA billing |
-
-> [!IMPORTANT]
-> For Windows Hello for Business key trust deployments, if you have several domains, at least one Windows Server Domain Controller 2016 or newer is required for each domain. For more information, see the [planning guide](./hello-adequate-domain-controllers.md).
+| Any supported Windows Server versions | Any supported Windows Server versions |
+| Any supported Windows Server versions | Any supported Windows Server versions |
+| Any supported Windows Server versions | Any supported Windows Server versions |
+| AD FS with 3rd Party MFA Adapter | AD FS with 3rd Party MFA Adapter |
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/hello-key-trust-adfs.md b/windows/security/identity-protection/hello-for-business/hello-key-trust-adfs.md
index 4a8dc18965..b08abdb82d 100644
--- a/windows/security/identity-protection/hello-for-business/hello-key-trust-adfs.md
+++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-adfs.md
@@ -1,337 +1,261 @@
---
-title: Prepare & Deploy Windows Active Directory Federation Services with key trust (Windows Hello for Business)
-description: How to Prepare and Deploy Windows Server 2016 Active Directory Federation Services for Windows Hello for Business using key trust.
-ms.date: 08/19/2018
+title: Prepare and deploy Active Directory Federation Services in an on-premises key trust
+description: Learn how to configure Active Directory Federation Services to support the Windows Hello for Business key trust model.
+ms.date: 12/12/2022
appliesto:
- ✅ Windows 10 and later
-ms.topic: article
+- ✅ Windows Server 2016 and later
+ms.topic: tutorial
---
-# Prepare and Deploy Windows Server 2016 Active Directory Federation Services with Key Trust
+# Prepare and deploy Active Directory Federation Services - on-premises key trust
[!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 role included with Windows Server 2016 and requires an additional server update. The on-premises key trust deployment uses Active Directory Federation Services roles for key registration and device registration.
+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*.
-The following guidance describes deploying a new instance of Active Directory Federation Services 2016 using the Windows Information Database as the configuration database, which is ideal for environments with no more than 30 federation servers and no more than 100 relying party trusts.
+The following guidance describes the deployment of a new instance of AD FS using the Windows Information Database (WID) as the configuration database.\
+WID is ideal for environments with no more than **30 federation servers** and no more than **100 relying party trusts**. If your environment exceeds either of these factors, or needs to provide *SAML artifact resolution*, *token replay detection*, or needs AD FS to operate as a federated provider role, then the deployment requires the use of SQL as a configuration database.\
+To deploy AD FS using SQL as its configuration database, review the [Deploying a Federation Server Farm](/windows-server/identity/ad-fs/deployment/deploying-a-federation-server-farm) checklist.
-If your environment exceeds either of these factors or needs to provide SAML artifact resolution, token replay detection, or needs Active Directory Federation Services to operate in a federated provider role, then your deployment needs to use a SQL for your configuration database. To deploy the Active Directory Federation Services using SQL as its configuration database, please review the [Deploying a Federation Server Farm](/windows-server/identity/ad-fs/deployment/deploying-a-federation-server-farm) checklist.
+A new AD FS farm should have a minimum of two federation servers for proper load balancing, which can be accomplished with external networking peripherals, or with using the Network Load Balancing Role included in Windows Server.
-If your environment has an existing instance of Active Directory Federation Services, then you’ll need to upgrade all nodes in the farm to Windows Server 2016 along with the Windows Server 2016 update. If your environment uses Windows Internal Database (WID) for the configuration database, please read [Upgrading to AD FS in Windows Server 2016 using a WID database](/windows-server/identity/ad-fs/deployment/upgrading-to-ad-fs-in-windows-server-2016) to upgrade your environment. If your environment uses SQL for the configuration database, please read [Upgrading to AD FS in Windows Server 2016 with SQL Server](/windows-server/identity/ad-fs/deployment/upgrading-to-ad-fs-in-windows-server-2016-sql) to upgrade your environment.
+Prepare the AD FS deployment by installing and **updating** two Windows Servers.
-Ensure you apply the Windows Server 2016 Update to all nodes in the farm after you have successfully completed the upgrade.
+## Enroll for a TLS server authentication certificate
-A new Active Directory Federation Services farm should have a minimum of two federation servers for proper load balancing, which can be accomplished with external networking peripherals, or with using the Network Load Balancing Role included in Windows Server.
+Typically, a federation service is an edge facing role. However, the federation services and instance used with the on-premises deployment of Windows Hello for Business does not need Internet connectivity.
-Prepare the Active Directory Federation Services deployment by installing and updating two Windows Server 2016 Servers. Ensure the update listed below is applied to each server before continuing.
+The AD FS role needs a *server authentication* certificate for the federation services, and you can use a certificate issued by your enterprise (internal) CA. The server authentication certificate should have the following names included in the certificate, if you are requesting an individual certificate for each node in the federation farm:
+ - **Subject Name**: the internal FQDN of the federation server
+ - **Subject Alternate Name**: the federation service name (e.g. *sts.corp.contoso.com*) or an appropriate wildcard entry (e.g. *\*.corp.contoso.com*)
-## Update Windows Server 2016
+The federation service name is set when the AD FS role is configured. You can choose any name, but that name must be different than the name of the server or host. For example, you can name the host server *adfs* and the federation service *sts*. In this example, the FQDN of the host is *adfs.corp.contoso.com* and the FQDN of the federation service is *sts.corp.contoso.com*.
-Sign-in the federation server with _local admin_ equivalent credentials.
-1. Ensure Windows Server 2016 is current by running **Windows Update** from **Settings**. Continue this process until no further updates are needed. If you’re not using Windows Update for updates, please review the [Windows Server 2016 update history page](https://support.microsoft.com/help/4000825/windows-10-windows-server-2016-update-history) to make sure you have the latest updates available installed.
-2. Ensure the latest server updates to the federation server includes [KB4088889 (14393.2155)](https://support.microsoft.com/help/4088889).
+You can also issue one certificate for all hosts in the farm. If you chose this option, leave the subject name *blank*, and include all the names in the subject alternate name when creating the certificate request. All names should include the FQDN of each host in the farm and the federation service name.
+
+When creating a wildcard certificate, mark the private key as exportable, so that the same certificate can be deployed across each federation server and web application proxy within the AD FS farm. Note that the certificate must be trusted (chain to a trusted root CA). Once you have successfully requested and enrolled the server authentication certificate on one node, you can export the certificate and private key to a PFX file using the Certificate Manager console. You can then import the certificate on the remaining nodes in the AD FS farm.
+
+Be sure to enroll or import the certificate into the AD FS server's computer certificate store. Also, ensure all nodes in the farm have the proper TLS server authentication certificate.
+
+### AD FS authentication certificate enrollment
+
+Sign-in the federation server with *domain administrator* equivalent credentials.
+
+1. Start the Local Computer **Certificate Manager** (certlm.msc)
+1. Expand the **Personal** node in the navigation pane
+1. Right-click **Personal**. Select **All Tasks > Request New Certificate**
+1. Select **Next** on the **Before You Begin** page
+1. Select **Next** on the **Select Certificate Enrollment Policy** page
+1. On the **Request Certificates** page, select the **Internal Web Server** check box
+1. Select the **⚠️ More information is required to enroll for this certificate. Click here to configure settings** link
+ :::image type="content" source="images/hello-internal-web-server-cert.png" lightbox="images/hello-internal-web-server-cert.png" alt-text="Example of Certificate Properties Subject Tab - This is what shows when you select the above link.":::
+1. Under **Subject name**, select **Common Name** from the **Type** list. Type the FQDN of the computer hosting the AD FS role and then select **Add**
+1. Under **Alternative name**, select **DNS** from the **Type** list. Type the FQDN of the name that you will use for your federation services (*sts.corp.contoso.com*). The name you use here MUST match the name you use when configuring the AD FS server role. Select **Add** and **OK** when finished
+1. Select **Enroll**
+
+A server authentication certificate should appear in the computer's personal certificate store.
+
+## Deploy the AD FS role
+
+AD FS provides *device registration* and *key registration* services to support the Windows Hello for Business on-premises deployments.
>[!IMPORTANT]
->The above referenced updates are mandatory for Windows Hello for Business all on-premises deployment and hybrid certificate trust deployments for domain joined computers.
+> Finish the entire AD FS configuration on the first server in the farm before adding the second server to the AD FS farm. Once complete, the second server receives the configuration through the shared configuration database when it is added the AD FS farm.
-## Enroll for a TLS Server Authentication Certificate
+Sign-in the federation server with *Enterprise Administrator* equivalent credentials.
-Key trust Windows Hello for Business on-premises deployments need a federation server for device registration and key registration. Typically, a federation service is an edge facing role. However, the federation services and instance used with the on-premises deployment of Windows Hello for Business does not need Internet connectivity.
+1. Start **Server Manager**. Select **Local Server** in the navigation pane
+1. Select **Manage > Add Roles and Features**
+1. Select **Next** on the **Before you begin** page
+1. On the **Select installation type** page, select **Role-based or feature-based installation > Next**
+1. On the **Select destination server** page, choose **Select a server from the server pool**. Select the federation server from the **Server Pool** list and **Next**
+1. On the **Select server roles** page, select **Active Directory Federation Services** and **Next**
+1. Select **Next** on the **Select features** page
+1. Select **Next** on the **Active Directory Federation Service** page
+1. Select **Install** to start the role installation
-The AD FS role needs a server authentication certificate for the federation services, but you can use a certificate issued by your enterprise (internal) certificate authority. The server authentication certificate should have the following names included in the certificate if you are requesting an individual certificate for each node in the federation farm:
-* Subject Name: The internal FQDN of the federation server (the name of the computer running AD FS)
-* Subject Alternate Name: Your federation service name, such as *fs.corp.contoso.com* (or an appropriate wildcard entry such as *.corp.contoso.com)
-
-You configure your federation service name when you configure the AD FS role. You can choose any name, but that name must be different than the name of the server or host. For example, you can name the host server **adfs** and the federation service **fs**. The FQDN of the host is adfs.corp.contoso.com and the FQDN of the federation service is fs.corp.contoso.com.
-
-You can, however, issue one certificate for all hosts in the farm. If you chose this option, then leave the subject name blank, and include all the names in the subject alternate name when creating the certificate request. All names should include the FQDN of each host in the farm and the federation service name.
-
-When creating a wildcard certificate, it is recommended that you mark the private key as exportable so that the same certificate can be deployed across each federation server and web application proxy within your AD FS farm. Note that the certificate must be trusted (chain to a trusted root CA). Once you have successfully requested and enrolled the server authentication certificate on one node, you can export the certificate and private key to a PFX file using the Certificate Manager console. You can then import the certificate on the remaining nodes in the AD FS farm.
-
-Be sure to enroll or import the certificate into the AD FS server’s computer certificate store. Also, ensure all nodes in the farm have the proper TLS server authentication certificate.
-
-### Internal Server Authentication Certificate Enrollment
-
-Sign-in the federation server with domain administrator equivalent credentials.
-1. Start the Local Computer **Certificate Manager** (certlm.msc).
-2. Expand the **Personal** node in the navigation pane.
-3. Right-click **Personal**. Select **All Tasks** and **Request New Certificate**.
-4. Click **Next** on the **Before You Begin** page.
-5. Click **Next** on the **Select Certificate Enrollment Policy** page.
-6. On the **Request Certificates** page, Select the **Internal Web Server** check box.
-7. Click the **More information is required to enroll for this certificate. Click here to configure settings** link
- 
-8. Under **Subject name**, select **Common Name** from the **Type** list. Type the FQDN of the computer hosting the Active Directory Federation Services role and then click **Add**. Under **Alternative name**, select **DNS** from the **Type** list. Type the FQDN of the name you will use for your federation services (fs.corp.contoso.com). The name you use here MUST match the name you use when configuring the Active Directory Federation Services server role. Click **Add**. Click **OK** when finished.
-9. Click **Enroll**.
-
-A server authentication certificate should appear in the computer’s Personal certificate store.
-
-## Deploy the Active Directory Federation Service Role
-
-The Active Directory Federation Service (AD FS) role provides the following services to support Windows Hello for Business on-premises deployments.
-* Device registration
-* Key registration
-
->[!IMPORTANT]
-> Finish the entire AD FS configuration on the first server in the farm before adding the second server to the AD FS farm. Once complete, the second server receives the configuration through the shared configuration database when it is added the AD FS farm.
-
-Windows Hello for Business depends on proper device registration. For on-premises key trust deployments, Windows Server 2016 AD FS handles device and key registration.
-
-Sign-in the federation server with _Enterprise Admin_ equivalent credentials.
-1. Start **Server Manager**. Click **Local Server** in the navigation pane.
-2. Click **Manage** and then click **Add Roles and Features**.
-3. Click **Next** on the **Before you begin** page.
-4. On the **Select installation type** page, select **Role-based or feature-based installation** and click **Next**.
-5. On the **Select destination server** page, choose **Select a server from the server pool**. Select the federation server from the **Server Pool** list. Click **Next**.
-6. On the **Select server roles** page, select **Active Directory Federation Services**. Click **Next**.
-7. Click **Next** on the **Select features** page.
-8. Click **Next** on the **Active Directory Federation Service** page.
-9. Click **Install** to start the role installation.
-
-## Review to validate
+## Review to validate the AD FS deployment
Before you continue with the deployment, validate your deployment progress by reviewing the following items:
-* Confirm the AD FS farm uses the correct database configuration.
-* Confirm the AD FS farm has an adequate number of nodes and is properly load balanced for the anticipated load.
-* Confirm **all** AD FS servers in the farm have the latest updates.
-* Confirm all AD FS servers have a valid server authentication certificate
- * The subject of the certificate is the common name (FQDN) of the host or a wildcard name.
- * The alternate name of the certificate contains a wildcard or the FQDN of the federation service
-## Device Registration Service Account Prerequisite
+> [!div class="checklist"]
+> * Confirm the AD FS farm uses the correct database configuration
+> * Confirm the AD FS farm has an adequate number of nodes and is properly load balanced for the anticipated load
+> * Confirm **all** AD FS servers in the farm have the latest updates installed
+> * Confirm all AD FS servers have a valid server authentication certificate
-The service account used for the device registration server depends on the domain controllers in the environment.
+## Device registration service account prerequisites
->[!NOTE]
->Follow the procedures below based on the domain controllers deployed in your environment. If the domain controller is not listed below, then it is not supported for Windows Hello for Business.
+The use of Group Managed Service Accounts (GMSA) is the preferred way to deploy service accounts for services that support them. GMSAs have security advantages over normal user accounts because Windows handles password management. This means the password is long, complex, and changes periodically. AD FS supports GMSAs, and it should be configured using them for additional security.
-### Windows Server 2012 or later Domain Controllers
+GSMA uses the *Microsoft Key Distribution Service* that is located on the domain controllers. Before you can create a GSMA, you must first create a root key for the service. You can skip this if your environment already uses GSMA.
-Windows Server 2012 or later domain controllers support Group Managed Service Accounts—the preferred way to deploy service accounts for services that support them. Group Managed Service Accounts, or GMSA, have security advantages over normal user accounts because Windows handles password management. This means the password is long, complex, and changes periodically. The best part of GMSA is all this happens automatically. AD FS supports GMSA and should be configured using them for additional defense in depth security.
+### Create KDS Root Key
-GSMA uses the Microsoft Key Distribution Service that is located on Windows Server 2012 or later domain controllers. Windows uses the Microsoft Key Distribution Service to protect secrets stored and used by the GSMA. Before you can create a GSMA, you must first create a root key for the service. You can skip this if your environment already uses GSMA.
+Sign-in a domain controller with *Enterprise Administrator* equivalent credentials.
-#### Create KDS Root Key
-
-Sign-in a domain controller with _Enterprise Admin_ equivalent credentials.
-1. Start an elevated Windows PowerShell console.
-2. Type `Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)`
-
-### Windows Server 2008 or 2008 R2 Domain Controllers
-
-Windows Server 2008 and 2008 R2 domain controllers do not host the Microsoft Key Distribution Service, nor do they support Group Managed Service Accounts. Therefore, you must use or create a normal user account as a service account where you are responsible for changing the password on a regular basis.
-
-#### Create an AD FS Service Account
-
-Sign-in a domain controller or management workstation with _Domain Admin_ equivalent credentials.
-1. Open **Active Directory Users and Computers**.
-2. Right-click the **Users** container, Click **New**. Click **User**.
-3. In the **New Object – User** window, type **adfssvc** in the **Full name** text box. Type **adfssvc** in the **User logon name** text box. Click **Next**.
-4. Enter and confirm a password for the **adfssvc** user. Clear the **User must change password at next logon** check box.
-5. Click **Next** and then click **Finish**.
+Start an elevated PowerShell console and execute the following command:
+```PowerShell
+Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)
+```
## Configure the Active Directory Federation Service Role
->[!IMPORTANT]
->Follow the procedures below based on the domain controllers deployed in your environment. If the domain controller is not listed below, then it is not supported for Windows Hello for Business.
+Use the following procedures to configure AD FS.
-### Windows Server 2016, 2012 R2 or later Domain Controllers
+Sign-in to the federation server with *Domain Administrator* equivalent credentials. These procedures assume you are configuring the first federation server in a federation server farm.
-Use the following procedures to configure AD FS when your environment uses **Windows Server 2012 or later Domain Controllers**. If you are not using Windows Server 2012 or later Domain Controllers, follow the procedures under the [Configure the Active Directory Federation Service Role (Windows Server 2008 or 2008R2 Domain Controllers)](#windows-server-2008-or-2008-r2-domain-controllers) section.
+1. Start **Server Manager**
+1. Select the notification flag in the upper right corner and select **Configure the federation services on this server**
+1. On the **Welcome** page, select **Create the first federation server farm > Next**
+1. On the **Connect to Active Directory Domain Services** page, select **Next**
+1. On the **Specify Service Properties** page, select the recently enrolled or imported certificate from the **SSL Certificate** list. The certificate is likely named after your federation service, such as *sts.corp.contoso.com*
+1. Select the federation service name from the **Federation Service Name** list
+1. Type the *Federation Service Display Name* in the text box. This is the name users see when signing in. Select **Next**
+1. On the **Specify Service Account** page, select **Create a Group Managed Service Account**. In the **Account Name** box, type *adfssvc*
+1. On the **Specify Configuration Database** page, select **Create a database on this server using Windows Internal Database** and select **Next**
+1. On the **Review Options** page, select **Next**
+1. On the **Pre-requisite Checks** page, select **Configure**
+1. When the process completes, select **Close**
-Sign-in the federation server with _Domain Admin_ equivalent credentials. These procedures assume you are configuring the first federation server in a federation server farm.
-1. Start **Server Manager**.
-2. Click the notification flag in the upper right corner. Click **Configure federation services on this server**.
- 
+### Add the AD FS service account to the *Key Admins* group
-3. On the **Welcome** page, click **Create the first federation server farm** and click **Next**.
-4. Click **Next** on the **Connect to Active Directory Domain Services** page.
-5. On the **Specify Service Properties** page, select the recently enrolled or imported certificate from the **SSL Certificate** list. The certificate is likely named after your federation service, such as *fs.corp.contoso.com* or *fs.contoso.com*.
-6. Select the federation service name from the **Federation Service Name** list.
-7. Type the Federation Service Display Name in the text box. This is the name users see when signing in. Click **Next**.
-8. On the **Specify Service Account** page, select **Create a Group Managed Service Account**. In the **Account Name** box, type **adfssvc**.
-9. On the **Specify Configuration Database** page, select **Create a database on this server using Windows Internal Database** and click **Next**.
-10. On the **Review Options** page, click **Next**.
-11. On the **Pre-requisite Checks** page, click **Configure**.
-12. When the process completes, click **Close**.
+During Windows Hello for Business enrollment, the public key is registered in an attribute of the user object in Active Directory. To ensure that the AD FS service can add and remove keys are part of its normal workflow, it must be a member of the *Key Admins* global group.
-### Windows Server 2008 or 2008 R2 Domain Controllers
+Sign-in to a domain controller or management workstation with *Domain Administrator* equivalent credentials.
-Use the following procedures to configure AD FS when your environment uses **Windows Server 2008 or 2008 R2 Domain Controllers**. If you are not using Windows Server 2008 or 2008 R2 Domain Controllers, follow the procedures under the [Configure the Active Directory Federation Service Role (Windows Server 2012 or later Domain Controllers)](#windows-server-2012-or-later-domain-controllers) section.
+1. Open **Active Directory Users and Computers**
+1. Select the **Users** container in the navigation pane
+1. Right-click **Key Admins** in the details pane and select **Properties**
+1. Select the **Members > Add…**
+1. In the **Enter the object names to select** text box, type *adfssvc*. Select **OK**
+1. Select **OK** to return to **Active Directory Users and Computers**
+1. Change to server hosting the AD FS role and restart it
-Sign-in the federation server with _Domain Admin_ equivalent credentials. These instructions assume you are configuring the first federation server in a federation server farm.
-1. Start **Server Manager**.
-2. Click the notification flag in the upper right corner. Click **Configure federation services on this server**.
- 
+## Configure the device registration service
-3. On the **Welcome** page, click **Create the first federation server farm** and click **Next**.
-4. Click **Next** on the **Connect to Active Directory Domain Services** page.
-5. On the **Specify Service Properties** page, select the recently enrolled or imported certificate from the **SSL Certificate** list. The certificate is likely named after your federation service, such as fs.corp.mstepdemo.net or fs.mstepdemo.net.
-6. Select the federation service name from the **Federation Service Name** list.
-7. Type the Federation Service Display Name in the text box. This is the name users see when signing in. Click **Next**.
-8. On the **Specify Service Account** page, Select **Use an existing domain user account or group Managed Service Account** and click **Select**.
- * In the **Select User or Service Account** dialog box, type the name of the previously created AD FS service account (example adfssvc) and click **OK**. Type the password for the AD FS service account and click **Next**.
-9. On the **Specify Configuration Database** page, select **Create a database on this server using Windows Internal Database** and click **Next**.
-10. On the **Review Options** page, click **Next**.
-11. On the **Pre-requisite Checks** page, click **Configure**.
-12. When the process completes, click **Close**.
-13. Do not restart the AD FS server. You will do this later.
+Sign-in to the federation server with *Enterprise Administrator* equivalent credentials. These instructions assume you are configuring the first federation server in a federation server farm.
+1. Open the **AD FS management** console
+1. In the navigation pane, expand **Service**. Select **Device Registration**
+1. In the details pane, select **Configure device registration**
+1. In the **Configure Device Registration** dialog, Select **OK**
-### Add the AD FS Service account to the KeyAdmins group
+:::image type="content" source="images/adfs-device-registration.png" lightbox="images/adfs-device-registration.png" alt-text="AD FS device registration: configuration of the service connection point.":::
-The KeyAdmins global group provides the AD FS service with the permissions needed to perform key registration.
+Triggering device registration from AD FS, creates the service connection point (SCP) in the Active Directory configuration partition. The SCP is used to store the device registration information that Windows clients will automatically discover.
-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 **KeyAdmins** 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 **adfssvc**. Click **OK**.
-6. Click **OK** to return to **Active Directory Users and Computers**.
-7. Change to server hosting the AD FS role and restart it.
+:::image type="content" source="images/adfs-scp.png" lightbox="images/adfs-scp.png" alt-text="AD FS device registration: service connection point object created by AD FS.":::
-
-## Configure the Device Registration Service
-
-Sign-in the federation server with _Enterprise Admin_ equivalent credentials. These instructions assume you are configuring the first federation server in a federation server farm.
-1. Open the **AD FS management** console.
-2. In the navigation pane, expand **Service**. Click **Device Registration**.
-3. In the details pane, click **Configure Device Registration**.
-4. In the **Configure Device Registration** dialog, click **OK**.
-
-## Review and validate
+## Review to validate the AD FS and Active Directory configuration
Before you continue with the deployment, validate your deployment progress by reviewing the following items:
-* Confirm you followed the correct procedures based on the domain controllers used in your deployment
- * Windows Server 2016, 2012 R2 or Windows Server 2012 R2
- * Windows Server 2008 or Windows Server 2008 R2
-* Confirm you have the correct service account based on your domain controller version.
-* Confirm you properly installed the AD FS role on your Windows Server 2016 based on the proper sizing of your federation, the number of relying parties, and database needs.
-* Confirm you used a certificate with the correct names as the server authentication certificate
- * Record the expiration date of the certificate and set a renewal reminder at least six weeks before it expires that includes the:
- * Certificate serial number
- * Certificate thumbprint
- * Common name of the certificate
- * Subject alternate name of the certificate
- * Name of the physical host server
- * The issued date
- * The expiration date
- * Issuing CA Vendor (if a third-party certificate)
-* Confirm you added the AD FS service account to the KeyAdmins group.
-* Confirm you enabled the Device Registration service.
+> [!div class="checklist"]
+> * Record the information about the AD FS certificate, and set a renewal reminder at least six weeks before it expires. Relevant information includes: certificate serial number, thumbprint, common name, subject alternate name, name of the physical host server, the issued date, the expiration date, and issuing CA vendor (if a third-party certificate)
+> * Confirm you added the AD FS service account to the KeyAdmins group
+> * Confirm you enabled the Device Registration service
-## Additional Federation Servers
+## Additional federation servers
-Organizations should deploy more than one federation server in their federation farm for high-availability. You should have a minimum of two federation services in your AD FS farm, however most organizations are likely to have more. This largely depends on the number of devices and users using the services provided by the AD FS farm.
+Organizations should deploy more than one federation server in their federation farm for high-availability. You should have a minimum of two federation services in your AD FS farm, however most organizations are likely to have more. This largely depends on the number of devices and users using the services provided by the AD FS farm.
-### Server Authentication Certificate
+### Server authentication certificate
Each server you add to the AD FS farm must have a proper server authentication certificate. Refer to the [Enroll for a TLS Server Authentication Certificate](#enroll-for-a-tls-server-authentication-certificate) section of this document to determine the requirements for your server authentication certificate. As previously stated, AD FS servers used exclusively for on-premises deployments of Windows Hello for Business can use enterprise server authentication certificates rather than server authentication certificates issued by public certificate authorities.
-### Install Additional Servers
+### Install additional servers
-Adding federation servers to the existing AD FS farm begins with ensuring the server are fully patched, to include Windows Server 2016 Update needed to support Windows Hello for Business deployments (https://aka.ms/whfbadfs1703). Next, install the Active Directory Federation Service role on the additional servers and then configure the server as an additional server in an existing farm.
+Adding federation servers to the existing AD FS farm begins with ensuring the server are fully patched, to include Windows Server 2016 Update needed to support Windows Hello for Business deployments (https://aka.ms/whfbadfs1703). Next, install the Active Directory Federation Service role on the additional servers and then configure the server as an additional server in an existing farm.
-## Load Balance AD FS Federation Servers
+## Load balance AD FS
Many environments load balance using hardware devices. Environments without hardware load-balancing capabilities can take advantage the network load-balancing feature included in Windows Server to load balance the AD FS servers in the federation farm. Install the Windows Network Load Balancing feature on all nodes participating in the AD FS farm that should be load balanced.
### Install Network Load Balancing Feature on AD FS Servers
-Sign-in the federation server with _Enterprise Admin_ equivalent credentials.
-1. Start **Server Manager**. Click **Local Server** in the navigation pane.
-2. Click **Manage** and then click **Add Roles and Features**.
-3. Click **Next** On the **Before you begin** page.
-4. On the **Select installation type** page, select **Role-based or feature-based installation** and click **Next**.
-5. On the **Select destination server** page, choose **Select a server from the server pool**. Select the federation server from the **Server Pool** list. Click **Next**.
-6. On the **Select server roles** page, click **Next**.
-7. Select **Network Load Balancing** on the **Select features** page.
-8. Click **Install** to start the feature installation
- 
+Sign-in the federation server with *Enterprise Administrator* equivalent credentials.
+
+1. Start **Server Manager**. Select **Local Server** in the navigation pane
+1. Select **Manage** and then select **Add Roles and Features**
+1. Select **Next** On the **Before you begin** page
+1. On the **Select installation type** page, select **Role-based or feature-based installation** and select **Next**
+1. On the **Select destination server** page, choose **Select a server from the server pool**. Select the federation server from the **Server Pool** list. Select **Next**
+1. On the **Select server roles** page, select **Next**
+1. Select **Network Load Balancing** on the **Select features** page
+1. Select **Install** to start the feature installation
### Configure Network Load Balancing for AD FS
Before you can load balance all the nodes in the AD FS farm, you must first create a new load balance cluster. Once you have created the cluster, then you can add new nodes to that cluster.
-Sign-in a node of the federation farm with _Admin_ equivalent credentials.
-1. Open **Network Load Balancing Manager** from **Administrative Tools**.
- 
-2. Right-click **Network Load Balancing Clusters**, and then click **New Cluster**.
-3. To connect to the host that is to be a part of the new cluster, in the **Host** text box, type the name of the host, and then click **Connect**.
- 
-4. Select the interface that you want to use with the cluster, and then click **Next**. (The interface hosts the virtual IP address and receives the client traffic to load balance.)
-5. In **Host Parameters**, select a value in **Priority (Unique host identifier)**. This parameter specifies a unique ID for each host. The host with the lowest numerical priority among the current members of the cluster handles all of the cluster's network traffic that is not covered by a port rule. Click **Next**.
-6. In **Cluster IP Addresses**, click **Add** and type the cluster IP address that is shared by every host in the cluster. NLB adds this IP address to the TCP/IP stack on the selected interface of all hosts that are chosen to be part of the cluster. Click **Next**.
- 
-7. In **Cluster Parameters**, select values in **IP Address** and **Subnet mask** (for IPv6 addresses, a subnet mask value is not needed). Type the full Internet name that users will use to access this NLB cluster.
- 
-8. In **Cluster operation mode**, click **Unicast** to specify that a unicast media access control (MAC) address should be used for cluster operations. In unicast mode, the MAC address of the cluster is assigned to the network adapter of the computer, and the built-in MAC address of the network adapter is not used. We recommend that you accept the unicast default settings. Click **Next**.
-9. In Port Rules, click Edit to modify the default port rules to use port 443.
- 
+Sign-in a node of the federation farm with *Administrator* equivalent credentials.
+
+1. Open **Network Load Balancing Manager** from **Administrative Tools**
+1. Right-click **Network Load Balancing Clusters**, and then select **New Cluster**
+1. To connect to the host that is to be a part of the new cluster, in the **Host** text box, type the name of the host, and then select **Connect**
+1. Select the interface that you want to use with the cluster, and then select **Next** (the interface hosts the virtual IP address and receives the client traffic to load balance)
+1. In **Host Parameters**, select a value in **Priority (Unique host identifier)**. This parameter specifies a unique ID for each host. The host with the lowest numerical priority among the current members of the cluster handles all of the cluster's network traffic that is not covered by a port rule. Select **Next**
+1. In **Cluster IP Addresses**, select **Add** and type the cluster IP address that is shared by every host in the cluster. NLB adds this IP address to the TCP/IP stack on the selected interface of all hosts that are chosen to be part of the cluster. Select **Next**
+1. In **Cluster Parameters**, select values in **IP Address** and **Subnet mask** (for IPv6 addresses, a subnet mask value is not needed). Type the full Internet name that users will use to access this NLB cluster
+1. In **Cluster operation mode**, select **Unicast** to specify that a unicast media access control (MAC) address should be used for cluster operations. In unicast mode, the MAC address of the cluster is assigned to the network adapter of the computer, and the built-in MAC address of the network adapter is not used. We recommend that you accept the unicast default settings. Select **Next**
+1. In Port Rules, select Edit to modify the default port rules to use port 443
### Additional AD FS Servers
-1. To add more hosts to the cluster, right-click the new cluster, and then click **Add Host to Cluster**.
-2. Configure the host parameters (including host priority, dedicated IP addresses, and load weight) for the additional hosts by following the same instructions that you used to configure the initial host. Because you are adding hosts to an already configured cluster, all the cluster-wide parameters remain the same.
- 
+1. To add more hosts to the cluster, right-click the new cluster, and then select **Add Host to Cluster**
+1. Configure the host parameters (including host priority, dedicated IP addresses, and load weight) for the additional hosts by following the same instructions that you used to configure the initial host. Because you are adding hosts to an already configured cluster, all the cluster-wide parameters remain the same
## Configure DNS for Device Registration
-Sign-in the domain controller or administrative workstation with domain administrator equivalent credentials. You’ll need the Federation service name to complete this task. You can view the federation service name by clicking **Edit Federation Service Properties** from the **Action** pan of the **AD FS** management console, or by using `(Get-AdfsProperties).Hostname.` (PowerShell) on the AD FS server.
-1. Open the **DNS Management** console.
-2. In the navigation pane, expand the domain controller name node and **Forward Lookup Zones**.
-3. In the navigation pane, select the node that has the name of your internal Active Directory domain name.
-4. In the navigation pane, right-click the domain name node and click **New Host (A or AAAA)**.
-5. In the **name** box, type the name of the federation service. In the **IP address** box, type the IP address of your federation server. Click **Add Host**.
-6. Right-click the `domain_name` node and select **New Alias (CNAME)**.
-7. In the **New Resource Record** dialog box, type "enterpriseregistration" in the **Alias** name box.
-8. In the **fully qualified domain name (FQDN)** of the target host box, type `federation_service_farm_name.domain_name.com`, and click OK.
-9. Close the DNS Management console.
+Sign-in the domain controller or administrative workstation with domain administrator equivalent credentials.\
+You'll need the *federation service* name to complete this task. You can view the federation service name by selecting **Edit Federation Service Properties** from the **Action** pan of the **AD FS** management console, or by using `(Get-AdfsProperties).Hostname.` (PowerShell) on the AD FS server.
+
+1. Open the **DNS Management** console
+1. In the navigation pane, expand the domain controller name node and **Forward Lookup Zones**
+1. In the navigation pane, select the node that has the name of your internal Active Directory domain name
+1. In the navigation pane, right-click the domain name node and select **New Host (A or AAAA)**
+1. In the **name** box, type the name of the federation service. In the **IP address** box, type the IP address of your federation server. Select **Add Host**
+1. Right-click the `` node and select **New Alias (CNAME)**
+1. In the **New Resource Record** dialog box, type `enterpriseregistration` in the **Alias** name box
+1. In the **fully qualified domain name (FQDN)** of the target host box, type `federation_service_farm_name. [!NOTE]
-> If your forest has multiple UPN suffixes, please make sure that `enterpriseregistration.upnsuffix.com` is present for each suffix.
+> If your forest has multiple UPN suffixes, please make sure that `enterpriseregistration.` is present for each suffix.
## Configure the Intranet Zone to include the federation service
-The Windows Hello provisioning presents web pages from the federation service. Configuring the intranet zone to include the federation service enables the user to authenticate to the federation service using integrated authentication. Without this setting, the connection to the federation service during Windows Hello provisioning prompts the user for authentication.
+The Windows Hello provisioning presents web pages from the federation service. Configuring the intranet zone to include the federation service enables the user to authenticate to the federation service using integrated authentication. Without this setting, the connection to the federation service during Windows Hello provisioning prompts the user for authentication.
### Create an Intranet Zone Group Policy
Sign-in the domain controller or administrative workstation 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 **Intranet Zone Settings** in the name box and click **OK**.
-5. In the content pane, right-click the **Intranet Zone Settings** Group Policy object and click **Edit**.
-6. In the navigation pane, expand **Policies** under **Computer Configuration**.
-7. Expand **Administrative Templates > Windows Component > Internet Explorer > Internet Control Panel**, and select **Security Page**.
-8. In the content pane, double-click **Site to Zone Assignment List**. Click **Enable**.
-9. Click **Show**. In the **Value Name** column, type the url of the federation service beginning with https. In the **Value** column, type the number **1**. Click OK twice, then close the Group Policy Management Editor.
+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 **Intranet Zone Settings** in the name box and select **OK**
+1. In the content pane, right-click the **Intranet Zone Settings** Group Policy object and select **Edit**
+1. In the navigation pane, expand **Policies** under **Computer Configuration**
+1. Expand **Administrative Templates > Windows Component > Internet Explorer > Internet Control Panel >Security Page**. Open **Site to Zone Assignment List**
+1. Select **Enable > Show**. In the **Value Name** column, type the url of the federation service beginning with https. In the **Value** column, type the number **1**. Select OK twice, then close the Group Policy Management Editor
### Deploy the Intranet Zone Group Policy object
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 **Intranet Zone Settings** or the name of the Windows Hello for Business Group Policy object you previously created and click **OK**.
+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 **Intranet Zone Settings** or the name of the Windows Hello for Business Group Policy object you previously created and select **OK**
-## Review
+## Review to validate the configuration
Before you continue with the deployment, validate your deployment progress by reviewing the following items:
-* Confirm all AD FS servers have a valid server authentication certificate
- * The subject of the certificate is the common name (FQDN) of the host or a wildcard name.
- * The alternate name of the certificate contains a wildcard or the FQDN of the federation service
-* Confirm the AD FS farm has an adequate number of nodes and is properly load balanced for the anticipated load.
-* Confirm **all** AD FS servers in the farm have the latest updates.
-* Confirm you restarted the AD FS service.
-* Confirm you created a DNS A Record for the federation service and the IP address used is the load-balanced IP address
-* Confirm you created and deployed the Intranet Zone settings to prevent double authentication to the federation server.
+> [!div class="checklist"]
+> * Confirm all AD FS servers have a valid server authentication certificate. The subject of the certificate is the common name (FQDN) of the host or a wildcard name. The alternate name of the certificate contains a wildcard or the FQDN of the federation service
+> * Confirm the AD FS farm has an adequate number of nodes and is properly load balanced for the anticipated load
+> * Confirm you restarted the AD FS service
+> * Confirm you created a DNS A Record for the federation service and the IP address used is the load-balanced IP address
+> * Confirm you created and deployed the Intranet Zone settings to prevent double authentication to the federation server
-## Follow the Windows Hello for Business on premises certificate trust deployment guide
-
-1. [Validate Active Directory prerequisites](hello-key-trust-validate-ad-prereq.md)
-2. [Validate and Configure Public Key Infrastructure](hello-key-trust-validate-pki.md)
-3. Prepare and Deploy Windows Server 2016 Active Directory Federation Services (*You are here*)
-4. [Validate and Deploy Multifactor Authentication Services (MFA)](hello-key-trust-validate-deploy-mfa.md)
-5. [Configure Windows Hello for Business Policy settings](hello-key-trust-policy-settings.md)
+> [!div class="nextstepaction"]
+> [Next: validate and deploy multi-factor authentication (MFA)](hello-key-trust-validate-deploy-mfa.md)
diff --git a/windows/security/identity-protection/hello-for-business/hello-key-trust-policy-settings.md b/windows/security/identity-protection/hello-for-business/hello-key-trust-policy-settings.md
index c618365d4e..03e7dbfe38 100644
--- a/windows/security/identity-protection/hello-for-business/hello-key-trust-policy-settings.md
+++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-policy-settings.md
@@ -1,71 +1,70 @@
---
-title: Configure Windows Hello for Business Policy settings - key trust
-description: Configure Windows Hello for Business Policy settings for Windows Hello for Business
-ms.date: 08/19/2018
+title: Configure Windows Hello for Business Policy settings in an on-premises key trust
+description: Configure Windows Hello for Business Policy settings for Windows Hello for Business in an on-premises key trust scenario
+ms.date: 12/12/2022
appliesto:
- ✅ Windows 10 and later
-ms.topic: article
+- ✅ Windows Server 2016 and later
+ms.topic: tutorial
---
-# Configure Windows Hello for Business Policy settings - Key Trust
+# 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)]
-To run the Group Policy Management Console from a Windows client, you need to install the Remote Server Administration Tools for Windows. You can download these tools from [Microsoft Download Center](https://www.microsoft.com/download/details.aspx?id=45520).
+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.
-Alternatively, you can create a copy of the .ADMX and .ADML files from a Windows client installation setup template folder 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.
+If you configure the Group Policy for computers, all users that sign-in to those computers will be allowed and prompted to enroll for Windows Hello for Business. If you configure the Group Policy for users, only those users will be allowed and prompted to enroll for Windows Hello for Business.
-On-premises certificate-based deployments of Windows Hello for Business needs one Group Policy setting: Enable Windows Hello for Business
+## Enable Windows Hello for Business group policy setting
-## Enable Windows Hello for Business Group Policy
+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.
-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.
+If you configure the Group Policy for computers, all users that sign-in to those computers will be allowed and prompted to enroll for Windows Hello for Business. If you configure the Group Policy for users, only those users will be allowed and prompted to enroll for Windows Hello for Business .
-If you configure the Group Policy for computers, all users that sign-in to those computers will be allowed and prompted to enroll for Windows Hello for Business. If you configure the Group Policy for users, only those users will be allowed and prompted to enroll for Windows Hello for Business. For these settings to be configured using GPO, you need to download and install the latest Administrative Templates (.admx) for Windows.
+## Create the GPO
+Sign in to a domain controller or management workstations with *Domain Administrator* equivalent credentials.
-## 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.
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. Close the **Group Policy Management Editor**.
+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, select **User Configuration > Policies > **Administrative Templates > Windows Component > Windows Hello for Business**
+1. In the content pane, double-click **Use Windows Hello for Business**. Select **Enable** and **OK**
+1. Close the **Group Policy Management Editor**
-## Configure Security in the Windows Hello for Business Group Policy object
+## Configure security in the Windows Hello for Business GPO
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.
+
+Sign in to a domain controller or management workstations with *Domain Administrator* 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. 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**.
+1. Expand the domain and select the **Group Policy Object** node in the navigation pane
+1. Double-click the **Enable Windows Hello for Business** Group Policy object
+1. In the **Security Filtering** section of the content pane, select **Add**. Type *Windows Hello for Business Users* or the name of the security group you previously created and select **OK**
+1. Select the **Delegation** tab. Select **Authenticated Users** and **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 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**.
+The application of the Windows Hello for Business Group Policy object uses security group filtering. This solution enables you to link the Group Policy object at the domain level, ensuring the GPO is within scope to all users. However, the security group filtering ensures that 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.
-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.
+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**
## 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.
+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.
+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.
@@ -73,47 +72,37 @@ Another policy setting becomes available when you enable the **Use a hardware se
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 the ability to set granular policies that enable you to disable specific modalities of biometrics, such as allowing facial recognition, but disallowing fingerprint recognition.
+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 disables all biometrics. Currently, Windows does not 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.
+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
+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. The policy settings included are:
-In the 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 Administrative Templates\System\PIN Complexity under both the Computer and User Configuration nodes of the Group Policy editor.
+- Require digits
+- Require lowercase letters
+- Maximum PIN length
+- Minimum PIN length
+- Expiration
+- History
+- Require special characters
+- Require uppercase letters
-## Review
+The settings can be found in *Administrative Templates\System\PIN Complexity*, under both the Computer and User Configuration nodes of the Group Policy editor.
+
+## Review to validate the configuration
Before you continue with the deployment, validate your deployment progress by reviewing the following items:
-* Confirm you authored Group Policy settings using the latest ADMX/ADML files (from the Windows 10 Creators Editions)
-* Confirm you configured the Enable Windows Hello for Business to the scope that matches your deployment (Computer vs. User)
-* Confirm you configure the Use Certificate enrollment for on-premises authentication policy setting.
-* Confirm you configure automatic certificate enrollment to the scope that matches your deployment (Computer vs. User)
-* Confirm you configured the proper security settings for the Group Policy object
- * Removed the allow permission for Apply Group Policy for Domain Users (Domain Users must always have the read permissions)
- * Add the Windows Hello for Business Users group to the Group Policy object and gave the group the allow permission for Apply Group Policy
-
-* Linked the Group Policy object to the correct locations within Active Directory
-* Deploy any additional Windows Hello for Business Group Policy setting is a policy separate from the one that enables it for users
+> [!div class="checklist"]
+> * Confirm you configured the Enable Windows Hello for Business to the scope that matches your deployment (Computer vs. User)
+> * Confirm you configured the proper security settings for the Group Policy object
+> * Confirm you removed the allow permission for Apply Group Policy for Domain Users (Domain Users must always have the read permissions)
+> * Confirm you added the Windows Hello for Business Users group to the Group Policy object, and gave the group the allow permission to Apply Group Policy
+> * Linked the Group Policy object to the correct locations within Active Directory
+> * Deployed any additional Windows Hello for Business Group Policy settings
## 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 that are not members of this group will not attempt to enroll for Windows Hello for Business.
-
-
-## Follow the Windows Hello for Business on premises certificate trust deployment guide
-1. [Validate Active Directory prerequisites](hello-cert-trust-validate-ad-prereq.md)
-2. [Validate and Configure Public Key Infrastructure](hello-cert-trust-validate-pki.md)
-3. [Prepare and Deploy Windows Server 2016 Active Directory Federation Services](hello-cert-trust-adfs.md)
-4. [Validate and Deploy Multifactor Authentication Services (MFA)](hello-cert-trust-validate-deploy-mfa.md)
-5. Configure Windows Hello for Business Policy settings (*You are here*)
+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 that are not members of this group will not attempt to enroll for Windows Hello for Business.
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-ad-prereq.md b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-ad-prereq.md
index 57080612a2..e53e1d194f 100644
--- a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-ad-prereq.md
+++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-ad-prereq.md
@@ -1,39 +1,32 @@
---
-title: Key registration for on-premises deployment of Windows Hello for Business
-description: How to Validate Active Directory prerequisites for Windows Hello for Business when deploying with the key trust model.
-ms.date: 08/19/2018
+title: Validate Active Directory prerequisites in an on-premises key trust
+description: Validate Active Directory prerequisites when deploying Windows Hello for Business in a key trust model.
+ms.date: 12/12/2022
appliesto:
- ✅ Windows 10 and later
-ms.topic: article
+- ✅ Windows Server 2016 and later
+ms.topic: tutorial
---
-# Validate Active Directory prerequisites - Key Trust
+# Validate Active Directory prerequisites - on-premises key trust
[!INCLUDE [hello-on-premises-key-trust](../../includes/hello-on-premises-key-trust.md)]
-Key trust deployments need an adequate number of 2016 or later 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), the [Planning an adequate number of Windows Server 2016 or later Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) section.
+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.
-> [!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.
+The key registration process for the on-premises deployment of Windows Hello for Business requires the Windows Server 2016 Active Directory or later schema.
-The key registration process for the On-premises deployment of Windows Hello for Business needs the Windows Server 2016 Active Directory or later schema. The key-trust model receives the schema extension when the first Windows Server 2016 domain controller is added to the forest. The minimum required domain functional and forest functional levels for Windows Hello for Business deployment is Windows Server 2008 R2.
+## Create the Windows Hello for Business Users security group
-## Create the Windows Hello for Business Users Security Global 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 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.
-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 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.
+Sign-in to a domain controller or to a management workstation with a *Domain Administrator* equivalent credentials.
-Sign-in a domain controller or management workstation with _Domain Admin_ equivalent credentials.
+1. Open **Active Directory Users and Computers**
+1. Select **View > Advanced Features**
+1. Expand the domain node from the navigation pane
+1. Right-click the **Users** container. Select **New > Group**
+1. Type *Windows Hello for Business Users* in the **Group Name**
+1. Select **OK**
-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**.
-
-
-## Follow the Windows Hello for Business on premises certificate trust deployment guide
-1. Validate Active Directory prerequisites (*You are here*)
-2. [Validate and Configure Public Key Infrastructure](hello-key-trust-validate-pki.md)
-3. [Prepare and Deploy Windows Server 2016 Active Directory Federation Services](hello-key-trust-adfs.md)
-4. [Validate and Deploy Multifactor Authentication Services (MFA)](hello-key-trust-validate-deploy-mfa.md)
-5. [Configure Windows Hello for Business Policy settings](hello-key-trust-policy-settings.md)
+> [!div class="nextstepaction"]
+> [Next: validate and configure PKI >](hello-key-trust-validate-pki.md)
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-deploy-mfa.md b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-deploy-mfa.md
index 046acb3df3..6088986d1e 100644
--- a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-deploy-mfa.md
+++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-deploy-mfa.md
@@ -1,28 +1,29 @@
---
title: Validate and Deploy MFA for Windows Hello for Business with key trust
-description: How to Validate and Deploy Multifactor Authentication (MFA) Services for Windows Hello for Business with key trust
-ms.date: 08/19/2018
+description: Validate and deploy multi-factor authentication (MFA) for Windows Hello for Business in an on-premises key trust model.
+ms.date: 12/12/2022
appliesto:
- ✅ Windows 10 and later
-ms.topic: article
+- ✅ Windows Server 2016 and later
+ms.topic: tutorial
---
-# Validate and Deploy Multifactor Authentication (MFA)
+
+# Validate and deploy multi-factor authentication - on-premises key trust
[!INCLUDE [hello-on-premises-key-trust](../../includes/hello-on-premises-key-trust.md)]
-> [!IMPORTANT]
-> As of July 1, 2019, Microsoft will no longer offer MFA Server for new deployments. New customers who would like to require multifactor 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.
+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 Hello for Business requires all users perform multi-factor authentication prior to creating and registering a Windows Hello for Business credential. On-premises deployments can use certificates, third-party authentication providers for AD FS, or a custom authentication provider for AD FS as an on-premises MFA option.
+- certificates
+- third-party authentication providers for AD FS
+- custom authentication provider for AD FS
+
+> [!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)
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 Windows Hello for Business on premises certificate trust deployment guide
-
-1. [Validate Active Directory prerequisites](hello-key-trust-validate-ad-prereq.md)
-2. [Validate and Configure Public Key Infrastructure](hello-key-trust-validate-pki.md)
-3. [Prepare and Deploy Windows Server 2016 Active Directory Federation Services](hello-key-trust-adfs.md)
-4. Validate and Deploy Multifactor Authentication Services (MFA) (*You are here*)
-5. [Configure Windows Hello for Business Policy settings](hello-key-trust-policy-settings.md)
\ No newline at end of file
+> [!div class="nextstepaction"]
+> [Next: configure Windows Hello for Business Policy settings](hello-key-trust-policy-settings.md)
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-pki.md b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-pki.md
index c3a9226714..dac396577a 100644
--- a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-pki.md
+++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-pki.md
@@ -1,245 +1,248 @@
---
-title: Validate Public Key Infrastructure - key trust model (Windows Hello for Business)
-description: How to Validate Public Key Infrastructure for Windows Hello for Business, under a key trust model.
-ms.date: 08/19/2018
+title: Configure and validate the Public Key Infrastructure in an on-premises key trust model
+description: Configure and validate the Public Key Infrastructure when deploying Windows Hello for Business in a key trust model.
+ms.date: 12/12/2022
appliesto:
- ✅ Windows 10 and later
-ms.topic: article
+- ✅ Windows Server 2016 and later
+ms.topic: tutorial
---
-# Validate and Configure Public Key Infrastructure - Key Trust
+# Configure and validate the Public Key Infrastructure - on-premises key trust
[!INCLUDE [hello-on-premises-key-trust](../../includes/hello-on-premises-key-trust.md)]
-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.
+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 certificate authority
+## Deploy an enterprise certification authority
-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.
+This guide assumes most enterprises have an existing public key infrastructure. Windows Hello for Business depends on an enterprise PKI running the Windows Server *Active Directory Certificate Services* role.
-### Lab-based public key infrastructure
+### Lab-based PKI
-The following instructions may be used to deploy simple public key infrastructure that is suitable for a lab environment.
+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.
+Sign in using *Enterprise Administrator* equivalent credentials on a Windows Server where you want the certification authority (CA) installed.
>[!NOTE]
->Never install a certificate authority on a domain controller in a production environment.
+>Never install a certification 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.
+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 Certificate Authority using a basic certificate authority configuration.
+3. Use the following command to configure the CA using a basic certification 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.
-
-### Configure Domain Controller Certificates
-
-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. Therefore, domain controllers need to request a certificate based on the Kerberos Authentication certificate template.
-
-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.
-
-Sign in to 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 **Certification 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.
-
-### Superseding the existing Domain Controller certificate
-
-Many domain controllers may have an existing domain controller certificate. The Active Directory Certificate Services provides a default certificate template from 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 to 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.
-
-### Configure an Internal Web Server Certificate template
-
-Windows clients use the https protocol when communicating with Active Directory Federation Services. To meet this need, you must issue a server authentication certificate to all the nodes in the Active Directory Federation Services 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 the Active Directory Federation Service can request the certificate.
-
-Sign in to 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 **Web Server** 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 **Certification Recipient** list.
-
-5. 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.
-
-6. On the **Request Handling** tab, select **Allow private key to be exported**.
-
-7. On the **Subject** tab, select the **Supply in the request** button if it is not already selected.
-
-8. On the **Security** tab, Click **Add**. Type **Domain Computers** in the **Enter the object names to select** box. Click **OK**. Select the **Allow** check box next to the **Enroll** permission.
-
-9. 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**.
-
-10. 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.
-
-### Publish Certificate Templates to the 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 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 **Certificate Templates** node. Click **New**, and click **Certificate Template** to issue.
-
-5. In the **Enable Certificates Templates** window, select the **Domain Controller Authentication (Kerberos)**, and **Internal Web Server** templates 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.
-
-### 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.
+ ```
+
+## 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.
+
+
+
+Configure domain controller certificates
+
+Clients must trust the domain controllers, and to it each domain controller must have a *Kerberos Authentication* certificate. Installing a certificate on the domain controllers enables the Key Distribution Center (KDC) to prove its identity to other members of the domain. The certificates provide clients a root of trust external to the domain, namely the *enterprise certification authority*.
+
+Domain controllers automatically request a domain controller certificate (if published) when they discover an enterprise CA is added to Active Directory. However, certificates based on the Domain Controller and Domain Controller Authentication certificate templates don't include the *KDC Authentication* object identifier (OID), which was later added to the Kerberos RFC. Therefore, domain controllers need to request a certificate based on the *Kerberos Authentication* certificate template.
+
+By default, the Active Directory CA provides and publishes the *Kerberos Authentication* certificate template. The cryptography configuration included in the template is based on older and less performant cryptography APIs. To ensure domain controllers request the proper certificate with the best available cryptography, use the *Kerberos Authentication* certificate template as a *baseline* to create an updated domain controller certificate template.
+
+Sign in to a CA or management workstations with *Domain Administrator* equivalent credentials.
+
+1. Open the **Certification Authority** management console
+1. Right-click **Certificate Templates > Manage**
+1. In the **Certificate Template Console**, right-click the **Kerberos Authentication** template in the details pane and select **Duplicate Template**
+1. On the **Compatibility** tab:
+ - Clear the **Show resulting changes** check box
+ - Select **Windows Server 2016** from the **Certification Authority** list
+ - Select **Windows 10 / Windows Server 2016** from the **Certificate Recipient** list
+1. On the **General** tab
+ - Type *Domain Controller Authentication (Kerberos)* in Template display name
+ - Adjust the validity and renewal period to meet your enterprise's needs
+ > [!NOTE]
+ > If you use different template names, you'll need to remember and substitute these names in different portions of the lab.
+1. On the **Subject Name** tab:
+ - Select the **Build from this Active Directory information** button if it isn't already selected
+ - Select **None** from the **Subject name format** list
+ - Select **DNS name** from the **Include this information in alternate subject** list
+ - Clear all other items
+1. On the **Cryptography** tab:
+ - select **Key Storage Provider** from the **Provider Category** list
+ - Select **RSA** from the **Algorithm name** list
+ - Type *2048* in the **Minimum key size** text box
+ - Select **SHA256** from the **Request hash** list
+1. Select **OK**
+1. Close the console
+
+
+
+
+
+
+Supersede existing domain controller certificates
+
+The domain controllers may have an existing domain controller certificate. The Active Directory Certificate Services provides a default certificate template for domain controllers called *domain controller certificate*. Later releases of Windows Server provided a new certificate template called *domain controller authentication certificate*. These certificate templates were provided prior to the update of the Kerberos specification that stated Key Distribution Centers (KDCs) performing certificate authentication needed to include the *KDC Authentication* extension.
+
+The *Kerberos Authentication* certificate template is the most current certificate template designated for domain controllers, and should be the one you deploy to all your domain controllers.\
+The *autoenrollment* feature allows you to replace the domain controller certificates. Use the following configuration to replace older domain controller certificates with new ones, using the *Kerberos Authentication* certificate template.
+
+Sign in to a CA or management workstations with *Enterprise Administrator* equivalent credentials.
+
+1. Open the **Certification Authority** management console
+1. Right-click **Certificate Templates > Manage**
+1. In the **Certificate Template Console**, right-click the *Domain Controller Authentication (Kerberos)* (or the name of the certificate template you created in the previous section) template in the details pane and select **Properties**
+1. Select the **Superseded Templates** tab. Select **Add**
+1. From the **Add Superseded Template** dialog, select the *Domain Controller* certificate template and select **OK > Add**
+1. From the **Add Superseded Template** dialog, select the *Domain Controller Authentication* certificate template and select **OK**
+1. From the **Add Superseded Template** dialog, select the *Kerberos Authentication* certificate template and select **OK**
+1. Add any other enterprise certificate templates that were previously configured for domain controllers to the **Superseded Templates** tab
+1. Select **OK** and close the **Certificate Templates** console
+
+The certificate template is configured to supersede all the certificate templates provided in the certificate templates superseded templates list. However, the certificate template and the superseding of certificate templates isn't active until the certificate template is published to one or more certificate authorities.
+
+
+
+
+
+Configure an internal web server certificate template
+
+Windows clients use the https protocol when communicating with Active Directory Federation Services (AD FS). To meet this need, you must issue a server authentication certificate to all the nodes in the AD FS farm. On-premises deployments can use a server authentication certificate issued by their enterprise PKI. You must configure a server authentication certificate template so the host running theAD FS can request the certificate.
+
+Sign in to a CA or management workstations with *Domain Administrator* equivalent credentials.
+
+1. Open the **Certification Authority** management console
+1. Right-click **Certificate Templates** and select **Manage**
+1. In the **Certificate Template Console**, right-click the **Web Server** template in the details pane and select **Duplicate Template**
+1. On the **Compatibility** tab:
+ - Clear the **Show resulting changes** check box
+ - Select **Windows Server 2016** from the **Certification Authority** list
+ - Select **Windows 10 / Windows Server 2016** from the **Certificate Recipient** list
+1. On the **General** tab:
+ - Type *Internal Web Server* in **Template display name**
+ - Adjust the validity and renewal period to meet your enterprise's needs
+ > [!NOTE]
+ > If you use different template names, you'll need to remember and substitute these names in different portions of the lab.
+1. On the **Request Handling** tab, select **Allow private key to be exported**
+1. On the **Subject** tab, select the **Supply in the request** button if it isn't already selected
+1. On the **Security** tab:
+ - Select **Add**
+ - Type **Domain Computers** in the **Enter the object names to select** box
+ - Select **OK**
+ - Select the **Allow** check box next to the **Enroll** permission
+1. On the **Cryptography** tab:
+ - Select **Key Storage Provider** from the **Provider Category** list
+ - Select **RSA** from the **Algorithm name** list
+ - Type *2048* in the **Minimum key size** text box
+ - Select **SHA256** from the **Request hash** list
+ - Select **OK**
+1. Close the console
+
+
+
+
+
+Unpublish Superseded Certificate Templates
+
+The certification authority only issues certificates based on published certificate templates. For security, it's a good practice to unpublish certificate templates that the CA isn't configured to issue. This includes the pre-published certificate template from the role installation and any superseded certificate templates.
+
+The newly created *domain controller authentication* certificate template supersedes previous domain controller certificate templates. Therefore, you need to unpublish these certificate templates from all issuing certificate authorities.
+
+Sign in to the CA or management workstation with *Enterprise Administrator* equivalent credentials.
+
+1. Open the **Certification Authority** management console
+1. Expand the parent node from the navigation pane > **Certificate Templates**
+1. Right-click the *Domain Controller* certificate template and select **Delete**. Select **Yes** on the **Disable certificate templates** window
+1. Repeat step 3 for the *Domain Controller Authentication* and *Kerberos Authentication* certificate templates
+
+
+
+
+
+Publish certificate templates to the CA
+
+A certification authority can only issue certificates for certificate templates that are published to it. If you have more than one CA, and you want more CAs to issue certificates based on the certificate template, then you must publish the certificate template to them.
+
+Sign in to the CA or management workstations with **Enterprise Admin** equivalent credentials.
+
+1. Open the **Certification Authority** management console
+1. Expand the parent node from the navigation pane
+1. Select **Certificate Templates** in the navigation pane
+1. Right-click the **Certificate Templates** node. Select **New > Certificate Template** to issue
+1. In the **Enable Certificates Templates** window, select the *Domain Controller Authentication (Kerberos)*, and *Internal Web Server* templates you created in the previous steps. Select **OK** to publish the selected certificate templates to the certification authority
+1. If you published the *Domain Controller Authentication (Kerberos)* certificate template, then unpublish the certificate templates you included in the superseded templates list
+ - To unpublish a certificate template, right-click the certificate template you want to unpublish and select **Delete**. Select **Yes** to confirm the operation
+1. Close the console
+
+
+
+### Configure automatic certificate enrollment for the domain controllers
+
+Domain controllers automatically request a certificate from the *Domain controller certificate* template. However, domain controllers are unaware of newer certificate templates or superseded configurations on certificate templates. To continue automatic enrollment and renewal of domain controller certificates, create and configure a Group Policy Object (GPO) for automatic certificate enrollment, linking the Group Policy object to the *Domain Controllers* Organizational Unit (OU).
+
+1. Open the **Group Policy Management Console** (gpmc.msc)
+1. Expand the domain and select the **Group Policy Object** node in the navigation pane
+1. Right-click **Group Policy object** and select **New**
+1. Type *Domain Controller Auto Certificate Enrollment* in the name box and select **OK**
+1. Right-click the **Domain Controller Auto Certificate Enrollment** Group Policy object and select **Edit**
+1. In the navigation pane, expand **Policies** under **Computer Configuration**
+1. Expand **Windows Settings > Security Settings > Public Key Policies**
+1. In the details pane, right-click **Certificate Services Client - Auto-Enrollment** and select **Properties**
+1. Select **Enabled** from the **Configuration Model** list
+1. Select the **Renew expired certificates, update pending certificates, and remove revoked certificates** check box
+1. Select the **Update certificates that use certificate templates** check box
+1. Select **OK**
+1. Close the **Group Policy Management Editor**
+
+### Deploy the domain controller auto certificate enrollment GPO
+
+Sign in to domain controller or management workstations with *Domain Administrator* equivalent credentials.
1. Start the **Group Policy Management Console** (gpmc.msc)
+1. In the navigation pane, expand the domain and expand the node with the Active Directory domain name. Right-click the **Domain Controllers** organizational unit and select **Link an existing GPO…**
+1. In the **Select GPO** dialog box, select *Domain Controller Auto Certificate Enrollment* or the name of the domain controller certificate enrollment Group Policy object you previously created
+1. Select **OK**
-2. Expand the domain and select the **Group Policy Object** node in the navigation pane.
+## Validate the configuration
-3. Right-click **Group Policy object** and select **New**
+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.
-4. Type *Domain Controller Auto Certificate Enrollment* in the name box and click **OK**.
+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.
-5. Right-click the **Domain Controller Auto Certificate Enrollment** Group Policy object and click **Edit**.
+### Use the event logs
-6. In the navigation pane, expand **Policies** under **Computer Configuration**.
+Sign in to domain controller or management workstations with *Domain Administrator* equivalent credentials.
-7. Expand **Windows Settings**, **Security Settings**, and click **Public Key Policies**.
+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
-8. In the details pane, right-click **Certificate Services Client – Auto-Enrollment** and select **Properties**.
+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.
-9. Select **Enabled** from the **Configuration Model** list.
+### Certificate Manager
-10. Select the **Renew expired certificates, update pending certificates, and remove revoked certificates** check box.
+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.
-11. Select the **Update certificates that use certificate templates** check box.
+### Certutil.exe
-12. Click **OK**. Close the **Group Policy Management Editor**.
+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.
-### Deploy the Domain Controller Auto Certificate Enrollment Group Policy Object
+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.
-Sign in to domain controller or management workstations with _Domain Admin_ equivalent credentials.
+### Troubleshooting
-1. Start the **Group Policy Management Console** (gpmc.msc).
+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`.
-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…**.
+Alternatively, you can forcefully trigger automatic certificate enrollment using `certreq.exe -autoenroll -q` from an elevated command prompt.
-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**.
+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.
-### Validating your work
-
-Windows Hello for Business is a distributed system, which on the surface appears complex and difficult. The key to a successful Windows Hello for Business deployment is to validate phases of work prior to moving to the next phase.
-
-You want to confirm your domain controllers enroll the correct certificates and not any unnecessary (superseded) certificate templates. You need to check each domain controller that autoenrollment for the computer occurred.
-
-#### Use the Event Logs
-
-Windows Server 2012 and later include Certificate Lifecycle events to determine the lifecycles of certificates for both users and computers. Using the Event Viewer, navigate to the CertificateServices-Lifecycles-System event log under Application and Services/Microsoft/Windows.
-
-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 CertificateServices-Lifecycles-System event. 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 do not appear in Certificate Manager.
-
-#### Certutil.exe
-
-You can use **certutil.exe** 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 -q -store my` to view locally enrolled certificates.
-
-To view detailed information about each certificate in the store, use `certutil -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 /force`.
-
-Alternatively, you can forcefully trigger automatic certificate enrollment using `certreq -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 certificate authority and the allow auto enrollment permissions.
-
-## Follow the Windows Hello for Business on premises key trust deployment guide
-
-1. [Validate Active Directory prerequisites](hello-key-trust-validate-ad-prereq.md)
-2. Validate and Configure Public Key Infrastructure (*You are here*)
-3. [Prepare and Deploy Windows Server 2016 Active Directory Federation Services](hello-key-trust-adfs.md)
-4. [Validate and Deploy Multifactor Authentication Services (MFA)](hello-key-trust-validate-deploy-mfa.md)
-5. [Configure Windows Hello for Business Policy settings](hello-key-trust-policy-settings.md)
+> [!div class="nextstepaction"]
+> [Next: prepare and deploy AD FS >](hello-key-trust-adfs.md)
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/hello-manage-in-organization.md b/windows/security/identity-protection/hello-for-business/hello-manage-in-organization.md
index b32ad3664c..a548960eab 100644
--- a/windows/security/identity-protection/hello-for-business/hello-manage-in-organization.md
+++ b/windows/security/identity-protection/hello-for-business/hello-manage-in-organization.md
@@ -5,7 +5,7 @@ ms.collection:
- highpri
ms.date: 2/15/2022
appliesto:
-- ✅ Windows 10 and later
+- ✅ Windows 10 and later
ms.topic: article
---
diff --git a/windows/security/identity-protection/hello-for-business/hello-overview.md b/windows/security/identity-protection/hello-for-business/hello-overview.md
index 010273238e..50d6d7f166 100644
--- a/windows/security/identity-protection/hello-for-business/hello-overview.md
+++ b/windows/security/identity-protection/hello-for-business/hello-overview.md
@@ -5,7 +5,7 @@ ms.collection:
- highpri
ms.topic: conceptual
appliesto:
-- ✅ Windows 10 and later
+ - ✅ Windows 10 and later
ms.date: 12/31/2017
---
# Windows Hello for Business Overview
diff --git a/windows/security/identity-protection/hello-for-business/hello-why-pin-is-better-than-password.md b/windows/security/identity-protection/hello-for-business/hello-why-pin-is-better-than-password.md
index ca25fdee58..89fe8f84ce 100644
--- a/windows/security/identity-protection/hello-for-business/hello-why-pin-is-better-than-password.md
+++ b/windows/security/identity-protection/hello-for-business/hello-why-pin-is-better-than-password.md
@@ -5,7 +5,7 @@ ms.collection:
- highpri
ms.date: 10/23/2017
appliesto:
-- ✅ Windows 10 and later
+- ✅ Windows 10 and later
ms.topic: article
---
# Why a PIN is better than an online password
diff --git a/windows/security/identity-protection/hello-for-business/images/adfs-device-registration.png b/windows/security/identity-protection/hello-for-business/images/adfs-device-registration.png
new file mode 100644
index 0000000000..cf0b7aeff4
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/adfs-device-registration.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/adfs-scp.png b/windows/security/identity-protection/hello-for-business/images/adfs-scp.png
new file mode 100644
index 0000000000..5a806fadf0
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/adfs-scp.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/hello-adfs-configure-2012r2.png b/windows/security/identity-protection/hello-for-business/images/hello-adfs-configure-2012r2.png
deleted file mode 100644
index 374d8f1297..0000000000
Binary files a/windows/security/identity-protection/hello-for-business/images/hello-adfs-configure-2012r2.png and /dev/null differ
diff --git a/windows/security/identity-protection/hello-for-business/images/hello-internal-web-server-cert.png b/windows/security/identity-protection/hello-for-business/images/hello-internal-web-server-cert.png
index cc78ba41cf..5db53fa03c 100644
Binary files a/windows/security/identity-protection/hello-for-business/images/hello-internal-web-server-cert.png and b/windows/security/identity-protection/hello-for-business/images/hello-internal-web-server-cert.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/hello-nlb-add-ip.png b/windows/security/identity-protection/hello-for-business/images/hello-nlb-add-ip.png
deleted file mode 100644
index 49b06a8cc2..0000000000
Binary files a/windows/security/identity-protection/hello-for-business/images/hello-nlb-add-ip.png and /dev/null differ
diff --git a/windows/security/identity-protection/hello-for-business/images/hello-nlb-cluster-ip-config.png b/windows/security/identity-protection/hello-for-business/images/hello-nlb-cluster-ip-config.png
deleted file mode 100644
index e74cc5f586..0000000000
Binary files a/windows/security/identity-protection/hello-for-business/images/hello-nlb-cluster-ip-config.png and /dev/null differ
diff --git a/windows/security/identity-protection/hello-for-business/images/hello-nlb-cluster-port-rule.png b/windows/security/identity-protection/hello-for-business/images/hello-nlb-cluster-port-rule.png
deleted file mode 100644
index c8d406f45f..0000000000
Binary files a/windows/security/identity-protection/hello-for-business/images/hello-nlb-cluster-port-rule.png and /dev/null differ
diff --git a/windows/security/identity-protection/hello-for-business/images/hello-nlb-cluster.png b/windows/security/identity-protection/hello-for-business/images/hello-nlb-cluster.png
deleted file mode 100644
index 3c4e29b213..0000000000
Binary files a/windows/security/identity-protection/hello-for-business/images/hello-nlb-cluster.png and /dev/null differ
diff --git a/windows/security/identity-protection/hello-for-business/images/hello-nlb-connect.png b/windows/security/identity-protection/hello-for-business/images/hello-nlb-connect.png
deleted file mode 100644
index c5aac0791e..0000000000
Binary files a/windows/security/identity-protection/hello-for-business/images/hello-nlb-connect.png and /dev/null differ
diff --git a/windows/security/identity-protection/hello-for-business/images/hello-nlb-feature-install.png b/windows/security/identity-protection/hello-for-business/images/hello-nlb-feature-install.png
deleted file mode 100644
index 3ab085a804..0000000000
Binary files a/windows/security/identity-protection/hello-for-business/images/hello-nlb-feature-install.png and /dev/null differ
diff --git a/windows/security/identity-protection/hello-for-business/images/hello-nlb-manager.png b/windows/security/identity-protection/hello-for-business/images/hello-nlb-manager.png
deleted file mode 100644
index 61af244a4c..0000000000
Binary files a/windows/security/identity-protection/hello-for-business/images/hello-nlb-manager.png and /dev/null differ
diff --git a/windows/security/identity-protection/hello-for-business/retired/hello-how-it-works.md b/windows/security/identity-protection/hello-for-business/retired/hello-how-it-works.md
index 5aa1fcad6a..1987c05d33 100644
--- a/windows/security/identity-protection/hello-for-business/retired/hello-how-it-works.md
+++ b/windows/security/identity-protection/hello-for-business/retired/hello-how-it-works.md
@@ -3,8 +3,7 @@ title: How Windows Hello for Business works (Windows)
description: Learn about registration, authentication, key material, and infrastructure for Windows Hello for Business.
ms.date: 10/16/2017
appliesto:
- - ✅ Windows 10
- - ✅ Windows 11
+- ✅ Windows 10 and later
ms.topic: article
---
# How Windows Hello for Business works in Windows devices
diff --git a/windows/security/identity-protection/hello-for-business/toc.yml b/windows/security/identity-protection/hello-for-business/toc.yml
index 502a196109..fb4c92826f 100644
--- a/windows/security/identity-protection/hello-for-business/toc.yml
+++ b/windows/security/identity-protection/hello-for-business/toc.yml
@@ -99,7 +99,7 @@
href: hello-deployment-key-trust.md
- name: Validate Active Directory prerequisites
href: hello-key-trust-validate-ad-prereq.md
- - name: Validate and configure Public Key Infrastructure (PKI)
+ - name: Configure and validate Public Key Infrastructure (PKI)
href: hello-key-trust-validate-pki.md
- name: Prepare and deploy Active Directory Federation Services (AD FS)
href: hello-key-trust-adfs.md
@@ -113,7 +113,7 @@
href: hello-deployment-cert-trust.md
- name: Validate Active Directory prerequisites
href: hello-cert-trust-validate-ad-prereq.md
- - name: Validate and configure Public Key Infrastructure (PKI)
+ - name: Configure and validate Public Key Infrastructure (PKI)
href: hello-cert-trust-validate-pki.md
- name: Prepare and Deploy Active Directory Federation Services (AD FS)
href: hello-cert-trust-adfs.md
diff --git a/windows/security/identity-protection/user-account-control/how-user-account-control-works.md b/windows/security/identity-protection/user-account-control/how-user-account-control-works.md
index 7f59ec2edf..a968914652 100644
--- a/windows/security/identity-protection/user-account-control/how-user-account-control-works.md
+++ b/windows/security/identity-protection/user-account-control/how-user-account-control-works.md
@@ -8,7 +8,7 @@ ms.localizationpriority: medium
ms.date: 09/23/2021
appliesto:
- ✅ Windows 10 and later
-- ✅ Windows Server 2016 and later
+- ✅ Windows Server 2016 and later
---
# How User Account Control works
diff --git a/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings.md b/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings.md
index 9ad0ff0106..f3c8c14d4e 100644
--- a/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings.md
+++ b/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings.md
@@ -7,7 +7,7 @@ ms.topic: article
ms.date: 04/19/2017
appliesto:
- ✅ Windows 10 and later
-- ✅ Windows Server 2016 and later
+- ✅ Windows Server 2016 and later
---
# User Account Control Group Policy and registry key settings
diff --git a/windows/security/identity-protection/user-account-control/user-account-control-overview.md b/windows/security/identity-protection/user-account-control/user-account-control-overview.md
index 1c975c2974..35851d61af 100644
--- a/windows/security/identity-protection/user-account-control/user-account-control-overview.md
+++ b/windows/security/identity-protection/user-account-control/user-account-control-overview.md
@@ -7,7 +7,7 @@ ms.topic: article
ms.date: 09/24/2011
appliesto:
- ✅ Windows 10 and later
-- ✅ Windows Server 2016 and later
+- ✅ Windows Server 2016 and later
---
# User Account Control
diff --git a/windows/security/identity-protection/user-account-control/user-account-control-security-policy-settings.md b/windows/security/identity-protection/user-account-control/user-account-control-security-policy-settings.md
index c6cf53662d..28f209a22e 100644
--- a/windows/security/identity-protection/user-account-control/user-account-control-security-policy-settings.md
+++ b/windows/security/identity-protection/user-account-control/user-account-control-security-policy-settings.md
@@ -5,7 +5,7 @@ ms.topic: article
ms.date: 09/24/2021
appliesto:
- ✅ Windows 10 and later
-- ✅ Windows Server 2016 and later
+- ✅ Windows Server 2016 and later
---
# User Account Control security policy settings
diff --git a/windows/security/images/icons/information.svg b/windows/security/images/icons/information.svg
new file mode 100644
index 0000000000..bc692eabb9
--- /dev/null
+++ b/windows/security/images/icons/information.svg
@@ -0,0 +1,3 @@
+
\ No newline at end of file
diff --git a/windows/security/includes/hello-cloud.md b/windows/security/includes/hello-cloud.md
index c40ed1027c..1c41485f11 100644
--- a/windows/security/includes/hello-cloud.md
+++ b/windows/security/includes/hello-cloud.md
@@ -1,7 +1,11 @@
-This document describes Windows Hello for Business functionalities or scenarios that apply to:\
-✅ **Deployment type:** [cloud](../identity-protection/hello-for-business/hello-how-it-works-technology.md#cloud-deployment)\
-✅ **Device registration type:** [Azure AD join](../identity-protection/hello-for-business/hello-how-it-works-technology.md#azure-active-directory-join)
-
-
-
---
+author: paolomatarazzo
+ms.author: paoloma
+ms.date: 12/08/2022
+ms.topic: include
+---
+
+[!INCLUDE [hello-intro](hello-intro.md)]
+- **Deployment type:** [!INCLUDE [hello-deployment-cloud](hello-deployment-cloud.md)]
+- **Join type:** [!INCLUDE [hello-join-aad](hello-join-aad.md)]
+---
\ No newline at end of file
diff --git a/windows/security/includes/hello-deployment-cloud.md b/windows/security/includes/hello-deployment-cloud.md
new file mode 100644
index 0000000000..8152da9722
--- /dev/null
+++ b/windows/security/includes/hello-deployment-cloud.md
@@ -0,0 +1,8 @@
+---
+author: paolomatarazzo
+ms.author: paoloma
+ms.date: 12/08/2022
+ms.topic: include
+---
+
+[cloud :::image type="icon" source="../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#cloud-deployment "For organizations using Azure AD-only identities. Device management is usually done via Intune/MDM")
\ No newline at end of file
diff --git a/windows/security/includes/hello-deployment-hybrid.md b/windows/security/includes/hello-deployment-hybrid.md
new file mode 100644
index 0000000000..b35d4b548e
--- /dev/null
+++ b/windows/security/includes/hello-deployment-hybrid.md
@@ -0,0 +1,8 @@
+---
+author: paolomatarazzo
+ms.author: paoloma
+ms.date: 12/08/2022
+ms.topic: include
+---
+
+[hybrid :::image type="icon" source="../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#hybrid-deployment "For organizations using Active Directory identities synchronized to Azure AD. Device management is usually done via Group Policy or Intune/MDM")
\ No newline at end of file
diff --git a/windows/security/includes/hello-deployment-onpremises.md b/windows/security/includes/hello-deployment-onpremises.md
new file mode 100644
index 0000000000..8746a5e9c7
--- /dev/null
+++ b/windows/security/includes/hello-deployment-onpremises.md
@@ -0,0 +1,8 @@
+---
+author: paolomatarazzo
+ms.author: paoloma
+ms.date: 12/08/2022
+ms.topic: include
+---
+
+[on-premises :::image type="icon" source="../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#on-premises-deployment "For organizations using Active Directory identities, not synchronized to Azure AD. Device management is usually done via Group Policy")
\ No newline at end of file
diff --git a/windows/security/includes/hello-hybrid-cert-trust-aad.md b/windows/security/includes/hello-hybrid-cert-trust-aad.md
index e80912d8b9..57c03e95a3 100644
--- a/windows/security/includes/hello-hybrid-cert-trust-aad.md
+++ b/windows/security/includes/hello-hybrid-cert-trust-aad.md
@@ -1,8 +1,12 @@
-This document describes Windows Hello for Business functionalities or scenarios that apply to:\
-✅ **Deployment type:** [hybrid](../identity-protection/hello-for-business/hello-how-it-works-technology.md#hybrid-deployment)\
-✅ **Trust type:** [certificate trust](../identity-protection/hello-for-business/hello-how-it-works-technology.md#certificate-trust)\
-✅ **Device registration type:** [Azure AD join](../identity-protection/hello-for-business/hello-how-it-works-technology.md#azure-active-directory-join)
-
-
-
---
+author: paolomatarazzo
+ms.author: paoloma
+ms.date: 12/08/2022
+ms.topic: include
+---
+
+[!INCLUDE [hello-intro](hello-intro.md)]
+- **Deployment type:** [!INCLUDE [hello-deployment-hybrid](hello-deployment-hybrid.md)]
+- **Trust type:** [!INCLUDE [hello-trust-certificate](hello-trust-certificate.md)]
+- **Join type:** [!INCLUDE [hello-join-aadj](hello-join-aad.md)]
+---
\ No newline at end of file
diff --git a/windows/security/includes/hello-hybrid-cert-trust-ad.md b/windows/security/includes/hello-hybrid-cert-trust-ad.md
index 4ef97bd233..4691d86bc0 100644
--- a/windows/security/includes/hello-hybrid-cert-trust-ad.md
+++ b/windows/security/includes/hello-hybrid-cert-trust-ad.md
@@ -1,8 +1,12 @@
-This document describes Windows Hello for Business functionalities or scenarios that apply to:\
-✅ **Deployment type:** [hybrid](../identity-protection/hello-for-business/hello-how-it-works-technology.md#hybrid-deployment)\
-✅ **Trust type:** [certificate trust](../identity-protection/hello-for-business/hello-how-it-works-technology.md#certificate-trust)\
-✅ **Device registration type:** [Hybrid Azure AD join](../identity-protection/hello-for-business/hello-how-it-works-technology.md#hybrid-azure-ad-join)
-
-
-
---
+author: paolomatarazzo
+ms.author: paoloma
+ms.date: 12/08/2022
+ms.topic: include
+---
+
+[!INCLUDE [hello-intro](hello-intro.md)]
+- **Deployment type:** [!INCLUDE [hello-deployment-hybrid](hello-deployment-hybrid.md)]
+- **Trust type:** [!INCLUDE [hello-trust-cloud-kerberos](hello-trust-cloud-kerberos.md)]
+- **Join type:** [!INCLUDE [hello-join-hybrid](hello-join-hybrid.md)]
+---
\ No newline at end of file
diff --git a/windows/security/includes/hello-hybrid-cert-trust.md b/windows/security/includes/hello-hybrid-cert-trust.md
index 77a897f264..d6ca6e8f5d 100644
--- a/windows/security/includes/hello-hybrid-cert-trust.md
+++ b/windows/security/includes/hello-hybrid-cert-trust.md
@@ -1,8 +1,12 @@
-This document describes Windows Hello for Business functionalities or scenarios that apply to:\
-✅ **Deployment type:** [hybrid](../identity-protection/hello-for-business/hello-how-it-works-technology.md#hybrid-deployment)\
-✅ **Trust type:** [certificate trust](../identity-protection/hello-for-business/hello-how-it-works-technology.md#certificate-trust)\
-✅ **Device registration type:** [Azure AD join](../identity-protection/hello-for-business/hello-how-it-works-technology.md#azure-active-directory-join), [Hybrid Azure AD join](../identity-protection/hello-for-business/hello-how-it-works-technology.md#hybrid-azure-ad-join)
-
-
-
---
+author: paolomatarazzo
+ms.author: paoloma
+ms.date: 12/08/2022
+ms.topic: include
+---
+
+[!INCLUDE [hello-intro](hello-intro.md)]
+- **Deployment type:** [!INCLUDE [hello-deployment-hybrid](hello-deployment-hybrid.md)]
+- **Trust type:** [!INCLUDE [hello-trust-certificate](hello-trust-certificate.md)]
+- **Join type:** [!INCLUDE [hello-join-aadj](hello-join-aad.md)], [!INCLUDE [hello-join-hybrid](hello-join-hybrid.md)]
+---
\ No newline at end of file
diff --git a/windows/security/includes/hello-hybrid-cloudkerb-trust.md b/windows/security/includes/hello-hybrid-cloudkerb-trust.md
index 4f68be791b..61346cd80e 100644
--- a/windows/security/includes/hello-hybrid-cloudkerb-trust.md
+++ b/windows/security/includes/hello-hybrid-cloudkerb-trust.md
@@ -1,8 +1,12 @@
-This document describes Windows Hello for Business functionalities or scenarios that apply to:\
-✅ **Deployment type:** [hybrid](../identity-protection/hello-for-business/hello-how-it-works-technology.md#hybrid-deployment)\
-✅ **Trust type:** [cloud Kerberos trust](../identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md)\
-✅ **Device registration type:** [Azure AD join](../identity-protection/hello-for-business/hello-how-it-works-technology.md#azure-active-directory-join), [Hybrid Azure AD join](../identity-protection/hello-for-business/hello-how-it-works-technology.md#hybrid-azure-ad-join)
-
-
-
---
+author: paolomatarazzo
+ms.author: paoloma
+ms.date: 12/08/2022
+ms.topic: include
+---
+
+[!INCLUDE [hello-intro](hello-intro.md)]
+- **Deployment type:** [!INCLUDE [hello-deployment-hybrid](hello-deployment-hybrid.md)]
+- **Trust type:** [!INCLUDE [hello-trust-cloud-kerberos](hello-trust-cloud-kerberos.md)]
+- **Join type:** [!INCLUDE [hello-join-aadj](hello-join-aad.md)], [!INCLUDE [hello-join-hybrid](hello-join-hybrid.md)]
+---
\ No newline at end of file
diff --git a/windows/security/includes/hello-hybrid-key-trust-ad.md b/windows/security/includes/hello-hybrid-key-trust-ad.md
index 68521a5a14..a5074f5bd4 100644
--- a/windows/security/includes/hello-hybrid-key-trust-ad.md
+++ b/windows/security/includes/hello-hybrid-key-trust-ad.md
@@ -1,8 +1,12 @@
-This document describes Windows Hello for Business functionalities or scenarios that apply to:\
-✅ **Deployment type:** [hybrid](../identity-protection/hello-for-business/hello-how-it-works-technology.md#hybrid-deployment)\
-✅ **Trust type:** [key trust](../identity-protection/hello-for-business/hello-how-it-works-technology.md#key-trust)\
-✅ **Device registration type:** [Hybrid Azure AD join](../identity-protection/hello-for-business/hello-how-it-works-technology.md#hybrid-azure-ad-join)
-
-
-
---
+author: paolomatarazzo
+ms.author: paoloma
+ms.date: 12/08/2022
+ms.topic: include
+---
+
+[!INCLUDE [hello-intro](hello-intro.md)]
+- **Deployment type:** [!INCLUDE [hello-deployment-hybrid](hello-deployment-hybrid.md)]
+- **Trust type:** [!INCLUDE [hello-trust-key](hello-trust-key.md)]
+- **Join type:** [!INCLUDE [hello-join-hybrid](hello-join-hybrid.md)]
+---
\ No newline at end of file
diff --git a/windows/security/includes/hello-hybrid-key-trust.md b/windows/security/includes/hello-hybrid-key-trust.md
index fdb7466014..d9feebc213 100644
--- a/windows/security/includes/hello-hybrid-key-trust.md
+++ b/windows/security/includes/hello-hybrid-key-trust.md
@@ -1,8 +1,12 @@
-This document describes Windows Hello for Business functionalities or scenarios that apply to:\
-✅ **Deployment type:** [hybrid](../identity-protection/hello-for-business/hello-how-it-works-technology.md#hybrid-deployment)\
-✅ **Trust type:** [key trust](../identity-protection/hello-for-business/hello-how-it-works-technology.md#key-trust)\
-✅ **Device registration type:** [Azure AD join](../identity-protection/hello-for-business/hello-how-it-works-technology.md#azure-active-directory-join), [Hybrid Azure AD join](../identity-protection/hello-for-business/hello-how-it-works-technology.md#hybrid-azure-ad-join)
-
-
-
---
+author: paolomatarazzo
+ms.author: paoloma
+ms.date: 12/08/2022
+ms.topic: include
+---
+
+[!INCLUDE [hello-intro](hello-intro.md)]
+- **Deployment type:** [!INCLUDE [hello-deployment-hybrid](hello-deployment-hybrid.md)]
+- **Trust type:** [!INCLUDE [hello-trust-key](hello-trust-key.md)]
+- **Join type:** [!INCLUDE [hello-join-aadj](hello-join-aad.md)], [!INCLUDE [hello-join-hybrid](hello-join-hybrid.md)]
+---
\ No newline at end of file
diff --git a/windows/security/includes/hello-hybrid-keycert-trust-aad.md b/windows/security/includes/hello-hybrid-keycert-trust-aad.md
index a8d82200d3..4c073f0897 100644
--- a/windows/security/includes/hello-hybrid-keycert-trust-aad.md
+++ b/windows/security/includes/hello-hybrid-keycert-trust-aad.md
@@ -1,7 +1,12 @@
-This document describes Windows Hello for Business functionalities or scenarios that apply to:\
-✅ **Deployment type:** [hybrid](../identity-protection/hello-for-business/hello-how-it-works-technology.md#hybrid-deployment)\
-✅ **Trust type:** [key trust](../identity-protection/hello-for-business/hello-how-it-works-technology.md#key-trust), [certificate trust](../identity-protection/hello-for-business/hello-how-it-works-technology.md#certificate-trust)\
-✅ **Device registration type:** [Azure AD join](../identity-protection/hello-for-business/hello-how-it-works-technology.md#azure-active-directory-join)
-
-
---
+author: paolomatarazzo
+ms.author: paoloma
+ms.date: 12/08/2022
+ms.topic: include
+---
+
+[!INCLUDE [hello-intro](hello-intro.md)]
+- **Deployment type:** [!INCLUDE [hello-deployment-hybrid](hello-deployment-hybrid.md)]
+- **Trust type:** [!INCLUDE [hello-trust-key](hello-trust-key.md)], [!INCLUDE [hello-trust-certificate](hello-trust-certificate.md)]
+- **Join type:** [!INCLUDE [hello-join-aadj](hello-join-aad.md)]
+---
\ No newline at end of file
diff --git a/windows/security/includes/hello-intro.md b/windows/security/includes/hello-intro.md
new file mode 100644
index 0000000000..46d97c93e6
--- /dev/null
+++ b/windows/security/includes/hello-intro.md
@@ -0,0 +1,8 @@
+---
+author: paolomatarazzo
+ms.author: paoloma
+ms.date: 12/08/2022
+ms.topic: include
+---
+
+This document describes Windows Hello for Business functionalities or scenarios that apply to:
\ No newline at end of file
diff --git a/windows/security/includes/hello-join-aad.md b/windows/security/includes/hello-join-aad.md
new file mode 100644
index 0000000000..5709970576
--- /dev/null
+++ b/windows/security/includes/hello-join-aad.md
@@ -0,0 +1,8 @@
+---
+author: paolomatarazzo
+ms.author: paoloma
+ms.date: 12/08/2022
+ms.topic: include
+---
+
+[Azure AD join :::image type="icon" source="../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#azure-active-directory-join "Devices that are Azure AD joined do not have any dependencies on Active Directory. Only local users accounts and Azure AD users can sign in to these devices")
\ No newline at end of file
diff --git a/windows/security/includes/hello-join-domain.md b/windows/security/includes/hello-join-domain.md
new file mode 100644
index 0000000000..0385e2089a
--- /dev/null
+++ b/windows/security/includes/hello-join-domain.md
@@ -0,0 +1,8 @@
+---
+author: paolomatarazzo
+ms.author: paoloma
+ms.date: 12/08/2022
+ms.topic: include
+---
+
+[domain join :::image type="icon" source="../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md "Devices that are domain joined do not have any dependencies on Azure AD. Only local users accounts and Active Directory users can sign in to these devices")
\ No newline at end of file
diff --git a/windows/security/includes/hello-join-hybrid.md b/windows/security/includes/hello-join-hybrid.md
new file mode 100644
index 0000000000..3d3e75c6b6
--- /dev/null
+++ b/windows/security/includes/hello-join-hybrid.md
@@ -0,0 +1,8 @@
+---
+author: paolomatarazzo
+ms.author: paoloma
+ms.date: 12/08/2022
+ms.topic: include
+---
+
+[hybrid Azure AD join :::image type="icon" source="../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#hybrid-azure-ad-join "Devices that are hybrid Azure AD joined don't have any dependencies on Azure AD. Only local users accounts and Active Directory users can sign in to these devices. Active Directory users that are synchronized to Azure AD will have single-sign on to both Active Directory and Azure AD-protected resources")
\ No newline at end of file
diff --git a/windows/security/includes/hello-on-premises-cert-trust.md b/windows/security/includes/hello-on-premises-cert-trust.md
index 2cc01ac3ac..b106b5b8c8 100644
--- a/windows/security/includes/hello-on-premises-cert-trust.md
+++ b/windows/security/includes/hello-on-premises-cert-trust.md
@@ -1,8 +1,12 @@
-This document describes Windows Hello for Business functionalities or scenarios that apply to:\
-✅ **Deployment type:** [on-premises](../identity-protection/hello-for-business/hello-how-it-works-technology.md#on-premises-deployment)\
-✅ **Trust type:** [certificate trust](../identity-protection/hello-for-business/hello-how-it-works-technology.md#certificate-trust)\
-✅ **Device registration type:** Active Directory domain join
-
-
-
---
+author: paolomatarazzo
+ms.author: paoloma
+ms.date: 12/08/2022
+ms.topic: include
+---
+
+[!INCLUDE [hello-intro](hello-intro.md)]
+- **Deployment type:** [!INCLUDE [hello-deployment-onpremises](hello-deployment-onpremises.md)]
+- **Trust type:** [!INCLUDE [hello-trust-certificate](hello-trust-certificate.md)]
+- **Join type:** [!INCLUDE [hello-join-domain](hello-join-domain.md)]
+---
\ No newline at end of file
diff --git a/windows/security/includes/hello-on-premises-key-trust.md b/windows/security/includes/hello-on-premises-key-trust.md
index cd6241fa72..f290b0d975 100644
--- a/windows/security/includes/hello-on-premises-key-trust.md
+++ b/windows/security/includes/hello-on-premises-key-trust.md
@@ -1,8 +1,12 @@
-This document describes Windows Hello for Business functionalities or scenarios that apply to:\
-✅ **Deployment type:** [on-premises](../identity-protection/hello-for-business/hello-how-it-works-technology.md#on-premises-deployment)\
-✅ **Trust type:** [key trust](../identity-protection/hello-for-business/hello-how-it-works-technology.md#key-trust)\
-✅ **Device registration type:** Active Directory domain join
-
-
-
---
+author: paolomatarazzo
+ms.author: paoloma
+ms.date: 12/08/2022
+ms.topic: include
+---
+
+[!INCLUDE [hello-intro](hello-intro.md)]
+- **Deployment type:** [!INCLUDE [hello-deployment-onpremises](hello-deployment-onpremises.md)]
+- **Trust type:** [!INCLUDE [hello-trust-key](hello-trust-key.md)]
+- **Join type:** [!INCLUDE [hello-join-domain](hello-join-domain.md)]
+---
\ No newline at end of file
diff --git a/windows/security/includes/hello-trust-certificate.md b/windows/security/includes/hello-trust-certificate.md
new file mode 100644
index 0000000000..ffc705fde0
--- /dev/null
+++ b/windows/security/includes/hello-trust-certificate.md
@@ -0,0 +1,8 @@
+---
+author: paolomatarazzo
+ms.author: paoloma
+ms.date: 12/08/2022
+ms.topic: include
+---
+
+[certificate trust :::image type="icon" source="../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#certificate-trust "This trust type uses a certificate to authenticate the users to Active Directory. It's required to issue certificates to the users and to the domain controllers")
\ No newline at end of file
diff --git a/windows/security/includes/hello-trust-cloud-kerberos.md b/windows/security/includes/hello-trust-cloud-kerberos.md
new file mode 100644
index 0000000000..5ddac53ba9
--- /dev/null
+++ b/windows/security/includes/hello-trust-cloud-kerberos.md
@@ -0,0 +1,8 @@
+---
+author: paolomatarazzo
+ms.author: paoloma
+ms.date: 12/08/2022
+ms.topic: include
+---
+
+[cloud Kerberos trust :::image type="icon" source="../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#cloud-kerberos-trust "This trust type uses security keys to authenticate the users to Active Directory. It's not required to issue any certificates, making it the recommended choice for environments that do not need certificate authentication")
\ No newline at end of file
diff --git a/windows/security/includes/hello-trust-key.md b/windows/security/includes/hello-trust-key.md
new file mode 100644
index 0000000000..133f7f5204
--- /dev/null
+++ b/windows/security/includes/hello-trust-key.md
@@ -0,0 +1,8 @@
+---
+author: paolomatarazzo
+ms.author: paoloma
+ms.date: 12/08/2022
+ms.topic: include
+---
+
+[key trust :::image type="icon" source="../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#key-trust "This trust type uses a raw key to authenticate the users to Active Directory. It's not required to issue certificates to users, but it's required to deploy certificates to domain controllers")
\ No newline at end of file
diff --git a/windows/security/includes/improve-request-performance.md b/windows/security/includes/improve-request-performance.md
index 24aaa25d9f..f928705138 100644
--- a/windows/security/includes/improve-request-performance.md
+++ b/windows/security/includes/improve-request-performance.md
@@ -1,14 +1,8 @@
---
-title: Improve request performance
-description: Improve request performance
-search.product: eADQiWindows 10XVcnh
-ms.prod: m365-security
-ms.localizationpriority: medium
-ms.collection: M365-security-compliance
-ms.topic: article
author: paolomatarazzo
ms.author: paoloma
-manager: aaroncz
+ms.date: 12/08/2022
+ms.topic: include
---
>[!TIP]
diff --git a/windows/security/includes/machineactionsnote.md b/windows/security/includes/machineactionsnote.md
index 31e3d1ac98..d4b4560d8f 100644
--- a/windows/security/includes/machineactionsnote.md
+++ b/windows/security/includes/machineactionsnote.md
@@ -1,12 +1,8 @@
---
-title: Perform a Machine Action via the Microsoft Defender for Endpoint API
-description: This page focuses on performing a machine action via the Microsoft Defender for Endpoint API.
-ms.date: 08/28/2017
-ms.reviewer:
author: paolomatarazzo
ms.author: paoloma
-manager: aaroncz
-ms.prod: m365-security
+ms.date: 12/08/2022
+ms.topic: include
---
>[!Note]
diff --git a/windows/security/includes/microsoft-defender-api-usgov.md b/windows/security/includes/microsoft-defender-api-usgov.md
index 74cfd90cbb..0b0b2be701 100644
--- a/windows/security/includes/microsoft-defender-api-usgov.md
+++ b/windows/security/includes/microsoft-defender-api-usgov.md
@@ -1,14 +1,8 @@
---
-title: Microsoft Defender for Endpoint API URIs for US Government
-description: Microsoft Defender for Endpoint API URIs for US Government
-search.product: eADQiWindows 10XVcnh
-ms.prod: m365-security
author: paolomatarazzo
ms.author: paoloma
-manager: aaroncz
-ms.localizationpriority: medium
-ms.collection: M365-security-compliance
-ms.topic: article
+ms.date: 12/08/2022
+ms.topic: include
---
>[!NOTE]
diff --git a/windows/security/includes/microsoft-defender.md b/windows/security/includes/microsoft-defender.md
index 0aade34b01..bd9a8d2c0d 100644
--- a/windows/security/includes/microsoft-defender.md
+++ b/windows/security/includes/microsoft-defender.md
@@ -1,13 +1,7 @@
---
-title: Microsoft 365 Defender important guidance
-description: A note in regard to important Microsoft 365 Defender guidance.
-ms.date:
-ms.reviewer:
-manager: aaroncz
author: paolomatarazzo
ms.author: paoloma
-manager: aaroncz
-ms.prod: m365-security
+ms.date: 12/08/2022
ms.topic: include
---
diff --git a/windows/security/includes/prerelease.md b/windows/security/includes/prerelease.md
index 58b056c484..c0212561bd 100644
--- a/windows/security/includes/prerelease.md
+++ b/windows/security/includes/prerelease.md
@@ -1,12 +1,8 @@
---
-title: Microsoft Defender for Endpoint Pre-release Disclaimer
-description: Disclaimer for pre-release version of Microsoft Defender for Endpoint.
-ms.date: 08/28/2017
-ms.reviewer:
author: paolomatarazzo
ms.author: paoloma
-manager: aaroncz
-ms.prod: m365-security
+ms.date: 12/08/2022
+ms.topic: include
---
> [!IMPORTANT]