deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-06-17 03:13:44 +00:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

Merge branch 'main' into dep-mixreal-8412877

Browse Source
This commit is contained in:
Aaron Czechowski
2023-12-18 11:21:03 -08:00
committed by GitHub
parent cd55afa2db b6f98a59b8
commit 348d072b48
229 changed files with 1388 additions and 4283 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
windows/application-management/docfx.json
View File

@ -42,9 +42,8 @@
"uhfHeaderId": "MSDocsHeader-Windows",
"ms.technology": "itpro-apps",
"ms.topic": "article",
"feedback_system": "GitHub",
"feedback_github_repo": "MicrosoftDocs/windows-itpro-docs",
"feedback_product_url": "https://support.microsoft.com/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332",
"feedback_system": "Standard",
"feedback_product_url": "https://support.microsoft.com/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332",
"_op_documentIdPathDepotMapping": {
"./": {
"depot_name": "MSDN.win-app-management",

5
windows/client-management/docfx.json
View File

@ -48,9 +48,8 @@
"ms.author": "vinpa",
"author": "vinaypamnani-msft",
"manager": "aaroncz",
"feedback_system": "GitHub",
"feedback_github_repo": "MicrosoftDocs/windows-itpro-docs",
"feedback_product_url": "https://support.microsoft.com/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332",
"feedback_system": "Standard",
"feedback_product_url": "https://support.microsoft.com/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332",
"_op_documentIdPathDepotMapping": {
"./": {
"depot_name": "MSDN.win-client-management",

5
windows/configuration/docfx.json
View File

@ -45,9 +45,8 @@
"ms.topic": "article",
"ms.prod": "windows-client",
"manager": "aaroncz",
"feedback_system": "GitHub",
"feedback_github_repo": "MicrosoftDocs/windows-itpro-docs",
"feedback_product_url": "https://support.microsoft.com/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332",
"feedback_system": "Standard",
"feedback_product_url": "https://support.microsoft.com/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332",
"_op_documentIdPathDepotMapping": {
"./": {
"depot_name": "MSDN.win-configuration",

2
windows/deployment/do/waas-delivery-optimization.md
View File

@ -59,7 +59,7 @@ The following table lists the minimum Windows 10 version that supports Delivery
| Edge Browser Updates | Windows 10 1809, Windows 11 | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
| Configuration Manager Express updates| Windows 10 1709 + Configuration Manager version 1711, Windows 11 | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
| Dynamic updates| Windows 10 1903, Windows 11 | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
| MDM Agent | Windows 11 | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
| MDM Agent | Windows 11 | :heavy_check_mark: | | |
| Xbox Game Pass (PC) | Windows 10 1809, Windows 11 | :heavy_check_mark: | | :heavy_check_mark: |
| Windows Package Manager| Windows 10 1809, Windows 11 | :heavy_check_mark: | | |
| MSIX Installer| Windows 10 2004, Windows 11 | :heavy_check_mark: | | |

5
windows/deployment/docfx.json
View File

@ -40,9 +40,8 @@
],
"breadcrumb_path": "/windows/resources/breadcrumb/toc.json",
"uhfHeaderId": "MSDocsHeader-Windows",
"feedback_system": "GitHub",
"feedback_github_repo": "MicrosoftDocs/windows-itpro-docs",
"feedback_product_url": "https://support.microsoft.com/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332",
"feedback_system": "Standard",
"feedback_product_url": "https://support.microsoft.com/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332",
"_op_documentIdPathDepotMapping": {
"./": {
"depot_name": "MSDN.win-development",

9
windows/deployment/update/includes/wufb-reports-endpoints.md
View File

@ -5,10 +5,11 @@ manager: aaroncz
ms.technology: itpro-updates
ms.prod: windows-client
ms.topic: include
ms.date: 08/21/2023
ms.date: 12/15/2023
ms.localizationpriority: medium
---
<!--This file is shared by updates/wufb-reports-prerequisites.md and the update/update-compliance-configuration-manual.md articles. Headings are driven by article context. -->
<!-- This file is shared by update/wufb-reports-prerequisites.md and update/wufb-reports-configuration-manual.md articles. Headings are driven by article context. -->
Devices must be able to contact the following endpoints in order to authenticate and send diagnostic data:
@ -20,5 +21,5 @@ Devices must be able to contact the following endpoints in order to authenticate
| `settings-win.data.microsoft.com` | Used by Windows components and applications to dynamically update their configuration. Required for Windows Update functionality. |
| `adl.windows.com` | Required for Windows Update functionality. |
| `oca.telemetry.microsoft.com` | Online Crash Analysis, used to provide device-specific recommendations and detailed errors if there are certain crashes. |
| `login.live.com` | This endpoint facilitates your Microsoft account access and is required to create the primary identifier we use for devices. Without this service, devices won't be visible in the solution. The Microsoft Account Sign-in Assistant service must also be running (wlidsvc). |
| `*.blob.core.windows.net` | Azure blob data storage.|
| `login.live.com` | This endpoint facilitates your Microsoft account access and is required to create the primary identifier we use for devices. Without this service, devices aren't visible in the solution. The Microsoft Account Sign-in Assistant service must also be running (wlidsvc). |
| `ceuswatcab01.blob.core.windows.net` <br> `ceuswatcab02.blob.core.windows.net` <br> `eaus2watcab01.blob.core.windows.net` <br> `eaus2watcab02.blob.core.windows.net` <br> `weus2watcab01.blob.core.windows.net` <br> `weus2watcab02.blob.core.windows.net` | Azure blob data storage. <!-- 8603508 --> |

17
windows/deployment/update/servicing-stack-updates.md
View File

@ -15,21 +15,22 @@ appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server </a>
ms.date: 12/31/2017
ms.date: 12/08/2023
---
# Servicing stack updates
## What is a servicing stack update?
Servicing stack updates provide fixes to the servicing stack, the component that installs Windows updates. Additionally, it contains the "component-based servicing stack" (CBS), which is a key underlying component for several elements of Windows deployment, such as DISM, SFC, changing Windows features or roles, and repairing components. The CBS is a small component that typically doesn't have updates released every month.
Servicing stack updates provide fixes to the servicing stack, the component that installs Windows updates. Additionally, it contains the component-based servicing stack (CBS), which is a key underlying component for several elements of Windows deployment, such as DISM, SFC, changing Windows features or roles, and repairing components. [CBS](https://techcommunity.microsoft.com/t5/ask-the-performance-team/understanding-component-based-servicing/ba-p/373012) is a small component that typically doesn't have updates released every month.
## Why should servicing stack updates be installed and kept up to date?
Servicing stack updates improve the reliability of the update process to mitigate potential issues while installing the latest quality updates and feature updates. If you don't install the latest servicing stack update, there's a risk that your device can't be updated with the latest Microsoft security fixes.
Servicing stack updates improve the reliability of the update process to mitigate potential issues while installing the latest quality updates and feature updates. If you don't have the latest servicing stack update installed, there's a risk that your device can't be updated with the latest Microsoft security fixes.
## When are they released?
Servicing stack update are released depending on new issues or vulnerabilities. In rare occasions a servicing stack update may need to be released on demand to address an issue impacting systems installing the monthly security update. Starting in November 2018 new servicing stack updates will be classified as "Security" with a severity rating of "Critical."
Servicing stack update are released depending on new issues or vulnerabilities. In rare occasions, a servicing stack update might need to be released out of band to address an issue impacting systems installing the monthly security update. New servicing stack updates are classified as `Security` with a severity rating of `Critical`.
## What's the difference between a servicing stack update and a cumulative update?
@ -38,14 +39,14 @@ Both Windows client and Windows Server use the cumulative update mechanism, in w
Servicing stack updates improve the reliability of the update process to mitigate potential issues while installing the latest monthly security update release and feature updates. If you don't install the latest servicing stack update, there's a risk that your device can't be updated with the latest Microsoft security fixes.
Microsoft publishes all cumulative updates and SSUs for Windows 10, version 2004 and later together as one cumulative monthly update to the normal release category in WSUS.
Microsoft publishes all cumulative updates and servicing stack updates for Windows 10, version 2004 and later together as one cumulative monthly update to the normal release category in Windows Server Update Services (WSUS).
## Is there any special guidance?
Microsoft recommends you install the latest servicing stack updates for your operating system before installing the latest cumulative update.
Typically, the improvements are reliability and performance improvements that don't require any specific special guidance. If there's any significant impact, it will be present in the release notes.
Most users don't need to install an isolated servicing stack update. In the rare case that you need to install an isolated servicing stack update, Microsoft recommends you install the latest servicing stack updates for your operating system before installing the latest cumulative update.
## Installation notes
* Servicing stack updates contain the full servicing stack; as a result, typically administrators only need to install the latest servicing stack update for the operating system.
@ -56,6 +57,6 @@ Typically, the improvements are reliability and performance improvements that do
## Simplifying on-premises deployment of servicing stack updates
With the Windows Update experience, servicing stack updates and cumulative updates are deployed together to the device. The update stack automatically orchestrates the installation, so both are applied correctly. Starting in February 2021, the cumulative update includes the latest servicing stack updates, to provide a single cumulative update payload to both Windows Server Update Services (WSUS) and Microsoft Catalog. If you use an endpoint management tool backed by WSUS, such as Configuration Manager, you'll only have to select and deploy the monthly cumulative update. The latest servicing stack updates will automatically be applied correctly. Release notes and file information for cumulative updates, including those related to the servicing stack, will be in a single KB article. The combined monthly cumulative update is available on Windows 10, version 2004 and later starting with the 2021 2C release, KB4601382.
With the Windows Update experience, servicing stack updates and cumulative updates are deployed together to the device. The update stack automatically orchestrates the installation, so both are applied correctly. Starting in February 2021, the cumulative update includes the latest servicing stack updates, to provide a single cumulative update payload to both WSUS and the Microsoft Update Catalog. If you use an endpoint management tool backed by WSUS, such as Configuration Manager, you'll only have to select and deploy the monthly cumulative update. The latest servicing stack updates will automatically be applied correctly. Release notes and file information for cumulative updates, including those related to the servicing stack, will be in a single KB article. The combined monthly cumulative update is available on Windows 10, version 2004 and later starting with [KB4601382](https://support.microsoft.com/kb/4601382), released in February of 2021.

51
windows/deployment/update/windows-update-logs.md
View File

@ -13,7 +13,7 @@ ms.collection:
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
ms.date: 12/31/2017
ms.date: 12/08/2023
---
# Windows Update log files
@ -24,18 +24,20 @@ The following table describes the log files created by Windows Update.
|Log file|Location|Description|When to use |
|-|-|-|-|
|windowsupdate.log|C:\Windows\Logs\WindowsUpdate|Starting in Windows 8.1 and continuing in Windows 10, Windows Update client uses Event Tracing for Windows (ETW) to generate diagnostic logs.|If you receive an error message when you run Windows Update, you can use the information that is included in the Windowsupdate.log log file to troubleshoot the issue.|
|UpdateSessionOrchestration.etl|C:\ProgramData\USOShared\Logs|Starting Windows 10, the Update Orchestrator is responsible for sequence of downloading and installing various update types from Windows Update. And the events are logged to these .etl files.|When you see that the updates are available but download is not getting triggered. <br>When Updates are downloaded but installation is not triggered.<br>When Updates are installed but reboot is not triggered. |
|windowsupdate.log|C:\Windows\Logs\WindowsUpdate|Starting in Windows 8.1 and continuing in Windows 10, Windows Update client uses Event Tracing for Windows (ETW) to generate diagnostic logs.|If you receive an error message when you run Windows Update, you can use the information included in the Windowsupdate.log log file to troubleshoot the issue.|
|UpdateSessionOrchestration.etl|C:\ProgramData\USOShared\Logs|Starting Windows 10, the Update Orchestrator Service is responsible for sequence of downloading and installing various update types from Windows Update. And the events are logged to these .etl files.|<ul> <li>When you see that the updates are available but download isn't getting triggered. </li><li>When updates are downloaded but installation isn't triggered. </li> <li>When updates are installed but reboot isn't triggered. </li></ul> |
|NotificationUxBroker.etl|C:\ProgramData\USOShared\Logs|Starting Windows 10, the notification toast or the banner is triggered by NotificationUxBroker.exe. |When you want to check whether the notification was triggered or not. |
|CBS.log|%systemroot%\Logs\CBS|This log provides insight on the update installation part in the servicing stack.|To troubleshoot the issues related to Windows Update installation.|
## Generating WindowsUpdate.log
## Generating WindowsUpdate.log
To merge and convert Windows Update trace files (.etl files) into a single readable WindowsUpdate.log file, see [Get-WindowsUpdateLog](/powershell/module/windowsupdate/get-windowsupdatelog?preserve-view=tru&view=win10-ps).
>[!NOTE]
>When you run the **Get-WindowsUpdateLog** cmdlet, an copy of WindowsUpdate.log file is created as a static log file. It does not update as the old WindowsUpdate.log unless you run **Get-WindowsUpdateLog** again.
### Windows Update log components
## Windows Update log components
The Windows Update engine has different component names. The following are some of the most common components that appear in the WindowsUpdate.log file:
- AGENT- Windows Update agent
@ -54,7 +56,7 @@ The Windows Update engine has different component names. The following are some
- PT- Synchronizes updates information to the local datastore
- REPORT- Collects reporting information
- SERVICE- Startup/shutdown of the Automatic Updates service
- SETUP- Installs new versions of the Windows Update client when it is available
- SETUP- Installs new versions of the Windows Update client when it's available
- SHUTDWN- Install at shutdown feature
- WUREDIR- The Windows Update redirector files
- WUWEB- The Windows Update ActiveX control
@ -68,7 +70,7 @@ The Windows Update engine has different component names. The following are some
>[!NOTE]
>Many component log messages are invaluable if you are looking for problems in that specific area. However, they can be useless if you don't filter to exclude irrelevant components so that you can focus on what's important.
### Windows Update log structure
## Windows Update log structure
The Windows update log structure is separated into four main identities:
- Time Stamps
@ -82,7 +84,7 @@ The Windows update log structure is separated into four main identities:
The WindowsUpdate.log structure is discussed in the following sections.
#### Time stamps
### Time stamps
The time stamp indicates the time at which the logging occurs.
- Messages are usually in chronological order, but there may be exceptions.
- A pause during a sync can indicate a network problem, even if the scan succeeds.
@ -90,15 +92,15 @@ The time stamp indicates the time at which the logging occurs.
![Windows Update time stamps.](images/update-time-log.png)
#### Process ID and thread ID
### Process ID and thread ID
The Process IDs and Thread IDs are random, and they can vary from log to log and even from service session to service session within the same log.
- The first four hex digits are the process ID.
- The next four hex digits are the thread ID.
- The first four digits, in hex, are the process ID.
- The next four digits, in hex, are the thread ID.
- Each component, such as the USO, Windows Update engine, COM API callers, and Windows Update installer handlers, has its own process ID.
![Windows Update process and thread IDs.](images/update-process-id.png)
#### Component name
### Component name
Search for and identify the components that are associated with the IDs. Different parts of the Windows Update engine have different component names. Some of them are as follows:
- ProtocolTalker - Client-server sync
@ -111,31 +113,36 @@ Search for and identify the components that are associated with the IDs. Differe
![Windows Update component name.](images/update-component-name.png)
#### Update identifiers
### Update identifiers
The following items are update identifiers:
#### Update ID and revision number
##### Update ID and revision number
There are different identifiers for the same update in different contexts. It's important to know the identifier schemes.
- Update ID: A GUID (indicated in the previous screenshot) that's assigned to a given update at publication time
- Update ID: A GUID (indicated in the previous screenshot) assigned to a given update at publication time
- Revision number: A number incremented every time that a given update (that has a given update ID) is modified and republished on a service
- Revision numbers are reused from one update to another (not a unique identifier).
- The update ID and revision number are often shown together as "{GUID}.revision."
![Windows Update update identifiers.](images/update-update-id.png)
##### Revision ID
- A Revision ID (don't confuse this value with "revision number") is a serial number that's issued when an update is initially published or revised on a given service.
- An existing update that's revised keeps the same update ID (GUID), has its revision number incremented (for example, from 100 to 101), but gets a new revision ID that is not related to the previous ID.
#### Revision ID
- A Revision ID (don't confuse this value with "revision number") is a serial number issued when an update is initially published or revised on a given service.
- An existing update that is revised keeps the same update ID (GUID), has its revision number incremented (for example, from 100 to 101), but gets a new revision ID that isn't related to the previous ID.
- Revision IDs are unique on a given update source, but not across multiple sources.
- The same update revision might have different revision IDs on Windows Update and WSUS.
- The same revision ID might represent different updates on Windows Update and WSUS.
##### Local ID
- Local ID is a serial number issued when an update is received from a service by a given Windows Update client
#### Local ID
- Local ID is a serial number issued by a given Windows Update client when an update is received from a service.
- Typically seen in debug logs, especially involving the local cache for update info (Datastore)
- Different client PCs will assign different Local IDs to the same update
- Different client PCs assign different Local IDs to the same update
- You can find the local IDs that a client is using by getting the client's %WINDIR%\SoftwareDistribution\Datastore\Datastore.edb file
##### Inconsistent terminology
#### Inconsistent terminology
- Sometimes the logs use terms inconsistently. For example, the InstalledNonLeafUpdateIDs list actually contains revision IDs, not update IDs.
- Recognize IDs by form and context:

49
windows/deployment/update/wufb-reports-configuration-manual.md
View File

@ -4,7 +4,7 @@ titleSuffix: Windows Update for Business reports
description: How to manually configure devices for Windows Update for Business reports using a PowerShell script.
ms.prod: windows-client
ms.technology: itpro-updates
ms.topic: conceptual
ms.topic: how-to
author: mestew
ms.author: mstewart
manager: aaroncz
@ -12,61 +12,60 @@ ms.localizationpriority: medium
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
ms.date: 11/15/2022
ms.date: 12/15/2023
---
# Manually configuring devices for Windows Update for Business reports
# Manually configure devices for Windows Update for Business reports
<!--37063317, 30141258, 37063041-->
There are a number of requirements to consider when manually configuring devices for Windows Update for Business reports. These requirements can potentially change with newer versions of Windows client. The [Windows Update for Business reports configuration script](wufb-reports-configuration-script.md) will be updated when any configuration requirements change so only a redeployment of the script will be required.
There are many requirements to consider when manually configuring devices for Windows Update for Business reports. These requirements can potentially change with later versions of Windows client. When any configuration requirements change, we'll update the [Windows Update for Business reports configuration script](wufb-reports-configuration-script.md). If that happens, you only need to redeploy the script.
The requirements are separated into different categories:
1. Ensuring the [**required policies**](#required-policies) for Windows Update for Business reports are correctly configured.
2. Devices in every network topography must send data to the [**required endpoints**](#required-endpoints) for Windows Update for Business reports. For example, devices in both main and satellite offices, which might have different network configurations, must be able to reach the endpoints.
3. Ensure [**Required Windows services**](#required-services) are running or are scheduled to run. It's recommended all Microsoft and Windows services are set to their out-of-box defaults to ensure proper functionality.
3. Ensure [**Required Windows services**](#required-services) are running or are scheduled to run. For proper functionality, leave Windows services set to their out-of-box default configurations.
## Required policies
Windows Update for Business reports has a number of policies that must be appropriately configured in order for devices to be processed by Microsoft and visible in Windows Update for Business reports. Thee policies are listed below, separated by whether the policies will be configured via [Mobile Device Management](/windows/client-management/mdm/) (MDM) or Group Policy. For both tables:
The Windows Update for Business reports service has several policies that you need to configure appropriately. These policies allow Microsoft to process your devices and show them in Windows Update for Business reports. The policies are listed in the following subsections, separated by [mobile device management](/windows/client-management/mdm/) (MDM) or group policy.
- **Policy** corresponds to the location and name of the policy.
- **Value** Indicates what value the policy must be set to. Windows Update for Business reports requires *at least* Basic (or Required) diagnostic data, but can function off Enhanced or Full (or Optional).
- **Function** details why the policy is required and what function it serves for Windows Update for Business reports. It will also detail a minimum version the policy is required, if any.
The following definitions apply for both tables:
### Mobile Device Management policies
- **Policy**: The location and name of the policy.
- **Value**: Set the policy to this value. Windows Update for Business reports requires at least *Required* (previously *Basic*) diagnostic data, but can function with *Enhanced* or *Optional* (previously *Full*).
- **Function**: Details for why the policy is required and what function it serves for Windows Update for Business reports. It also details a minimum version the policy requires, if any.
Each MDM Policy links to its documentation in the configuration service provider (CSP) hierarchy, providing its exact location in the hierarchy and more details.
### MDM policies
| Policy | Data type | Value | Function | Required or recommended|
Each MDM policy links to more detailed documentation in the configuration service provider (CSP) hierarchy.
| Policy | Data type | Value | Function | Required or recommended |
|---|---|---|---|---|
|**System/**[**AllowTelemetry**](/windows/client-management/mdm/policy-csp-system#system-allowtelemetry) |Integer | 1 - Basic |Configures the maximum allowed diagnostic data to be sent to Microsoft. Individual users can still set this value lower than what the policy defines. For more information, see the following policy. | Required |
|**System/**[**ConfigureTelemetryOptInSettingsUx**](/windows/client-management/mdm/policy-csp-system#system-configuretelemetryoptinsettingsux) |Integer |1 - Disable Telemetry opt-in Settings | Determines whether users of the device can adjust diagnostic data to levels lower than the level defined by AllowTelemetry. We recommend that you disable this policy or the effective diagnostic data level on devices might not be sufficient. | Recommended |
|**System/**[**AllowDeviceNameInDiagnosticData**](/windows/client-management/mdm/policy-csp-system#system-allowdevicenameindiagnosticdata) |Integer | 1 - Allowed | Allows device name to be sent for Windows Diagnostic Data. If this policy is Not Configured or set to 0 (Disabled), Device Name won't be sent and won't be visible in Windows Update for Business reports, showing `#` instead. | Recommended |
| **System/**[**ConfigureTelemetryOptInChangeNotification**](/windows/client-management/mdm/policy-csp-system#configuretelemetryoptinchangenotification) | Integer | 1 - Disabled | Disables user notifications that appear for changes to the diagnostic data level. | Recommended |
| **System/**[**AllowTelemetry**](/windows/client-management/mdm/policy-csp-system#allowtelemetry) | Integer | `1`: Basic (Required) | Configures the device to send the minimum required diagnostic data. | Required |
| **System/**[**ConfigureTelemetryOptInSettingsUx**](/windows/client-management/mdm/policy-csp-system#configuretelemetryoptinsettingsux) | Integer | `1`: Disable diagnostic data opt-in settings | Determines whether users of the device can adjust diagnostic data to levels lower than you define by the *AllowTelemetry* policy. Set the recommended value to disable opt-in settings, or users can change the effective diagnostic data level that might not be sufficient. | Recommended |
| **System/**[**AllowDeviceNameInDiagnosticData**](/windows/client-management/mdm/policy-csp-system#allowdevicenameindiagnosticdata) | Integer | `1`: Allowed | Allows the device to send its name with Windows diagnostic data. If you don't configure this policy or set it to `0`: Disabled, then the data doesn't include the device name. If the data doesn't include the device name, you can't see the device in Windows Update for Business reports. In this instance, the reports show `#` instead. | Recommended |
| **System/**[**ConfigureTelemetryOptInChangeNotification**](/windows/client-management/mdm/policy-csp-system#configuretelemetryoptinchangenotification) | Integer | `1`: Disabled | Disables user notifications that appear for changes to the diagnostic data level. | Recommended |
### Group policies
All Group policies that need to be configured for Windows Update for Business reports are under **Computer Configuration>Administrative Templates>Windows Components\Data Collection and Preview Builds**. All of these policies must be in the *Enabled* state and set to the defined *Value* below.
All group policies that you need to configure for Windows Update for Business reports are under the following path: **Computer Configuration > Administrative Templates > Windows Components > Data Collection and Preview Builds**. All of these policies must be in the *Enabled* state and set to the defined *Value*.
| Policy | Value | Function | Required or recommended|
|---|---|---|---|
|**Allow Diagnostic Data** | Send required diagnostic data (minimum) | Configures the maximum allowed diagnostic data to be sent to Microsoft. Individual users can still set this value lower than what the policy defines. For more information, see the **Configure diagnostic data opt-in setting user interface**. | Required |
|**Configure diagnostic data opt-in setting user interface** | Disable diagnostic data opt in settings | Determines whether users of the device can adjust diagnostic data to levels lower than the level defined by AllowTelemetry. We recommend that you disable this policy, otherwise the effective diagnostic data level on devices might not be sufficient. | Recommended |
|**Allow device name to be sent in Windows diagnostic data** | Enabled | Allows device name to be sent for Windows Diagnostic Data. If this policy is Not Configured or Disabled, Device Name won't be sent and won't be visible in Windows Update for Business reports, showing `#` instead. | Recommended |
|**Configure diagnostic data opt-in change notifications** | Disable diagnostic data change notifications | Disables user notifications that appear for changes to the diagnostic data level. | Recommended |
| **Allow Diagnostic Data** | Send required diagnostic data | Configures the device to send the minimum required diagnostic data. | Required |
| **Configure diagnostic data opt-in setting user interface** | Disable diagnostic data opt-in settings | Determines whether users of the device can adjust diagnostic data to levels lower than you define by the *Allow Diagnostic Data* policy. Set the recommended value to disable opt-in settings, or users can change the effective diagnostic data level that might not be sufficient. | Recommended |
| **Allow device name to be sent in Windows diagnostic data** | Enabled | Allows the device to send its name with Windows diagnostic data. If you don't configure this policy or set it to *Disabled*, then the data doesn't include the device name. If the data doesn't include the device name, you can't see the device in Windows Update for Business reports. In this instance, the reports show `#` instead. | Recommended |
| **Configure diagnostic data opt-in change notifications** | Disable diagnostic data change notifications | Disables user notifications that appear for changes to the diagnostic data level. | Recommended |
## Required endpoints
To enable data sharing between devices, your network, and Microsoft's Diagnostic Data Service, configure your proxy to allow devices to contact the below endpoints.
<!--Using include for endpoint access requirements-->
[!INCLUDE [Endpoints for Windows Update for Business reports](./includes/wufb-reports-endpoints.md)]
## Required services
Many Windows and Microsoft services are required to ensure that not only the device can function, but Windows Update for Business reports can see device data. It's recommended that you allow all default services from the out-of-box experience to remain running. The [Windows Update for Business reports Configuration Script](wufb-reports-configuration-script.md) checks whether the majority of these services are running or are allowed to run automatically.
Many Windows services are required for Windows Update for Business reports to see device data. Allow all default services from the out-of-box experience to remain running. Use the [Windows Update for Business reports configuration script](wufb-reports-configuration-script.md) to check whether required services are running or are allowed to run automatically.
## Next steps

28
windows/deployment/update/wufb-reports-prerequisites.md
View File

@ -11,7 +11,7 @@ manager: aaroncz
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
ms.date: 08/30/2023
ms.date: 12/15/2023
---
# Windows Update for Business reports prerequisites
@ -22,12 +22,12 @@ Before you begin the process of adding Windows Update for Business reports to yo
## Azure and Microsoft Entra ID
- An Azure subscription with [Microsoft Entra ID](/azure/active-directory/)
- An Azure subscription with [Microsoft Entra ID](/azure/active-directory/).
- Devices must be Microsoft Entra joined and meet the below OS, diagnostic, and endpoint access requirements.
- Devices can be [Microsoft Entra joined](/azure/active-directory/devices/concept-azure-ad-join) or [Microsoft Entra hybrid joined](/azure/active-directory/devices/concept-azure-ad-join-hybrid).
- Devices that are [Microsoft Entra registered](/azure/active-directory/devices/concept-azure-ad-register) only (Workplace joined) aren't supported with Windows Update for Business reports.
- The Log Analytics workspace must be in a [supported region](#log-analytics-regions)
- Data in the **Driver update** tab of the [workbook](wufb-reports-workbook.md) is only available for devices that receive driver and firmware updates from the [Windows Update for Business deployment service](deployment-service-overview.md)
- Devices that are [Microsoft Entra registered](/azure/active-directory/devices/concept-azure-ad-register) only (workplace joined) aren't supported with Windows Update for Business reports.
- The Log Analytics workspace must be in a [supported region](#log-analytics-regions).
- Data in the **Driver update** tab of the [workbook](wufb-reports-workbook.md) is only available for devices that receive driver and firmware updates from the [Windows Update for Business deployment service](deployment-service-overview.md).
## Permissions
@ -38,7 +38,7 @@ Before you begin the process of adding Windows Update for Business reports to yo
- Windows 11 Professional, Education, Enterprise, and [Enterprise multi-session](/azure/virtual-desktop/windows-10-multisession-faq) editions
- Windows 10 Professional, Education, Enterprise, and [Enterprise multi-session](/azure/virtual-desktop/windows-10-multisession-faq) editions
Windows Update for Business reports only provides data for the standard Desktop Windows client version and isn't currently compatible with Windows Server, Surface Hub, IoT, or other versions.
Windows Update for Business reports only provides data for the standard desktop Windows client version and isn't currently compatible with Windows Server, Surface Hub, IoT, or other versions.
## Windows client servicing channels
@ -49,27 +49,25 @@ Windows Update for Business reports supports Windows client devices on the follo
### Windows operating system updates
- For [Changes to Windows diagnostic data collection](/windows/privacy/changes-to-windows-diagnostic-data-collection#services-that-rely-on-enhanced-diagnostic-data), installing the January 2023 release preview cumulative update, or a later equivalent update, is recommended
For [changes to Windows diagnostic data collection](/windows/privacy/changes-to-windows-diagnostic-data-collection#services-that-rely-on-enhanced-diagnostic-data), installing the January 2023 release preview cumulative update, or a later equivalent update, is recommended.
## Diagnostic data requirements
At minimum, Windows Update for Business reports requires devices to send diagnostic data at the *Required* level (previously *Basic*). For more information about what's included in different diagnostic levels, see [Configure Windows diagnostic data in your organization](/windows/privacy/configure-windows-diagnostic-data-in-your-organization).
At minimum, Windows Update for Business reports requires devices to send diagnostic data at the *Required* level (previously *Basic*). For more information about what data each diagnostic level includes, see [Configure Windows diagnostic data in your organization](/windows/privacy/configure-windows-diagnostic-data-in-your-organization).
The following levels are recommended, but not required:
- The *Enhanced* level for Windows 10 devices
- The *Optional* level for Windows 11 devices (previously *Full*) <!--8027083-->
Device names don't appear in Windows Update for Business reports unless you individually opt-in devices by using a policy. The configuration script does this for you, but when using other client configuration methods, set one of the following to display device names:
- The *Enhanced* level for Windows 10 devices.
- The *Optional* level for Windows 11 devices (previously *Full*). <!--8027083-->
- CSP: System/[AllowDeviceNameInDiagnosticData](/windows/client-management/mdm/policy-csp-system#system-allowdevicenameindiagnosticdata)
- Group Policy: **Allow device name to be sent in Windows diagnostic data** under **Computer Configuration\Administrative Templates\Windows Components\Data Collection and Preview Builds**
Device names don't appear in Windows Update for Business reports unless you individually opt in devices by using a policy. The configuration script does this action for you, but when using other client configuration methods, set one of the following policies to display device names:
- CSP: System/[AllowDeviceNameInDiagnosticData](/windows/client-management/mdm/policy-csp-system#system-allowdevicenameindiagnosticdata)
- Group Policy: **Allow device name to be sent in Windows diagnostic data** under **Computer Configuration\Administrative Templates\Windows Components\Data Collection and Preview Builds**
> [!TIP]
> Windows Update for Business reports uses [services configuration](/windows/privacy/manage-connections-from-windows-operating-system-components-to-microsoft-services#bkmk-svccfg), also called OneSettings. Disabling the services configuration can cause some of the client data to be incorrect or missing in reports. For more information, see the [DisableOneSettingsDownloads](/windows/client-management/mdm/policy-csp-system#disableonesettingsdownloads) policy settings.
Microsoft is committed to providing you with effective controls over your data and ongoing transparency into our data handling practices. For more information about data handling and privacy for Windows diagnostic data, see [Configure Windows diagnostic data in your organization](/windows/privacy/configure-windows-diagnostic-data-in-your-organization) and [Changes to Windows diagnostic data collection](/windows/privacy/changes-to-windows-diagnostic-data-collection#services-that-rely-on-enhanced-diagnostic-data).
## Endpoints

4
windows/deployment/windows-autopatch/deploy/windows-autopatch-groups-manage-autopatch-groups.md
View File

@ -1,7 +1,7 @@
---
title: Manage Windows Autopatch groups
description: This article explains how to manage Autopatch groups
ms.date: 07/25/2023
ms.date: 12/13/2023
ms.prod: windows-client
ms.technology: itpro-updates
ms.topic: how-to
@ -46,7 +46,7 @@ Before you start managing Autopatch groups, ensure you’ve met the following pr
- Windows Autopatch – Ring2
- Windows Autopatch – Ring3
- Windows Autopatch – Last
- Additionally, **don't** modify the Microsoft Entra group ownership of any of the groups above otherwise, Autopatch groups device registration process won't be able to add devices into these groups. If the ownership is modified, you must add the **Modern Workplace Management** Service Principal as the owner of these groups.
- Additionally, **don't** modify the Microsoft Entra group ownership of any of the groups above otherwise, Autopatch groups device registration process won't be able to add devices into these groups. If the ownership is modified, you must add the **Modern Workplace Management** enterprise application as the owner of these groups.
- For more information, see [assign an owner or member of a group in Microsoft Entra ID](/azure/active-directory/privileged-identity-management/groups-assign-member-owner#assign-an-owner-or-member-of-a-group) for steps on how to add owners to Azure Microsoft Entra groups.
- Make sure you have [app-only auth turned on in your Windows Autopatch tenant](../operate/windows-autopatch-maintain-environment.md#windows-autopatch-tenant-actions). Otherwise, the Autopatch groups functionality won’t work properly. Autopatch uses app-only auth to:
- Read device attributes to successfully register devices.

10
windows/deployment/windows-autopatch/references/windows-autopatch-changes-to-tenant.md
View File

@ -1,7 +1,7 @@
---
title: Changes made at tenant enrollment
description: This reference article details the changes made to your tenant when enrolling into Windows Autopatch
ms.date: 06/23/2023
ms.date: 12/13/2023
ms.prod: windows-client
ms.technology: itpro-updates
ms.topic: reference
@ -32,14 +32,6 @@ Windows Autopatch creates an enterprise application in your tenant. This enterpr
| ----- | ------ | ----- |
| Modern Workplace Management | The Modern Workplace Management application:<ul><li>Manages the service</li><li>Publishes baseline configuration updates</li><li>Maintains overall service health</li></ul> | <ul><li>DeviceManagementApps.ReadWrite.All</li><li>DeviceManagementConfiguration.ReadWrite.All</li><li>DeviceManagementManagedDevices.PriviligedOperation.All</li><li>DeviceManagementManagedDevices.ReadWrite.All</li><li>DeviceManagementRBAC.ReadWrite.All</li><li>DeviceManagementServiceConfig.ReadWrite.All</li><li>Directory.Read.All</li><li>Group.Create</li><li>Policy.Read.All</li><li>WindowsUpdates.ReadWrite.All</li></ul> |
### Service principal
Windows Autopatch will create a service principal in your tenant to establish an identity and restrict access to what resources the service has access to within the tenant. For more information, see [Application and service principal objects in Microsoft Entra ID](/azure/active-directory/develop/app-objects-and-service-principals#service-principal-object). The service principal created by Windows Autopatch is:
- Modern Workplace Customer APIs
<a name='azure-active-directory-groups'></a>
## Microsoft Entra groups
Windows Autopatch will create the required Microsoft Entra groups to operate the service.

9
windows/deployment/windows-autopatch/whats-new/windows-autopatch-whats-new-2023.md
View File

@ -1,7 +1,7 @@
---
title: What's new 2023
description: This article lists the 2023 feature releases and any corresponding Message center post numbers.
ms.date: 12/04/2023
ms.date: 12/14/2023
ms.prod: windows-client
ms.technology: itpro-updates
ms.topic: whats-new
@ -29,6 +29,13 @@ Minor corrections such as typos, style, or formatting issues aren't listed.
| ----- | ----- |
| [Prerequisites](../prepare/windows-autopatch-prerequisites.md#more-about-licenses) | Added F SKU licenses to the [More about licenses](../prepare/windows-autopatch-prerequisites.md#more-about-licenses) section. Also see [FAQ](../overview/windows-autopatch-faq.yml)<ul><li>[MC690609](https://admin.microsoft.com/adminportal/home#/MessageCenter)</li></ul> |
## December service release
| Message center post number | Description |
| ----- | ----- |
| [MC697414](https://admin.microsoft.com/adminportal/home#/MessageCenter) | New Feature: Alerts for Windows Autopatch policy conflicts Public Preview announcement |
| [MC695483](https://admin.microsoft.com/adminportal/home#/MessageCenter) | Planned Maintenance: Windows Autopatch configuration update – December 2023 |
## November service release
| Message center post number | Description |

5
windows/hub/docfx.json
View File

@ -44,9 +44,8 @@
"uhfHeaderId": "MSDocsHeader-Windows",
"ms.technology": "itpro-fundamentals",
"ms.topic": "article",
"feedback_system": "GitHub",
"feedback_github_repo": "MicrosoftDocs/windows-itpro-docs",
"feedback_product_url": "https://support.microsoft.com/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332",
"feedback_system": "Standard",
"feedback_product_url": "https://support.microsoft.com/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332",
"_op_documentIdPathDepotMapping": {
"./": {
"depot_name": "MSDN.windows-hub",

6
windows/hub/zone-pivot-groups.yml
View File

@ -1,13 +1,13 @@
# YamlMime:ZonePivotGroups
groups:
- id: windows-versions-10-11
- id: windows-versions-11-10
title: Windows versions
prompt: "Select the Windows version you want to learn about:"
pivots:
- id: windows-10
title: Windows 10
- id: windows-11
title: Windows 11
- id: windows-10
title: Windows 10
- id: windows-editions-proent-proedu
title: Windows editions
prompt: "Select the Windows edition you want to learn about:"

5
windows/privacy/docfx.json
View File

@ -39,9 +39,8 @@
"uhfHeaderId": "MSDocsHeader-Windows",
"ms.technology": "itpro-privacy",
"ms.topic": "article",
"feedback_system": "GitHub",
"feedback_github_repo": "MicrosoftDocs/windows-itpro-docs",
"feedback_product_url": "https://support.microsoft.com/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332",
"feedback_system": "Standard",
"feedback_product_url": "https://support.microsoft.com/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332",
"_op_documentIdPathDepotMapping": {
"./": {
"depot_name": "MSDN.privacy",

5
windows/security/application-security/application-isolation/microsoft-defender-application-guard/configure-md-app-guard.md
View File

@ -2,12 +2,15 @@
title: Configure the Group Policy settings for Microsoft Defender Application Guard
description: Learn about the available Group Policy settings for Microsoft Defender Application Guard.
ms.localizationpriority: medium
ms.date: 07/11/2023
ms.date: 12/12/2023
ms.topic: how-to
---
# Configure Microsoft Defender Application Guard policy settings
[!INCLUDE [mdag-edge-deprecation-notice](../../../includes/mdag-edge-deprecation-notice.md)]
Microsoft Defender Application Guard (Application Guard) works with Group Policy to help you manage your organization's computer settings. By using Group Policy, you can configure a setting once, and then copy it onto many computers. For example, you can set up multiple security settings in a Group Policy Object, which is linked to a domain, and then apply all those settings to every endpoint in the domain.
Application Guard uses both network isolation and application-specific settings.

6
windows/security/application-security/application-isolation/microsoft-defender-application-guard/faq-md-app-guard.yml
View File

@ -1,14 +1,16 @@
### YamlMime:FAQ
metadata:
title: FAQ - Microsoft Defender Application Guard (Windows 10)
title: FAQ - Microsoft Defender Application Guard
description: Learn about the commonly asked questions and answers for Microsoft Defender Application Guard.
ms.localizationpriority: medium
ms.topic: faq
ms.date: 07/11/2023
ms.date: 12/12/2023
title: Frequently asked questions - Microsoft Defender Application Guard
summary: |
[!INCLUDE [mdag-edge-deprecation-notice](../../../includes/mdag-edge-deprecation-notice.md)]
This article lists frequently asked questions with answers for Microsoft Defender Application Guard (Application Guard). Questions span features, integration with the Windows operating system, and general configuration.
## Frequently Asked Questions

4
windows/security/application-security/application-isolation/microsoft-defender-application-guard/install-md-app-guard.md
View File

@ -1,12 +1,14 @@
---
title: Enable hardware-based isolation for Microsoft Edge
description: Learn about the Microsoft Defender Application Guard modes (Standalone or Enterprise-managed), and how to install Application Guard in your enterprise.
ms.date: 07/11/2023
ms.date: 12/12/2023
ms.topic: how-to
---
# Prepare to install Microsoft Defender Application Guard
[!INCLUDE [mdag-edge-deprecation-notice](../../../includes/mdag-edge-deprecation-notice.md)]
Before you continue, review [System requirements for Microsoft Defender Application Guard](reqs-md-app-guard.md) to review the hardware and software installation requirements for Microsoft Defender Application Guard.
> [!NOTE]

4
windows/security/application-security/application-isolation/microsoft-defender-application-guard/md-app-guard-browser-extension.md
View File

@ -2,12 +2,14 @@
title: Microsoft Defender Application Guard Extension
description: Learn about the Microsoft Defender Application Guard browser extension, which extends Application Guard's protection to more web browsers.
ms.localizationpriority: medium
ms.date: 07/11/2023
ms.date: 12/12/2023
ms.topic: conceptual
---
# Microsoft Defender Application Guard Extension
[!INCLUDE [mdag-edge-deprecation-notice](../../../includes/mdag-edge-deprecation-notice.md)]
[Microsoft Defender Application Guard Extension](https://www.microsoft.com/security/blog/2019/05/23/new-browser-extensions-for-integrating-microsofts-hardware-based-isolation/) is a web browser add-on available for [Chrome](https://chrome.google.com/webstore/detail/application-guard-extensi/mfjnknhkkiafjajicegabkbimfhplplj/) and [Firefox](https://addons.mozilla.org/en-US/firefox/addon/application-guard-extension/).
[Microsoft Defender Application Guard](md-app-guard-overview.md) provides Hyper-V isolation on Windows 10 and Windows 11, to protect users from potentially harmful content on the web. The extension helps Application Guard protect users running other web browsers.

4
windows/security/application-security/application-isolation/microsoft-defender-application-guard/md-app-guard-overview.md
View File

@ -1,12 +1,14 @@
---
title: Microsoft Defender Application Guard
description: Learn about Microsoft Defender Application Guard and how it helps combat malicious content and malware out on the Internet.
ms.date: 07/11/2023
ms.date: 12/12/2023
ms.topic: conceptual
---
# Microsoft Defender Application Guard overview
[!INCLUDE [mdag-edge-deprecation-notice](../../../includes/mdag-edge-deprecation-notice.md)]
Microsoft Defender Application Guard (MDAG) is designed to help prevent old and newly emerging attacks to help keep employees productive. Using our unique hardware isolation approach, our goal is to destroy the playbook that attackers use by making current attack methods obsolete.
## What is Application Guard and how does it work?

4
windows/security/application-security/application-isolation/microsoft-defender-application-guard/reqs-md-app-guard.md
View File

@ -3,11 +3,13 @@ title: System requirements for Microsoft Defender Application Guard
description: Learn about the system requirements for installing and running Microsoft Defender Application Guard.
ms.topic: overview
ms.localizationpriority: medium
ms.date: 07/11/2023
ms.date: 12/12/2023
---
# System requirements for Microsoft Defender Application Guard
[!INCLUDE [mdag-edge-deprecation-notice](../../../includes/mdag-edge-deprecation-notice.md)]
The threat landscape is continually evolving. While hackers are busy developing new techniques to breach enterprise networks by compromising workstations, phishing schemes remain one of the top ways to lure employees into social engineering attacks. Microsoft Defender Application Guard is designed to help prevent old, and newly emerging attacks, to help keep employees productive.
> [!NOTE]

4
windows/security/application-security/application-isolation/microsoft-defender-application-guard/test-scenarios-md-app-guard.md
View File

@ -2,12 +2,14 @@
title: Testing scenarios with Microsoft Defender Application Guard
description: Suggested testing scenarios for Microsoft Defender Application Guard, showing how it works in both Standalone and Enterprise-managed mode.
ms.localizationpriority: medium
ms.date: 07/11/2023
ms.date: 12/12/2023
ms.topic: conceptual
---
# Application Guard testing scenarios
[!INCLUDE [mdag-edge-deprecation-notice](../../../includes/mdag-edge-deprecation-notice.md)]
We've come up with a list of scenarios that you can use to test hardware-based isolation in your organization.
## Application Guard in standalone mode

5
windows/security/docfx.json
View File

@ -45,9 +45,8 @@
"ms.prod": "windows-client",
"ms.technology": "itpro-security",
"manager": "aaroncz",
"feedback_system": "GitHub",
"feedback_github_repo": "MicrosoftDocs/windows-itpro-docs",
"feedback_product_url": "https://support.microsoft.com/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332",
"feedback_system": "Standard",
"feedback_product_url": "https://support.microsoft.com/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332",
"_op_documentIdPathDepotMapping": {
"./": {
"depot_name": "MSDN.security",

2
windows/security/identity-protection/credential-guard/how-it-works.md
View File

@ -2,7 +2,7 @@
ms.date: 08/31/2023
title: How Credential Guard works
description: Learn how Credential Guard uses virtualization to protect secrets, so that only privileged system software can access them.
ms.topic: conceptual
ms.topic: concept-article
---
# How Credential Guard works

8
windows/security/identity-protection/hello-for-business/hello-aad-join-cloud-only-deploy.md → windows/security/identity-protection/hello-for-business/deploy/cloud.md
View File

@ -6,7 +6,7 @@ ms.topic: how-to
---
# Cloud-only deployment
[!INCLUDE [hello-hybrid-key-trust](./includes/hello-cloud.md)]
[!INCLUDE [apply-to-cloud](includes/apply-to-cloud.md)]
## Introduction
@ -21,7 +21,7 @@ You may wish to disable the automatic Windows Hello for Business enrollment prom
Cloud only deployments will use Microsoft Entra multifactor authentication (MFA) during Windows Hello for Business enrollment, and there's no additional MFA configuration needed. If you aren't already registered in MFA, you'll be guided through the MFA registration as part of the Windows Hello for Business enrollment process.
The necessary Windows Hello for Business prerequisites are located at [Cloud Only Deployment](hello-identity-verification.md#azure-ad-cloud-only-deployment).
The necessary Windows Hello for Business prerequisites are located at [Cloud Only Deployment](requirements.md#azure-ad-cloud-only-deployment).
It's possible for federated domains to configure the *FederatedIdpMfaBehavior* flag. The flag instructs Microsoft Entra ID to accept, enforce, or reject the MFA challenge from the federated IdP. For more information, see [federatedIdpMfaBehavior values](/graph/api/resources/internaldomainfederation#federatedidpmfabehavior-values). To check this setting, use the following PowerShell command:
@ -54,7 +54,7 @@ The following method explains how to disable Windows Hello for Business enrollme
When disabled, users can't provision Windows Hello for Business. When set to Disabled, you can still configure the subsequent settings for Windows Hello for Business even though this policy won't enable Windows Hello for Business.
> [!NOTE]
> This policy is only applied during new device enrollments. For currently enrolled devices, you can [set the same settings in a device configuration policy](hello-manage-in-organization.md).
> This policy is only applied during new device enrollments. For currently enrolled devices, you can [set the same settings in a device configuration policy](../hello-manage-in-organization.md).
## Disable Windows Hello for Business enrollment without Intune
@ -62,7 +62,7 @@ If you don't use Intune in your organization, then you can disable Windows Hello
Intune uses the following registry keys: **`HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Policies\PassportForWork\<Tenant-ID>\Device\Policies`**
To look up your Tenant ID, see [How to find your Microsoft Entra tenant ID](/azure/active-directory/fundamentals/how-to-find-tenant) or try the following, ensuring to sign-in with your organization's account:
To look up your Tenant ID, see [How to find your Microsoft Entra tenant ID](/azure/active-directory/fundamentals/how-to-find-tenant) or try the following, ensuring to sign in with your organization's account:
```msgraph-interactive
GET https://graph.microsoft.com/v1.0/organization?$select=id

7
windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-adfs.md → windows/security/identity-protection/hello-for-business/deploy/hybrid-cert-trust-adfs.md
View File

@ -1,7 +1,7 @@
---
title: Configure Active Directory Federation Services in a hybrid certificate trust model
description: Learn how to configure Active Directory Federation Services to support the Windows Hello for Business hybrid certificate trust model.
ms.date: 01/03/2023
ms.date: 12/15/2023
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
@ -10,9 +10,10 @@ appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016</a>
ms.topic: tutorial
---
# Configure Active Directory Federation Services - hybrid certificate trust
[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-cert-trust.md)]
[!INCLUDE [apply-to-hybrid-cert-trust](includes/apply-to-hybrid-cert-trust.md)]
The Windows Hello for Business certificate-based deployments use AD FS as the certificate registration authority (CRA).
The CRA is responsible for issuing and revoking certificates to users. Once the registration authority verifies the certificate request, it signs the certificate request using its enrollment agent certificate and sends it to the certificate authority.\
@ -80,4 +81,4 @@ Before moving to the next section, ensure the following steps are complete:
> - Update group memberships for the AD FS service account
> [!div class="nextstepaction"]
> [Next: configure policy settings >](/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-provision)
> [Next: configure policy settings >](hybrid-cert-trust-enroll.md)

42
windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-provision.md → windows/security/identity-protection/hello-for-business/deploy/hybrid-cert-trust-enroll.md
View File

@ -1,19 +1,25 @@
---
title: Windows Hello for Business hybrid certificate trust clients configuration and enrollment
title: Configure and provision Windows Hello for Business in a hybrid certificate trust model
description: Learn how to configure devices and enroll them in Windows Hello for Business in a hybrid certificate trust scenario.
ms.date: 01/03/2023
ms.date: 12/15/2023
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2022</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2019</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016</a>
ms.topic: tutorial
---
# Configure and provision Windows Hello for Business - hybrid certificate trust
[!INCLUDE [hello-hybrid-certificate-trust](./includes/hello-hybrid-cert-trust.md)]
[!INCLUDE [apply-to-hybrid-cert-trust](includes/apply-to-hybrid-cert-trust.md)]
## Policy Configuration
After the prerequisites are met and the PKI and AD FS configurations are validated, Windows Hello for business must be enabled on the Windows devices. Follow the instructions below to configure your devices using either Microsoft Intune or group policy (GPO).
#### [:::image type="icon" source="../../images/icons/group-policy.svg"::: **GPO**](#tab/gpo)
# [:::image type="icon" source="images/group-policy.svg"::: **GPO**](#tab/gpo)
> [!IMPORTANT]
> The information in this section applies to Microsoft Entra hybrid joined devices only.
@ -41,7 +47,7 @@ Windows Hello for Business provisioning performs the initial enrollment of the W
The process requires no user interaction, provided the user signs-in using Windows Hello for Business. The certificate is renewed in the background before it expires.
### Enable and configure Windows Hello for Business
### Enable and configure Windows Hello for Business with group policy
Sign-in a domain controller or management workstations with *Domain Admin* equivalent credentials.
@ -64,8 +70,8 @@ Sign-in a domain controller or management workstations with *Domain Admin* equiv
> [!NOTE]
> Windows Hello for Business can be configured using different policies. These policies are optional to configure, but it's recommended to enable *Use a hardware security device*.
>
> For more information about these policies, see [Group Policy settings for Windows Hello for Business](hello-manage-in-organization.md#group-policy-settings-for-windows-hello-for-business).
>
> For more information about these policies, see [Group Policy settings for Windows Hello for Business](../hello-manage-in-organization.md#group-policy-settings-for-windows-hello-for-business).
### Configure security for GPO
@ -90,14 +96,15 @@ The application of Group Policy object uses security group filtering. This solut
Users (or devices) must receive the Windows Hello for Business group policy settings and have the proper permission to provision Windows Hello for Business. You can provide users with these settings and permissions by adding members to the *Windows Hello for Business Users* group. Users and groups who aren't members of this group won't attempt to enroll for Windows Hello for Business.
#### [:::image type="icon" source="../../images/icons/intune.svg"::: **Intune**](#tab/intune)
# [:::image type="icon" source="images/intune.svg"::: **Intune**](#tab/intune)
## Configure Windows Hello for Business using Microsoft Intune
> [!IMPORTANT]
> The information in this section applies to Microsoft Entra joined devices managed by Intune. Before proceeding, ensure that you completed the steps described in:
> - [Configure single sign-on for Microsoft Entra joined devices](hello-hybrid-aadj-sso.md)
> - [Using Certificates for AADJ On-premises Single-sign On](hello-hybrid-aadj-sso-cert.md)
>
> - [Configure single sign-on for Microsoft Entra joined devices](../hello-hybrid-aadj-sso.md)
> - [Using Certificates for AADJ On-premises Single-sign On](../hello-hybrid-aadj-sso-cert.md)
For Microsoft Entra joined devices enrolled in Intune, you can use Intune policies to manage Windows Hello for Business.
@ -106,7 +113,7 @@ There are different ways to enable and configure Windows Hello for Business in I
- Using a policy applied at the tenant level. The tenant policy:
- Is only applied at enrollment time, and any changes to its configuration won't apply to devices already enrolled in Intune
- It applies to *all devices* getting enrolled in Intune. For this reason, the policy is usually disabled and Windows Hello for Business is enabled using a policy targeted to a security group
- A device configuration policy that is applied *after* device enrollment. Any changes to the policy will be applied to the devices during regular policy refresh intervals. Chose from the following policy types:
- A device configuration policy that is applied *after* device enrollment. Any changes to the policy will be applied to the devices during regular policy refresh intervals. Choose from the following policy types:
- [Settings catalog][MEM-1]
- [Security baselines][MEM-2]
- [Custom policy][MEM-3], via the [PassportForWork CSP][MEM-4]
@ -122,7 +129,7 @@ To check the Windows Hello for Business policy applied at enrollment time:
1. Select **Windows Hello for Business**
1. Verify the status of **Configure Windows Hello for Business** and any settings that may be configured
:::image type="content" source="images/whfb-intune-disable.png" alt-text="Disablement of Windows Hello for Business from Microsoft Intune admin center." lightbox="images/whfb-intune-disable.png":::
:::image type="content" source="images/whfb-intune-disable.png" alt-text="Screenshot that shows disablement of Windows Hello for Business from Microsoft Intune admin center." lightbox="images/whfb-intune-disable.png":::
If the tenant-wide policy is enabled and configured to your needs, you can skip to [Enroll in Windows Hello for Business](#enroll-in-windows-hello-for-business). Otherwise, follow the instructions below to create a policy using an *account protection* policy.
@ -138,14 +145,14 @@ To configure Windows Hello for Business using an *account protection* policy:
1. Specify a **Name** and, optionally, a **Description** > **Next**
1. Under *Block Windows Hello for Business*, select **Disabled** and multiple policies become available
- These policies are optional to configure, but it's recommended to configure *Enable to use a Trusted Platform Module (TPM)* to **Yes**
- For more information about these policies, see [MDM policy settings for Windows Hello for Business](hello-manage-in-organization.md#mdm-policy-settings-for-windows-hello-for-business)
- For more information about these policies, see [MDM policy settings for Windows Hello for Business](../hello-manage-in-organization.md#mdm-policy-settings-for-windows-hello-for-business)
1. Under *Enable to certificate for on-premises resources*, select **YES**
1. Select **Next**
1. Optionally, add *scope tags* > **Next**
1. Assign the policy to a security group that contains as members the devices or users that you want to configure > **Next**
1. Review the policy configuration and select **Create**
:::image type="content" source="images/whfb-intune-account-protection-cert-enable.png" alt-text="Enablement of Windows Hello for Business from Microsoft Intune admin center using an account protection policy." lightbox="images/whfb-intune-account-protection-cert-enable.png":::
:::image type="content" source="images/whfb-intune-account-protection-cert-enable.png" alt-text="Screenshot that shows enablement of Windows Hello for Business from Microsoft Intune admin center using an account protection policy." lightbox="images/whfb-intune-account-protection-cert-enable.png":::
---
@ -165,12 +172,12 @@ This is the process that occurs after a user signs in, to enroll in Windows Hell
1. After a successful MFA, the provisioning flow asks the user to create and validate a PIN. This PIN must observe any PIN complexity policies configured on the device
1. The remainder of the provisioning includes Windows Hello for Business requesting an asymmetric key pair for the user, preferably from the TPM (or required if explicitly set through policy). Once the key pair is acquired, Windows communicates with Microsoft Entra ID to register the public key. When key registration completes, Windows Hello for Business provisioning informs the user they can use their PIN to sign-in. The user may close the provisioning application and see their desktop. While the user has completed provisioning, Microsoft Entra Connect synchronizes the user's key to Active Directory
:::image type="content" source="images/haadj-whfb-pin-provisioning.gif" alt-text="Animation showing a user logging on to an HAADJ device with a password, and being prompted to enroll in Windows Hello for Business.":::
:::image type="content" source="images/haadj-whfb-pin-provisioning.gif" alt-text="Screenshot that shows animation showing a user logging on to an HAADJ device with a password, and being prompted to enroll in Windows Hello for Business.":::
> [!IMPORTANT]
> The following is the enrollment behavior prior to Windows Server 2016 update [KB4088889 (14393.2155)](https://support.microsoft.com/help/4088889).
>
> The minimum time needed to synchronize the user's public key from Microsoft Entra ID to the on-premises Active Directory is 30 minutes. The Microsoft Entra Connect scheduler controls the synchronization interval.
>
> The minimum time needed to synchronize the user's public key from Microsoft Entra ID to the on-premises Active Directory is 30 minutes. The Microsoft Entra Connect scheduler controls the synchronization interval.
> **This synchronization latency delays the user's ability to authenticate and use on-premises resources until the user's public key has synchronized to Active Directory.** Once synchronized, the user can authenticate and use on-premises resources.
> Read [Microsoft Entra Connect Sync: Scheduler](/azure/active-directory/connect/active-directory-aadconnectsync-feature-scheduler) to view and adjust the **synchronization cycle** for your organization.
>
@ -188,7 +195,6 @@ The certificate authority validates the certificate was signed by the registrati
<!--links-->
[AZ-4]: /azure/active-directory/devices/troubleshoot-device-dsregcmd
[AZ-5]: /azure/active-directory/connect/active-directory-aadconnectsync-feature-scheduler
[MEM-1]: /mem/intune/configuration/settings-catalog
[MEM-2]: /mem/intune/protect/security-baselines

18
windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-validate-pki.md → windows/security/identity-protection/hello-for-business/deploy/hybrid-cert-trust-pki.md
View File

@ -1,7 +1,7 @@
---
title: Configure and validate the Public Key Infrastructure in an hybrid certificate trust model
title: Configure and validate the PKI in an hybrid certificate trust model
description: Configure and validate the Public Key Infrastructure when deploying Windows Hello for Business in a hybrid certificate trust model.
ms.date: 01/03/2023
ms.date: 12/15/2023
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
@ -10,9 +10,9 @@ appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016</a>
ms.topic: tutorial
---
# Configure and validate the Public Key Infrastructure - hybrid certificate trust
# Configure and validate the PKI in a hybrid certificate trust model
[!INCLUDE [hello-hybrid-cert-trust](./includes/hello-hybrid-cert-trust.md)]
[!INCLUDE [apply-to-hybrid-cert-trust](includes/apply-to-hybrid-cert-trust.md)]
Windows Hello for Business must have a Public Key Infrastructure (PKI) when using the *key trust* or *certificate trust* models. The domain controllers must have a certificate, which serves as a *root of trust* for clients. The certificate ensures that clients don't communicate with rogue domain controllers.
@ -29,6 +29,7 @@ Hybrid certificate trust deployments issue users a sign-in certificate, enabling
> [!IMPORTANT]
> For Microsoft Entra joined devices to authenticate to on-premises resources, ensure to:
>
> - Install the root CA certificate in the device's trusted root certificate store. See [how to deploy a trusted certificate profile](/mem/intune/protect/certificates-trusted-root#to-create-a-trusted-certificate-profile) via Intune
> - Publish your certificate revocation list to a location that is available to Microsoft Entra joined devices, such as a web-based URL
@ -54,7 +55,7 @@ Sign in to the CA or management workstations with **Enterprise Admin** equivalen
1. Close the console
> [!IMPORTANT]
> If you plan to deploy **Microsoft Entra joined** devices, and require single sign-on (SSO) to on-premises resources when signing in with Windows Hello for Business, follow the procedures to [update your CA to include an http-based CRL distribution point](hello-hybrid-aadj-sso.md).
> If you plan to deploy **Microsoft Entra joined** devices, and require single sign-on (SSO) to on-premises resources when signing in with Windows Hello for Business, follow the procedures to [update your CA to include an http-based CRL distribution point](../hello-hybrid-aadj-sso.md).
## Configure and deploy certificates to domain controllers
@ -66,9 +67,9 @@ Sign in to the CA or management workstations with **Enterprise Admin** equivalen
## Section review and next steps
Before moving to the next section, ensure the following steps are complete:
> [!div class="checklist"]
> Before moving to the next section, ensure the following steps are complete:
>
> - Configure domain controller certificates
> - Supersede existing domain controller certificates
> - Unpublish superseded certificate templates
@ -79,7 +80,6 @@ Before moving to the next section, ensure the following steps are complete:
> - Validate the domain controllers configuration
> [!div class="nextstepaction"]
> [Next: configure AD FS >](hello-hybrid-cert-whfb-settings-adfs.md)
> [Next: configure AD FS >](hybrid-cert-trust-adfs.md)
<!--links-->
[SERV-1]: /troubleshoot/windows-server/windows-security/requirements-domain-controller

52
windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust.md → windows/security/identity-protection/hello-for-business/deploy/hybrid-cert-trust.md
View File

@ -1,39 +1,40 @@
---
title: Windows Hello for Business hybrid certificate trust deployment
description: Learn how to deploy Windows Hello for Business in a hybrid certificate trust scenario.
ms.date: 03/16/2023
ms.date: 12/15/2023
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2022</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2019</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016</a>
ms.topic: how-to
ms.topic: tutorial
---
# Hybrid certificate trust deployment
[!INCLUDE [hello-hybrid-cert-trust](./includes/hello-hybrid-cert-trust.md)]
[!INCLUDE [apply-to-hybrid-cert-trust](includes/apply-to-hybrid-cert-trust.md)]
Hybrid environments are distributed systems that enable organizations to use on-premises and Microsoft Entra protected resources. Windows Hello for Business uses the existing distributed system as a foundation on which organizations can provide two-factor authentication and single sign-on to modern resources.
This deployment guide describes how to deploy Windows Hello for Business in a hybrid certificate trust scenario.
> [!IMPORTANT]
> Windows Hello for Business *cloud Kerberos trust* is the recommended deployment model when compared to the *key trust model*. It is also the recommended deployment model if you don't need to deploy certificates to the end users. For more information, see [cloud Kerberos trust deployment](hello-hybrid-cloud-kerberos-trust.md).
> Windows Hello for Business *cloud Kerberos trust* is the recommended deployment model when compared to the *key trust model*. It is also the recommended deployment model if you don't need to deploy certificates to the end users. For more information, see [cloud Kerberos trust deployment](hybrid-cloud-kerberos-trust.md).
It's recommended that you review the [Windows Hello for Business planning guide](hello-planning-guide.md) prior to using the deployment guide. The planning guide helps you make decisions by explaining the available options with each aspect of the deployment and explains the potential outcomes based on each of these decisions.
It's recommended that you review the [Windows Hello for Business planning guide](../hello-planning-guide.md) prior to using the deployment guide. The planning guide helps you make decisions by explaining the available options with each aspect of the deployment and explains the potential outcomes based on each of these decisions.
## Prerequisites
The following prerequisites must be met for a hybrid certificate trust deployment:
> [!div class="checklist"]
> * Directories and directory synchronization
> * Federated authentication to Microsoft Entra ID
> * Device registration
> * Public Key Infrastructure
> * Multifactor authentication
> * Device management
> The following prerequisites must be met for a hybrid certificate trust deployment:
>
> - Directories and directory synchronization
> - Federated authentication to Microsoft Entra ID
> - Device registration
> - Public Key Infrastructure
> - Multifactor authentication
> - Device management
### Directories and directory synchronization
@ -43,7 +44,7 @@ Hybrid Windows Hello for Business needs two directories:
- A Microsoft Entra tenant with a Microsoft Entra ID P1 or P2 subscription
The two directories must be synchronized with [Microsoft Entra Connect Sync][AZ-1], which synchronizes user accounts from the on-premises Active Directory to Microsoft Entra ID.
The hybrid-certificate trust deployment needs an *Microsoft Entra ID P1 or P2* subscription because it uses the device write-back synchronization feature.
The hybrid-certificate trust deployment needs a *Microsoft Entra ID P1 or P2* subscription because it uses the device write-back synchronization feature.
> [!NOTE]
> Windows Hello for Business hybrid certificate trust is not supported if the users' on-premises UPN suffix cannot be added as a verified domain in Microsoft Entra ID.
@ -51,8 +52,6 @@ The hybrid-certificate trust deployment needs an *Microsoft Entra ID P1 or P2* s
> [!IMPORTANT]
> Windows Hello for Business is tied between a user and a device. Both the user and device object must be synchronized between Microsoft Entra ID and Active Directory.
<a name='federated-authentication-to-azure-ad'></a>
### Federated authentication to Microsoft Entra ID
Windows Hello for Business hybrid certificate trust doesn't support Microsoft Entra ID *Pass-through Authentication* (PTA) or *password hash sync* (PHS).\
@ -91,8 +90,6 @@ The enterprise PKI and a certificate registration authority (CRA) are required t
During Windows Hello for Business provisioning, users receive a sign-in certificate through the CRA.
<a name='multi-factor-authentication'></a>
### Multifactor authentication
The Windows Hello for Business provisioning process lets a user enroll in Windows Hello for Business using their user name and password as one factor, but requires a second factor of authentication.\
@ -110,28 +107,23 @@ To configure Windows Hello for Business, devices can be configured through a mob
## Next steps
Once the prerequisites are met, deploying Windows Hello for Business with a hybrid key trust model consists of the following steps:
> [!div class="checklist"]
> * Configure and validate the PKI
> * Configure AD FS
> * Configure Windows Hello for Business settings
> * Provision Windows Hello for Business on Windows clients
> * Configure single sign-on (SSO) for Microsoft Entra joined devices
> Once the prerequisites are met, deploying Windows Hello for Business with a hybrid key trust model consists of the following steps:
>
> - Configure and validate the PKI
> - Configure AD FS
> - Configure Windows Hello for Business settings
> - Provision Windows Hello for Business on Windows clients
> - Configure single sign-on (SSO) for Microsoft Entra joined devices
> [!div class="nextstepaction"]
> [Next: configure and validate the Public Key Infrastructure >](hello-hybrid-cert-trust-validate-pki.md)
> [Next: configure and validate the Public Key Infrastructure >](hybrid-cert-trust-pki.md)
<!--links-->
[AZ-1]: /azure/active-directory/hybrid/how-to-connect-sync-whatis
[AZ-2]: /azure/multi-factor-authentication/multi-factor-authentication
[AZ-3]: /azure/multi-factor-authentication/multi-factor-authentication-whats-next
[AZ-4]: /azure/active-directory/devices/troubleshoot-device-dsregcmd
[AZ-5]: /azure/active-directory/connect/active-directory-aadconnectsync-feature-scheduler
[AZ-6]: /azure/active-directory/hybrid/whatis-phs
[AZ-7]: /azure/active-directory/connect/active-directory-aadconnect-pass-through-authentication
[AZ-8]: /azure/active-directory/devices/hybrid-azuread-join-plan
[AZ-9]: /azure/active-directory/devices/hybrid-azuread-join-federated-domains
[AZ-10]: /azure/active-directory/devices/howto-hybrid-azure-ad-join#federated-domains
[AZ-11]: /azure/active-directory/devices/hybrid-azuread-join-manual

12
windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust-provision.md → windows/security/identity-protection/hello-for-business/deploy/hybrid-cloud-kerberos-trust-enroll.md
View File

@ -8,7 +8,7 @@ ms.topic: tutorial
---
# Configure and provision Windows Hello for Business - cloud Kerberos trust
[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-cloudkerb-trust.md)]
[!INCLUDE [apply-to-hybrid-cloud-kerberos-trust](includes/apply-to-hybrid-cloud-kerberos-trust.md)]
## Deployment steps
@ -29,7 +29,7 @@ If you haven't deployed Microsoft Entra Kerberos, follow the instructions in the
After setting up the Microsoft Entra Kerberos object, Windows Hello for business cloud Kerberos trust must be enabled on your Windows devices. Follow the instructions below to configure your devices using either Microsoft Intune or group policy (GPO).
#### [:::image type="icon" source="../../images/icons/intune.svg"::: **Intune**](#tab/intune)
#### [:::image type="icon" source="images/intune.svg"::: **Intune**](#tab/intune)
For devices managed by Intune, you can use Intune policies to configure Windows Hello for Business.
@ -68,7 +68,7 @@ To configure Windows Hello for Business using an account protection policy:
1. Specify a **Name** and, optionally, a **Description** > **Next**.
1. Under **Block Windows Hello for Business**, select **Disabled** and multiple policies become available.
- These policies are optional to configure, but it's recommended to configure **Enable to use a Trusted Platform Module (TPM)** to **Yes**.
- For more information about these policies, see [MDM policy settings for Windows Hello for Business](hello-manage-in-organization.md#mdm-policy-settings-for-windows-hello-for-business).
- For more information about these policies, see [MDM policy settings for Windows Hello for Business](../hello-manage-in-organization.md#mdm-policy-settings-for-windows-hello-for-business).
1. Under **Enable to certificate for on-premises resources**, select **Not configured**
1. Select **Next**.
1. Optionally, add **scope tags** and select **Next**.
@ -107,7 +107,7 @@ To configure the cloud Kerberos trust policy:
1. Assign the policy to a security group that contains as members the devices or users that you want to configure.
#### [:::image type="icon" source="../../images/icons/group-policy.svg"::: **GPO**](#tab/gpo)
#### [:::image type="icon" source="images/group-policy.svg"::: **GPO**](#tab/gpo)
Microsoft Entra hybrid joined organizations can use Windows Hello for Business Group Policy to manage the feature. Group Policy can be configured to enable users to enroll and use Windows Hello for Business.
@ -118,7 +118,7 @@ You can configure the Enable Windows Hello for Business Group Policy setting for
Cloud Kerberos trust requires setting a dedicated policy for it to be enabled. This policy is only available as a computer configuration.
> [!NOTE]
> If you deployed Windows Hello for Business configuration using both Group Policy and Microsoft Intune, Group Policy settings will take precedence and Intune settings will be ignored. For more information about deploying Windows Hello for Business configuration using Microsoft Intune, see [Windows device settings to enable Windows Hello for Business in Intune][MEM-1] and [PassportForWork CSP](/windows/client-management/mdm/passportforwork-csp). For more information about policy conflicts, see [Policy conflicts from multiple policy sources](hello-manage-in-organization.md#policy-conflicts-from-multiple-policy-sources).
> If you deployed Windows Hello for Business configuration using both Group Policy and Microsoft Intune, Group Policy settings will take precedence and Intune settings will be ignored. For more information about deploying Windows Hello for Business configuration using Microsoft Intune, see [Windows device settings to enable Windows Hello for Business in Intune][MEM-1] and [PassportForWork CSP](/windows/client-management/mdm/passportforwork-csp). For more information about policy conflicts, see [Policy conflicts from multiple policy sources](../hello-manage-in-organization.md#policy-conflicts-from-multiple-policy-sources).
#### Update administrative templates
@ -199,7 +199,7 @@ If you deployed Windows Hello for Business using the certificate trust model, an
## Frequently Asked Questions
For a list of frequently asked questions about Windows Hello for Business cloud Kerberos trust, see [Windows Hello for Business Frequently Asked Questions](hello-faq.yml#cloud-kerberos-trust).
For a list of frequently asked questions about Windows Hello for Business cloud Kerberos trust, see [Windows Hello for Business Frequently Asked Questions](../hello-faq.yml#cloud-kerberos-trust).
<!--Links-->

6
windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md → windows/security/identity-protection/hello-for-business/deploy/hybrid-cloud-kerberos-trust.md
View File

@ -8,7 +8,7 @@ ms.topic: tutorial
---
# Cloud Kerberos trust deployment
[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-cloudkerb-trust.md)]
[!INCLUDE [apply-to-hybrid-cloud-kerberos-trust](includes/apply-to-hybrid-cloud-kerberos-trust.md)]
Windows Hello for Business replaces password sign-in with strong authentication, using an asymmetric key pair. This deployment guide provides the information to deploy Windows Hello for Business in a *cloud Kerberos trust* scenario.
@ -45,7 +45,7 @@ When Microsoft Entra Kerberos is enabled in an Active Directory domain, an *Azur
:::image type="content" source="images/azuread-kerberos-object.png" alt-text="Active Directory Users and Computers console, showing the computer object representing the Microsoft Entra Kerberos server ":::
For more information about how Microsoft Entra Kerberos enables access to on-premises resources, see [enabling passwordless security key sign-in to on-premises resources][AZ-1].\
For more information about how Microsoft Entra Kerberos works with Windows Hello for Business cloud Kerberos trust, see [Windows Hello for Business authentication technical deep dive](hello-how-it-works-authentication.md#hybrid-azure-ad-join-authentication-using-cloud-kerberos-trust).
For more information about how Microsoft Entra Kerberos works with Windows Hello for Business cloud Kerberos trust, see [Windows Hello for Business authentication technical deep dive](../hello-how-it-works-authentication.md#hybrid-azure-ad-join-authentication-using-cloud-kerberos-trust).
> [!IMPORTANT]
> When implementing the cloud Kerberos trust deployment model, you *must* ensure that you have an adequate number of *read-write domain controllers* in each Active Directory site where users will be authenticating with Windows Hello for Business. For more information, see [Capacity planning for Active Directory][SERV-1].
@ -84,7 +84,7 @@ Once the prerequisites are met, deploying Windows Hello for Business with a clou
> * Provision Windows Hello for Business on Windows clients
> [!div class="nextstepaction"]
> [Next: configure and provision Windows Hello for Business >](hello-hybrid-cloud-kerberos-trust-provision.md)
> [Next: configure and provision Windows Hello for Business >](hybrid-cloud-kerberos-trust-enroll.md)
<!--Links-->

14
windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-provision.md → windows/security/identity-protection/hello-for-business/deploy/hybrid-key-trust-enroll.md
View File

@ -7,11 +7,11 @@ ms.topic: tutorial
# Configure and enroll in Windows Hello for Business - hybrid key trust
[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-key-trust.md)]
[!INCLUDE [apply-to-hybrid-key-trust](includes/apply-to-hybrid-key-trust.md)]
After the prerequisites are met and the PKI configuration is validated, Windows Hello for business must be enabled on the Windows devices. Follow the instructions below to configure your devices using either Microsoft Intune or group policy (GPO).
#### [:::image type="icon" source="../../images/icons/intune.svg"::: **Intune**](#tab/intune)
#### [:::image type="icon" source="images/intune.svg"::: **Intune**](#tab/intune)
## Configure Windows Hello for Business using Microsoft Intune
@ -54,7 +54,7 @@ To configure Windows Hello for Business using an *account protection* policy:
1. Specify a **Name** and, optionally, a **Description** > **Next**
1. Under *Block Windows Hello for Business*, select **Disabled** and multiple policies become available
- These policies are optional to configure, but it's recommended to configure *Enable to use a Trusted Platform Module (TPM)* to **Yes**
- For more information about these policies, see [MDM policy settings for Windows Hello for Business](hello-manage-in-organization.md#mdm-policy-settings-for-windows-hello-for-business)
- For more information about these policies, see [MDM policy settings for Windows Hello for Business](../hello-manage-in-organization.md#mdm-policy-settings-for-windows-hello-for-business)
1. Select **Next**
1. Optionally, add *scope tags* > **Next**
1. Assign the policy to a security group that contains as members the devices or users that you want to configure > **Next**
@ -62,7 +62,7 @@ To configure Windows Hello for Business using an *account protection* policy:
:::image type="content" source="images/whfb-intune-account-protection-enable.png" alt-text="Enablement of Windows Hello for Business from Microsoft Intune admin center using an account protection policy." lightbox="images/whfb-intune-account-protection-enable.png":::
#### [:::image type="icon" source="../../images/icons/group-policy.svg"::: **GPO**](#tab/gpo)
#### [:::image type="icon" source="images/group-policy.svg"::: **GPO**](#tab/gpo)
## Configure Windows Hello for Business using group policies
@ -72,7 +72,7 @@ It's suggested to create a security group (for example, *Windows Hello for Busin
The Windows Hello for Business Group Policy object delivers the correct Group Policy settings to the user, which enables them to enroll and use Windows Hello for Business to authenticate to Azure and Active Directory
> [!NOTE]
> If you deployed Windows Hello for Business configuration using both Group Policy and Intune, Group Policy settings will take precedence and Intune settings will be ignored. For more information about policy conflicts, see [Policy conflicts from multiple policy sources](hello-manage-in-organization.md#policy-conflicts-from-multiple-policy-sources)
> If you deployed Windows Hello for Business configuration using both Group Policy and Intune, Group Policy settings will take precedence and Intune settings will be ignored. For more information about policy conflicts, see [Policy conflicts from multiple policy sources](../hello-manage-in-organization.md#policy-conflicts-from-multiple-policy-sources)
### Enable Windows Hello for Business group policy setting
@ -100,8 +100,8 @@ Sign-in a domain controller or management workstations with *Domain Admin* equiv
> [!NOTE]
> Windows Hello for Business can be configured using different policies. These policies are optional to configure, but it's recommended to enable *Use a hardware security device*.
>
> For more information about these policies, see [Group Policy settings for Windows Hello for Business](hello-manage-in-organization.md#group-policy-settings-for-windows-hello-for-business).
>
> For more information about these policies, see [Group Policy settings for Windows Hello for Business](../hello-manage-in-organization.md#group-policy-settings-for-windows-hello-for-business).
### Configure security for GPO

12
windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md → windows/security/identity-protection/hello-for-business/deploy/hybrid-key-trust-pki.md
View File

@ -1,6 +1,6 @@
---
title: Configure and validate the Public Key Infrastructure in an hybrid key trust model
description: Configure and validate the Public Key Infrastructure when deploying Windows Hello for Business in an hybrid key trust model.
title: Configure and validate the Public Key Infrastructure in a hybrid key trust model
description: Configure and validate the Public Key Infrastructure when deploying Windows Hello for Business in a hybrid key trust model.
ms.date: 01/03/2023
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
@ -12,7 +12,7 @@ ms.topic: tutorial
---
# Configure and validate the Public Key Infrastructure - hybrid key trust
[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-key-trust.md)]
[!INCLUDE [apply-to-hybrid-key-trust](includes/apply-to-hybrid-key-trust.md)]
Windows Hello for Business must have a Public Key Infrastructure (PKI) when using the *key trust* model. The domain controllers must have a certificate, which serves as a *root of trust* for clients. The certificate ensures that clients don't communicate with rogue domain controllers.
@ -53,6 +53,7 @@ Sign in using *Enterprise Administrator* equivalent credentials on a Windows Ser
> [!IMPORTANT]
> For Microsoft Entra joined devices to authenticate to on-premises resources, ensure to:
>
> - Install the root CA certificate in the device's trusted root certificate store. See [how to deploy a trusted certificate profile](/mem/intune/protect/certificates-trusted-root#to-create-a-trusted-certificate-profile) via Intune
> - Publish your certificate revocation list to a location that is available to Microsoft Entra joined devices, such as a web-based URL
@ -74,7 +75,7 @@ Sign in to the CA or management workstations with **Enterprise Admin** equivalen
1. Close the console
> [!IMPORTANT]
> If you plan to deploy **Microsoft Entra joined** devices, and require single sign-on (SSO) to on-premises resources when signing in with Windows Hello for Business, follow the procedures to [update your CA to include an http-based CRL distribution point](hello-hybrid-aadj-sso.md).
> If you plan to deploy **Microsoft Entra joined** devices, and require single sign-on (SSO) to on-premises resources when signing in with Windows Hello for Business, follow the procedures to [update your CA to include an http-based CRL distribution point](../hello-hybrid-aadj-sso.md).
## Configure and deploy certificates to domain controllers
@ -89,6 +90,7 @@ Sign in to the CA or management workstations with **Enterprise Admin** equivalen
Before moving to the next section, ensure the following steps are complete:
> [!div class="checklist"]
>
> - Configure domain controller certificates
> - Supersede existing domain controller certificates
> - Unpublish superseded certificate templates
@ -97,7 +99,7 @@ Before moving to the next section, ensure the following steps are complete:
> - Validate the domain controllers configuration
> [!div class="nextstepaction"]
> [Next: configure and provision Windows Hello for Business >](hello-hybrid-key-trust-provision.md)
> [Next: configure and provision Windows Hello for Business >](hybrid-key-trust-enroll.md)
<!--links-->
[SERV-1]: /troubleshoot/windows-server/windows-security/requirements-domain-controller

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

@ -12,16 +12,16 @@ ms.topic: how-to
---
# Hybrid key trust deployment
[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-key-trust.md)]
[!INCLUDE [apply-to-hybrid-key-trust](includes/apply-to-hybrid-key-trust.md)]
Hybrid environments are distributed systems that enable organizations to use on-premises and Microsoft Entra protected resources. Windows Hello for Business uses the existing distributed system as a foundation on which organizations can provide two-factor authentication and single sign-on to modern resources.
This deployment guide describes how to deploy Windows Hello for Business in a hybrid key trust scenario.
> [!IMPORTANT]
> Windows Hello for Business *cloud Kerberos trust* is the recommended deployment model when compared to the *key trust model*. For more information, see [cloud Kerberos trust deployment](hello-hybrid-cloud-kerberos-trust.md).
> Windows Hello for Business *cloud Kerberos trust* is the recommended deployment model when compared to the *key trust model*. For more information, see [cloud Kerberos trust deployment](hybrid-cloud-kerberos-trust.md).
It is recommended that you review the [Windows Hello for Business planning guide](hello-planning-guide.md) prior to using the deployment guide. The planning guide helps you make decisions by explaining the available options with each aspect of the deployment and explains the potential outcomes based on each of these decisions.
It is recommended that you review the [Windows Hello for Business planning guide](../hello-planning-guide.md) prior to using the deployment guide. The planning guide helps you make decisions by explaining the available options with each aspect of the deployment and explains the potential outcomes based on each of these decisions.
## Prerequisites
@ -94,7 +94,7 @@ Once the prerequisites are met, deploying Windows Hello for Business with a hybr
> * Configure single sign-on (SSO) for Microsoft Entra joined devices
> [!div class="nextstepaction"]
> [Next: configure and validate the Public Key Infrastructure >](hello-hybrid-key-trust-validate-pki.md)
> [Next: configure and validate the Public Key Infrastructure >](hybrid-key-trust-pki.md)
<!--links-->
[AZ-1]: /azure/active-directory/hybrid/how-to-connect-sync-whatis

0
windows/security/identity-protection/hello-for-business/images/adfs-device-registration.png → windows/security/identity-protection/hello-for-business/deploy/images/adfs-device-registration.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 400 KiB

After

Width:  |  Height:  |  Size: 400 KiB

0
windows/security/identity-protection/hello-for-business/images/adfs-scp.png → windows/security/identity-protection/hello-for-business/deploy/images/adfs-scp.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 475 KiB

After

Width:  |  Height:  |  Size: 475 KiB

0
windows/security/identity-protection/hello-for-business/images/azuread-kerberos-object.png → windows/security/identity-protection/hello-for-business/deploy/images/azuread-kerberos-object.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 114 KiB

After

Width:  |  Height:  |  Size: 114 KiB

0
windows/security/identity-protection/hello-for-business/images/cloud-trust-prereq-check.png → windows/security/identity-protection/hello-for-business/deploy/images/cloud-trust-prereq-check.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 98 KiB

After

Width:  |  Height:  |  Size: 98 KiB

0
windows/security/identity-protection/hello-for-business/images/event358.png → windows/security/identity-protection/hello-for-business/deploy/images/event358.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 536 KiB

After

Width:  |  Height:  |  Size: 536 KiB

3
windows/security/identity-protection/hello-for-business/deploy/images/group-policy.svg Normal file
View File

@ -0,0 +1,3 @@
<svg xmlns="http://www.w3.org/2000/svg" width="18" height="18" viewBox="0 0 2048 2048">
<path d="M1792 0q53 0 99 20t82 55 55 81 20 100q0 53-20 99t-55 82-81 55-100 20h-128v1280q0 53-20 99t-55 82-81 55-100 20H256q-53 0-99-20t-82-55-55-81-20-100q0-53 20-99t55-82 81-55 100-20V256q0-53 20-99t55-82 81-55T512 0h1280zM128 1792q0 27 10 50t27 40 41 28 50 10h930q-34-60-34-128t34-128H256q-27 0-50 10t-40 27-28 41-10 50zm1280 128q27 0 50-10t40-27 28-41 10-50V256q0-68 34-128H512q-27 0-50 10t-40 27-28 41-10 50v1280h1024q26 0 45 19t19 45q0 26-19 45t-45 19q-25 0-49 9t-42 28q-18 18-27 42t-10 49q0 27 10 50t27 40 41 28 50 10zm384-1536q27 0 50-10t40-27 28-41 10-50q0-27-10-50t-27-40-41-28-50-10q-27 0-50 10t-40 27-28 41-10 50v128h128zm-1280 0h896v128H512V384zm0 256h256v128H512V640zm0 256h256v128H512V896zm0 256h256v128H512v-128zm640-512q53 0 99 20t82 55 55 81 20 100q0 17-4 33t-4 31v539l-248-124-248 124V960q0-14-4-30t-4-34q0-53 20-99t55-82 81-55 100-20zm0 128q-27 0-50 10t-40 27-28 41-10 50q0 27 10 50t27 40 41 28 50 10q27 0 50-10t40-27 28-41 10-50q0-27-10-50t-27-40-41-28-50-10zm136 549v-204q-30 20-65 29t-71 10q-36 0-71-9t-65-30v204l136-68 136 68z" fill="#0078D4" />
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 1.1 KiB

0
windows/security/identity-protection/hello-for-business/images/haadj-whfb-pin-provisioning.gif → windows/security/identity-protection/hello-for-business/deploy/images/haadj-whfb-pin-provisioning.gif
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 3.1 MiB

After

Width:  |  Height:  |  Size: 3.1 MiB

0
windows/security/identity-protection/hello-for-business/images/hello-cloud-trust-intune-large.png → windows/security/identity-protection/hello-for-business/deploy/images/hello-cloud-trust-intune-large.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 52 KiB

After

Width:  |  Height:  |  Size: 52 KiB

0
windows/security/identity-protection/hello-for-business/images/hello-cloud-trust-intune.png → windows/security/identity-protection/hello-for-business/deploy/images/hello-cloud-trust-intune.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 15 KiB

After

Width:  |  Height:  |  Size: 15 KiB

0
windows/security/identity-protection/hello-for-business/images/hello-internal-web-server-cert.png → windows/security/identity-protection/hello-for-business/deploy/images/hello-internal-web-server-cert.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 651 KiB

After

Width:  |  Height:  |  Size: 651 KiB

3
windows/security/identity-protection/hello-for-business/deploy/images/information.svg Normal file
View File

@ -0,0 +1,3 @@
<svg width="16" height="16" viewBox="0 0 16 16" fill="none" xmlns="http://www.w3.org/2000/svg">
<path d="M8 7C8.27614 7 8.5 7.22386 8.5 7.5V10.5C8.5 10.7761 8.27614 11 8 11C7.72386 11 7.5 10.7761 7.5 10.5V7.5C7.5 7.22386 7.72386 7 8 7ZM8.00001 6.24907C8.41369 6.24907 8.74905 5.91371 8.74905 5.50003C8.74905 5.08635 8.41369 4.751 8.00001 4.751C7.58633 4.751 7.25098 5.08635 7.25098 5.50003C7.25098 5.91371 7.58633 6.24907 8.00001 6.24907ZM2 8C2 4.68629 4.68629 2 8 2C11.3137 2 14 4.68629 14 8C14 11.3137 11.3137 14 8 14C4.68629 14 2 11.3137 2 8ZM8 3C5.23858 3 3 5.23858 3 8C3 10.7614 5.23858 13 8 13C10.7614 13 13 10.7614 13 8C13 5.23858 10.7614 3 8 3Z" fill="#0078D4" />
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 680 B

24
windows/security/identity-protection/hello-for-business/deploy/images/intune.svg Normal file
View File

@ -0,0 +1,24 @@
<svg id="a9ed4d43-c916-4b9a-b9ca-be76fbdc694c" xmlns="http://www.w3.org/2000/svg" width="18" height="18" viewBox="0 0 18 18">
<defs>
<linearGradient id="aaede26b-698f-4a65-b6db-859d207e2da6" x1="8.05" y1="11.32" x2="8.05" y2="1.26" gradientUnits="userSpaceOnUse">
<stop offset="0" stop-color="#0078d4" />
<stop offset="0.82" stop-color="#5ea0ef" />
</linearGradient>
<linearGradient id="bc54987f-34ba-4701-8ce4-6eca10aff9e9" x1="8.05" y1="15.21" x2="8.05" y2="11.32" gradientUnits="userSpaceOnUse">
<stop offset="0" stop-color="#1490df" />
<stop offset="0.98" stop-color="#1f56a3" />
</linearGradient>
<linearGradient id="a5434fd8-c18c-472c-be91-f2aa070858b7" x1="8.05" y1="7.87" x2="8.05" y2="4.94" gradientUnits="userSpaceOnUse">
<stop offset="0" stop-color="#d2ebff" />
<stop offset="1" stop-color="#f0fffd" />
</linearGradient>
</defs>
<title>Icon-intune-329</title>
<rect x="0.5" y="1.26" width="15.1" height="10.06" rx="0.5" fill="url(#aaede26b-698f-4a65-b6db-859d207e2da6)" />
<rect x="1.34" y="2.1" width="13.42" height="8.39" rx="0.28" fill="#fff" />
<path d="M11.08,14.37c-1.5-.23-1.56-1.31-1.55-3h-3c0,1.74-.06,2.82-1.55,3a.87.87,0,0,0-.74.84h7.54A.88.88,0,0,0,11.08,14.37Z" fill="url(#bc54987f-34ba-4701-8ce4-6eca10aff9e9)" />
<path d="M17.17,5.91H10.29a2.31,2.31,0,1,0,0,.92H11v9.58a.33.33,0,0,0,.33.33h5.83a.33.33,0,0,0,.33-.33V6.24A.33.33,0,0,0,17.17,5.91Z" fill="#32bedd" />
<rect x="11.62" y="6.82" width="5.27" height="8.7" rx="0.12" fill="#fff" />
<circle cx="8.05" cy="6.41" r="1.46" opacity="0.9" fill="url(#a5434fd8-c18c-472c-be91-f2aa070858b7)" />
<path d="M14.88,10.82,13.76,9.7a.06.06,0,0,0-.1.05v.68a.06.06,0,0,1-.06.06H11v.83H13.6a.06.06,0,0,1,.06.06v.69a.06.06,0,0,0,.1,0L14.88,11A.12.12,0,0,0,14.88,10.82Z" fill="#0078d4" />
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 1.8 KiB

0
windows/security/identity-protection/hello-for-business/images/whfb-intune-account-protection-cert-enable.png → windows/security/identity-protection/hello-for-business/deploy/images/whfb-intune-account-protection-cert-enable.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 242 KiB

After

Width:  |  Height:  |  Size: 242 KiB

0
windows/security/identity-protection/hello-for-business/images/whfb-intune-account-protection-enable.png → windows/security/identity-protection/hello-for-business/deploy/images/whfb-intune-account-protection-enable.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 234 KiB

After

Width:  |  Height:  |  Size: 234 KiB

0
windows/security/identity-protection/hello-for-business/images/whfb-intune-disable.png → windows/security/identity-protection/hello-for-business/deploy/images/whfb-intune-disable.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 249 KiB

After

Width:  |  Height:  |  Size: 249 KiB

9
windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-cloud.md Normal file
View File

@ -0,0 +1,9 @@
---
ms.date: 12/15/2023
ms.topic: include
---
[!INCLUDE [intro](intro.md)]
- **Deployment type:** [!INCLUDE [tooltip-deployment-cloud](tooltip-deployment-cloud.md)]
- **Join type:** [!INCLUDE [tootip-join-entra](tooltip-join-entra.md)]
---

10
windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-hybrid-cert-trust-entra.md Normal file
View File

@ -0,0 +1,10 @@
---
ms.date: 12/15/2023
ms.topic: include
---
[!INCLUDE [intro](intro.md)]
- **Deployment type:** [!INCLUDE [tooltip-deployment-hybrid](tooltip-deployment-hybrid.md)]
- **Trust type:** [!INCLUDE [tooltip-cert-trust](tooltip-trust-cert.md)]
- **Join type:** [!INCLUDE [tooltip-join-entra](tooltip-join-entra.md)]
---

10
windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-hybrid-cert-trust.md Normal file
View File

@ -0,0 +1,10 @@
---
ms.date: 12/15/2023
ms.topic: include
---
[!INCLUDE [intro](intro.md)]
- **Deployment type:** [!INCLUDE [tooltip-deployment-hybrid](tooltip-deployment-hybrid.md)]
- **Trust type:** [!INCLUDE [tooltip-cert-trust](tooltip-trust-cert.md)]
- **Join type:** [!INCLUDE [tooltip-join-entra](tooltip-join-entra.md)], [!INCLUDE [tooltip-join-hybrid](tooltip-join-hybrid.md)]
---

10
windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-hybrid-cloud-kerberos-trust.md Normal file
View File

@ -0,0 +1,10 @@
---
ms.date: 12/15/2023
ms.topic: include
---
[!INCLUDE [intro](intro.md)]
- **Deployment type:** [!INCLUDE [tooltip-deployment-hybrid](tooltip-deployment-hybrid.md)]
- **Trust type:** [!INCLUDE [tooltip-trust-cloud-kerberos](tooltip-trust-cloud-kerberos.md)]
- **Join type:** [!INCLUDE [tooltip-join-entra](tooltip-join-entra.md)], [!INCLUDE [tooltip-join-hybrid](tooltip-join-hybrid.md)]
---

10
windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-hybrid-key-and-cert-trust.md Normal file
View File

@ -0,0 +1,10 @@
---
ms.date: 12/15/2023
ms.topic: include
---
[!INCLUDE [intro](intro.md)]
- **Deployment type:** [!INCLUDE [tooltip-deployment-hybrid](tooltip-deployment-hybrid.md)]
- **Trust type:** [!INCLUDE [tooltip-trust-key](tooltip-trust-key.md)],[!INCLUDE [tooltip-cert-trust](tooltip-trust-cert.md)]
- **Join type:** [!INCLUDE [tooltip-join-entra](tooltip-join-entra.md)]
---

10
windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-hybrid-key-trust.md Normal file
View File

@ -0,0 +1,10 @@
---
ms.date: 12/15/2023
ms.topic: include
---
[!INCLUDE [intro](intro.md)]
- **Deployment type:** [!INCLUDE [tooltip-deployment-hybrid](tooltip-deployment-hybrid.md)]
- **Trust type:** [!INCLUDE [tooltip-trust-key](tooltip-trust-key.md)]
- **Join type:** [!INCLUDE [tooltip-join-entra](tooltip-join-entra.md)], [!INCLUDE [tooltip-join-hybrid](tooltip-join-hybrid.md)]
---

10
windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-on-premises-cert-trust-entra.md Normal file
View File

@ -0,0 +1,10 @@
---
ms.date: 12/15/2023
ms.topic: include
---
[!INCLUDE [intro](intro.md)]
- **Deployment type:** [!INCLUDE [tooltip-deployment-onpremises](tooltip-deployment-onpremises.md)]
- **Trust type:** [!INCLUDE [tooltip-cert-trust](tooltip-trust-cert.md)]
- **Join type:** [!INCLUDE [tooltip-join-domain](tooltip-join-domain.md)]
---

10
windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-on-premises-key-trust.md Normal file
View File

@ -0,0 +1,10 @@
---
ms.date: 12/08/2022
ms.topic: include
---
[!INCLUDE [intro](intro.md)]
- **Deployment type:** [!INCLUDE [tooltip-deployment-onpremises](tooltip-deployment-onpremises.md)]
- **Trust type:** [!INCLUDE [tooltip-trust-key](tooltip-trust-key.md)]
- **Join type:** [!INCLUDE [tooltip-join-domain](tooltip-join-domain.md)]
---

0
windows/security/identity-protection/hello-for-business/includes/auth-certificate-template.md → windows/security/identity-protection/hello-for-business/deploy/includes/auth-certificate-template.md
View File

2
windows/security/identity-protection/hello-for-business/includes/dc-certificate-deployment.md → windows/security/identity-protection/hello-for-business/deploy/includes/dc-certificate-deployment.md
View File

@ -1,5 +1,5 @@
---
ms.date: 12/28/2022
ms.date: 12/15/2023
ms.topic: include
---

3
windows/security/identity-protection/hello-for-business/includes/dc-certificate-supersede.md → windows/security/identity-protection/hello-for-business/deploy/includes/dc-certificate-supersede.md
View File

@ -1,5 +1,5 @@
---
ms.date: 12/28/2022
ms.date: 12/15/2023
ms.topic: include
---
@ -30,4 +30,3 @@ However, the certificate template and the superseding of certificate templates i
>To see all certificates in the NTAuth store, use the following command:
>
> `Certutil -viewstore -enterprise NTAuth`

33
windows/security/identity-protection/hello-for-business/includes/dc-certificate-template.md → windows/security/identity-protection/hello-for-business/deploy/includes/dc-certificate-template.md
View File

@ -1,5 +1,5 @@
---
ms.date: 12/28/2022
ms.date: 12/15/2023
ms.topic: include
---
@ -27,25 +27,14 @@ Sign in to a CA or management workstations with *Domain Administrator* equivalen
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
1. Use the following table to configure the template:
| Tab Name | Configurations |
| --- | --- |
| *Compatibility* | <ul><li>Clear the **Show resulting changes** check box</li><li>Select **Windows Server 2016** from the *Certification Authority list*</li><li>Select **Windows 10 / Windows Server 2016** from the *Certification Recipient list*</li></ul>|
| *General* | <ul><li>Specify a **Template display name**, for example *Domain Controller Authentication (Kerberos)*</li><li>Set the validity period to the desired value</li><li>Take note of the template name for later, which should be the same as the Template display name minus spaces</li></ul>|
| *Subject Name* | <ul><li>Select **Build from this Active Directory information**</li><li>Select **None** from the **Subject name format** list</li><li>Select **DNS name** from the **Include this information in alternate subject** list</li><li>Clear all other items</li></ul>|
|*Cryptography*|<ul><li>Set the *Provider Category* to **Key Storage Provider**</li><li>Set the *Algorithm name* to **RSA**</li><li>Set the *minimum key size* to **2048**</li><li>Set the *Request hash* to **SHA256**</li>|
1. Select **OK** to finalize your changes and create the new template
1. Close the console

2
windows/security/identity-protection/hello-for-business/includes/dc-certificate-validate.md → windows/security/identity-protection/hello-for-business/deploy/includes/dc-certificate-validate.md
View File

@ -1,5 +1,5 @@
---
ms.date: 12/28/2022
ms.date: 12/15/2023
ms.topic: include
---

2
windows/security/identity-protection/hello-for-business/includes/enrollment-agent-certificate-template.md → windows/security/identity-protection/hello-for-business/deploy/includes/enrollment-agent-certificate-template.md
View File

@ -1,5 +1,5 @@
---
ms.date: 01/03/2022
ms.date: 12/15/2023
ms.topic: include
---

2
windows/security/identity-protection/hello-for-business/includes/hello-intro.md → windows/security/identity-protection/hello-for-business/deploy/includes/intro.md
View File

@ -1,5 +1,5 @@
---
ms.date: 12/08/2022
ms.date: 12/15/2023
ms.topic: include
---

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

@ -1,5 +1,5 @@
---
ms.date: 01/03/2023
ms.date: 12/15/2023
ms.topic: include
---

6
windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-deployment-cloud.md Normal file
View File

@ -0,0 +1,6 @@
---
ms.date: 12/15/2023
ms.topic: include
---
[cloud :::image type="icon" source="../images/information.svg" border="false":::](../../hello-how-it-works-technology.md#cloud-deployment "For organizations using Microsoft Entra-only identities. Device management is usually done via Intune/MDM")

6
windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-deployment-hybrid.md Normal file
View File

@ -0,0 +1,6 @@
---
ms.date: 12/15/2023
ms.topic: include
---
[hybrid :::image type="icon" source="../images/information.svg" border="false":::](../../hello-how-it-works-technology.md#hybrid-deployment "For organizations using Active Directory identities synchronized to Microsoft Entra ID. Device management is usually done via Group Policy or Intune/MDM")

6
windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-deployment-onpremises.md Normal file
View File

@ -0,0 +1,6 @@
---
ms.date: 12/15/2023
ms.topic: include
---
[on-premises :::image type="icon" source="../images/information.svg" border="false":::](../../hello-how-it-works-technology.md#on-premises-deployment "For organizations using Active Directory identities, not synchronized to Microsoft Entra ID. Device management is usually done via Group Policy")

6
windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-join-domain.md Normal file
View File

@ -0,0 +1,6 @@
---
ms.date: 12/15/2023
ms.topic: include
---
[domain join :::image type="icon" source="../images/information.svg" border="false":::](../../hello-how-it-works-technology.md)

6
windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-join-entra.md Normal file
View File

@ -0,0 +1,6 @@
---
ms.date: 12/15/2023
ms.topic: include
---
[Microsoft Entra join :::image type="icon" source="../images/information.svg" border="false":::](../../hello-how-it-works-technology.md#azure-active-directory-join "Devices that are Microsoft Entra joined do not have any dependencies on Active Directory. Only local users accounts and Microsoft Entra users can sign in to these devices")

6
windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-join-hybrid.md Normal file
View File

@ -0,0 +1,6 @@
---
ms.date: 12/15/2023
ms.topic: include
---
[Microsoft Entra hybrid join :::image type="icon" source="../images/information.svg" border="false":::](../../hello-how-it-works-technology.md#hybrid-azure-ad-join "Devices that are Microsoft Entra hybrid joined don't have any dependencies on Microsoft Entra ID. Only local users accounts and Active Directory users can sign in to these devices. Active Directory users that are synchronized to Microsoft Entra ID will have single-sign on to both Active Directory and Microsoft Entra protected resources")

6
windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-trust-cert.md Normal file
View File

@ -0,0 +1,6 @@
---
ms.date: 12/15/2023
ms.topic: include
---
[certificate trust :::image type="icon" source="../images/information.svg" border="false":::](../../hello-how-it-works-technology.md#certificate-trust "This trust type uses a certificate to authenticate the users to Active Directory. It's required to issue certificates to the users and to the domain controllers")

6
windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-trust-cloud-kerberos.md Normal file
View File

@ -0,0 +1,6 @@
---
ms.date: 12/08/2022
ms.topic: include
---
[cloud Kerberos trust :::image type="icon" source="../images/information.svg" border="false":::](../../hello-how-it-works-technology.md#cloud-kerberos-trust "This trust type uses security keys to authenticate the users to Active Directory. It's not required to issue any certificates, making it the recommended choice for environments that don't need certificate authentication")

6
windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-trust-key.md Normal file
View File

@ -0,0 +1,6 @@
---
ms.date: 12/08/2022
ms.topic: include
---
[key trust :::image type="icon" source="../images/information.svg" border="false":::](../../hello-how-it-works-technology.md#key-trust "This trust type uses a raw key to authenticate the users to Active Directory. It's not required to issue certificates to users, but it's required to deploy certificates to domain controllers")

3
windows/security/identity-protection/hello-for-business/includes/unpublish-superseded-templates.md → windows/security/identity-protection/hello-for-business/deploy/includes/unpublish-superseded-templates.md
View File

@ -1,5 +1,5 @@
---
ms.date: 12/28/2022
ms.date: 12/15/2023
ms.topic: include
---
@ -15,4 +15,3 @@ Sign in to the CA or management workstation with *Enterprise Administrator* equi
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

27
windows/security/identity-protection/hello-for-business/deploy/includes/web-server-certificate-template.md Normal file
View File

@ -0,0 +1,27 @@
---
ms.date: 12/15/2023
ms.topic: include
---
### Configure an internal web server certificate template
Windows clients communicate with AD FS via HTTPS. To meet this need, a *server authentication* certificate must be issued to all the nodes in the AD FS farm. On-premises deployments can use a *server authentication* certificate issued by the enterprise PKI. A *server authentication* certificate template must be configured, so the AD FS nodes can request a certificate.
Sign in to a CA or management workstations with *Domain Administrator* equivalent credentials.
1. Open the **Certification Authority** management console
1. Right-click **Certificate Templates > Manage**
1. In the **Certificate Template Console**, right-click the **Web Server** template in the details pane and select **Duplicate Template**
1. Use the following table to configure the template:
| Tab Name | Configurations |
|--|--|
| *Compatibility* | <ul><li>Clear the **Show resulting changes** check box</li><li>Select **Windows Server 2016** from the *Certification Authority list*</li><li>Select **Windows 10 / Windows Server 2016** from the *Certification Recipient list*</li></ul> |
| *General* | <ul><li>Specify a **Template display name**, for example *Internal Web Server*</li><li>Set the validity period to the desired value</li><li>Take note of the template name for later, which should be the same as the Template display name minus spaces</li></ul> |
| *Request Handling* | Select **Allow private key to be exported** |
| *Subject Name* | Select **Supply in the request** |
| *Security* | Add **Domain Computers** with **Enroll** access |
| *Cryptography* | <ul><li>Set the *Provider Category* to **Key Storage Provider**</li><li>Set the *Algorithm name* to **RSA**</li><li>Set the *minimum key size* to **2048**</li><li>Set the *Request hash* to **SHA256**</li> |
1. Select **OK** to finalize your changes and create the new template
1. Close the console

41
windows/security/identity-protection/hello-for-business/hello-deployment-guide.md → windows/security/identity-protection/hello-for-business/deploy/index.md
View File

@ -3,16 +3,18 @@ title: Windows Hello for Business Deployment Overview
description: Use this deployment guide to successfully deploy Windows Hello for Business in an existing environment.
ms.date: 02/15/2022
ms.topic: overview
appliesto:
---
# Windows Hello for Business Deployment Overview
Windows Hello for Business is the springboard to a world without passwords. It replaces username and password sign-in to Windows with strong user authentication based on an asymmetric key pair.
This deployment overview is to guide you through deploying Windows Hello for Business. Your first step should be to use the Passwordless Wizard in the [Microsoft 365 admin center](https://admin.microsoft.com/AdminPortal/Home#/modernonboarding/passwordlesssetup) or the [Planning a Windows Hello for Business Deployment](hello-planning-guide.md) guide to determine the right deployment model for your organization.
This deployment overview is to guide you through deploying Windows Hello for Business. Your first step should be to use the Passwordless Wizard in the [Microsoft 365 admin center](https://admin.microsoft.com/AdminPortal/Home#/modernonboarding/passwordlesssetup) or the [Planning a Windows Hello for Business Deployment](../hello-planning-guide.md) guide to determine the right deployment model for your organization.
Once you've chosen a deployment model, the deployment guide for that model will provide you with the information needed to successfully deploy Windows Hello for Business in your environment. Read the [Windows Hello for Business Deployment Prerequisite Overview](hello-identity-verification.md) for a summary of the prerequisites for each different Windows Hello for Business deployment model.
Once you've chosen a deployment model, the deployment guide for that model will provide you with the information needed to successfully deploy Windows Hello for Business in your environment. Read the [Windows Hello for Business Deployment Prerequisite Overview](requirements.md) for a summary of the prerequisites for each different Windows Hello for Business deployment model.
## Assumptions
## Requirements
This guide assumes that baseline infrastructure exists which meets the requirements for your deployment. For either hybrid or on-premises deployments, it is expected that you have:
@ -21,12 +23,12 @@ This guide assumes that baseline infrastructure exists which meets the requireme
- Multi-factor Authentication is required during Windows Hello for Business provisioning
- Proper name resolution, both internal and external names
- Active Directory and an adequate number of domain controllers per site to support authentication
- Active Directory Certificate Services 2012 or later (Note: certificate services are not needed for cloud Kerberos trust deployments)
- Active Directory Certificate Services 2012 or later (Note: certificate services aren't needed for cloud Kerberos trust deployments)
- One or more workstation computers running Windows 10, version 1703 or later
If you are installing a server role for the first time, ensure the appropriate server operating system is installed, updated with the latest patches, and joined to the domain. This document provides guidance to install and configure the specific roles on that server.
If you're installing a server role for the first time, ensure the appropriate server operating system is installed, updated with the latest patches, and joined to the domain. This document provides guidance to install and configure the specific roles on that server.
Do not begin your deployment until the hosting servers and infrastructure (not roles) identified in your prerequisite worksheet are configured and properly working.
Don't begin your deployment until the hosting servers and infrastructure (not roles) identified in your prerequisite worksheet are configured and properly working.
## Deployment and trust models
@ -36,27 +38,28 @@ Hybrid deployments are for enterprises that use Microsoft Entra ID. On-premises
The trust model determines how you want users to authenticate to the on-premises Active Directory:
- The key-trust model is for enterprises who do not want to issue end-entity certificates to their users and have an adequate number of 2016 domain controllers in each site to support authentication. This still requires Active Directory Certificate Services for domain controller certificates.
- The cloud-trust model is also for hybrid enterprises who do not want to issue end-entity certificates to their users and have an adequate number of 2016 domain controllers in each site to support authentication. This trust model is simpler to deploy than key trust and does not require Active Directory Certificate Services. We recommend using **cloud Kerberos trust** instead of **Key Trust** if the clients in your enterprise support it.
- The key-trust model is for enterprises who don't want to issue end-entity certificates to their users and have an adequate number of 2016 domain controllers in each site to support authentication. This still requires Active Directory Certificate Services for domain controller certificates.
- The cloud-trust model is also for hybrid enterprises who don't want to issue end-entity certificates to their users and have an adequate number of 2016 domain controllers in each site to support authentication. This trust model is simpler to deploy than key trust and doesn't require Active Directory Certificate Services. We recommend using **cloud Kerberos trust** instead of **Key Trust** if the clients in your enterprise support it.
- The certificate-trust model is for enterprises that *do* want to issue end-entity certificates to their users and have the benefits of certificate expiration and renewal, similar to how smart cards work today.
- The certificate trust model also supports enterprises which are not ready to deploy Windows Server 2016 Domain Controllers.
- The certificate trust model also supports enterprises, which aren't ready to deploy Windows Server 2016 Domain Controllers.
> [!Note]
> RDP does not support authentication with Windows Hello for Business Key Trust or cloud Kerberos trust deployments as a supplied credential. RDP is only supported with certificate trust deployments as a supplied credential at this time. Windows Hello for Business Key Trust and cloud Kerberos trust can be used with [Remote Credential Guard](../remote-credential-guard.md).
> [!NOTE]
> RDP does not support authentication with Windows Hello for Business Key Trust or cloud Kerberos trust deployments as a supplied credential. RDP is only supported with certificate trust deployments as a supplied credential at this time. Windows Hello for Business Key Trust and cloud Kerberos trust can be used with [Remote Credential Guard](../../remote-credential-guard.md).
Following are the various deployment guides and models included in this topic:
- [Microsoft Entra hybrid joined cloud Kerberos trust Deployment](hello-hybrid-cloud-kerberos-trust.md)
- [Microsoft Entra hybrid joined Key Trust Deployment](hello-hybrid-key-trust.md)
- [Microsoft Entra hybrid joined Certificate Trust Deployment](hello-hybrid-cert-trust.md)
- [Microsoft Entra join Single Sign-on Deployment Guides](hello-hybrid-aadj-sso.md)
- [On Premises Key Trust Deployment](hello-deployment-key-trust.md)
- [On Premises Certificate Trust Deployment](hello-deployment-cert-trust.md)
- [Microsoft Entra hybrid joined cloud Kerberos trust Deployment](hybrid-cloud-kerberos-trust.md)
- [Microsoft Entra hybrid joined Key Trust Deployment](hybrid-key-trust.md)
- [Microsoft Entra hybrid joined Certificate Trust Deployment](hybrid-cert-trust.md)
- [Microsoft Entra join Single Sign-on Deployment Guides](../hello-hybrid-aadj-sso.md)
- [On Premises Key Trust Deployment](hybrid-cloud-kerberos-trust.md)
- [On Premises Certificate Trust Deployment](on-premises-cert-trust.md)
For Windows Hello for Business hybrid [certificate trust prerequisites](/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust#directory-synchronization) and [key trust prerequisites](/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust#directory-synchronization) deployments, you will need Microsoft Entra Connect to synchronize user accounts in the on-premises Active Directory with Microsoft Entra ID. For on-premises deployments, both key and certificate trust, use the Azure MFA server where the credentials are not synchronized to Microsoft Entra ID. Learn how to [deploy Multifactor Authentication Services (MFA) for key trust](hello-key-trust-validate-deploy-mfa.md) and [for certificate trust](hello-cert-trust-validate-deploy-mfa.md) deployments.
For Windows Hello for Business hybrid [certificate trust prerequisites](/windows/security/identity-protection/hello-for-business/deploy/hybrid-cert-trust#directory-synchronization) and [key trust prerequisites](/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust#directory-synchronization) deployments, you'll need Microsoft Entra Connect to synchronize user accounts in the on-premises Active Directory with Microsoft Entra ID. For on-premises deployments, both key and certificate trust, use the Azure MFA server where the credentials aren't synchronized to Microsoft Entra ID. Learn how to [deploy Multifactor Authentication Services (MFA) for key trust](on-premises-key-trust-mfa.md) and [for certificate trust](on-premises-cert-trust-mfa.md) deployments.
## Provisioning
Windows Hello for Business provisioning begins immediately after the user has signed in, after the user profile is loaded, but before the user receives their desktop. Windows only launches the provisioning experience if all the prerequisite checks pass. You can determine the status of the prerequisite checks by viewing the **User Device Registration** in the **Event Viewer** under **Applications and Services Logs\Microsoft\Windows**.
Note that you need to allow access to the URL account.microsoft.com to initiate Windows Hello for Business provisioning. This URL launches the subsequent steps in the provisioning process and is required to successfully complete Windows Hello for Business provisioning. This URL does not require any authentication and as such, does not collect any user data.
> [!NOTE]
> You must allow access to the URL `account.microsoft.com` to initiate Windows Hello for Business provisioning. This URL launches the subsequent steps in the provisioning process and is required to successfully complete Windows Hello for Business provisioning. This URL doesn't require any authentication and as such, doesn't collect any user data.

14
windows/security/identity-protection/hello-for-business/hello-cert-trust-adfs.md → windows/security/identity-protection/hello-for-business/deploy/on-premises-cert-trust-adfs.md
View File

@ -1,7 +1,7 @@
---
title: Prepare and deploy Active Directory Federation Services in an on-premises certificate trust model
description: Learn how to configure Active Directory Federation Services to support the Windows Hello for Business on-premises certificate trust model.
ms.date: 09/07/2023
ms.date: 12/15/2023
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
@ -10,9 +10,10 @@ appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016</a>
ms.topic: tutorial
---
# Prepare and deploy Active Directory Federation Services - on-premises certificate trust
[!INCLUDE [hello-on-premises-cert-trust](./includes/hello-on-premises-cert-trust.md)]
[!INCLUDE [apply-to-on-premises-cert-trust-entra](includes/apply-to-on-premises-cert-trust-entra.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*.
@ -29,6 +30,7 @@ Prepare the AD FS deployment by installing and **updating** two Windows Servers.
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*)
@ -50,7 +52,7 @@ Sign-in the federation server with *domain administrator* equivalent credentials
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.":::
:::image type="content" source="images/hello-internal-web-server-cert.png" lightbox="images/hello-internal-web-server-cert.png" alt-text="Screenshot that shows 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**
@ -159,11 +161,11 @@ Sign-in to the federation server with *Enterprise Administrator* equivalent cred
1. In the details pane, select **Configure device registration**
1. In the **Configure Device Registration** dialog, Select **OK**
:::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.":::
:::image type="content" source="images/adfs-device-registration.png" lightbox="images/adfs-device-registration.png" alt-text="Screenshot that shows AD FS device registration: configuration of the service connection point.":::
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.
:::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.":::
:::image type="content" source="images/adfs-scp.png" lightbox="images/adfs-scp.png" alt-text="Screenshot that shows AD FS device registration: service connection point object created by AD FS.":::
## Review to validate the AD FS and Active Directory configuration
@ -318,4 +320,4 @@ Each file in this folder represents a certificate in the service account's Perso
For detailed information about the certificate, use `Certutil -q -v <certificateThumbprintFileName>`.
> [!div class="nextstepaction"]
> [Next: validate and deploy multi-factor authentication (MFA)](hello-cert-trust-validate-deploy-mfa.md)
> [Next: validate and deploy multi-factor authentication (MFA) >](on-premises-cert-trust-mfa.md)

14
windows/security/identity-protection/hello-for-business/hello-cert-trust-policy-settings.md → windows/security/identity-protection/hello-for-business/deploy/on-premises-cert-trust-enroll.md
View File

@ -1,14 +1,22 @@
---
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.date: 09/07/2023
ms.date: 12/15/2023
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2022</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2019</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016</a>
ms.topic: tutorial
---
# Configure Windows Hello for Business group policy settings - on-premises certificate Trust
[!INCLUDE [hello-on-premises-cert-trust](./includes/hello-on-premises-cert-trust.md)]
[!INCLUDE [apply-to-on-premises-cert-trust-entra](includes/apply-to-on-premises-cert-trust-entra.md)]
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
@ -72,7 +80,7 @@ The application of the Windows Hello for Business Group Policy object uses secur
## Other Related Group Policy settings
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.
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

6
windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-deploy-mfa.md → windows/security/identity-protection/hello-for-business/deploy/on-premises-cert-trust-mfa.md
View File

@ -1,7 +1,7 @@
---
title: Validate and Deploy MFA for Windows Hello for Business with certificate trust
description: Validate and deploy multifactor authentication (MFA) for Windows Hello for Business in an on-premises certificate trust model.
ms.date: 09/07/2023
ms.date: 12/15/2023
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
@ -13,7 +13,7 @@ ms.topic: tutorial
# Validate and deploy multifactor authentication - on-premises certificate trust
[!INCLUDE [hello-on-premises-cert-trust](./includes/hello-on-premises-cert-trust.md)]
[!INCLUDE [apply-to-on-premises-cert-trust-entra](includes/apply-to-on-premises-cert-trust-entra.md)]
Windows Hello for Business requires users perform multifactor authentication (MFA) prior to enroll in the service. On-premises deployments can use, as MFA option:
@ -28,4 +28,4 @@ For information about third-party authentication methods, see [Configure Additio
Follow the integration and deployment guide for the authentication provider you plan to integrate to AD FS. Make sure that the authentication provider is selected as a multifactor 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)
> [Next: configure Windows Hello for Business Policy settings >](on-premises-cert-trust-enroll.md)

7
windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-pki.md → windows/security/identity-protection/hello-for-business/deploy/on-premises-cert-trust-pki.md
View File

@ -1,7 +1,7 @@
---
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: 09/07/2023
ms.date: 12/15/2023
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
@ -10,9 +10,10 @@ appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016</a>
ms.topic: tutorial
---
# Configure and validate the Public Key Infrastructure - on-premises certificate trust
[!INCLUDE [hello-on-premises-cert-trust](./includes/hello-on-premises-cert-trust.md)]
[!INCLUDE [apply-to-on-premises-cert-trust-entra](includes/apply-to-on-premises-cert-trust-entra.md)]
Windows Hello for Business must have a Public Key Infrastructure (PKI) when using the *key trust* or *certificate trust* models. The domain controllers must have a certificate, which serves as a root of trust for clients. The certificate ensures that clients don't communicate with rogue domain controllers. The certificate trust model extends certificate issuance to client computers. During Windows Hello for Business provisioning, the user receives a sign-in certificate.
@ -56,4 +57,4 @@ Sign in to the CA or management workstations with **Enterprise Admin** equivalen
[!INCLUDE [dc-certificate-validate](includes/dc-certificate-validate.md)]
> [!div class="nextstepaction"]
> [Next: prepare and deploy AD FS >](hello-cert-trust-adfs.md)
> [Next: prepare and deploy AD FS >](on-premises-cert-trust-adfs.md)

43
windows/security/identity-protection/hello-for-business/deploy/on-premises-cert-trust.md Normal file
View File

@ -0,0 +1,43 @@
---
title: 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/15/2023
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2022</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2019</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016</a>
ms.topic: tutorial
---
# Deployment guide for the on-premises certificate trust model
[!INCLUDE [apply-to-on-premises-cert-trust-entra](includes/apply-to-on-premises-cert-trust-entra.md)]
Windows Hello for Business replaces username and password authentication to Windows with an asymmetric key pair. This deployment guide provides the information to deploy Windows Hello for Business in an on-premises environment.
There are four steps to deploying Windows Hello for Business in an on-premises certificate trust model:
1. [Validate and configure a PKI](on-premises-cert-trust-pki.md)
1. [Prepare and deploy AD FS](on-premises-cert-trust-adfs.md)
1. [Validate and deploy multi-factor authentication (MFA)](on-premises-cert-trust-mfa.md)
1. [Configure Windows Hello for Business Policy settings](on-premises-cert-trust-enroll.md)
## Create the Windows Hello for Business Users security group
While this is not a required step, it is recommended to create a security group to simplify the deployment.
The *Windows Hello for Business Users* group is used to make it easy to deploy Windows Hello for Business in phases. You assign certificate templates and 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.
Sign-in to a domain controller or to a management workstation with a *Domain Administrator* 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**
> [!div class="nextstepaction"]
> [Next: validate and configure a PKI >](on-premises-cert-trust-pki.md)

4
windows/security/identity-protection/hello-for-business/hello-key-trust-adfs.md → windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust-adfs.md
View File

@ -12,7 +12,7 @@ ms.topic: tutorial
---
# Prepare and deploy Active Directory Federation Services - on-premises key trust
[!INCLUDE [hello-on-premises-key-trust](./includes/hello-on-premises-key-trust.md)]
[!INCLUDE [apply-to-on-premises-key-trust](includes/apply-to-on-premises-key-trust.md)]
Windows Hello for Business works exclusively with the Active Directory Federation Service (AD FS) role included with Windows Server. The on-premises key trust deployment model uses AD FS for *key registration* and *device registration*.
@ -261,4 +261,4 @@ Before you continue with the deployment, validate your deployment progress by re
> * Confirm you created and deployed the Intranet Zone settings to prevent double authentication to the federation server
> [!div class="nextstepaction"]
> [Next: validate and deploy multi-factor authentication (MFA)](hello-key-trust-validate-deploy-mfa.md)
> [Next: validate and deploy multi-factor authentication (MFA)](on-premises-key-trust-mfa.md)

2
windows/security/identity-protection/hello-for-business/hello-key-trust-policy-settings.md → windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust-enroll.md
View File

@ -9,7 +9,7 @@ ms.topic: tutorial
---
# Configure Windows Hello for Business group policy settings - on-premises key trust
[!INCLUDE [hello-on-premises-key-trust](./includes/hello-on-premises-key-trust.md)]
[!INCLUDE [apply-to-on-premises-key-trust](includes/apply-to-on-premises-key-trust.md)]
On-premises key trust deployments of Windows Hello for Business need one Group Policy setting: *Enable Windows Hello for Business*.
The Group Policy setting determines whether users are allowed, and prompted, to enroll for Windows Hello for Business. It can be configured for computers or users.

4
windows/security/identity-protection/hello-for-business/hello-key-trust-validate-deploy-mfa.md → windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust-mfa.md
View File

@ -13,7 +13,7 @@ ms.topic: tutorial
# Validate and deploy multifactor authentication - on-premises key trust
[!INCLUDE [hello-on-premises-key-trust](./includes/hello-on-premises-key-trust.md)]
[!INCLUDE [apply-to-on-premises-key-trust](includes/apply-to-on-premises-key-trust.md)]
Windows Hello for Business requires users perform multifactor authentication (MFA) prior to enroll in the service. On-premises deployments can use, as MFA option:
@ -29,4 +29,4 @@ For information on available third-party authentication methods see [Configure A
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 multifactor 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-key-trust-policy-settings.md)
> [Next: configure Windows Hello for Business Policy settings](on-premises-key-trust-enroll.md)

4
windows/security/identity-protection/hello-for-business/hello-key-trust-validate-pki.md → windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust-pki.md
View File

@ -12,7 +12,7 @@ ms.topic: tutorial
---
# Configure and validate the Public Key Infrastructure - on-premises key trust
[!INCLUDE [hello-on-premises-key-trust](./includes/hello-on-premises-key-trust.md)]
[!INCLUDE [apply-to-on-premises-key-trust](includes/apply-to-on-premises-key-trust.md)]
Windows Hello for Business must have a Public Key Infrastructure (PKI) when using the *key trust* or *certificate trust* models. The domain controllers must have a certificate, which serves as a root of trust for clients. The certificate ensures that clients don't communicate with rogue domain controllers.
@ -52,4 +52,4 @@ Sign in to the CA or management workstations with **Enterprise Admin** equivalen
[!INCLUDE [dc-certificate-validate](includes/dc-certificate-validate.md)]
> [!div class="nextstepaction"]
> [Next: prepare and deploy AD FS >](hello-key-trust-adfs.md)
> [Next: prepare and deploy AD FS >](on-premises-key-trust-adfs.md)

35
windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust.md Normal file
View File

@ -0,0 +1,35 @@
---
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
ms.topic: tutorial
---
# Deployment guide overview - on-premises key trust
[!INCLUDE [apply-to-on-premises-key-trust](includes/apply-to-on-premises-key-trust.md)]
Windows Hello for Business replaces username and password authentication to Windows with an asymmetric key pair. This deployment guide provides the information to deploy Windows Hello for Business in an on-premises environment:
1. [Validate and configure a PKI](on-premises-key-trust-pki.md)
1. [Prepare and deploy AD FS](on-premises-key-trust-adfs.md)
1. [Validate and deploy multifactor authentication (MFA)](on-premises-key-trust-mfa.md)
1. [Configure Windows Hello for Business Policy settings](on-premises-key-trust-enroll.md)
## Create the Windows Hello for Business Users security group
While this isn't a required step, it's recommended to create a security group to simplify the deployment.
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.
Sign-in to a domain controller or to a management workstation with a *Domain Administrator* 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**
> [!div class="nextstepaction"]
> [Next: validate and configure PKI >](on-premises-key-trust-pki.md)

0
windows/security/identity-protection/hello-for-business/hello-identity-verification.md → windows/security/identity-protection/hello-for-business/deploy/requirements.md
View File

77
windows/security/identity-protection/hello-for-business/deploy/toc.yml Normal file
View File

@ -0,0 +1,77 @@
items:
- name: Windows Hello for Business deployment overview
href: index.md
- name: Deployment prerequisite overview
href: requirements.md
- name: Cloud-only deployment
href: cloud.md
- name: Hybrid deployments
items:
- name: Cloud Kerberos trust deployment
items:
- name: Overview
href: hybrid-cloud-kerberos-trust.md
displayName: cloud Kerberos trust
- name: Configure and provision Windows Hello for Business
href: hybrid-cloud-kerberos-trust-enroll.md
displayName: cloud Kerberos trust
- name: Key trust deployment
items:
- name: Overview
href: hybrid-key-trust.md
displayName: key trust
- name: Configure and validate the PKI
href: hybrid-key-trust-pki.md
displayName: key trust
- name: Configure and provision Windows Hello for Business
href: hybrid-key-trust-enroll.md
displayName: key trust
- name: Configure SSO for Microsoft Entra joined devices
href: ../hello-hybrid-aadj-sso.md
displayName: key trust
- name: Certificate trust deployment
items:
- name: Overview
href: hybrid-cert-trust.md
displayName: certificate trust
- name: Configure and validate Public Key Infrastructure (PKI)
href: hybrid-cert-trust-pki.md
displayName: certificate trust
- name: Configure AD FS
href: hybrid-cert-trust-adfs.md
displayName: certificate trust
- name: Configure and enroll in Windows Hello for Business
href: hybrid-cert-trust-enroll.md
displayName: certificate trust
- name: Configure SSO for Microsoft Entra joined devices
href: ../hello-hybrid-aadj-sso.md
displayName: certificate trust
- name: Deploy certificates to Microsoft Entra joined devices
href: ../hello-hybrid-aadj-sso-cert.md
displayName: certificate trust
- name: On-premises deployments
items:
- name: Key trust deployment
items:
- name: Overview
href: hybrid-cloud-kerberos-trust.md
- name: Configure and validate the PKI
href: on-premises-key-trust-pki.md
- name: Prepare and deploy Active Directory Federation Services (AD FS)
href: on-premises-key-trust-adfs.md
- name: Validate and deploy multi-factor authentication (MFA) services
href: on-premises-key-trust-mfa.md
- name: Configure Windows Hello for Business policy settings
href: on-premises-key-trust-enroll.md
- name: Certificate trust deployment
items:
- name: Overview
href: on-premises-cert-trust.md
- name: Configure and validate Public Key Infrastructure (PKI)
href: on-premises-cert-trust-pki.md
- name: Prepare and Deploy Active Directory Federation Services (AD FS)
href: on-premises-cert-trust-adfs.md
- name: Validate and deploy multi-factor authentication (MFA)
href: on-premises-cert-trust-mfa.md
- name: Configure and enroll in Windows Hello for Business
href: on-premises-cert-trust-enroll.md

99
windows/security/identity-protection/hello-for-business/hello-adequate-domain-controllers.md
View File

@ -1,99 +0,0 @@
---
title: Plan an adequate number of Domain Controllers for Windows Hello for Business deployments
description: Learn how to plan for an adequate number of Domain Controllers to support Windows Hello for Business deployments.
ms.date: 03/10/2023
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2022</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2019</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016</a>
ms.topic: conceptual
---
# Plan an adequate number of Domain Controllers for Windows Hello for Business deployments
> [!NOTE]
>There was an issue with key trust authentication on Windows Server 2019. To fix it, refer to [KB4487044](https://support.microsoft.com/help/4487044/windows-10-update-kb4487044).
## How many is adequate
How can you find out how many domain controllers are needed? You can use performance monitoring on your domain controllers to determine existing authentication traffic. Windows Server 2016 and above includes the KDC AS Requests performance counter. You can use this counter to determine how much of a domain controller's load is due to initial Kerberos authentication. It's important to remember that authentication for a Windows Hello for Business key trust deployment does not affect Kerberos authentication - it remains unchanged.
Windows 10 or Windows 11 accomplishes Windows Hello for Business key trust authentication by mapping an Active Directory user account to one or more public keys. This mapping occurs on the domain controller, which is why the deployment needs Windows Server 2016 or later domain controllers. Public key mapping is only supported by Windows Server 2016 domain controllers and above. Therefore, users in a key trust deployment must authenticate to a Windows Server 2016 and above domain controller.
Determining an adequate number of Windows Server domain controllers is important to ensure you have enough domain controllers to satisfy all authentication requests, including users mapped with public key trust. What many administrators do not realize is that adding a domain controller that supports public key mapping (in this case Windows Server 2016 or later) to a deployment of existing domain controllers which do not support public key mapping (Windows Server 2008R2, Windows Server 2012R2) instantly makes that single domain controller susceptible to carrying the most load, or what is commonly referred to as "piling on". To illustrate the "piling on" concept, consider the following scenario:
Consider a controlled environment where there are 1000 client computers and the authentication load of these 1000 client computers is evenly distributed across 10 domain controllers in the environment. The Kerberos AS requests load would look something like the following:
![dc-chart1.](images/plan/dc-chart1.png)
The environment changes. The first change includes DC1 upgraded to Windows Server 2016 or later to support Windows Hello for Business key-trust authentication. Next, 100 clients enroll for Windows Hello for Business using the public key trust deployment. Given all other factors stay constant, the authentication would now look like the following:
![dc-chart2.](images/plan/dc-chart2.png)
The Windows Server 2016 or later domain controller is handling 100 percent of all public key trust authentication. However, it is also handling 10 percent of password authentication. Why? This behavior occurs because domain controllers 2 - 10 only support password and certificate trust authentication; only a Windows Server 2016 and above domain controller supports public key trust authentication. The Windows Server 2016 and above domain controller still understands how to authenticate password and certificate trust authentication and will continue to share the load of authenticating those clients. Because DC1 can handle all forms of authentication, it will bear more of the authentication load, and easily become overloaded. What if another Windows Server 2016 or later domain controller is added, but without deploying Windows Hello for Business to any more clients?
![dc-chart3.](images/plan/dc-chart3.png)
Upgrading another domain controller to Windows Server 2016 or later distributes the public key trust authentication across two domain controllers - each supporting 50 percent of the load. But it doesn't change the distribution of password and certificate trust authentication. Both Windows Server 2019 domain controllers still share 10 percent of this load. Now look at the scenario when half of the domain controllers are upgraded to Windows Server 2016 or later, but the number of Windows Hello for Business clients remains the same.
![dc-chart4.](images/plan/dc-chart4.png)
Domain controllers 1 through 5 now share the public key trust authentication load where each domain controller handles 20 percent of the public key trust load but they each still handle 10 percent of the password and certificate trust authentication. These domain controllers still have a heavier load than domain controllers 6 through 10; however, the load is adequately distributed. Now look the scenario when half of the client computers are upgraded to Windows Hello for Business using a key-trust deployment.
![dc-chart5.](images/plan/dc-chart5.png)
You'll notice the distribution did not change. Each Windows Server 2016 or later domain controller handles 20 percent of the public key trust authentication. However, increasing the volume of authentication (by increasing the number of clients) increases the amount of work that is represented by the same 20 percent. In the previous example, 20 percent of public key trust authentication equated to a volume of 20 authentications per domain controller capable of public key trust authentication. However, with upgraded clients, that same 20 percent represents a volume of 100 public key trust authentications per public key trust capable domain controller. Also, the distribution of non-public key trust authentication remained at 10 percent, but the volume of password and certificate trust authentications decreased across the older domain controllers.
There are several conclusions here:
- Upgrading domain controllers changes the distribution of new authentication, but doesn't change the distribution of older authentication.
- Upgrading domain controllers does not affect the distribution of password and certificate trust authentication because newer domain controllers can support password and certificate trust authentication.
- Upgraded domain controllers typically carry a heavier authentication load than down-level domain controllers because they support more forms of authentication.
- Upgrading clients to Windows Hello for Business, increases the volume of public key trust authentication distributed across domain controllers which support it and, reduces the volume of password and certificate trust authentication across all domain controllers
- Upgrading clients to Windows Hello for Business but does not affect the distribution of authentication; only the volume of authentication.
The preceding was an example to show why it's unrealistic to have a "one-size-fits-all" number to describe what "an adequate amount" means. In the real world, authentication is not evenly distributed across domain controllers.
## Determining total AS Request load
Each organization needs to have a baseline of the AS request load that occurs in their environment. Windows Server provides the KDC AS Requests performance counter that helps you determine this.
Pick a site where you plan to upgrade the clients to Windows Hello for Business public key trust. Pick a time when authentication traffic is most significant--Monday morning is great time as everyone is returning to the office. Enable the performance counter on *all* the domain controllers in that site. Collect KDC AS Requests performance counters for two hours:
- A half-hour before you expect initial authentication (sign-ins and unlocks) to be significant
- The hour you believe initial authentication to be significant
- And a half-hour after you expect initial authentication to be significant
For example, if employees are scheduled to come into the office at 9:00am. Your performance capture should begin at 8:30am and end at 10:30am. Ensure your performance logs do not wrap the data. You want to see authentication trend upward, peak, and trend downward.
> [!NOTE]
> To capture all the authentication traffic. Ensure that all computers are powered down to get the most accurate authentication information (computers and services authenticate at first power up--you need to consider this authentication in your evaluation).
Aggregate the performance data of all domain controllers. Look for the maximum KDC AS Requests for each domain controller. Find the median time when the maximum number of requests occurred for the site, this should represent when the site is experiencing the highest amount of authentication.
Add the number of authentications for each domain controller for the median time. You now have the total authentication for the site during a peak time. Using this metric, you can determine the distribution of authentication across the domain controllers in the site by dividing the domain controller's authentication number for the median time by the total authentication. Multiply the quotient by 10 to convert the distribution to a percentage. To validate your math, all the distributions should equal 100 percent.
Review the distribution of authentication. Hopefully, none of these are above 70 percent. It's always good to reserve some capacity for the unexpected. Also, the primary purposes of a domain controller are to provide authentication and handle Active Directory operations. Identify domain controllers with lower distributions of authentication as potential candidates for the initial domain controller upgrades in conjunction with a reasonable distribution of clients provisioned for Windows Hello for Business.
## Monitoring Authentication
Using the same methods described above, monitor the Kerberos authentication after upgrading a domain controller and your first phase of Windows Hello for Business deployments. Make note of the delta of authentication before and after upgrading the domain controller to Windows Server 2016 or newer. This delta is representative of authentication resulting from the first phase of your Windows Hello for Business clients. It gives you a baseline for your environment to where you can form a statement such as:
```"Every n Windows Hello for Business clients results in x percentage of key-trust authentication."```
Where *n* equals the number of clients you switched to Windows Hello for Business and *x* equals the increased percentage of authentication from the upgraded domain controller. Armed with this information, you can apply the observations of upgrading domain controllers and increasing Windows Hello for Business client count to appropriately phase your deployment.
Remember, increasing the number of clients changes the volume of authentication distributed across the Windows Server 2016 or newer domain controllers. If there is only one Windows Server 2016 or newer domain controller, there's no distribution and you are simply increasing the volume of authentication for which THAT domain controller is responsible.
Increasing the number of domain controllers distributes the volume of authentication, but doesn't change it. Therefore, as you add more domain controllers, the burden of authentication, for which each domain controller is responsible, decreases. Upgrading two domain controller changes the distribution to 50 percent. Upgrading three domain controllers changes the distribution to 33 percent, and so on.
## Strategy
The simplest strategy you can employ is to upgrade one domain controller and monitor the single domain controller as you continue to phase in new Windows Hello for Business key-trust clients until it reaches a 70 or 80 percent threshold.
Then, upgrade a second domain controller. Monitor the authentication on both domain controllers to determine how the authentication distributes between the two domain controllers. Introduce more Windows Hello for Business clients while monitoring the authentication on the two upgraded domain controllers. Once those reach your environment's designated capacity, you can upgrade another domain controller.
Repeat until your deployment for that site is complete. Now, monitor authentication across all your domain controllers like you did the very first time. Determine the distribution of authentication for each domain controller. Identify the percentage of distribution for which it is responsible. If a single domain controller is responsible for 70 percent of more of the authentication, you may want to consider adding a domain controller to reduce the distribution of authentication volume.
However, before considering this, ensure the high load of authentication is not a result of applications and services where their configuration has a statically-configured domain controller. Adding domain controllers will not resolve the additional authentication load problem in this scenario. Instead, manually distribute the authentication to different domain controllers among all the services or applications. Alternatively, try simply using the domain name rather than a specific domain controller. Each domain controller has an A record registered in DNS for the domain name, which DNS will round robin with each DNS query. It's not the best load balancer, however, it is a better alternative to static domain controller configurations, provided the configuration is compatible with your service or application.

2
windows/security/identity-protection/hello-for-business/hello-and-password-changes.md
View File

@ -2,7 +2,7 @@
title: Windows Hello and password changes
description: Learn the impact of changing a password when using Windows Hello.
ms.date: 03/15/2023
ms.topic: conceptual
ms.topic: concept-article
---
# Windows Hello and password changes

6
windows/security/identity-protection/hello-for-business/hello-biometrics-in-enterprise.md
View File

@ -2,7 +2,7 @@
title: Windows Hello biometrics in the enterprise
description: Windows Hello uses biometrics to authenticate users and guard against potential spoofing, through fingerprint matching and facial recognition.
ms.date: 01/12/2021
ms.topic: conceptual
ms.topic: concept-article
---
# Windows Hello biometrics in the enterprise
@ -25,9 +25,7 @@ The Windows Hello authenticator works to authenticate and allow employees onto y
Windows Hello provides many benefits, including:
- It helps to strengthen your protections against credential theft. Because an attacker must have both the device and the biometric info or PIN, it's much more difficult to gain access without the employee's knowledge.
- Employees get a simple authentication method (backed up with a PIN) that's always with them, so there's nothing to lose. No more forgetting passwords!
- Support for Windows Hello is built into the operating system so you can add additional biometric devices and policies as part of a coordinated rollout or to individual employees or groups using Group Policy or Mobile Device Management (MDM) configurations service provider (CSP) policies.<br>For more info about the available Group Policies and MDM CSPs, see the [Implement Windows Hello for Business in your organization](hello-manage-in-organization.md) topic.
## Where is Windows Hello data stored?
@ -80,7 +78,7 @@ To use Iris authentication, you'll need a [HoloLens 2 device](/hololens/). All H
## Related topics
- [Windows Hello for Business](hello-identity-verification.md)
- [Windows Hello for Business](deploy/requirements.md)
- [How Windows Hello for Business works](hello-how-it-works.md)
- [Manage Windows Hello for Business in your organization](hello-manage-in-organization.md)
- [Why a PIN is better than a password](hello-why-pin-is-better-than-password.md)

33
windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-ad-prereq.md
View File

@ -1,33 +0,0 @@
---
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: 09/07/2023
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2022</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2019</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016</a>
ms.topic: tutorial
---
# 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 requires the Windows Server 2016 Active Directory or later schema.
## Create the Windows Hello for Business Users security group
The *Windows Hello for Business Users* group is used to make it easy to deploy Windows Hello for Business in phases. You assign Group Policy 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.
Sign-in to a domain controller or to a management workstation with a *Domain Administrator* 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**
> [!div class="nextstepaction"]
> [Next: validate and configure PKI >](hello-cert-trust-validate-pki.md)

23
windows/security/identity-protection/hello-for-business/hello-deployment-cert-trust.md
View File

@ -1,23 +0,0 @@
---
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: 09/07/2023
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2022</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2019</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016</a>
ms.topic: tutorial
---
# 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 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 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)

17
windows/security/identity-protection/hello-for-business/hello-deployment-key-trust.md
View File

@ -1,17 +0,0 @@
---
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
ms.topic: tutorial
---
# 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 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)
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)

172
windows/security/identity-protection/hello-for-business/hello-deployment-rdp-certs.md
View File

@ -1,172 +0,0 @@
---
title: Deploy certificates for remote desktop sign-in
description: Learn how to deploy certificates to cloud Kerberos trust and key trust users, to enable remote desktop sign-in with supplied credentials.
ms.topic: how-to
ms.date: 07/25/2023
---
# Deploy certificates for remote desktop (RDP) sign-in
This document describes Windows Hello for Business functionalities or scenarios that apply to:
- **Deployment type:** [!INCLUDE [hybrid](./includes/hello-deployment-hybrid.md)]
- **Trust type:** [!INCLUDE [cloud-kerberos](./includes/hello-trust-cloud-kerberos.md)], [!INCLUDE [key](./includes/hello-trust-key.md)]
- **Join type:** [!INCLUDE [hello-join-aadj](./includes/hello-join-aad.md)], [!INCLUDE [hello-join-hybrid](./includes/hello-join-hybrid.md)]
---
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:
- Deploy certificates to hybrid joined devices using an on-premises Active Directory Certificate Services enrollment policy
- Deploy certificates to hybrid or Microsoft Entra joined devices using Intune
- Work with third-party PKIs
## Deploy certificates via Active Directory Certificate Services (AD CS)
> [!NOTE]
> This process is applicable to *Microsoft Entra hybrid joined* devices only.
To deploy certificates using an on-premises Active Directory Certificate Services enrollment policy, you must first create a *certificate template*, and then deploy certificates based on that template.
### Create a Windows Hello for Business certificate template
Follow these steps to create a certificate template:
1. Sign in to your issuing certificate authority (CA) and open *Server Manager*
1. Select **Tools > Certification Authority**. The Certification Authority Microsoft Management Console (MMC) opens
1. In the MMC, expand the CA name and right-click **Certificate Templates > Manage**
1. The Certificate Templates console opens. All of the certificate templates are displayed in the details pane
1. Right-click the **Smartcard Logon** template and select **Duplicate Template**
1. Use the following table to configure the template:
| Tab Name | Configurations |
| --- | --- |
| *Compatibility* | <ul><li>Clear the **Show resulting changes** check box</li><li>Select **Windows Server 2012 or Windows Server 2012 R2** from the *Certification Authority list*</li><li>Select **Windows Server 2012 or Windows Server 2012 R2** from the *Certification Recipient list*</li></ul>|
| *General* | <ul><li>Specify a **Template display name**, for example *WHfB Certificate Authentication*</li><li>Set the validity period to the desired value</li><li>Take note of the Template name for later, which should be the same as the Template display name minus spaces (*WHfBCertificateAuthentication* in this example)</li></ul>|
| *Extensions* | Verify the **Application Policies** extension includes **Smart Card Logon**|
| *Subject Name* | <ul><li> Select the **Build from this Active Directory** information button if it isn't already selected</li><li>Select **Fully distinguished name** from the **Subject name format** list if Fully distinguished name isn't already selected</li><li>Select the **User Principal Name (UPN)** check box under **Include this information in alternative subject name**</li></ul><br>**Note:** If you deploy certificates via Intune, select **Supply in the request** instead of *Build from this Active Directory*.|
|*Request Handling*|<ul><li>Set the Purpose to **Signature and smartcard logon** and select **Yes** when prompted to change the certificate purpose</li><li>Select the **Renew with same key** check box</li><li>Select **Prompt the user during enrollment**</li></ul>|
|*Cryptography*|<ul><li>Set the Provider Category to **Key Storage Provider**</li><li>Set the Algorithm name to **RSA**</li><li>Set the minimum key size to **2048**</li><li>Select **Requests must use one of the following providers**</li><li>Select **Microsoft Software Key Storage Provider**</li><li>Set the Request hash to **SHA256**</li></ul>|
|*Security*|Add the security group that you want to give **Enroll** access to. For example, if you want to give access to all users, select the **Authenticated** users group, and then select Enroll permissions for them|
1. Select **OK** to finalize your changes and create the new template. Your new template should now appear in the list of Certificate Templates
1. Close the Certificate Templates console
1. Open an elevated command prompt and change to a temporary working directory
1. Execute the following command, replacing `<TemplateName>` with the **Template display name** noted above
```cmd
certutil.exe -dstemplate <TemplateName> > <TemplateName.txt>
```
1. Open the text file created by the command above.
- Delete the last line of the output from the file that reads\
`CertUtil: -dsTemplate command completed successfully.`
- Modify the line that reads\
`pKIDefaultCSPs = "1,Microsoft Software Key Storage Provider"` to\
`pKIDefaultCSPs = "1,Microsoft Passport Key Storage Provider"`
1. Save the text file
1. Update the certificate template by executing the following command:
```cmd
certutil.exe -dsaddtemplate <TemplateName.txt>
```
1. In the Certificate Authority console, right-click **Certificate Templates**, select **New > Certificate Template to Issue**
1. From the list of templates, select the template you previously created (**WHFB Certificate Authentication**) and select **OK**. It can take some time for the template to replicate to all servers and become available in this list
1. After the template replicates, in the MMC, right-click in the Certification Authority list, select **All Tasks > Stop Service**. Right-click the name of the CA again, select **All Tasks > Start Service**
### Request a certificate
1. Sign in to a client that is Microsoft Entra hybrid joined, ensuring that the client has line of sight to a domain controller and the issuing CA
1. Open the **Certificates - Current User** Microsoft Management Console (MMC). To do so, you can execute the command `certmgr.msc`
1. In the left pane of the MMC, right-click **Personal > All Tasks > Request New Certificate…**
1. On the Certificate Enrollment screen, select **Next**
1. Under *Select Certificate Enrollment Policy*, select **Active Directory Enrollment Policy > Next**
1. Under *Request Certificates*, select the check-box for the certificate template you created in the previous section (*WHfB Certificate Authentication*) and then select **Enroll**
1. After a successful certificate request, select **Finish** on the Certificate Installation Results screen
## Deploy certificates via Intune
> [!CAUTION]
> This process is applicable to both *Microsoft Entra joined* and *Microsoft Entra hybrid joined* devices that are managed via Intune.
>
> If you deploy certificates via Intune and configure Windows Hello for Business via group policy, the devices will fail to obtain a certificate, logging the error code `0x82ab0011` in the `DeviceManagement-Enterprise-Diagnostic-Provider` log.\
> To avoid the error, configure Windows Hello for Business via Intune instead of group policy.
Deploying a certificate to Microsoft Entra joined or Microsoft Entra hybrid joined devices may be achieved using the Simple Certificate Enrollment Protocol (SCEP) or PKCS (PFX) via Intune. For guidance deploying the required infrastructure, refer to:
- [Configure infrastructure to support SCEP certificate profiles with Microsoft Intune][MEM-1]
- [Configure and use PKCS certificates with Intune][MEM-2]
Next, you should deploy the root CA certificate (and any other intermediate certificate authority certificates) to Microsoft Entra joined Devices using a *Trusted root certificate* policy with Intune. For guidance, refer to [Create trusted certificate profiles in Microsoft Intune][MEM-5].
Once these requirements are met, a policy can be configured in Intune that provisions certificates for the users on the targeted device.
### Create a policy in Intune
This section describes how to configure a SCEP policy in Intune. Similar steps can be followed to configure a PKCS policy.
1. Go to the <a href="https://go.microsoft.com/fwlink/?linkid=2109431" target="_blank"><b>Microsoft Intune admin center</b></a>
1. Select **Devices > Configuration profiles > Create profile**
1. Select **Platform > Windows 10 and later** and **Profile type > Templates > SCEP Certificate**
1. Select **Create**
1. In the *Basics* panel, provide a **Name** and, optionally, a **Description > Next**
1. In the *Configuration settings* panel, use the following table to configure the policy:
| Setting| Configurations |
| --- | --- |
|*Certificate Type*| User |
|*Subject name format* | `CN={{UserPrincipalName}}` |
|*Subject alternative name* |From the dropdown, select **User principal name (UPN)** with a value of `{{UserPrincipalName}}`
|*Certificate validity period* | Configure a value of your choosing|
|*Key storage provider (KSP)* | **Enroll to Windows Hello for Business, otherwise fail (Windows 10 and later)**
|*Key usage*| **Digital Signature**|
|*Key size (bits)* | **2048**|
|*For Hash algorithm*|**SHA-2**|
|*Root Certificate*| Select **+Root Certificate** and select the trusted certificate profile created earlier for the Root CA Certificate|
|*Extended key usage*| <ul><li>*Name:* **Smart Card Logon**</li><li>*Object Identifier:* `1.3.6.1.4.1.311.20.2.2`</li><li>*Predefined Values:* **Not configured**</li><br><li>*Name:* **Client Authentication**</li><li>*Object Identifier:* `1.3.6.1.5.5.7.3.2 `</li><li>*Predefined Values:* **Client Authentication**</li></ul>|
|*Renewal threshold (%)*|Configure a value of your choosing|
|*SCEP Server URLs*|Provide the public endpoint(s) that you configured during the deployment of your SCEP infrastructure|
1. Select **Next**
1. In the *Assignments* panel, assign the policy to a security group that contains as members the devices or users that you want to configure and select **Next**
1. In the *Applicability Rules* panel, configure issuance restrictions, if needed, and select **Next**
1. In the *Review + create* panel, review the policy configuration and select **Create**
For more information how to configure SCEP policies, see [Configure SCEP certificate profiles in Intune][MEM-3].
To configure PKCS policies, see [Configure and use PKCS certificate with Intune][MEM-4].
### Request a certificate for Intune clients
Once the Intune policy is created, targeted clients will request a certificate during their next policy refresh cycle. To validate that the certificate is present in the user store, follow these steps:
1. Sign in to a client targeted by the Intune policy
1. Open the **Certificates - Current User** Microsoft Management Console (MMC). To do so, you can execute the command `certmgr.msc`
1. In the left pane of the MMC, expand **Personal** and select **Certificates**
1. In the right-hand pane of the MMC, check for the new certificate
## Use third-party certification authorities
If you're using a non-Microsoft PKI, the certificate templates published to the on-premises Active Directory may not be available. For guidance with integration of Intune/SCEP with non-Microsoft PKI deployments, refer to [Use third-party certification authorities (CA) with SCEP in Microsoft Intune][MEM-6].
As an alternative to using SCEP or if none of the previously covered solutions will work in your environment, you can manually generate Certificate Signing Requests (CSR) for submission to your PKI. To assist with this approach, you can use the [Generate-CertificateRequest][HTTP-1] PowerShell commandlet.
The `Generate-CertificateRequest` commandlet will generate an *.inf* file for a pre-existing Windows Hello for Business key. The *.inf* can be used to generate a certificate request manually using `certreq.exe`. The commandlet will also generate a *.req* file, which can be submitted to your PKI for a certificate.
## RDP sign-in with Windows Hello for Business certificate authentication
After obtaining a certificate, users can RDP to any Windows devices in the same Active Directory forest as the user's Active Directory account.
> [!NOTE]
> The certificate chain of the issuing CA must be trusted by the target server.
1. Open the Remote Desktop Client (`mstsc.exe`) on the client where the authentication certificate has been deployed
1. Attempt an RDP session to a target server
1. Use the certificate credential protected by your Windows Hello for Business gesture to authenticate
[MEM-1]: /mem/intune/protect/certificates-scep-configure
[MEM-2]: /mem/intune/protect/certificates-pfx-configure
[MEM-3]: /mem/intune/protect/certificates-profile-scep
[MEM-4]: /mem/intune/protect/certificates-pfx-configure
[MEM-5]: /mem/intune/protect/certificates-trusted-root
[MEM-6]: /mem/intune/protect/certificate-authority-add-scep-overview
[HTTP-1]: https://www.powershellgallery.com/packages/Generate-CertificateRequest

4
windows/security/identity-protection/hello-for-business/hello-faq.yml
View File

@ -5,7 +5,7 @@ metadata:
author: paolomatarazzo
ms.author: paoloma
ms.topic: faq
ms.date: 08/03/2023
ms.date: 12/08/2023
title: Common questions about Windows Hello for Business
summary: Windows Hello for Business replaces password sign-in with strong authentication, using an asymmetric key pair. This Frequently Asked Questions (FAQ) article is intended to help you learn more about Windows Hello for Business.
@ -242,7 +242,7 @@ sections:
- attempting to access on-premises resources secured by Active Directory
- question: Can I use RDP/VDI with Windows Hello for Business cloud Kerberos trust?
answer: |
Windows Hello for Business cloud Kerberos trust can't be used as a supplied credential with RDP/VDI. Similar to key trust, cloud Kerberos trust can be used for RDP with [Remote Credential Guard](/windows/security/identity-protection/remote-credential-guard) or if a [certificate is enrolled into Windows Hello for Business](hello-deployment-rdp-certs.md) for this purpose.
Windows Hello for Business cloud Kerberos trust can't be used as a supplied credential with RDP/VDI. Similar to key trust, cloud Kerberos trust can be used for RDP with [Remote Credential Guard](/windows/security/identity-protection/remote-credential-guard) or if a [certificate is enrolled into Windows Hello for Business](rdp-sign-in.md) for this purpose.
- question: Do all my domain controllers need to be fully patched as per the prerequisites for me to use Windows Hello for Business cloud Kerberos trust?
answer: |
No, only the number necessary to handle the load from all cloud Kerberos trust devices.

2
windows/security/identity-protection/hello-for-business/hello-feature-dual-enrollment.md
View File

@ -2,7 +2,7 @@
title: Dual Enrollment
description: Learn how to configure Windows Hello for Business dual enrollment and how to configure Active Directory to support Domain Administrator enrollment.
ms.date: 07/05/2023
ms.topic: conceptual
ms.topic: how-to
---
# Dual Enrollment

47
windows/security/identity-protection/hello-for-business/hello-feature-remote-desktop.md
View File

@ -1,47 +0,0 @@
---
title: Remote Desktop
description: Learn how Windows Hello for Business supports using biometrics with remote desktop
ms.date: 09/01/2023
ms.topic: conceptual
---
# Remote Desktop
**Requirements**
- Hybrid and On-premises Windows Hello for Business deployments
- Microsoft Entra joined, Microsoft Entra hybrid joined, and Enterprise joined devices
Windows Hello for Business supports using a certificate deployed to a Windows Hello for Business container as a supplied credential to establish a remote desktop connection to a server or another device. This feature takes advantage of the redirected smart card capabilities of the remote desktop protocol. Windows Hello for Business key trust can be used with [Remote Credential Guard](../remote-credential-guard.md) to establish a remote desktop protocol connection.
Microsoft continues to investigate supporting using keys trust for supplied credentials in a future release.
## Remote Desktop with Biometrics
**Requirements**
- Hybrid and On-premises Windows Hello for Business deployments
- Microsoft Entra joined, Microsoft Entra hybrid joined, and Enterprise joined devices
- Biometric enrollments
The ability for users to authenticate to a remote desktop session using their Windows Hello for Business biometric is on by default.
### How does it work
Windows generates and stores cryptographic keys using a software component called a key storage provider (KSP). Software-based keys are created and stored using the Microsoft Software Key Storage Provider. Smart card keys are created and stored using the Microsoft Smart Card Key Storage Provider. Keys created and protected by Windows Hello for Business are created and stored using the Microsoft Passport Key Storage Provider.
A certificate on a smart card starts with creating an asymmetric key pair using the Microsoft Smart Card KSP. Windows requests a certificate based on the key pair from your enterprises issuing certificate authority, which returns a certificate that is stored in the user's Personal certificate store. The private key remains on the smart card and the public key is stored with the certificate. Metadata on the certificate (and the key) stores the key storage provider used to create the key (remember the certificate contains the public key).
The same concept applies to Windows Hello for Business, except that the keys are created using the Microsoft Passport KSP. The user's private key remains protected by the device's security module (TPM) and the user's gesture (PIN/biometric). The certificate APIs hide the complexity. When an application uses a certificate, the certificate APIs locate the keys using the saved key storage provider. The key storage providers direct the certificate APIs on which provider they use to find the private key associated with the certificate. This is how Windows knows you have a smart card certificate without the smart card inserted (and prompts you to insert the smart card).
Windows Hello for Business emulates a smart card for application compatibility, and the Microsoft Passport KSP prompts the user for their biometric gesture or PIN.
### Compatibility
Users appreciate convenience of biometrics and administrators value the security however, you may experience compatibility issues with your applications and Windows Hello for Business certificates. You can relax knowing a Group Policy setting and a [MDM URI](/windows/client-management/mdm/passportforwork-csp) exist to help you revert to the previous behavior for those users who need it.
> [!div class="mx-imgBorder"]
> ![WHFB Certificate GP Setting.](images/rdpbio/rdpbiopolicysetting.png)
> [!IMPORTANT]
> The remote desktop with biometric feature does not work with [Dual Enrollment](hello-feature-dual-enrollment.md) feature or scenarios where the user provides alternative credentials. Microsoft continues to investigate supporting the feature.

Some files were not shown because too many files have changed in this diff Show More