- Windows Autopatch adds devices to its managed database.
- Flags devices as **Active** in the **Registered** tab.
- The Microsoft Entra device ID of the device successfully registered is added into the Microsoft Cloud Managed Desktop Extension’s allowlist. Windows Autopatch installs the Microsoft Cloud Managed Desktop Extension agent once devices are registered, so the agent can communicate back to the Microsoft Cloud Managed Desktop Extension service.
- The agent is the **Modern Workplace - Autopatch Client setup** PowerShell script that was created during the Windows Autopatch tenant enrollment process. The script is executed once devices are successfully registered into the Windows Autopatch service.
|
| **Step 9: Review device registration status** | IT admins review the device registration status in both the **Registered** and **Not registered** tabs.- If the device was **successfully registered**, the device shows up in the **Registered** tab.
- If **not**, the device shows up in the **Not registered** tab.
|
| **Step 10: End of registration workflow** | This is the end of the Windows Autopatch device registration workflow. |
@@ -69,7 +69,7 @@ During the tenant enrollment process, Windows Autopatch creates two different
- [Service-based deployment ring set](../deploy/windows-autopatch-groups-overview.md#service-based-deployment-rings)
- [Software update-based deployment ring set](../deploy/windows-autopatch-groups-overview.md#software-based-deployment-rings)
-The following four Azure AD assigned groups are used to organize devices for the service-based deployment ring set:
+The following four Microsoft Entra ID assigned groups are used to organize devices for the service-based deployment ring set:
| Service-based deployment ring | Description |
| ----- | ----- |
@@ -78,7 +78,7 @@ The following four Azure AD assigned groups are used to organize devices for the
| Modern Workplace Devices-Windows Autopatch-Fast | Fast deployment ring for quick rollout and adoption |
| Modern Workplace Devices-Windows Autopatch-Broad | Final deployment ring for broad rollout into the organization |
-The five Azure AD assigned groups that are used to organize devices for the software update-based deployment ring set within the [Default Autopatch group](../deploy/windows-autopatch-groups-overview.md#default-deployment-ring-composition):
+The five Microsoft Entra ID assigned groups that are used to organize devices for the software update-based deployment ring set within the [Default Autopatch group](../deploy/windows-autopatch-groups-overview.md#default-deployment-ring-composition):
| Software updates-based deployment ring | Description |
| ----- | ----- |
@@ -158,7 +158,7 @@ If you want to move devices to different deployment rings (either service or sof
If you don't see the Ring assigned by column change to **Pending** in Step 5, check to see whether the device exists in Microsoft Intune or not by searching for it in its device blade. For more information, see [Device details in Intune](/mem/intune/remote-actions/device-inventory).
> [!WARNING]
-> Moving devices between deployment rings through directly changing Azure AD group membership isn't supported and may cause unintended configuration conflicts within the Windows Autopatch service. To avoid service interruption to devices, use the **Assign device to ring** action described previously to move devices between deployment rings.
+> Moving devices between deployment rings through directly changing Microsoft Entra group membership isn't supported and may cause unintended configuration conflicts within the Windows Autopatch service. To avoid service interruption to devices, use the **Assign device to ring** action described previously to move devices between deployment rings.
## Automated deployment ring remediation functions
diff --git a/windows/deployment/windows-autopatch/deploy/windows-autopatch-groups-manage-autopatch-groups.md b/windows/deployment/windows-autopatch/deploy/windows-autopatch-groups-manage-autopatch-groups.md
index 18ff0f2a4a..93aeb12df6 100644
--- a/windows/deployment/windows-autopatch/deploy/windows-autopatch-groups-manage-autopatch-groups.md
+++ b/windows/deployment/windows-autopatch/deploy/windows-autopatch-groups-manage-autopatch-groups.md
@@ -19,7 +19,7 @@ ms.collection:
Autopatch groups help Microsoft Cloud-Managed services meet organizations where they are in their update management journey.
-Autopatch groups is a logical container or unit that groups several [Azure AD groups](/azure/active-directory/fundamentals/active-directory-groups-view-azure-portal), and software update policies, such as [Update rings policy for Windows 10 and later](/mem/intune/protect/windows-10-update-rings) and [feature updates policy for Windows 10 and later policies](/mem/intune/protect/windows-10-feature-updates).
+Autopatch groups is a logical container or unit that groups several [Microsoft Entra groups](/azure/active-directory/fundamentals/active-directory-groups-view-azure-portal), and software update policies, such as [Update rings policy for Windows 10 and later](/mem/intune/protect/windows-10-update-rings) and [feature updates policy for Windows 10 and later policies](/mem/intune/protect/windows-10-feature-updates).
## Autopatch groups prerequisites
@@ -36,7 +36,7 @@ Before you start managing Autopatch groups, ensure you’ve met the following pr
- Windows Autopatch – DSS Policy [First]
- Windows Autopatch – DSS Policy [Fast]
- Windows Autopatch – DSS Policy [Broad]
-- Ensure the following Azure AD assigned groups are in your tenant before using Autopatch groups. **Don’t** modify the Azure AD group membership types (Assigned or Dynamic). Otherwise, the Windows Autopatch service won’t be able to read the device group membership from these groups and causes the Autopatch groups feature and other service-related operations to not work properly.
+- Ensure the following Microsoft Entra ID assigned groups are in your tenant before using Autopatch groups. **Don’t** modify the Microsoft Entra group membership types (Assigned or Dynamic). Otherwise, the Windows Autopatch service won’t be able to read the device group membership from these groups and causes the Autopatch groups feature and other service-related operations to not work properly.
- Modern Workplace Devices-Windows Autopatch-Test
- Modern Workplace Devices-Windows Autopatch-First
- Modern Workplace Devices-Windows Autopatch-Fast
@@ -46,14 +46,14 @@ 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 Azure AD 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.
- - For more information, see [assign an owner or member of a group in Azure AD](/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 Azure AD 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** Service Principal 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.
- Manage all configurations related to the operation of the service.
-- Make sure that all device-based Azure AD groups you intend to use with Autopatch groups are created prior to using the feature.
- - Review your existing Azure AD group dynamic queries and direct device memberships to avoid having device membership overlaps in between device-based Azure AD groups that are going to be used with Autopatch groups. This can help prevent device conflicts within an Autopatch group or across several Autopatch groups. **Autopatch groups doesn't support user-based Azure AD groups**.
-- Ensure devices used with your existing Azure AD groups meet [device registration prerequisite checks](../deploy/windows-autopatch-register-devices.md#prerequisites-for-device-registration) when being registered with the service. Autopatch groups register devices on your behalf, and devices can be moved to **Registered** or **Not registered** tabs in the Devices blade accordingly.
+- Make sure that all device-based Microsoft Entra groups you intend to use with Autopatch groups are created prior to using the feature.
+ - Review your existing Microsoft Entra group dynamic queries and direct device memberships to avoid having device membership overlaps in between device-based Microsoft Entra groups that are going to be used with Autopatch groups. This can help prevent device conflicts within an Autopatch group or across several Autopatch groups. **Autopatch groups doesn't support user-based Microsoft Entra groups**.
+- Ensure devices used with your existing Microsoft Entra groups meet [device registration prerequisite checks](../deploy/windows-autopatch-register-devices.md#prerequisites-for-device-registration) when being registered with the service. Autopatch groups register devices on your behalf, and devices can be moved to **Registered** or **Not registered** tabs in the Devices blade accordingly.
> [!TIP]
> [Update rings](/mem/intune/protect/windows-10-update-rings) and [feature updates](/mem/intune/protect/windows-10-feature-updates) for Windows 10 and later policies that are created and managed by Windows Autopatch can be restored using the [Policy health](../operate/windows-autopatch-policy-health-and-remediation.md) feature. For more information on remediation actions, see [restore Windows update policies](../operate/windows-autopatch-policy-health-and-remediation.md#restore-windows-update-policies).
@@ -73,12 +73,12 @@ Before you start managing Autopatch groups, ensure you’ve met the following pr
1. In **Basics** page, enter a **name** and a **description** then select **Next: Deployment rings**.
1. Enter up to 64 characters for the Autopatch group name and 150 characters maximum for the description. The Autopatch group name is appended to both the update rings and the DSS policy names that get created once the Custom Autopatch group is created.
1. In **Deployment rings** page, select **Add deployment ring** to add the number of deployment rings to the Custom Autopatch group.
-1. Each new deployment ring added must have either an Azure AD device group assigned to it, or an Azure AD group that is dynamically distributed across your deployments rings using defined percentages.
- 1. In the **Dynamic groups** area, select **Add groups** to select one or more existing device-based Azure AD groups to be used for Dynamic group distribution.
+1. Each new deployment ring added must have either a Microsoft Entra device group assigned to it, or a Microsoft Entra group that is dynamically distributed across your deployments rings using defined percentages.
+ 1. In the **Dynamic groups** area, select **Add groups** to select one or more existing device-based Microsoft Entra groups to be used for Dynamic group distribution.
1. In the **Dynamic group distribution** column, select the desired deployment ring checkbox. Then, either:
- 1. Enter the percentage of devices that should be added from the Azure AD groups selected in step 9. The percentage calculation for devices must equal to 100%, or
+ 1. Enter the percentage of devices that should be added from the Microsoft Entra groups selected in step 9. The percentage calculation for devices must equal to 100%, or
1. Select **Apply default dynamic group distribution** to use the default values.
-1. In the **Assigned group** column, select **Add group to ring** to add an existing Azure AD group to any of the defined deployment rings. The **Test** and **Last** deployment rings only support Assigned group distribution. These deployment rings don't support Dynamic distribution.
+1. In the **Assigned group** column, select **Add group to ring** to add an existing Microsoft Entra group to any of the defined deployment rings. The **Test** and **Last** deployment rings only support Assigned group distribution. These deployment rings don't support Dynamic distribution.
1. Select **Next: Windows Update settings**.
1. Select the **horizontal ellipses (…)** > **Manage deployment cadence** to [customize your gradual rollout of Windows quality and feature updates](../operate/windows-autopatch-windows-update.md). Select **Save**.
1. Select the **horizontal ellipses (…)** > **Manage notifications** to customize the end-user experience when receiving Windows updates. Select **Save**.
@@ -86,10 +86,10 @@ Before you start managing Autopatch groups, ensure you’ve met the following pr
1. Once the review is done, select **Create** to save your custom Autopatch group.
> [!CAUTION]
-> A device-based Azure AD group can only be used with one deployment ring in an Autopatch group at a time. This applies to deployment rings within the same Autopatch group and across different deployment rings across different Autopatch groups. If you try to create or edit an Autopatch group to use a device-based Azure AD group that’s been already used, you'll receive an error that prevents you from finish creating or editing the Autopatch group (Default or Custom).
+> A device-based Microsoft Entra group can only be used with one deployment ring in an Autopatch group at a time. This applies to deployment rings within the same Autopatch group and across different deployment rings across different Autopatch groups. If you try to create or edit an Autopatch group to use a device-based Microsoft Entra group that’s been already used, you'll receive an error that prevents you from finish creating or editing the Autopatch group (Default or Custom).
> [!IMPORTANT]
-> Windows Autopatch creates the device-based Azure AD assigned groups based on the choices made in the deployment ring composition page. Additionally, the service assigns the update ring policies for each deployment ring created in the Autopatch group based on the choices made in the Windows Update settings page as part of the Autopatch group guided end-user experience.
+> Windows Autopatch creates the device-based Microsoft Entra ID assigned groups based on the choices made in the deployment ring composition page. Additionally, the service assigns the update ring policies for each deployment ring created in the Autopatch group based on the choices made in the Windows Update settings page as part of the Autopatch group guided end-user experience.
## Edit the Default or a Custom Autopatch group
@@ -107,7 +107,7 @@ Before you start managing Autopatch groups, ensure you’ve met the following pr
1. Once the review is done, select **Save** to finish editing the Autopatch group.
> [!IMPORTANT]
-> Windows Autopatch creates the device-based Azure AD assigned groups based on the choices made in the deployment ring composition page. Additionally, the service assigns the update ring policies for each deployment ring created in the Autopatch group based on the choices made in the Windows Update settings page as part of the Autopatch group guided end-user experience.
+> Windows Autopatch creates the device-based Microsoft Entra ID assigned groups based on the choices made in the deployment ring composition page. Additionally, the service assigns the update ring policies for each deployment ring created in the Autopatch group based on the choices made in the Windows Update settings page as part of the Autopatch group guided end-user experience.
## Rename a Custom Autopatch group
@@ -119,7 +119,7 @@ You **can’t** rename the Default Autopatch group. However, you can rename a Cu
1. In the **New Autopatch group name**, enter the new Autopatch group name of your choice, then click **Rename group**.
> [!IMPORTANT]
-> Autopatch supports up to 64 characters for the custom Autopatch group name. Additionally, when you rename a custom Autopatch group all [update rings for Windows 10 and later policy in Intune](/mem/intune/protect/windows-10-update-rings) and [feature updates for Windows 10 and later policy in Intune](/mem/intune/protect/windows-10-feature-updates) associated with the custom Autopatch group are renamed to include the new Autopatch group name you define in its name string. Also, when renaming a custom Autopatch group all Azure AD groups representing the custom Autopatch group's deployment rings are renamed to include the new Autopatch group name you define in its name string.
+> Autopatch supports up to 64 characters for the custom Autopatch group name. Additionally, when you rename a custom Autopatch group all [update rings for Windows 10 and later policy in Intune](/mem/intune/protect/windows-10-update-rings) and [feature updates for Windows 10 and later policy in Intune](/mem/intune/protect/windows-10-feature-updates) associated with the custom Autopatch group are renamed to include the new Autopatch group name you define in its name string. Also, when renaming a custom Autopatch group all Microsoft Entra groups representing the custom Autopatch group's deployment rings are renamed to include the new Autopatch group name you define in its name string.
## Delete a Custom Autopatch group
@@ -135,12 +135,12 @@ You **can’t** delete the Default Autopatch group. However, you can delete a Cu
## Manage device conflict scenarios when using Autopatch groups
-Overlap in device membership is a common scenario when working with device-based Azure AD groups since sometimes dynamic queries can be large in scope or the same assigned device membership can be used across different Azure AD groups.
+Overlap in device membership is a common scenario when working with device-based Microsoft Entra groups since sometimes dynamic queries can be large in scope or the same assigned device membership can be used across different Microsoft Entra groups.
-Since Autopatch groups allow you to use your existing Azure AD groups to create your own deployment ring composition, the service takes on the responsibility of monitoring and automatically solving some of the device conflict scenarios that may occur.
+Since Autopatch groups allow you to use your existing Microsoft Entra groups to create your own deployment ring composition, the service takes on the responsibility of monitoring and automatically solving some of the device conflict scenarios that may occur.
> [!CAUTION]
-> A device-based Azure AD group can only be used with one deployment ring in an Autopatch group at a time. This applies to deployment rings within the same Autopatch group and across different deployment rings across different Autopatch groups. If you try to create or edit an Autopatch group to use a device-based Azure AD group that’s been already used, you'll receive an error that prevents you from creating or editing the Autopatch group (Default or Custom).
+> A device-based Microsoft Entra group can only be used with one deployment ring in an Autopatch group at a time. This applies to deployment rings within the same Autopatch group and across different deployment rings across different Autopatch groups. If you try to create or edit an Autopatch group to use a device-based Microsoft Entra group that’s been already used, you'll receive an error that prevents you from creating or editing the Autopatch group (Default or Custom).
### Device conflict in deployment rings within an Autopatch group
@@ -172,11 +172,11 @@ Device conflict across different deployment rings in different Autopatch groups
#### Device conflict prior to device registration
-When you create or edit the Custom or Default Autopatch group, Windows Autopatch checks if the devices that are part of the Azure AD groups, used in Autopatch groups’ deployment rings, are registered with the service.
+When you create or edit the Custom or Default Autopatch group, Windows Autopatch checks if the devices that are part of the Microsoft Entra groups, used in Autopatch groups’ deployment rings, are registered with the service.
| Conflict scenario | Conflict resolution |
| ----- | ----- |
-| Devices are in the Custom-to-Custom Autopatch group device conflict scenario | You must resolve this conflict.Devices will fail to register with the service and will be sent to the **Not registered** tab. You’re required to make sure the Azure AD groups that are used with the Custom Autopatch groups don’t have device membership overlaps.
|
+| Devices are in the Custom-to-Custom Autopatch group device conflict scenario | You must resolve this conflict.Devices will fail to register with the service and will be sent to the **Not registered** tab. You’re required to make sure the Microsoft Entra groups that are used with the Custom Autopatch groups don’t have device membership overlaps.
|
#### Device conflict post device registration
diff --git a/windows/deployment/windows-autopatch/deploy/windows-autopatch-groups-overview.md b/windows/deployment/windows-autopatch/deploy/windows-autopatch-groups-overview.md
index a706404138..b482faa489 100644
--- a/windows/deployment/windows-autopatch/deploy/windows-autopatch-groups-overview.md
+++ b/windows/deployment/windows-autopatch/deploy/windows-autopatch-groups-overview.md
@@ -21,7 +21,7 @@ As organizations move to a managed-service model where Microsoft manages update
## What are Windows Autopatch groups?
-Autopatch groups is a logical container or unit that groups several [Azure AD groups](/azure/active-directory/fundamentals/active-directory-groups-view-azure-portal), and software update policies, such as [Update rings policy for Windows 10 and later](/mem/intune/protect/windows-10-update-rings) and [feature updates for Windows 10 and later policies](/mem/intune/protect/windows-10-feature-updates).
+Autopatch groups is a logical container or unit that groups several [Microsoft Entra groups](/azure/active-directory/fundamentals/active-directory-groups-view-azure-portal), and software update policies, such as [Update rings policy for Windows 10 and later](/mem/intune/protect/windows-10-update-rings) and [feature updates for Windows 10 and later policies](/mem/intune/protect/windows-10-feature-updates).
## Key benefits
@@ -29,9 +29,9 @@ Autopatch groups help Microsoft Cloud-Managed services meet organizations where
| Benefit | Description |
| ----- | ----- |
-| Replicating your organizational structure | You can set up Autopatch groups to replicate your organizational structures represented by your existing device-based Azure AD group targeting logic. |
+| Replicating your organizational structure | You can set up Autopatch groups to replicate your organizational structures represented by your existing device-based Microsoft Entra group targeting logic. |
| Having a flexible number of deployments | Autopatch groups give you the flexibility of having the right number of deployment rings that work within your organization. You can set up to 15 deployment rings per Autopatch group. |
-| Deciding which device(s) belong to deployment rings | Along with using your existing device-based Azure AD groups and choosing the number of deployment rings, you can also decide which devices belong to deployment rings during the device registration process when setting up Autopatch groups. |
+| Deciding which device(s) belong to deployment rings | Along with using your existing device-based Microsoft Entra groups and choosing the number of deployment rings, you can also decide which devices belong to deployment rings during the device registration process when setting up Autopatch groups. |
| Choosing the deployment cadence | You choose the right software update deployment cadence for your business. |
## High-level architecture diagram overview
@@ -43,8 +43,8 @@ Autopatch groups is a function app that is part of the device registration micro
| Step | Description |
| ----- | ----- |
| Step 1: Create an Autopatch group | Create an Autopatch group. |
-| Step 2: Windows Autopatch uses Microsoft Graph to create Azure AD and policy assignments | Windows Autopatch service uses Microsoft Graph to coordinate the creation of:- Azure AD groups
- Software update policy assignments with other Microsoft services, such as Azure AD, Intune, and Windows Update for Business (WUfB) based on IT admin choices when you create or edit an Autopatch group.
|
-| Step 3: Intune assigns software update policies | Once Azure AD groups are created in the Azure AD service, Intune is used to assign the software update policies to these groups and provide the number of devices that need the software update policies to the Windows Update for Business (WUfB) service. |
+| Step 2: Windows Autopatch uses Microsoft Graph to create Microsoft Entra ID and policy assignments | Windows Autopatch service uses Microsoft Graph to coordinate the creation of:- Microsoft Entra groups
- Software update policy assignments with other Microsoft services, such as Microsoft Entra ID, Intune, and Windows Update for Business (WUfB) based on IT admin choices when you create or edit an Autopatch group.
|
+| Step 3: Intune assigns software update policies | Once Microsoft Entra groups are created in the Microsoft Entra service, Intune is used to assign the software update policies to these groups and provide the number of devices that need the software update policies to the Windows Update for Business (WUfB) service. |
| Step 4: Windows Update for Business responsibilities | Windows Update for Business (WUfB) is the service responsible for:- Delivering those update policies
- Retrieving update deployment statuses back from devices
- Sending back the status information to Microsoft Intune, and then to the Windows Autopatch service
|
## Key concepts
@@ -70,7 +70,7 @@ The Default Autopatch group **can’t** be deleted or renamed. However, you can
#### Default deployment ring composition
-By default, the following [software update-based deployment rings](#software-based-deployment-rings), represented by Azure AD assigned groups, are used:
+By default, the following [software update-based deployment rings](#software-based-deployment-rings), represented by Microsoft Entra ID assigned groups, are used:
- Windows Autopatch – Test
- Windows Autopatch – Ring1
@@ -84,7 +84,7 @@ By default, the following [software update-based deployment rings](#software-bas
> For more information about the differences between **Assigned** and **Dynamic** deployment ring distribution types, see [about deployment rings](#about-deployment-rings). Only deployment rings that are placed in between the **Test** and the **Last** deployment rings can be used with the **Dynamic** deployment ring distributions.
> [!CAUTION]
-> These and other Azure AD assigned groups created by Autopatch groups **can't** be missing in your tenant, otherwise, Autopatch groups might not function properly.
+> These and other Microsoft Entra ID assigned groups created by Autopatch groups **can't** be missing in your tenant, otherwise, Autopatch groups might not function properly.
The **Last** deployment ring, the fifth deployment ring in the Default Autopatch group, is intended to provide coverage for scenarios where a group of specialized devices and/or VIP/Executive users. They must receive software update deployments after the organization’s general population to mitigate disruptions to your organization’s critical businesses.
@@ -96,7 +96,7 @@ The Default Autopatch group provides a default update deployment cadence for its
Autopatch groups set up the [Update rings policy for Windows 10 and later](/mem/intune/protect/windows-10-update-rings) for each of its deployment rings in the Default Autopatch group. See the following default policy values:
-| Policy name | Azure AD group assignment | Quality updates deferral in days | Feature updates deferral in days | Feature updates uninstall window in days | Deadline for quality updates in days | Deadline for feature updates in days | Grace period | Auto restart before deadline |
+| Policy name | Microsoft Entra group assignment | Quality updates deferral in days | Feature updates deferral in days | Feature updates uninstall window in days | Deadline for quality updates in days | Deadline for feature updates in days | Grace period | Auto restart before deadline |
| ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- |
| Windows Autopatch Update Policy - default - Test | Windows Autopatch - Test | 0 | 0 | 30 | 0 | 5 | 0 | Yes |
| Windows Autopatch Update Policy - default - Ring1 | Windows Autopatch - Ring1 | 1 | 0 | 30 | 2 | 5 |2 | Yes |
@@ -108,7 +108,7 @@ Autopatch groups set up the [Update rings policy for Windows 10 and later](/mem/
Autopatch groups set up the [feature updates for Windows 10 and later policies](/mem/intune/protect/windows-10-feature-updates) for each of its deployment rings in the Default Autopatch group, see the following default policy values:
-| Policy name | Azure AD group assignment |Feature update version | Rollout options | First deployment ring availability | Final deployment ring availability | Day between deployment rings | Support end date |
+| Policy name | Microsoft Entra group assignment |Feature update version | Rollout options | First deployment ring availability | Final deployment ring availability | Day between deployment rings | Support end date |
| ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- |
| Windows Autopatch - DSS Policy [Test] | Windows Autopatch - Test | Windows 10 21H2 | Make update available as soon as possible | N/A | N/A | N/A | June 11, 2024; 1:00AM |
| Windows Autopatch - DSS Policy [Ring1] | Windows Autopatch - Ring1 | Windows 10 21H2 | Make update available as soon as possible | N/A | N/A | N/A | June 11, 2024; 1:00AM |
@@ -129,12 +129,12 @@ By default, a Custom Autopatch group has the Test and Last deployment rings auto
Deployment rings make it possible for an Autopatch group to have software update deployments sequentially delivered in a gradual rollout within the Autopatch group.
-Windows Autopatch aligns with Azure AD and Intune terminology for device group management. There are two types of deployment ring group distribution in Autopatch groups:
+Windows Autopatch aligns with Microsoft Entra ID and Intune terminology for device group management. There are two types of deployment ring group distribution in Autopatch groups:
| Deployment ring distribution | Description |
| ----- | ----- |
-| Dynamic | You can use one or more device-based Azure AD groups, either dynamic query-based or assigned to use in your deployment ring composition.Azure AD groups that are used with the Dynamic distribution type can be used to distribute devices across several deployment rings based on percentage values that can be customized.
|
-| Assigned | You can use one single device-based Azure AD group, either dynamic query-based, or assigned to use in your deployment ring composition. |
+| Dynamic | You can use one or more device-based Microsoft Entra groups, either dynamic query-based or assigned to use in your deployment ring composition.Microsoft Entra groups that are used with the Dynamic distribution type can be used to distribute devices across several deployment rings based on percentage values that can be customized.
|
+| Assigned | You can use one single device-based Microsoft Entra group, either dynamic query-based, or assigned to use in your deployment ring composition. |
| Combination of Dynamic and Assigned | To provide a greater level of flexibility when working on deployment ring compositions, you can combine both device distribution types in Autopatch groups.The combination of Dynamic and Assigned device distribution is **not** supported for the Test and Last deployment ring in Autopatch groups.
|
#### About the Test and Last deployment rings
@@ -147,7 +147,7 @@ If you only keep Test and Last deployment rings in your Default Autopatch group,
> Both the **Test** and **Last** deployment rings **can't** be removed or renamed from the Default or Custom Autopatch groups. Autopatch groups don't support the use of one single deployment ring as part of its deployment ring composition because you need at least two deployment rings for their gradual rollout. If you must implement a specific scenario with a single deployment ring, and gradual rollout isn’t required, consider managing these devices outside Windows Autopatch.
> [!TIP]
-> Both the **Test** and **Last** deployment rings only support one single Azure AD group assignment at a time. If you need to assign more than one Azure AD group, you can nest the other Azure AD groups under the ones you plan to use with the **Test** and **Last** deployment rings. Only one level of Azure AD group nesting is supported.
+> Both the **Test** and **Last** deployment rings only support one single Microsoft Entra group assignment at a time. If you need to assign more than one Microsoft Entra group, you can nest the other Microsoft Entra groups under the ones you plan to use with the **Test** and **Last** deployment rings. Only one level of Microsoft Entra group nesting is supported.
#### Service-based versus software update-based deployment rings
@@ -160,7 +160,7 @@ Autopatch groups creates two different layers. Each layer contains its own deplo
The service-based deployment ring set is exclusively used to keep Windows Autopatch updated with both service and device-level configuration policies, apps and APIs needed for core functions of the service.
-The following are the Azure AD assigned groups that represent the service-based deployment rings. These groups can't be deleted or renamed:
+The following are the Microsoft Entra ID assigned groups that represent the service-based deployment rings. These groups can't be deleted or renamed:
- Modern Workplace Devices-Windows Autopatch-Test
- Modern Workplace Devices-Windows Autopatch-First
@@ -168,13 +168,13 @@ The following are the Azure AD assigned groups that represent the service-based
- Modern Workplace Devices-Windows Autopatch-Broad
> [!CAUTION]
-> **Don’t** modify the Azure AD group membership types (Assigned and Dynamic). Otherwise, the Windows Autopatch service won’t be able to read the device group membership from these groups, and causes the Autopatch groups feature and other service-related operations to not work properly. Additionally, it's **not** supported to have Configuration Manager collections directly synced to any Azure AD group created by Autopatch groups.
+> **Don’t** modify the Microsoft Entra group membership types (Assigned and Dynamic). Otherwise, the Windows Autopatch service won’t be able to read the device group membership from these groups, and causes the Autopatch groups feature and other service-related operations to not work properly. Additionally, it's **not** supported to have Configuration Manager collections directly synced to any Microsoft Entra group created by Autopatch groups.
##### Software-based deployment rings
The software-based deployment ring set is exclusively used with software update management policies, such as the Windows update ring and feature update policies, in the Default Windows Autopatch group.
-The following are the Azure AD assigned groups that represent the software updates-based deployment rings. These groups can't be deleted or renamed:
+The following are the Microsoft Entra ID assigned groups that represent the software updates-based deployment rings. These groups can't be deleted or renamed:
- Windows Autopatch - Test
- Windows Autopatch – Ring1
@@ -183,14 +183,14 @@ The following are the Azure AD assigned groups that represent the software updat
- Windows Autopatch – Last
> [!IMPORTANT]
-> Additional Azure AD assigned groups are created and added to list when you add more deployment rings to the Default Autopatch group.
+> Additional Microsoft Entra ID assigned groups are created and added to list when you add more deployment rings to the Default Autopatch group.
> [!CAUTION]
-> **Don’t** modify the Azure AD group membership types (Assigned and Dynamic). Otherwise, the Windows Autopatch service won’t be able to read the device group membership from these groups, and causes the Autopatch groups feature and other service-related operations to not work properly. Additionally, it's **not** supported to have Configuration Manager collections directly synced to any Azure AD group created by Autopatch groups.
+> **Don’t** modify the Microsoft Entra group membership types (Assigned and Dynamic). Otherwise, the Windows Autopatch service won’t be able to read the device group membership from these groups, and causes the Autopatch groups feature and other service-related operations to not work properly. Additionally, it's **not** supported to have Configuration Manager collections directly synced to any Microsoft Entra group created by Autopatch groups.
### About device registration
-Autopatch groups register devices with the Windows Autopatch service when you either [create](../deploy/windows-autopatch-groups-manage-autopatch-groups.md#create-a-custom-autopatch-group) or [edit a Custom Autopatch group](../deploy/windows-autopatch-groups-manage-autopatch-groups.md#edit-the-default-or-a-custom-autopatch-group), and/or when you [edit the Default Autopatch group](../deploy/windows-autopatch-groups-manage-autopatch-groups.md#edit-the-default-or-a-custom-autopatch-group) to use your existing Azure AD groups instead of the Windows Autopatch Device Registration group provided by the service.
+Autopatch groups register devices with the Windows Autopatch service when you either [create](../deploy/windows-autopatch-groups-manage-autopatch-groups.md#create-a-custom-autopatch-group) or [edit a Custom Autopatch group](../deploy/windows-autopatch-groups-manage-autopatch-groups.md#edit-the-default-or-a-custom-autopatch-group), and/or when you [edit the Default Autopatch group](../deploy/windows-autopatch-groups-manage-autopatch-groups.md#edit-the-default-or-a-custom-autopatch-group) to use your existing Microsoft Entra groups instead of the Windows Autopatch Device Registration group provided by the service.
## Common ways to use Autopatch groups
diff --git a/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices.md b/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices.md
index a2734bb584..4cb39e3d34 100644
--- a/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices.md
+++ b/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices.md
@@ -31,44 +31,48 @@ Windows Autopatch can take over software update management control of devices th
### Windows Autopatch groups device registration
-When you either create/edit a [Custom Autopatch group](../deploy/windows-autopatch-groups-overview.md#about-custom-autopatch-groups) or edit the [Default Autopatch group](../deploy/windows-autopatch-groups-overview.md#about-the-default-autopatch-group) to add or remove deployment rings, the device-based Azure AD groups you use when setting up your deployment rings are scanned to see if devices need to be registered with the Windows Autopatch service.
+When you either create/edit a [Custom Autopatch group](../deploy/windows-autopatch-groups-overview.md#about-custom-autopatch-groups) or edit the [Default Autopatch group](../deploy/windows-autopatch-groups-overview.md#about-the-default-autopatch-group) to add or remove deployment rings, the device-based Microsoft Entra groups you use when setting up your deployment rings are scanned to see if devices need to be registered with the Windows Autopatch service.
-If devices aren’t registered, Autopatch groups starts the device registration process by using your existing device-based Azure AD groups instead of the Windows Autopatch Device Registration group.
+If devices aren’t registered, Autopatch groups starts the device registration process by using your existing device-based Microsoft Entra groups instead of the Windows Autopatch Device Registration group.
For more information, see [create Custom Autopatch groups](../deploy/windows-autopatch-groups-manage-autopatch-groups.md#create-a-custom-autopatch-group) and [edit Autopatch group](../deploy/windows-autopatch-groups-manage-autopatch-groups.md#edit-the-default-or-a-custom-autopatch-group) to register devices using the Autopatch groups device registration method.
-#### Supported scenarios when nesting other Azure AD groups
+
-Windows Autopatch also supports the following Azure AD nested group scenarios:
+#### Supported scenarios when nesting other Microsoft Entra groups
-Azure AD groups synced up from:
+Windows Autopatch also supports the following Microsoft Entra nested group scenarios:
+
+Microsoft Entra groups synced up from:
- On-premises Active Directory groups (Windows Server AD)
- [Configuration Manager collections](/mem/configmgr/core/clients/manage/collections/create-collections#bkmk_aadcollsync)
> [!WARNING]
-> It isn't recommended to sync Configuration Manager collections straight to the **Windows Autopatch Device Registration** Azure AD group. Use a different Azure AD group when syncing Configuration Manager collections to Azure AD groups then you can nest this or these groups into the **Windows Autopatch Device Registration** Azure AD group.
+> It isn't recommended to sync Configuration Manager collections straight to the **Windows Autopatch Device Registration** Microsoft Entra group. Use a different Microsoft Entra group when syncing Configuration Manager collections to Microsoft Entra groups then you can nest this or these groups into the **Windows Autopatch Device Registration** Microsoft Entra group.
> [!IMPORTANT]
-> The **Windows Autopatch Device Registration** Azure AD group only supports **one level** of Azure AD nested groups.
+> The **Windows Autopatch Device Registration** Microsoft Entra group only supports **one level** of Microsoft Entra nested groups.
-### Clean up dual state of Hybrid Azure AD joined and Azure registered devices in your Azure AD tenant
+
-An [Azure AD dual state](/azure/active-directory/devices/hybrid-azuread-join-plan#handling-devices-with-azure-ad-registered-state) occurs when a device is initially connected to Azure AD as an [Azure AD Registered](/azure/active-directory/devices/concept-azure-ad-register) device. However, when you enable Hybrid Azure AD join, the same device is connected twice to Azure AD but as a [Hybrid Azure AD device](/azure/active-directory/devices/concept-azure-ad-join-hybrid).
+### Clean up dual state of Microsoft Entra hybrid joined and Azure registered devices in your Microsoft Entra tenant
-In the dual state, you end up having two Azure AD device records with different join types for the same device. In this case, the Hybrid Azure AD device record takes precedence over the Azure AD registered device record for any type of authentication in Azure AD, which makes the Azure AD registered device record stale.
+An [Microsoft Entra dual state](/azure/active-directory/devices/hybrid-azuread-join-plan#handling-devices-with-azure-ad-registered-state) occurs when a device is initially connected to Microsoft Entra ID as an [Microsoft Entra registered](/azure/active-directory/devices/concept-azure-ad-register) device. However, when you enable Microsoft Entra hybrid join, the same device is connected twice to Microsoft Entra ID but as a [Hybrid Microsoft Entra device](/azure/active-directory/devices/concept-azure-ad-join-hybrid).
-It's recommended to detect and clean up stale devices in Azure AD before registering devices with Windows Autopatch, see [How To: Manage state devices in Azure AD](/azure/active-directory/devices/manage-stale-devices).
+In the dual state, you end up having two Microsoft Entra device records with different join types for the same device. In this case, the Hybrid Microsoft Entra device record takes precedence over the Microsoft Entra registered device record for any type of authentication in Microsoft Entra ID, which makes the Microsoft Entra registered device record stale.
+
+It's recommended to detect and clean up stale devices in Microsoft Entra ID before registering devices with Windows Autopatch, see [How To: Manage state devices in Microsoft Entra ID](/azure/active-directory/devices/manage-stale-devices).
> [!WARNING]
-> If you don't clean up stale devices in Azure AD before registering devices with Windows Autopatch, you might end up seeing devices failing to meet the **Intune or Cloud-Attached (Device must be either Intune-managed or Co-managed)** pre-requisite check in the **Not ready** tab because it's expected that these stale Azure AD devices aren't enrolled into the Intune service anymore.
+> If you don't clean up stale devices in Microsoft Entra ID before registering devices with Windows Autopatch, you might end up seeing devices failing to meet the **Intune or Cloud-Attached (Device must be either Intune-managed or Co-managed)** pre-requisite check in the **Not ready** tab because it's expected that these stale Microsoft Entra devices aren't enrolled into the Intune service anymore.
## Prerequisites for device registration
To be eligible for Windows Autopatch management, devices must meet a minimum set of required software-based prerequisites:
- Windows 10 (1809+)/11 Enterprise or Professional editions (only x64 architecture).
-- Either [Hybrid Azure AD-Joined](/azure/active-directory/devices/concept-azure-ad-join-hybrid) or [Azure AD-joined only](/azure/active-directory/devices/concept-azure-ad-join-hybrid) (personal devices aren't supported).
+- Either [Microsoft Entra hybrid joined](/azure/active-directory/devices/concept-azure-ad-join-hybrid) or [Microsoft Entra joined only](/azure/active-directory/devices/concept-azure-ad-join-hybrid) (personal devices aren't supported).
- Managed by Microsoft Intune.
- [Already enrolled into Microsoft Intune](/mem/intune/user-help/enroll-windows-10-device) and/or [Configuration Manager co-management](/windows/deployment/windows-autopatch/prepare/windows-autopatch-prerequisites#configuration-manager-co-management-requirements).
- Must switch the following Microsoft Configuration Manager [co-management workloads](/mem/configmgr/comanage/how-to-switch-workloads) to Microsoft Intune (either set to Pilot Intune or Intune):
@@ -114,20 +118,20 @@ The following are the possible device readiness statuses in Windows Autopatch:
A role defines the set of permissions granted to users assigned to that role. You can use one of the following built-in roles in Windows Autopatch to register devices:
-- Azure AD Global Administrator
+- Microsoft Entra Global Administrator
- Intune Service Administrator
-For more information, see [Azure AD built-in roles](/azure/active-directory/roles/permissions-reference) and [Role-based access control (RBAC) with Microsoft Intune](/mem/intune/fundamentals/role-based-access-control).
+For more information, see [Microsoft Entra built-in roles](/azure/active-directory/roles/permissions-reference) and [Role-based access control (RBAC) with Microsoft Intune](/mem/intune/fundamentals/role-based-access-control).
-If you want to assign less-privileged user accounts to perform specific tasks in the Windows Autopatch portal, such as register devices with the service, you can add these user accounts into one of the two Azure AD groups created during the [tenant enrollment](../prepare/windows-autopatch-enroll-tenant.md) process:
+If you want to assign less-privileged user accounts to perform specific tasks in the Windows Autopatch portal, such as register devices with the service, you can add these user accounts into one of the two Microsoft Entra groups created during the [tenant enrollment](../prepare/windows-autopatch-enroll-tenant.md) process:
-| Azure AD Group name | Discover devices | Modify columns | Refresh device list | Export to .CSV | Device actions |
+| Microsoft Entra group name | Discover devices | Modify columns | Refresh device list | Export to .CSV | Device actions |
| ----- | ----- | ----- | ----- | ----- | ----- |
| Modern Workplace Roles - Service Administrator | Yes | Yes | Yes | Yes | Yes |
| Modern Workplace Roles - Service Reader | No | Yes | Yes | Yes | No |
> [!TIP]
-> If you're adding less-privileged user accounts into the **Modern Workplace Roles - Service Administrator** Azure AD group, it's recommended to add the same users as owners of the **Windows Autopatch Device Registration** Azure AD group. Owners of the **Windows Autopatch Device Registration** Azure AD group can add new devices as members of the group for registration purposes.For more information, see [assign an owner of member of a group in Azure AD](/azure/active-directory/privileged-identity-management/groups-assign-member-owner#assign-an-owner-or-member-of-a-group).
+> If you're adding less-privileged user accounts into the **Modern Workplace Roles - Service Administrator** Microsoft Entra group, it's recommended to add the same users as owners of the **Windows Autopatch Device Registration** Microsoft Entra group. Owners of the **Windows Autopatch Device Registration** Microsoft Entra group can add new devices as members of the group for registration purposes.For more information, see [assign an owner of 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).
## Details about the device registration process
@@ -206,7 +210,7 @@ There's a few more device management lifecycle scenarios to consider when planni
If a device was previously registered into the Windows Autopatch service, but it needs to be reimaged, you must run one of the device provisioning processes available in Microsoft Intune to reimage the device.
-The device will be rejoined to Azure AD (either Hybrid or Azure AD-only). Then, re-enrolled into Intune as well. No further action is required from you or the Windows Autopatch service, because the Azure AD device ID record of that device remains the same.
+The device will be rejoined to Microsoft Entra ID (either Hybrid or Microsoft Entra-only). Then, re-enrolled into Intune as well. No further action is required from you or the Windows Autopatch service, because the Microsoft Entra device ID record of that device remains the same.
### Device repair and hardware replacement
@@ -216,7 +220,7 @@ If you need to repair a device that was previously registered into the Windows A
- MAC address (non-removable NICs)
- OS hard drive's serial, model, manufacturer information
-When one of these hardware changes occurs, Azure AD creates a new device ID record for that device, even if it's technically the same device.
+When one of these hardware changes occurs, Microsoft Entra ID creates a new device ID record for that device, even if it's technically the same device.
> [!IMPORTANT]
-> If a new Azure AD device ID is generated for a device that was previously registered into the Windows Autopatch service, even if it's technically same device, the new Azure AD device ID must be added either through device direct membership or through nested Azure AD dynamic/assigned group into the **Windows Autopatch Device Registration** Azure AD group. This process guarantees that the newly generated Azure AD device ID is registered with Windows Autopatch and that the device continues to have its software updates managed by the service.
+> If a new Microsoft Entra device ID is generated for a device that was previously registered into the Windows Autopatch service, even if it's technically same device, the new Microsoft Entra device ID must be added either through device direct membership or through nested Microsoft Entra dynamic/assigned group into the **Windows Autopatch Device Registration** Microsoft Entra group. This process guarantees that the newly generated Microsoft Entra device ID is registered with Windows Autopatch and that the device continues to have its software updates managed by the service.
diff --git a/windows/deployment/windows-autopatch/operate/windows-autopatch-device-alerts.md b/windows/deployment/windows-autopatch/operate/windows-autopatch-device-alerts.md
index 0f80250e80..563e6370c5 100644
--- a/windows/deployment/windows-autopatch/operate/windows-autopatch-device-alerts.md
+++ b/windows/deployment/windows-autopatch/operate/windows-autopatch-device-alerts.md
@@ -54,7 +54,7 @@ Alert resolutions are provided through the Windows Update service and provide th
| `CancelledByUser` | User canceled the update | The Windows Update service has reported the update was canceled by the user.It's recommended to work with the end user to allow updates to execute as scheduled.
|
| `DamagedMedia` | The update file or hard drive is damaged | The Windows Update service has indicated the update payload might be damaged or corrupt. It's recommended to run `Chkdsk /F` on the device with administrator privileges, then retry the update. For more information, see [chkdsk](/windows-server/administration/windows-commands/chkdsk?tabs=event-viewer).
|
| `DeploymentConflict` | Device is in more than one deployment of the same update type. Only the first deployment assigned is effective. | The Windows Update service has reported a policy conflict.For more information, see the [Windows Autopatch Policy Health dashboard](../operate/windows-autopatch-policy-health-and-remediation.md).
If the alert persists, [submit a support request](../operate/windows-autopatch-support-request.md).
|
-| `DeviceRegistrationInvalidAzureADDeviceId` | The device isn't able to register or authenticate properly with Windows Update because of an invalid Azure AD Device ID. | The Windows Update service has reported a device registration issue.For more information, see [Windows Autopatch post-device registration readiness checks](../deploy/windows-autopatch-post-reg-readiness-checks.md).
If the alert persists, [submit a support request](../operate/windows-autopatch-support-request.md).
|
+| `DeviceRegistrationInvalidAzureADDeviceId` | The device isn't able to register or authenticate properly with Windows Update because of an invalid Microsoft Entra Device ID. | The Windows Update service has reported a device registration issue.For more information, see [Windows Autopatch post-device registration readiness checks](../deploy/windows-autopatch-post-reg-readiness-checks.md).
If the alert persists, [submit a support request](../operate/windows-autopatch-support-request.md).
|
| `DeviceRegistrationInvalidGlobalDeviceId` | The device isn't able to register or authenticate properly with Windows Update because of an invalid Global Device ID. |The Windows Update service has reported that the MSA Service may be disabled preventing Global Device ID assignment.Check that the MSA Service is running or able to run on device.
If the alert persists, [submit a support request](../operate/windows-autopatch-support-request.md).
|
| `DeviceRegistrationIssue` | The device isn't able to register or authenticate properly with Windows Update. | The Windows Update service has reported a device registration issue.For more information, see [Windows Autopatch post-device registration readiness checks](../deploy/windows-autopatch-post-reg-readiness-checks.md).
If the alert persists, [submit a support request](../operate/windows-autopatch-support-request.md).
|
| `DeviceRegistrationNoTrustType` | The device isn't able to register or authenticate properly with Windows Update because it can't establish Trust. | The Windows Update service has reported a device registration issue.For more information, see [Windows Autopatch post-device registration readiness checks](../deploy/windows-autopatch-post-reg-readiness-checks.md).
If the alert persists, [submit a support request](../operate/windows-autopatch-support-request.md).
|
diff --git a/windows/deployment/windows-autopatch/operate/windows-autopatch-exclude-device.md b/windows/deployment/windows-autopatch/operate/windows-autopatch-exclude-device.md
index c41dd12e0c..843b7e8d3c 100644
--- a/windows/deployment/windows-autopatch/operate/windows-autopatch-exclude-device.md
+++ b/windows/deployment/windows-autopatch/operate/windows-autopatch-exclude-device.md
@@ -16,12 +16,12 @@ ms.collection:
# Exclude a device
-To avoid end-user disruption, excluding a device in Windows Autopatch only deletes the Windows Autopatch device record itself. Excluding a device can't delete the Microsoft Intune and/or the Azure Active Directory device records. Microsoft assumes you'll keep managing those devices yourself in some capacity.
+To avoid end-user disruption, excluding a device in Windows Autopatch only deletes the Windows Autopatch device record itself. Excluding a device can't delete the Microsoft Intune and/or the Microsoft Entra device records. Microsoft assumes you'll keep managing those devices yourself in some capacity.
-When you exclude a device from the Windows Autopatch service, the device is flagged as **excluded** so Windows Autopatch doesn't try to restore the device into the service again, since the exclusion command doesn't trigger device membership removal from the **Windows Autopatch Device Registration** group, or any other Azure AD group, used with Autopatch groups.
+When you exclude a device from the Windows Autopatch service, the device is flagged as **excluded** so Windows Autopatch doesn't try to restore the device into the service again, since the exclusion command doesn't trigger device membership removal from the **Windows Autopatch Device Registration** group, or any other Microsoft Entra group, used with Autopatch groups.
> [!IMPORTANT]
-> The Azure AD team doesn't recommend appending query statements to remove specific device from a dynamic query due to dynamic query performance issues.
+> The Microsoft Entra team doesn't recommend appending query statements to remove specific device from a dynamic query due to dynamic query performance issues.
**To exclude a device:**
@@ -32,7 +32,7 @@ When you exclude a device from the Windows Autopatch service, the device is flag
1. Once a device or multiple devices are selected, select **Device actions**. Then, select **Exclude device**.
> [!WARNING]
-> Excluding devices from the Windows Autopatch Device Registration group, or any other Azure AD group, used with Autopatch groups doesn't exclude devices from the Windows Autopatch service.
+> Excluding devices from the Windows Autopatch Device Registration group, or any other Microsoft Entra group, used with Autopatch groups doesn't exclude devices from the Windows Autopatch service.
## Only view excluded devices
diff --git a/windows/deployment/windows-autopatch/operate/windows-autopatch-groups-update-management.md b/windows/deployment/windows-autopatch/operate/windows-autopatch-groups-update-management.md
index 12e39f7f30..66164cc373 100644
--- a/windows/deployment/windows-autopatch/operate/windows-autopatch-groups-update-management.md
+++ b/windows/deployment/windows-autopatch/operate/windows-autopatch-groups-update-management.md
@@ -34,7 +34,7 @@ Keeping your devices up to date is a balance of speed and stability. Windows Aut
Autopatch groups help Microsoft Cloud-Managed services meet all organizations where they are at in their update management journey.
-Autopatch groups is a logical container that groups several [Azure AD groups](/azure/active-directory/fundamentals/active-directory-groups-view-azure-portal), and software update policies, such as Windows Update rings and feature update policies, together.
+Autopatch groups is a logical container that groups several [Microsoft Entra groups](/azure/active-directory/fundamentals/active-directory-groups-view-azure-portal), and software update policies, such as Windows Update rings and feature update policies, together.
For more information on key benefits and how to use Autopatch groups, see [Autopatch groups overview](../deploy/windows-autopatch-groups-overview.md).
diff --git a/windows/deployment/windows-autopatch/operate/windows-autopatch-groups-windows-feature-update-overview.md b/windows/deployment/windows-autopatch/operate/windows-autopatch-groups-windows-feature-update-overview.md
index f2522d91fa..8ffc66a28a 100644
--- a/windows/deployment/windows-autopatch/operate/windows-autopatch-groups-windows-feature-update-overview.md
+++ b/windows/deployment/windows-autopatch/operate/windows-autopatch-groups-windows-feature-update-overview.md
@@ -64,7 +64,7 @@ Windows Autopatch’s default Windows feature update release is a service-driven
> [!TIP]
> Windows Autopatch allows you to [create custom Windows feature update releases](../operate/windows-autopatch-groups-manage-windows-feature-update-release.md#create-a-custom-release).
-When devices are registered by manually adding them to the Windows Autopatch Device Registration Azure AD assigned group, devices are assigned to deployment rings as part of the default Autopatch group. Each deployment ring has its own Windows feature update policy assigned to them. This is intended to minimize unexpected Windows OS upgrades once new devices register with the service.
+When devices are registered by manually adding them to the Windows Autopatch Device Registration Microsoft Entra ID assigned group, devices are assigned to deployment rings as part of the default Autopatch group. Each deployment ring has its own Windows feature update policy assigned to them. This is intended to minimize unexpected Windows OS upgrades once new devices register with the service.
The policies:
@@ -98,7 +98,7 @@ There are two scenarios that the Global release is used:
| Scenario | Description |
| ----- | ----- |
-| Scenario #1 | You assign Azure AD groups to be used with the deployment ring (Last) or you add additional deployment rings when you customize the [Default Autopatch group](../deploy/windows-autopatch-groups-manage-autopatch-groups.md#edit-the-default-or-a-custom-autopatch-group).A global Windows feature update policy is automatically assigned behind the scenes to the newly added deployment rings or when you assigned Azure AD groups to the deployment ring (Last) in the Default Autopatch group.
|
+| Scenario #1 | You assign Microsoft Entra groups to be used with the deployment ring (Last) or you add additional deployment rings when you customize the [Default Autopatch group](../deploy/windows-autopatch-groups-manage-autopatch-groups.md#edit-the-default-or-a-custom-autopatch-group).A global Windows feature update policy is automatically assigned behind the scenes to the newly added deployment rings or when you assigned Microsoft Entra groups to the deployment ring (Last) in the Default Autopatch group.
|
| Scenario #2 | You create new [Custom Autopatch groups](../deploy/windows-autopatch-groups-manage-autopatch-groups.md#create-a-custom-autopatch-group).The global Windows feature policy is automatically assigned behind the scenes to all deployment rings as part of the Custom Autopatch groups you create.
|
> [!NOTE]
@@ -142,7 +142,7 @@ Feature update policies work with Windows Update rings policies. Windows Update
The following table details the default Windows Update rings policy values that affect either the default or custom Windows feature updates releases:
-| Policy name | Azure AD group assignment | Quality updates deferral in days | Feature updates deferral in days | Feature updates uninstall window in days | Deadline for quality updates in days | Deadline for feature updates in days | Grace period | Auto restart before deadline |
+| Policy name | Microsoft Entra group assignment | Quality updates deferral in days | Feature updates deferral in days | Feature updates uninstall window in days | Deadline for quality updates in days | Deadline for feature updates in days | Grace period | Auto restart before deadline |
| ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- |
| Windows Autopatch Update Policy - default - Test | Windows Autopatch - Test | 0 | 0 | 30 | 0 | 5 | 0 | Yes |
| Windows Autopatch Update Policy - default - Ring1 | Windows Autopatch - Ring1 | 1 | 0 | 30 | 2 | 5 |2 | Yes |
diff --git a/windows/deployment/windows-autopatch/operate/windows-autopatch-groups-windows-feature-update-status-report.md b/windows/deployment/windows-autopatch/operate/windows-autopatch-groups-windows-feature-update-status-report.md
index da80289277..8fe50bb86f 100644
--- a/windows/deployment/windows-autopatch/operate/windows-autopatch-groups-windows-feature-update-status-report.md
+++ b/windows/deployment/windows-autopatch/operate/windows-autopatch-groups-windows-feature-update-status-report.md
@@ -48,7 +48,7 @@ The following information is available as optional columns in the Feature update
| Column name | Description |
| ----- | ----- |
-| Azure Active Directory (AD) device ID | The current Azure AD recorded device ID for the device |
+| Microsoft Entra device ID | The current Microsoft Entra ID recorded device ID for the device |
| Serial number | The current Intune recorded serial number for the device |
| Intune last check in time | The last time the device checked in to Intune |
| Service State | The Service State provided from Windows Update |
@@ -73,7 +73,7 @@ The following options are available:
| Option | Description |
| ----- | ----- |
-| Search | Use to search by device name, Azure AD device ID or serial number |
+| Search | Use to search by device name, Microsoft Entra device ID or serial number |
| Sort | Select the **column headings** to sort the report data in ascending and descending order. |
| Export | Select **Export devices** at the top of the page to export data from this report into a CSV file. |
| Filter | Select either the **Add filters** or at the top of the report to filter the results. |
diff --git a/windows/deployment/windows-autopatch/operate/windows-autopatch-groups-windows-quality-update-status-report.md b/windows/deployment/windows-autopatch/operate/windows-autopatch-groups-windows-quality-update-status-report.md
index 703ee03554..af916925f0 100644
--- a/windows/deployment/windows-autopatch/operate/windows-autopatch-groups-windows-quality-update-status-report.md
+++ b/windows/deployment/windows-autopatch/operate/windows-autopatch-groups-windows-quality-update-status-report.md
@@ -51,7 +51,7 @@ The following information is available as optional columns in the Quality update
| Column name | Description |
| ----- | ----- |
-| Azure Active Directory (AD) device ID | The current Azure AD recorded device ID for the device |
+| Microsoft Entra device ID | The current Microsoft Entra ID recorded device ID for the device |
| Serial number | The current Intune recorded serial number for the device |
| Intune last check in time | The last time the device checked in to Intune |
| Service State | The Service State provided from Windows Update |
@@ -75,7 +75,7 @@ The following options are available:
| Option | Description |
| ----- | ----- |
-| Search | Use to search by device name, Azure AD device ID or serial number |
+| Search | Use to search by device name, Microsoft Entra device ID or serial number |
| Sort | Select the **column headings** to sort the report data in ascending and descending order. |
| Export | Select **Export devices** at the top of the page to export data from this report into a CSV file. |
| Filter | Select either the **Add filters** or at the top of the report to filter the results. |
diff --git a/windows/deployment/windows-autopatch/operate/windows-autopatch-maintain-environment.md b/windows/deployment/windows-autopatch/operate/windows-autopatch-maintain-environment.md
index cab93e35da..3b72dc6d90 100644
--- a/windows/deployment/windows-autopatch/operate/windows-autopatch-maintain-environment.md
+++ b/windows/deployment/windows-autopatch/operate/windows-autopatch-maintain-environment.md
@@ -23,13 +23,13 @@ After you've completed enrollment in Windows Autopatch, some management settings
1. If any of the items apply to your environment, make the adjustments as described.
> [!NOTE]
-> As your operations continue in the following months, if you make changes after enrollment to policies in Microsoft Intune, Azure Active Directory, or Microsoft 365 that affect Windows Autopatch, it's possible that Windows Autopatch could stop operating properly. To avoid problems with the service, check the specific settings described in [Fix issues found by the readiness assessment tool](../prepare/windows-autopatch-fix-issues.md) before you change the policies listed there.
+> As your operations continue in the following months, if you make changes after enrollment to policies in Microsoft Intune, Microsoft Entra ID, or Microsoft 365 that affect Windows Autopatch, it's possible that Windows Autopatch could stop operating properly. To avoid problems with the service, check the specific settings described in [Fix issues found by the readiness assessment tool](../prepare/windows-autopatch-fix-issues.md) before you change the policies listed there.
## Microsoft Intune settings
| Setting | Description |
| ----- | ----- |
-| Deployment rings for Windows 10 or later | For any deployment rings for Windows 10 or later policies you've created, exclude the **Modern Workplace Devices - All** Azure AD group from each policy. For more information, see [Create and assign deployment rings](/mem/intune/protect/windows-10-update-rings#create-and-assign-update-rings).Windows Autopatch creates some update ring policies. These policies have "**Modern Workplace**" in the name. For example:
- Modern Workplace Update Policy [Broad]-[Windows Autopatch]
- Modern Workplace Update Policy [Fast]-[Windows Autopatch]
- Modern Workplace Update Policy [First]-[Windows Autopatch]
- Modern Workplace Update Policy [Test]-[Windows Autopatch]
When you update your own policies, ensure that you don't exclude the **Modern Workplace Devices - All** Azure AD group from the policies that Windows Autopatch created.
**To resolve the Not ready result:**
After enrolling into Autopatch, make sure that any update ring policies you have **exclude** the **Modern Workplace Devices - All** Azure Active Directory (AD) group. For more information, see [Manage Windows 10 software updates in Intune](/mem/intune/protect/windows-update-for-business-configure).
**To resolve the Advisory result:**
- Make sure that any update ring policies you have **exclude** the **Modern Workplace Devices - All** Azure Active Directory (AD) group.
- If you have assigned Azure AD user groups to these policies, make sure that any update ring policies you have also **exclude** the **Modern Workplace - All** Azure AD group that you add your Windows Autopatch users to (or an equivalent group).
For more information, see [Manage Windows 10 software updates in Intune](/mem/intune/protect/windows-update-for-business-configure).
|
+| Deployment rings for Windows 10 or later | For any deployment rings for Windows 10 or later policies you've created, exclude the **Modern Workplace Devices - All** Microsoft Entra group from each policy. For more information, see [Create and assign deployment rings](/mem/intune/protect/windows-10-update-rings#create-and-assign-update-rings).Windows Autopatch creates some update ring policies. These policies have "**Modern Workplace**" in the name. For example:
- Modern Workplace Update Policy [Broad]-[Windows Autopatch]
- Modern Workplace Update Policy [Fast]-[Windows Autopatch]
- Modern Workplace Update Policy [First]-[Windows Autopatch]
- Modern Workplace Update Policy [Test]-[Windows Autopatch]
When you update your own policies, ensure that you don't exclude the **Modern Workplace Devices - All** Microsoft Entra group from the policies that Windows Autopatch created.
**To resolve the Not ready result:**
After enrolling into Autopatch, make sure that any update ring policies you have **exclude** the **Modern Workplace Devices - All** Microsoft Entra group. For more information, see [Manage Windows 10 software updates in Intune](/mem/intune/protect/windows-update-for-business-configure).
**To resolve the Advisory result:**
- Make sure that any update ring policies you have **exclude** the **Modern Workplace Devices - All** Microsoft Entra group.
- If you have assigned Microsoft Entra user groups to these policies, make sure that any update ring policies you have also **exclude** the **Modern Workplace - All** Microsoft Entra group that you add your Windows Autopatch users to (or an equivalent group).
For more information, see [Manage Windows 10 software updates in Intune](/mem/intune/protect/windows-update-for-business-configure).
|
## Windows Autopatch configurations
@@ -56,7 +56,7 @@ The type of banner that appears depends on the severity of the action. Currently
| Action type | Severity | Description |
| ----- | ----- | ----- |
-| Maintain tenant access | Critical | Required licenses have expired. The licenses include:- Microsoft Intune
- Azure Active Directory Premium
- Windows 10/11 Enterprise E3 or higher
- For more information about specific services plans, see [Windows Autopatch Prerequisites](../prepare/windows-autopatch-prerequisites.md)
To take action on missing licenses, you can visit the Microsoft 365 admin center or contact your Microsoft account manager. Until you have renewed the required licenses to run the service, Windows Autopatch marks your tenant as **inactive**. For more information, see [Microsoft 365 - What happens after my subscription expires?](/microsoft-365/commerce/subscriptions/what-if-my-subscription-expires)
|
+| Maintain tenant access | Critical | Required licenses have expired. The licenses include:- Microsoft Intune
- Microsoft Entra ID P1 or P2
- Windows 10/11 Enterprise E3 or higher
- For more information about specific services plans, see [Windows Autopatch Prerequisites](../prepare/windows-autopatch-prerequisites.md)
To take action on missing licenses, you can visit the Microsoft 365 admin center or contact your Microsoft account manager. Until you have renewed the required licenses to run the service, Windows Autopatch marks your tenant as **inactive**. For more information, see [Microsoft 365 - What happens after my subscription expires?](/microsoft-365/commerce/subscriptions/what-if-my-subscription-expires)
|
| Maintain tenant access | Critical | Address tenant access issues. Windows Autopatch currently can’t manage your tenant. Until you take action, your tenant is marked as **inactive**, and you have only limited access to the Windows Autopatch portal.Reasons for tenant access issues:
- You haven't yet migrated to the new [Windows Autopatch enterprise application](../references/windows-autopatch-changes-to-tenant.md#windows-autopatch-enterprise-applications). Windows Autopatch uses this enterprise application to run the service.
- You have blocked or removed the permissions required for the Windows Autopatch enterprise application.
Take action by consenting to allow Windows Autopatch to make the appropriate changes on your behalf. You must be a Global Administrator to consent to this action. Once you provide consent, Windows Autopatch remediates this critical action for you.
For more information, see [Windows Autopatch enterprise applications](../overview/windows-autopatch-privacy.md#tenant-access).
|
### Inactive status
diff --git a/windows/deployment/windows-autopatch/operate/windows-autopatch-unenroll-tenant.md b/windows/deployment/windows-autopatch/operate/windows-autopatch-unenroll-tenant.md
index ecc8f356a9..2c89d2a8ce 100644
--- a/windows/deployment/windows-autopatch/operate/windows-autopatch-unenroll-tenant.md
+++ b/windows/deployment/windows-autopatch/operate/windows-autopatch-unenroll-tenant.md
@@ -25,7 +25,7 @@ If you're looking to unenroll your tenant from Windows Autopatch, this article d
Unenrolling from Windows Autopatch requires manual actions from both you and from the Windows Autopatch Service Engineering Team. The Windows Autopatch Service Engineering Team will:
- Remove Windows Autopatch access to your tenant.
-- Exclude your devices from the Windows Autopatch service. Excluding your devices from Windows Autopatch won't remove your devices from Intune, Azure AD or Configuration Manager. The Windows Autopatch Service Engineering Team follows the same process and principles as laid out in [Exclude a device](../operate/windows-autopatch-exclude-device.md).
+- Exclude your devices from the Windows Autopatch service. Excluding your devices from Windows Autopatch won't remove your devices from Intune, Microsoft Entra ID or Configuration Manager. The Windows Autopatch Service Engineering Team follows the same process and principles as laid out in [Exclude a device](../operate/windows-autopatch-exclude-device.md).
- Delete all data that we've stored in the Windows Autopatch data storage.
> [!NOTE]
@@ -36,7 +36,7 @@ Unenrolling from Windows Autopatch requires manual actions from both you and fro
| Responsibility | Description |
| ----- | ----- |
| Windows Autopatch data | Windows Autopatch will delete user data that is within the Windows Autopatch service. We won’t make changes to any other data. For more information about how data is used in Windows Autopatch, see [Privacy](../overview/windows-autopatch-privacy.md). |
-| Excluding devices | Windows Autopatch will exclude all devices previously registered with the service. Only the Windows Autopatch device record is deleted. We won't delete Microsoft Intune and/or Azure Active Directory device records. For more information, see [Exclude a device](../operate/windows-autopatch-exclude-device.md). |
+| Excluding devices | Windows Autopatch will exclude all devices previously registered with the service. Only the Windows Autopatch device record is deleted. We won't delete Microsoft Intune and/or Microsoft Entra device records. For more information, see [Exclude a device](../operate/windows-autopatch-exclude-device.md). |
## Your responsibilities after unenrolling your tenant
diff --git a/windows/deployment/windows-autopatch/overview/windows-autopatch-deployment-guide.md b/windows/deployment/windows-autopatch/overview/windows-autopatch-deployment-guide.md
index fb1b851773..7fc5bce674 100644
--- a/windows/deployment/windows-autopatch/overview/windows-autopatch-deployment-guide.md
+++ b/windows/deployment/windows-autopatch/overview/windows-autopatch-deployment-guide.md
@@ -66,7 +66,7 @@ The following deployment steps can be used as a guide to help you to create your
| ----- | ----- |
| **1A: Set up the service** | - Prepare your environment, review existing update policies and [General Considerations](#general-considerations)
- Review and understand [changes made at tenant enrollment](../references/windows-autopatch-changes-to-tenant.md) when enrolling into the service
- Enroll into the service and [add your admin contacts](../deploy/windows-autopatch-admin-contacts.md)
- Review [Roles and responsibilities](../overview/windows-autopatch-roles-responsibilities.md)
- Verify the [changes made at tenant enrollment](../references/windows-autopatch-changes-to-tenant.md) completed successfully
|
| **1B: Confirm update service needs and configure your workloads** | - [Windows quality updates](../operate/windows-autopatch-windows-quality-update-overview.md): Expedite preferences and cadence customizations
- [Windows feature updates](../operate/windows-autopatch-windows-feature-update-overview.md): Servicing version preferences
- [Driver and firmware updates](../operate/windows-autopatch-manage-driver-and-firmware-updates.md): Set to either Manual or Automatic
- [Microsoft 365 Apps for enterprise](../operate/windows-autopatch-microsoft-365-apps-enterprise.md): Set to either Monthly Enterprise Channel or opt-out
- [Microsoft Edge](../operate/windows-autopatch-edge.md): Required. Beta and Stable Channel
- [Microsoft Teams](../operate/windows-autopatch-teams.md): Required. Automatic
|
-| **1C: Consider your Autopatch groups distribution** | Organizations have a range of Windows devices including desktop computers, laptops and tablets that might be grouped across multiple logical or physical locations. When planning your Autopatch groups strategy, consider the Autopatch group structure that best fits your organizational needs. It's recommended to utilize the service defaults as much as possible. However, if necessary, you can customize the [Default Autopatch group](../deploy/windows-autopatch-groups-overview.md#about-the-default-autopatch-group) with additional deployment rings and/or [create your own Custom Autopatch group(s)](../deploy/windows-autopatch-groups-overview.md#about-the-default-autopatch-group).
- Review your device inventory and consider a representative mix of devices across your distribution
- Review your Azure AD groups that you wish to use to register devices into the service
- Review [device registration options](../deploy/windows-autopatch-device-registration-overview.md) and [register your first devices](../deploy/windows-autopatch-register-devices.md)
|
+| **1C: Consider your Autopatch groups distribution** | Organizations have a range of Windows devices including desktop computers, laptops and tablets that might be grouped across multiple logical or physical locations. When planning your Autopatch groups strategy, consider the Autopatch group structure that best fits your organizational needs. It's recommended to utilize the service defaults as much as possible. However, if necessary, you can customize the [Default Autopatch group](../deploy/windows-autopatch-groups-overview.md#about-the-default-autopatch-group) with additional deployment rings and/or [create your own Custom Autopatch group(s)](../deploy/windows-autopatch-groups-overview.md#about-the-default-autopatch-group).
- Review your device inventory and consider a representative mix of devices across your distribution
- Review your Microsoft Entra groups that you wish to use to register devices into the service
- Review [device registration options](../deploy/windows-autopatch-device-registration-overview.md) and [register your first devices](../deploy/windows-autopatch-register-devices.md)
|
| **1D: Review network optimization** | It's important to [prepare your network](../prepare/windows-autopatch-configure-network.md) to ensure that your devices have access to updates in the most efficient way, without impacting your infrastructure.
A recommended approach to manage bandwidth consumption is to utilize [Delivery Optimization](../prepare/windows-autopatch-configure-network.md#delivery-optimization). You can use Delivery Optimization to reduce bandwidth consumption by sharing the work of downloading these packages amongst multiple devices in your deployment. |
### Step two: Evaluate
@@ -121,7 +121,7 @@ Once migrated, there are several configuration tasks that you no longer need to
| Automated management of deployment ring membership | Manually check collection membership and targets | Manage "static" deployment ring membership |
| Maintain minimum Windows feature version and progressively move between servicing versions | Spend time developing, testing and rolling-out task sequence | Set up and deploy Windows feature update policies |
| Service provides release management, signal monitoring, testing, and Windows Update deployment | Setup, target and monitor update test collections | Manage Test deployment rings and manually monitor update signals |
-| Simple, integrated process to turn on the service as part of the Windows 365 provisioning policy | Manually target Cloud PCs in device collections | Manually target Cloud PCs in Azure AD groups |
+| Simple, integrated process to turn on the service as part of the Windows 365 provisioning policy | Manually target Cloud PCs in device collections | Manually target Cloud PCs in Microsoft Entra groups |
In addition to the reports, other benefits include:
@@ -179,7 +179,7 @@ When you migrate from Configuration Manager to Windows Autopatch, the fastest pa
| **1** | Turn on co-management | If you're using co-management across Configuration Manager and your managed devices, you meet the key requirements to use Windows Autopatch.
If you don't have co-management, see [How to use co-management in Configuration Manager](/mem/configmgr/comanage/how-to-enable) |
| **2** | Use required co-management workloads | Using Windows Autopatch requires that your managed devices use the following three co-management workloads:- Windows Update policies workload
- Device configuration workload
- Office Click-to-Run apps workload
If you have these workloads configured, you meet the key requirements to use Windows Autopatch. If you don't have these workloads configured, review [How to switch Configuration Manager workloads to Intune](/mem/configmgr/comanage/how-to-switch-workloads) |
| **3** | Prepare your policies | You should consider any existing policy configurations in your Configuration Manager (or on-premises) environment that could impact your deployment of Windows Autopatch. For more information, review [General considerations](#general-considerations) |
-| **4** | Ensure Configuration Manager collections or Azure AD device groups readiness | To move devices to Windows Autopatch, you must register devices with the Windows Autopatch service. To do so, use either Azure AD device groups, or Configuration Manager collections. Ensure you have either Azure AD device groups or Configuration Manager collections that allow you to evaluate, pilot and then migrate to the Windows Autopatch service. For more information, see [Register your devices](../deploy/windows-autopatch-register-devices.md#before-you-begin). |
+| **4** | Ensure Configuration Manager collections or Microsoft Entra device groups readiness | To move devices to Windows Autopatch, you must register devices with the Windows Autopatch service. To do so, use either Microsoft Entra device groups, or Configuration Manager collections. Ensure you have either Microsoft Entra device groups or Configuration Manager collections that allow you to evaluate, pilot and then migrate to the Windows Autopatch service. For more information, see [Register your devices](../deploy/windows-autopatch-register-devices.md#before-you-begin). |
### Optimized deployment path: Configuration Manager to Windows Autopatch
diff --git a/windows/deployment/windows-autopatch/overview/windows-autopatch-faq.yml b/windows/deployment/windows-autopatch/overview/windows-autopatch-faq.yml
index 6ac52fd9df..54d107d92d 100644
--- a/windows/deployment/windows-autopatch/overview/windows-autopatch-faq.yml
+++ b/windows/deployment/windows-autopatch/overview/windows-autopatch-faq.yml
@@ -31,7 +31,7 @@ sections:
Autopatch isn't available for 'A' or 'F' series licensing.
- question: Will Windows Autopatch support local domain join Windows 10?
answer: |
- Windows Autopatch doesn't support local (on-premises) domain join. Windows Autopatch supports [Hybrid AD join](/azure/active-directory/devices/concept-azure-ad-join-hybrid) or pure [Azure AD join](/azure/active-directory/devices/concept-azure-ad-join-hybrid).
+ Windows Autopatch doesn't support local (on-premises) domain join. Windows Autopatch supports [Hybrid AD join](/azure/active-directory/devices/concept-azure-ad-join-hybrid) or pure [Microsoft Entra join](/azure/active-directory/devices/concept-azure-ad-join-hybrid).
- question: Will Windows Autopatch be available for state and local government customers?
answer: |
Windows Autopatch is available for all Windows E3 customers using Azure commercial cloud. However, Autopatch isn't currently supported for government cloud (GCC) customers. Although Windows 365 Enterprise is in the Azure Commercial cloud, when Windows 365 Enterprise is used with a GCC customer tenant, Autopatch is not supported.
@@ -111,7 +111,7 @@ sections:
No, you can't customize update scheduling. However, you can specify [active hours](../operate/windows-autopatch-windows-quality-update-end-user-exp.md#servicing-window) to prevent users from updating during business hours.
- question: Does Autopatch support include and exclude groups, or dynamic groups to define deployment ring membership?
answer: |
- Windows Autopatch doesn't support managing update deployment ring membership using your Azure AD groups. For more information, see [Moving devices in between deployment rings](../operate/windows-autopatch-update-management.md#moving-devices-in-between-deployment-rings).
+ Windows Autopatch doesn't support managing update deployment ring membership using your Microsoft Entra groups. For more information, see [Moving devices in between deployment rings](../operate/windows-autopatch-update-management.md#moving-devices-in-between-deployment-rings).
- question: Does Autopatch have two release cadences per update or are there two release cadences per-ring?
answer: |
The release cadences are defined based on the update type. For example, a [regular cadence](../operate/windows-autopatch-windows-quality-update-overview.md#windows-quality-update-releases) (for a Windows quality update would be a gradual rollout from the Test ring to the Broad ring over 14 days whereas an [expedited release](../operate/windows-autopatch-windows-quality-update-overview.md#expedited-releases) would roll out more rapidly.
diff --git a/windows/deployment/windows-autopatch/overview/windows-autopatch-privacy.md b/windows/deployment/windows-autopatch/overview/windows-autopatch-privacy.md
index 0ce2010fe7..043db6fb77 100644
--- a/windows/deployment/windows-autopatch/overview/windows-autopatch-privacy.md
+++ b/windows/deployment/windows-autopatch/overview/windows-autopatch-privacy.md
@@ -23,13 +23,13 @@ Windows Autopatch is a cloud service for enterprise customers designed to keep e
Windows Autopatch provides its service to enterprise customers, and properly administers customers' enrolled devices by using data from various sources.
-The sources include Azure Active Directory (Azure AD), Microsoft Intune, and Microsoft Windows 10/11. The sources provide a comprehensive view of the devices that Windows Autopatch manages.
+The sources include Microsoft Entra ID, Microsoft Intune, and Microsoft Windows 10/11. The sources provide a comprehensive view of the devices that Windows Autopatch manages.
| Data source | Purpose |
| ------ | ------ |
| [Microsoft Windows 10/11 Enterprise](/windows/windows-10/) | Management of device setup experience, managing connections to other services, and operational support for IT pros. |
| [Windows Update for Business](/windows/deployment/update/waas-manage-updates-wufb) | Uses Windows 10/11 Enterprise diagnostic data to provide additional information on Windows 10/11 update. |
-| [Microsoft Intune](/mem/intune/fundamentals/what-is-intune) | Device management and to keep your data secure. The following endpoint management data sources are used:
- [Microsoft Azure Active Directory](/azure/active-directory/): Authentication and identification of all user accounts.
- [Microsoft Intune](/mem/intune/): Distributing device configurations, device management and application management.
+| [Microsoft Intune](/mem/intune/fundamentals/what-is-intune) | Device management and to keep your data secure. The following endpoint management data sources are used:
- [Microsoft Entra ID](/azure/active-directory/): Authentication and identification of all user accounts.
- [Microsoft Intune](/mem/intune/): Distributing device configurations, device management and application management.
| [Windows Autopatch](https://go.microsoft.com/fwlink/?linkid=2109431) | Data provided by the customer or generated by the service during running of the service. |
| [Microsoft 365 Apps for enterprise](https://www.microsoft.com/microsoft-365/enterprise/compare-office-365-plans)| Management of Microsoft 365 Apps. |
@@ -90,9 +90,11 @@ Windows Autopatch creates and uses guest accounts using just-in-time access func
Microsoft Windows Update for Business uses data from Windows diagnostics to analyze update status and failures. Windows Autopatch uses this data and uses it to mitigate, and resolve problems to ensure that all registered devices are up to date based on a predefined update cadence.
-## Microsoft Azure Active Directory
+
-Identifying data used by Windows Autopatch is stored by Azure Active Directory (AD) in a geographical location. The geographical location is based on the location provided by the organization upon subscribing to Microsoft online services, such as Microsoft Apps for Enterprise and Azure. For more information on where your Azure AD data is located, see [Azure Active Directory - Where is your data located?](https://msit.powerbi.com/view?r=eyJrIjoiODdjOWViZDctMWRhZS00ODUzLWI4MmQtNWM5NjBkZTBkNjFlIiwidCI6IjcyZjk4OGJmLTg2ZjEtNDFhZi05MWFiLTJkN2NkMDExZGI0NyIsImMiOjV9)
+## Microsoft Entra ID
+
+Identifying data used by Windows Autopatch is stored by Microsoft Entra ID in a geographical location. The geographical location is based on the location provided by the organization upon subscribing to Microsoft online services, such as Microsoft Apps for Enterprise and Azure. For more information on where your Microsoft Entra data is located, see [Microsoft Entra ID - Where is your data located?](https://msit.powerbi.com/view?r=eyJrIjoiODdjOWViZDctMWRhZS00ODUzLWI4MmQtNWM5NjBkZTBkNjFlIiwidCI6IjcyZjk4OGJmLTg2ZjEtNDFhZi05MWFiLTJkN2NkMDExZGI0NyIsImMiOjV9)
## Microsoft Intune
@@ -136,7 +138,7 @@ For DSRs from other products related to the service, see the following articles:
- [Windows diagnostic data](/compliance/regulatory/gdpr-dsr-windows)
- [Microsoft Intune data](/compliance/regulatory/gdpr-dsr-intune)
-- [Azure Active Directory data](/compliance/regulatory/gdpr-dsr-azure)
+- [Microsoft Entra data](/compliance/regulatory/gdpr-dsr-azure)
## Legal
diff --git a/windows/deployment/windows-autopatch/prepare/windows-autopatch-configure-network.md b/windows/deployment/windows-autopatch/prepare/windows-autopatch-configure-network.md
index 76fb999285..c7695ea433 100644
--- a/windows/deployment/windows-autopatch/prepare/windows-autopatch-configure-network.md
+++ b/windows/deployment/windows-autopatch/prepare/windows-autopatch-configure-network.md
@@ -44,7 +44,7 @@ There are URLs from several Microsoft products that must be in the allowed list
| ----- | ----- |
| Windows 10/11 Enterprise including Windows Update for Business | [Manage connection endpoints for Windows 10 Enterprise, version 1909](/windows/privacy/manage-windows-1909-endpoints)[Manage connection endpoints for Windows 10 Enterprise, version 2004](/windows/privacy/manage-windows-2004-endpoints)
[Connection endpoints for Windows 10 Enterprise, version 20H2](/windows/privacy/manage-windows-20h2-endpoints)
[Manage connection endpoints for Windows 10 Enterprise, version 21H1](/windows/privacy/manage-windows-21h1-endpoints)
[Manage connection endpoints for Windows 10 Enterprise, version 21H2](/windows/privacy/manage-windows-21h2-endpoints)
[Manage connection endpoints for Windows 11 Enterprise](/windows/privacy/manage-windows-11-endpoints)
|
| Microsoft 365 | [Microsoft 365 URL and IP address ranges](/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide&preserve-view=true) |
-| Azure Active Directory | [Hybrid identity required ports and protocols](/azure/active-directory/hybrid/reference-connect-ports)[Active Directory and Active Directory Domain Services Port Requirements](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd772723(v=ws.10))
|
+| Microsoft Entra ID | [Hybrid identity required ports and protocols](/azure/active-directory/hybrid/reference-connect-ports)[Active Directory and Active Directory Domain Services Port Requirements](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd772723(v=ws.10))
|
| Microsoft Intune | [Intune network configuration requirements](/intune/network-bandwidth-use)[Network endpoints for Microsoft Intune](/mem/intune/fundamentals/intune-endpoints)
| Microsoft Edge | [Allowlist for Microsoft Edge Endpoints](/deployedge/microsoft-edge-security-endpoints) |
| Microsoft Teams | [Office 365 URLs and IP address ranges](/microsoft-365/enterprise/urls-and-ip-address-ranges) |
diff --git a/windows/deployment/windows-autopatch/prepare/windows-autopatch-enroll-tenant.md b/windows/deployment/windows-autopatch/prepare/windows-autopatch-enroll-tenant.md
index 3a6e0a1197..95f0ed85fc 100644
--- a/windows/deployment/windows-autopatch/prepare/windows-autopatch-enroll-tenant.md
+++ b/windows/deployment/windows-autopatch/prepare/windows-autopatch-enroll-tenant.md
@@ -33,7 +33,7 @@ To start using the Windows Autopatch service, ensure you meet the [Windows Autop
> [!IMPORTANT]
> The online Readiness assessment tool helps you check your readiness to enroll in Windows Autopatch for the first time. Once you enroll, you'll no longer be able to access the tool again.
-The Readiness assessment tool checks the settings in [Microsoft Intune](#microsoft-intune-settings) and [Azure Active Directory](#azure-active-directory-settings) (Azure AD) to ensure the settings work with Windows Autopatch. We aren't, however, checking the workloads in Configuration Manager necessary for Windows Autopatch. For more information about workload prerequisites, see [Configuration Manager co-management requirements](../prepare/windows-autopatch-prerequisites.md#configuration-manager-co-management-requirements).
+The Readiness assessment tool checks the settings in [Microsoft Intune](#microsoft-intune-settings) and [Microsoft Entra ID](#azure-active-directory-settings) (Microsoft Entra ID) to ensure the settings work with Windows Autopatch. We aren't, however, checking the workloads in Configuration Manager necessary for Windows Autopatch. For more information about workload prerequisites, see [Configuration Manager co-management requirements](../prepare/windows-autopatch-prerequisites.md#configuration-manager-co-management-requirements).
**To access and run the Readiness assessment tool:**
@@ -56,9 +56,11 @@ The following are the Microsoft Intune settings:
| ----- | ----- |
| Deployment rings for Windows 10 or later | Verifies that Intune's deployment rings for Windows 10 or later policy doesn't target all users or all devices. Policies of this type shouldn't target any Windows Autopatch devices. For more information, see [Configure deployment rings for Windows 10 and later in Intune](/mem/intune/protect/windows-10-update-rings). |
-### Azure Active Directory settings
+
-The following are the Azure Active Directory settings:
+### Microsoft Entra settings
+
+The following are the Microsoft Entra settings:
| Check | Description |
| ----- | ----- |
@@ -74,7 +76,7 @@ For each check, the tool reports one of four possible results:
| Ready | No action is required before completing enrollment. |
| Advisory | Follow the steps in the tool or this article for the best experience with enrollment and for users.You can complete enrollment, but you must fix these issues before you deploy your first device. |
| Not ready | You must fix these issues before enrollment. You can't enroll into Windows Autopatch if you don't fix these issues. Follow the steps in the tool or this article to resolve them. |
-| Error | The Azure Active Directory (AD) role you're using doesn't have sufficient permissions to run this check. |
+| Error | The Microsoft Entra role you're using doesn't have sufficient permissions to run this check. |
## Step 3: Fix issues with your tenant
@@ -104,7 +106,7 @@ Once these actions are complete, you've now successfully enrolled your tenant.
You can choose to delete the data we collect directly within the Readiness assessment tool.
-Windows Autopatch retains the data associated with these checks for 12 months after the last time you ran a check in your Azure Active Directory organization (tenant). After 12 months, we retain the data in a deidentified form.
+Windows Autopatch retains the data associated with these checks for 12 months after the last time you ran a check in your Microsoft Entra organization (tenant). After 12 months, we retain the data in a deidentified form.
> [!NOTE]
> Windows Autopatch will only delete the results we collect within the Readiness assessment tool; Autopatch won't delete any other tenant-level data.
diff --git a/windows/deployment/windows-autopatch/prepare/windows-autopatch-fix-issues.md b/windows/deployment/windows-autopatch/prepare/windows-autopatch-fix-issues.md
index 39f30591e9..8acdf328e5 100644
--- a/windows/deployment/windows-autopatch/prepare/windows-autopatch-fix-issues.md
+++ b/windows/deployment/windows-autopatch/prepare/windows-autopatch-fix-issues.md
@@ -31,10 +31,10 @@ For each check, the tool reports one of four possible results:
| Ready | No action is required before completing enrollment. |
| Advisory | Follow the steps in the tool or this article for the best experience with enrollment and for users.
You can complete enrollment, but you must fix these issues before you deploy your first device. |
| Not ready | You must fix these issues before enrollment. You can't enroll into Windows Autopatch if you don't fix these issues. Follow the steps in the tool or this article to resolve them. |
-| Error | The Azure Active Directory (AD) role you're using doesn't have sufficient permission to run this check or your tenant isn't properly licensed for Microsoft Intune. |
+| Error | The Microsoft Entra role you're using doesn't have sufficient permission to run this check or your tenant isn't properly licensed for Microsoft Intune. |
> [!NOTE]
-> The results reported by this tool reflect the status of your settings only at the time that you ran it. If you make changes later to policies in Microsoft Intune, Azure Active Directory (AD), or Microsoft 365, items that were "Ready" can become "Not ready". To avoid problems with Windows Autopatch operations, review the specific settings described in this article before you change any policies.
+> The results reported by this tool reflect the status of your settings only at the time that you ran it. If you make changes later to policies in Microsoft Intune, Microsoft Entra ID, or Microsoft 365, items that were "Ready" can become "Not ready". To avoid problems with Windows Autopatch operations, review the specific settings described in this article before you change any policies.
## Microsoft Intune settings
@@ -48,9 +48,11 @@ Your "Update rings for Windows 10 or later" policy in Intune must not target any
| ----- | ----- |
| Advisory | You have an "update ring" policy that targets all devices, all users, or both. Windows Autopatch creates our own update ring policies during enrollment. To avoid conflicts with Windows Autopatch devices, we exclude our devices group from your existing update ring policies that target all devices, all users, or both. You must consent to this change when you go to enroll your tenant.
|
-## Azure Active Directory settings
+
-You can access Azure Active Directory (AD) settings in the [Azure portal](https://portal.azure.com/).
+## Microsoft Entra settings
+
+You can access Microsoft Entra settings in the [Azure portal](https://portal.azure.com/).
### Co-management
@@ -66,4 +68,4 @@ Windows Autopatch requires the following licenses:
| Result | Meaning |
| ----- | ----- |
-| Not ready | Windows Autopatch requires Windows 10/11 Enterprise E3 (or higher) to be assigned to your users. Additionally, Azure Active Directory Premium, and Microsoft Intune are required. For more information, see [more about licenses](../prepare/windows-autopatch-prerequisites.md#more-about-licenses). |
+| Not ready | Windows Autopatch requires Windows 10/11 Enterprise E3 (or higher) to be assigned to your users. Additionally, Microsoft Entra ID P1 or P2, and Microsoft Intune are required. For more information, see [more about licenses](../prepare/windows-autopatch-prerequisites.md#more-about-licenses). |
diff --git a/windows/deployment/windows-autopatch/prepare/windows-autopatch-prerequisites.md b/windows/deployment/windows-autopatch/prepare/windows-autopatch-prerequisites.md
index 90e7324a39..b0df16842e 100644
--- a/windows/deployment/windows-autopatch/prepare/windows-autopatch-prerequisites.md
+++ b/windows/deployment/windows-autopatch/prepare/windows-autopatch-prerequisites.md
@@ -21,9 +21,9 @@ Getting started with Windows Autopatch has been designed to be easy. This articl
| Area | Prerequisite details |
| ----- | ----- |
-| Licensing | Windows Autopatch requires Windows 10/11 Enterprise E3 (or higher) to be assigned to your users. Additionally, Azure Active Directory Premium and Microsoft Intune are required. For details about the specific service plans, see [more about licenses](#more-about-licenses).For more information on available licenses, see [Microsoft 365 licensing](https://www.microsoft.com/microsoft-365/compare-microsoft-365-enterprise-plans).
For more information about licensing terms and conditions for products and services purchased through Microsoft Commercial Volume Licensing Programs, see the [Product Terms site](https://www.microsoft.com/licensing/terms/). |
+| Licensing | Windows Autopatch requires Windows 10/11 Enterprise E3 (or higher) to be assigned to your users. Additionally, Microsoft Entra ID P1 or P2 and Microsoft Intune are required. For details about the specific service plans, see [more about licenses](#more-about-licenses).
For more information on available licenses, see [Microsoft 365 licensing](https://www.microsoft.com/microsoft-365/compare-microsoft-365-enterprise-plans).
For more information about licensing terms and conditions for products and services purchased through Microsoft Commercial Volume Licensing Programs, see the [Product Terms site](https://www.microsoft.com/licensing/terms/). |
| Connectivity | All Windows Autopatch devices require connectivity to multiple Microsoft service endpoints from the corporate network.
For the full list of required IPs and URLs, see [Configure your network](../prepare/windows-autopatch-configure-network.md). |
-| Azure Active Directory | Azure Active Directory must either be the source of authority for all user accounts, or user accounts must be synchronized from on-premises Active Directory using the latest supported version of Azure Active Directory Connect to enable Hybrid Azure Active Directory join.
- For more information, see [Azure Active Directory Connect](/azure/active-directory/hybrid/whatis-azure-ad-connect) and [Hybrid Azure Active Directory join](/azure/active-directory/devices/howto-hybrid-azure-ad-join)
- For more information on supported Azure Active Directory Connect versions, see [Azure AD Connect:Version release history](/azure/active-directory/hybrid/reference-connect-version-history).
|
+| Microsoft Entra ID | Microsoft Entra ID must either be the source of authority for all user accounts, or user accounts must be synchronized from on-premises Active Directory using the latest supported version of Microsoft Entra Connect to enable Microsoft Entra hybrid join.
- For more information, see [Microsoft Entra Connect](/azure/active-directory/hybrid/whatis-azure-ad-connect) and [Microsoft Entra hybrid join](/azure/active-directory/devices/howto-hybrid-azure-ad-join)
- For more information on supported Microsoft Entra Connect versions, see [Microsoft Entra Connect:Version release history](/azure/active-directory/hybrid/reference-connect-version-history).
|
| Device management | [Devices must be already enrolled with Microsoft Intune](/mem/intune/user-help/enroll-windows-10-device) prior to registering with Windows Autopatch. Intune must be set as the Mobile Device Management (MDM) authority or co-management must be turned on and enabled on the target devices.At a minimum, the Windows Update, Device configuration and Office Click-to-Run apps workloads must be set to Pilot Intune or Intune. You must also ensure that the devices you intend on bringing to Windows Autopatch are in the targeted device collection. For more information, see [co-management requirements for Windows Autopatch](#configuration-manager-co-management-requirements).
Other device management prerequisites include:
- Devices must be corporate-owned. Windows bring-your-own-devices (BYOD) are blocked during device registration prerequisite checks.
- Devices must be managed by either Intune or Configuration Manager co-management. Devices only managed by Configuration Manager aren't supported.
- Devices must be in communication with Microsoft Intune in the **last 28 days**. Otherwise, the devices won't be registered with Autopatch.
- Devices must be connected to the internet.
- Devices must have a **Serial number**, **Model** and **Manufacturer**. Device emulators that don't generate this information fail to meet **Intune or Cloud-attached** prerequisite check.
See [Register your devices](/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices) for more details on device prerequisites and on how the device registration process works with Windows Autopatch.
For more information on co-management, see [co-management for Windows devices](/mem/configmgr/comanage/overview).
|
| Data and privacy | For more information on Windows Autopatch privacy practices, see [Windows Autopatch Privacy](../overview/windows-autopatch-privacy.md). |
diff --git a/windows/deployment/windows-autopatch/references/windows-autopatch-changes-to-tenant.md b/windows/deployment/windows-autopatch/references/windows-autopatch-changes-to-tenant.md
index f0c9059f9c..30030ec7cc 100644
--- a/windows/deployment/windows-autopatch/references/windows-autopatch-changes-to-tenant.md
+++ b/windows/deployment/windows-autopatch/references/windows-autopatch-changes-to-tenant.md
@@ -34,13 +34,15 @@ Windows Autopatch creates an enterprise application in your tenant. This enterpr
### 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 Azure Active Directory](/azure/active-directory/develop/app-objects-and-service-principals#service-principal-object). The service principal created by Windows Autopatch is:
+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
-## Azure Active Directory groups
+
-Windows Autopatch will create the required Azure Active Directory groups to operate the service.
+## Microsoft Entra groups
+
+Windows Autopatch will create the required Microsoft Entra groups to operate the service.
The following groups target Windows Autopatch configurations to devices and management of the service by our [first party enterprise applications](#windows-autopatch-enterprise-applications).
diff --git a/windows/deployment/windows-autopatch/references/windows-autopatch-driver-and-firmware-updates-public-preview-addendum.md b/windows/deployment/windows-autopatch/references/windows-autopatch-driver-and-firmware-updates-public-preview-addendum.md
index 00eb8bc49b..21d90312fd 100644
--- a/windows/deployment/windows-autopatch/references/windows-autopatch-driver-and-firmware-updates-public-preview-addendum.md
+++ b/windows/deployment/windows-autopatch/references/windows-autopatch-driver-and-firmware-updates-public-preview-addendum.md
@@ -26,4 +26,4 @@ Capitalized terms used but not defined herein have the meanings given in the Pro
## Data Handling
-Driver and Firmware Updates Preview integrates Customer Data from other Products, including Windows, Microsoft Intune, Azure Active Directory, and Office (collectively for purposes of this provision "Windows Autopatch Input Services"). Once Customer Data from Windows Autopatch Input Services is integrated into Driver and Firmware Updates Preview, only the Product Terms and [DPA provisions](https://www.microsoft.com/licensing/terms/product/Glossary/all) applicable to Driver and Firmware Updates Preview apply to that data.
+Driver and Firmware Updates Preview integrates Customer Data from other Products, including Windows, Microsoft Intune, Microsoft Entra ID, and Office (collectively for purposes of this provision "Windows Autopatch Input Services"). Once Customer Data from Windows Autopatch Input Services is integrated into Driver and Firmware Updates Preview, only the Product Terms and [DPA provisions](https://www.microsoft.com/licensing/terms/product/Glossary/all) applicable to Driver and Firmware Updates Preview apply to that data.
diff --git a/windows/deployment/windows-autopatch/whats-new/windows-autopatch-whats-new-2023.md b/windows/deployment/windows-autopatch/whats-new/windows-autopatch-whats-new-2023.md
index 31f2216143..e800c3533c 100644
--- a/windows/deployment/windows-autopatch/whats-new/windows-autopatch-whats-new-2023.md
+++ b/windows/deployment/windows-autopatch/whats-new/windows-autopatch-whats-new-2023.md
@@ -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: 10/04/2023
+ms.date: 10/19/2023
ms.prod: windows-client
ms.technology: itpro-updates
ms.topic: whats-new
@@ -21,6 +21,14 @@ This article lists new and updated feature releases, and service releases, with
Minor corrections such as typos, style, or formatting issues aren't listed.
+## October 2023
+
+## October service release
+
+| Message center post number | Description |
+| ----- | ----- |
+| [MC680344](https://admin.microsoft.com/adminportal/home#/MessageCenter) | Planned Maintenance: Service Improvements |
+
## September 2023
### September feature releases or updates
diff --git a/windows/hub/breadcrumb/toc.yml b/windows/hub/breadcrumb/toc.yml
index b8fb1254fb..211570e4b0 100644
--- a/windows/hub/breadcrumb/toc.yml
+++ b/windows/hub/breadcrumb/toc.yml
@@ -1,67 +1,3 @@
-items:
- - name: Docs
- tocHref: /
- topicHref: /
- items:
- - name: Windows
- tocHref: /windows/
- topicHref: /windows/resources/
- items:
- - name: What's new
- tocHref: /windows/whats-new/
- topicHref: /windows/whats-new/
- - name: Configuration
- tocHref: /windows/configuration/
- topicHref: /windows/configuration/
- - name: Deployment
- tocHref: /windows/deployment/
- topicHref: /windows/deployment/
- items:
- - name: Delivery Optimization
- tocHref: /windows/deployment/do/
- topicHref: /windows/deployment/do/
- - name: Application management
- tocHref: /windows/application-management/
- topicHref: /windows/application-management/
- - name: Client management
- tocHref: /windows/client-management/
- topicHref: /windows/client-management/
- items:
- - name: CSP reference
- tocHref: /windows/client-management/mdm/
- topicHref: /windows/client-management/mdm/
- - name: Privacy
- tocHref: /windows/privacy/
- topicHref: /windows/privacy/
- - name: Security
- tocHref: /windows/security/
- topicHref: /windows/security/
- items:
- - name: Hardware security
- tocHref: /windows/security/hardware-security/
- topicHref: /windows/security/hardware-security/
- - name: Operating system security
- tocHref: /windows/security/operating-system-security/
- topicHref: /windows/security/operating-system-security/
- - name: Identity protection
- tocHref: /windows/security/identity-protection/
- topicHref: /windows/security/identity-protection/
- - name: Application security
- tocHref: /windows/security/application-security/
- topicHref: /windows/security/application-security/
- items:
- - name: Application Control for Windows
- tocHref: /windows/security/application-security/application-control/windows-defender-application-control/
- topicHref: /windows/security/application-security/application-control/windows-defender-application-control/
- - name: Microsoft Defender Application Guard
- tocHref: /windows/security/application-security/application-isolation/microsoft-defender-application-guard/
- topicHref: /windows/security/application-security/application-isolation/microsoft-defender-application-guard/md-app-guard-overview
- - name: Security foundations
- tocHref: /windows/security/security-foundations/
- topicHref: /windows/security/security-foundations/
- - name: Security auditing
- tocHref: /windows/security/threat-protection/auditing/
- topicHref: /windows/security/threat-protection/auditing/security-auditing-overview
- - name: Security policy settings
- tocHref: /windows/security/threat-protection/security-policy-settings/
- topicHref: /windows/security/threat-protection/security-policy-settings/security-policy-settings
\ No newline at end of file
+- name: Windows
+ tocHref: /windows/
+ topicHref: /windows/index
diff --git a/windows/security/cloud-security/toc.yml b/windows/security/cloud-security/toc.yml
index 7c46b6e146..4132706858 100644
--- a/windows/security/cloud-security/toc.yml
+++ b/windows/security/cloud-security/toc.yml
@@ -1,7 +1,7 @@
items:
- name: Overview
href: index.md
-- name: Join Active Directory and Azure AD with single sign-on (SSO) 🔗
+- name: Join Active Directory and Microsoft Entra ID with single sign-on (SSO) 🔗
href: /azure/active-directory/devices/concept-azure-ad-join
- name: Security baselines with Intune 🔗
href: /mem/intune/protect/security-baselines
@@ -15,4 +15,3 @@ items:
href: /windows/deployment/windows-autopatch
- name: Windows Autopilot 🔗
href: /windows/deployment/windows-autopilot
-
diff --git a/windows/security/hardware-security/tpm/how-windows-uses-the-tpm.md b/windows/security/hardware-security/tpm/how-windows-uses-the-tpm.md
index b150c5e788..e75ebe55d6 100644
--- a/windows/security/hardware-security/tpm/how-windows-uses-the-tpm.md
+++ b/windows/security/hardware-security/tpm/how-windows-uses-the-tpm.md
@@ -57,7 +57,7 @@ For TPM-based virtual smart cards, the TPM protects the use and storage of the c
Windows Hello for Business provides authentication methods intended to replace passwords, which can be difficult to remember and easily compromised. In addition, username/password solutions for authentication often reuse the same credential combinations on multiple devices and services. If those credentials are compromised, they are compromised in multiple places. Windows Hello for Business combines the information provisioned on each device (i.e., the cryptographic key) with additional information to authenticate users. On a system that has a TPM, the TPM can protect the key. If a system does not have a TPM, software-based techniques protect the key. The additional information the user supplies can be a PIN value or, if the system has the necessary hardware, biometric information, such as fingerprint or facial recognition. To protect privacy, the biometric information is used only on the provisioned device to access the provisioned key: it is not shared across devices.
-The adoption of new authentication technology requires that identity providers and organizations deploy and use that technology. Windows Hello for Business lets users authenticate with their existing Microsoft account, an Active Directory account, a Microsoft Azure Active Directory account, or even non-Microsoft Identity Provider Services or Relying Party Services that support [Fast ID Online V2.0 authentication](https://go.microsoft.com/fwlink/p/?LinkId=533889).
+The adoption of new authentication technology requires that identity providers and organizations deploy and use that technology. Windows Hello for Business lets users authenticate with their existing Microsoft account, an Active Directory account, a Microsoft Entra account, or even non-Microsoft Identity Provider Services or Relying Party Services that support [Fast ID Online V2.0 authentication](https://go.microsoft.com/fwlink/p/?LinkId=533889).
Identity providers have flexibility in how they provision credentials on client devices. For example, an organization might provision only those devices that have a TPM so that the organization knows that a TPM protects the credentials. The ability to distinguish a TPM from malware acting like a TPM requires the following TPM capabilities (see Figure 1):
diff --git a/windows/security/hardware-security/tpm/tpm-recommendations.md b/windows/security/hardware-security/tpm/tpm-recommendations.md
index a4d4b53a79..afea335006 100644
--- a/windows/security/hardware-security/tpm/tpm-recommendations.md
+++ b/windows/security/hardware-security/tpm/tpm-recommendations.md
@@ -104,7 +104,7 @@ The following table defines which Windows features require TPM support.
Windows Defender System Guard (DRTM) | Yes | No | Yes | TPM 2.0 and UEFI firmware is required.
Credential Guard | No | Yes | Yes | Windows 10, version 1507 (End of Life as of May 2017) only supported TPM 2.0 for Credential Guard. Beginning with Windows 10, version 1511, TPM 1.2 and 2.0 are supported. Paired with Windows Defender System Guard, TPM 2.0 provides enhanced security for Credential Guard. Windows 11 requires TPM 2.0 by default to facilitate easier enablement of this enhanced security for customers.
Device Health Attestation| Yes | Yes | Yes | TPM 2.0 is recommended since it supports newer cryptographic algorithms. TPM 1.2 only supports the SHA-1 algorithm which is being deprecated.
- Windows Hello/Windows Hello for Business| No | Yes | Yes | Azure AD join supports both versions of TPM, but requires TPM with keyed-hash message authentication code (HMAC) and Endorsement Key (EK) certificate for key attestation support. TPM 2.0 is recommended over TPM 1.2 for better performance and security. Windows Hello as a FIDO platform authenticator will take advantage of TPM 2.0 for key storage.
+ Windows Hello/Windows Hello for Business| No | Yes | Yes | Microsoft Entra join supports both versions of TPM, but requires TPM with keyed-hash message authentication code (HMAC) and Endorsement Key (EK) certificate for key attestation support. TPM 2.0 is recommended over TPM 1.2 for better performance and security. Windows Hello as a FIDO platform authenticator will take advantage of TPM 2.0 for key storage.
UEFI Secure Boot | No | Yes | Yes
TPM Platform Crypto Provider Key Storage Provider| Yes | Yes | Yes
Virtual Smart Card | Yes | Yes | Yes
diff --git a/windows/security/identity-protection/credential-guard/how-it-works.md b/windows/security/identity-protection/credential-guard/how-it-works.md
index 69eef9c3f9..f69a8b0486 100644
--- a/windows/security/identity-protection/credential-guard/how-it-works.md
+++ b/windows/security/identity-protection/credential-guard/how-it-works.md
@@ -28,7 +28,7 @@ Some ways to store credentials aren't protected by Credential Guard, including:
- Third-party security packages
- When Credential Guard is enabled, NTLMv1, MS-CHAPv2, Digest, and CredSSP can't use the signed-in credentials. Thus, single sign-on doesn't work with these protocols. However, applications can prompt for credentials or use credentials stored in the Windows Vault, which aren't protected by Credential Guard with any of these protocols
> [!CAUTION]
- > It's recommended that valuable credentials, such as the sign-in credentials, aren't used with NTLMv1, MS-CHAPv2, Digest, or CredSSP protocols. If these protocols must be used by domain or Azure AD users, secondary credentials should be provisioned for these use cases.
+ > It's recommended that valuable credentials, such as the sign-in credentials, aren't used with NTLMv1, MS-CHAPv2, Digest, or CredSSP protocols. If these protocols must be used by domain or Microsoft Entra users, secondary credentials should be provisioned for these use cases.
- Supplied credentials for NTLM authentication aren't protected. If a user is prompted for and enters credentials for NTLM authentication, these credentials are vulnerable to be read from LSASS memory. These same credentials are vulnerable to key loggers as well
- Kerberos service tickets aren't protected by Credential Guard, but the Kerberos Ticket Granting Ticket (TGT) is protected
- When Credential Guard is enabled, Kerberos doesn't allow *unconstrained Kerberos delegation* or *DES encryption*, not only for signed-in credentials, but also prompted or saved credentials
diff --git a/windows/security/identity-protection/hello-for-business/hello-aad-join-cloud-only-deploy.md b/windows/security/identity-protection/hello-for-business/hello-aad-join-cloud-only-deploy.md
index d053855ed5..58eac4892c 100644
--- a/windows/security/identity-protection/hello-for-business/hello-aad-join-cloud-only-deploy.md
+++ b/windows/security/identity-protection/hello-for-business/hello-aad-join-cloud-only-deploy.md
@@ -15,7 +15,7 @@ When you Microsoft Entra join a Windows device, the system prompts you to enroll
You may wish to disable the automatic Windows Hello for Business enrollment prompts if you aren't ready to use it in your environment. This article describes how to disable Windows Hello for Business enrollment in a cloud only environment.
> [!NOTE]
-> During the out-of-box experience (OOBE) flow of an Microsoft Entra join, you will see a provisioning PIN when you don't have Intune. You can always cancel the PIN screen and set this cancellation with registry keys to prevent future prompts.
+> During the out-of-box experience (OOBE) flow of a Microsoft Entra join, you will see a provisioning PIN when you don't have Intune. You can always cancel the PIN screen and set this cancellation with registry keys to prevent future prompts.
## Prerequisites
@@ -58,7 +58,7 @@ The following method explains how to disable Windows Hello for Business enrollme
## Disable Windows Hello for Business enrollment without Intune
-If you don't use Intune in your organization, then you can disable Windows Hello for Business using the registry. You can use a third-party MDM, or some other method that you use to manage these devices. Because these systems are Azure AD Joined only, and not domain joined, these settings can also be made manually in the registry.
+If you don't use Intune in your organization, then you can disable Windows Hello for Business using the registry. You can use a third-party MDM, or some other method that you use to manage these devices. Because these systems are Microsoft Entra joined only, and not domain joined, these settings can also be made manually in the registry.
Intune uses the following registry keys: **`HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Policies\PassportForWork\\Device\Policies`**
diff --git a/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-deploy-mfa.md b/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-deploy-mfa.md
index 83576f884f..087d2813e3 100644
--- a/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-deploy-mfa.md
+++ b/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-deploy-mfa.md
@@ -1,6 +1,6 @@
---
title: Validate and Deploy MFA for Windows Hello for Business with certificate trust
-description: Validate and deploy multi-factor authentication (MFA) for Windows Hello for Business in an on-premises certificate trust model.
+description: Validate and deploy multifactor authentication (MFA) for Windows Hello for Business in an on-premises certificate trust model.
ms.date: 09/07/2023
appliesto:
- ✅ Windows 11
@@ -11,21 +11,21 @@ appliesto:
ms.topic: tutorial
---
-# Validate and deploy multi-factor authentication - on-premises certificate trust
+# Validate and deploy multifactor authentication - on-premises certificate trust
[!INCLUDE [hello-on-premises-cert-trust](./includes/hello-on-premises-cert-trust.md)]
-Windows Hello for Business requires users perform multi-factor authentication (MFA) prior to enroll in the service. On-premises deployments can use, as MFA option:
+Windows Hello for Business requires users perform multifactor authentication (MFA) prior to enroll in the service. On-premises deployments can use, as MFA option:
- third-party authentication providers for AD FS
- custom authentication provider for AD FS
> [!IMPORTANT]
-> As of July 1, 2019, Microsoft will no longer offer MFA Server for new deployments. New customers who would like to require multi-factor authentication from their users should use cloud-based Azure AD Multi-Factor Authentication. Existing customers who have activated MFA Server prior to July 1 will be able to download the latest version, future updates and generate activation credentials as usual.
+> As of July 1, 2019, Microsoft will no longer offer MFA Server for new deployments. New customers who would like to require multifactor authentication from their users should use cloud-based Microsoft Entra multifactor authentication. Existing customers who have activated MFA Server prior to July 1 will be able to download the latest version, future updates and generate activation credentials as usual.
For information about third-party authentication methods, see [Configure Additional Authentication Methods for AD FS](/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs). To create a custom authentication method, see [Build a Custom Authentication Method for AD FS in Windows Server](/windows-server/identity/ad-fs/development/ad-fs-build-custom-auth-method).
-Follow the integration and deployment guide for the authentication provider you plan to integrate to AD FS. Make sure that the authentication provider is selected as a multi-factor authentication option in the AD FS authentication policy. For information on configuring AD FS authentication policies, see [Configure Authentication Policies](/windows-server/identity/ad-fs/operations/configure-authentication-policies).
+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)
\ No newline at end of file
+> [Next: configure Windows Hello for Business Policy settings](hello-cert-trust-policy-settings.md)
diff --git a/windows/security/identity-protection/hello-for-business/hello-deployment-guide.md b/windows/security/identity-protection/hello-for-business/hello-deployment-guide.md
index aef79952c9..8b24e78f64 100644
--- a/windows/security/identity-protection/hello-for-business/hello-deployment-guide.md
+++ b/windows/security/identity-protection/hello-for-business/hello-deployment-guide.md
@@ -30,9 +30,9 @@ Do not begin your deployment until the hosting servers and infrastructure (not r
## Deployment and trust models
-Windows Hello for Business has three deployment models: Azure AD cloud only, hybrid, and on-premises. Hybrid has three trust models: *Key Trust*, *Certificate Trust*, and *cloud Kerberos trust*. On-premises deployment models only support *Key Trust* and *Certificate Trust*.
+Windows Hello for Business has three deployment models: Microsoft Entra cloud only, hybrid, and on-premises. Hybrid has three trust models: *Key Trust*, *Certificate Trust*, and *cloud Kerberos trust*. On-premises deployment models only support *Key Trust* and *Certificate Trust*.
-Hybrid deployments are for enterprises that use Azure Active Directory. On-premises deployments are for enterprises who exclusively use on-premises Active Directory. Remember that the environments that use Azure Active Directory must use the hybrid deployment model for all domains in that forest.
+Hybrid deployments are for enterprises that use Microsoft Entra ID. On-premises deployments are for enterprises who exclusively use on-premises Active Directory. Remember that the environments that use Microsoft Entra ID must use the hybrid deployment model for all domains in that forest.
The trust model determines how you want users to authenticate to the on-premises Active Directory:
@@ -46,14 +46,14 @@ The trust model determines how you want users to authenticate to the on-premises
Following are the various deployment guides and models included in this topic:
-- [Hybrid Azure AD Joined cloud Kerberos trust Deployment](hello-hybrid-cloud-kerberos-trust.md)
-- [Hybrid Azure AD Joined Key Trust Deployment](hello-hybrid-key-trust.md)
-- [Hybrid Azure AD Joined Certificate Trust Deployment](hello-hybrid-cert-trust.md)
-- [Azure AD Join Single Sign-on Deployment Guides](hello-hybrid-aadj-sso.md)
+- [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)
-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 Azure Active Directory Connect to synchronize user accounts in the on-premises Active Directory with Azure Active Directory. For on-premises deployments, both key and certificate trust, use the Azure MFA server where the credentials are not synchronized to Azure Active Directory. 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/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.
## Provisioning
diff --git a/windows/security/identity-protection/hello-for-business/hello-deployment-issues.md b/windows/security/identity-protection/hello-for-business/hello-deployment-issues.md
index 7882589fd0..b5c4e51668 100644
--- a/windows/security/identity-protection/hello-for-business/hello-deployment-issues.md
+++ b/windows/security/identity-protection/hello-for-business/hello-deployment-issues.md
@@ -8,13 +8,15 @@ ms.topic: troubleshooting
The content of this article is to help troubleshoot known deployment issues for Windows Hello for Business.
-## PIN reset on Azure AD join devices fails with *We can't open that page right now* error
+
-PIN reset on Azure AD-joined devices uses a flow called *web sign-in* to authenticate the user above lock. Web sign in only allows navigation to specific domains. If web sign-in attempts to navigate to a domain that isn't allowed, it displays a page with the error message *We can't open that page right now*.
+## PIN reset on Microsoft Entra join devices fails with *We can't open that page right now* error
+
+PIN reset on Microsoft Entra joined devices uses a flow called *web sign-in* to authenticate the user above lock. Web sign in only allows navigation to specific domains. If web sign-in attempts to navigate to a domain that isn't allowed, it displays a page with the error message *We can't open that page right now*.
### Identify PIN Reset allowed domains issue
-The user can launch the PIN reset flow from the lock screen using the *I forgot my PIN* link in the PIN credential provider. Selecting the link launches a full screen UI for the PIN experience on Azure AD Join devices. Typically, the UI displays an Azure authentication page, where the user authenticates using Azure AD credentials and completes MFA.
+The user can launch the PIN reset flow from the lock screen using the *I forgot my PIN* link in the PIN credential provider. Selecting the link launches a full screen UI for the PIN experience on Microsoft Entra join devices. Typically, the UI displays an Azure authentication page, where the user authenticates using Microsoft Entra credentials and completes MFA.
In federated environments, authentication may be configured to route to AD FS or a third-party identity provider. If the PIN reset flow is launched and attempts to navigate to a federated identity provider server page, it fails and displays the *We can't open that page right now* error, if the domain for the server page isn't included in an allowlist.
@@ -22,7 +24,7 @@ If you're a customer of *Azure US Government* cloud, PIN reset also attempts to
### Resolve PIN Reset allowed domains issue
-To resolve the error, you can configure a list of allowed domains for PIN reset using the [ConfigureWebSignInAllowedUrls](/windows/client-management/mdm/policy-csp-authentication#authentication-configurewebsigninallowedurls) policy. For information on how to configure the policy, see [Configure allowed URLs for federated identity providers on Azure AD joined devices](hello-feature-pin-reset.md#configure-allowed-urls-for-federated-identity-providers-on-azure-ad-joined-devices).
+To resolve the error, you can configure a list of allowed domains for PIN reset using the [ConfigureWebSignInAllowedUrls](/windows/client-management/mdm/policy-csp-authentication#authentication-configurewebsigninallowedurls) policy. For information on how to configure the policy, see [Configure allowed URLs for federated identity providers on Microsoft Entra joined devices](hello-feature-pin-reset.md#configure-allowed-urls-for-federated-identity-providers-on-azure-ad-joined-devices).
## Hybrid key trust sign in broken due to user public key deletion
@@ -32,11 +34,11 @@ Applies to:
- Windows Server 2016, builds 14393.3930 to 14393.4048
- Windows Server 2019, builds 17763.1457 to 17763.1613
-In Hybrid key trust deployments with domain controllers running certain builds of Windows Server 2016 and Windows Server 2019, the user's Windows Hello for Business key is deleted after they sign-in. Subsequent sign-ins will fail until the user's key is synced during the next Azure AD Connect delta sync cycle.
+In Hybrid key trust deployments with domain controllers running certain builds of Windows Server 2016 and Windows Server 2019, the user's Windows Hello for Business key is deleted after they sign-in. Subsequent sign-ins will fail until the user's key is synced during the next Microsoft Entra Connect delta sync cycle.
### Identify user public key deletion issue
-After the user provisions a Windows Hello for Business credential in a hybrid key trust environment, the key must sync from Azure AD to AD during an Azure AD Connect sync cycle. The user's public key is written to the `msDS-KeyCredentialLink` attribute of the user object.
+After the user provisions a Windows Hello for Business credential in a hybrid key trust environment, the key must sync from Microsoft Entra ID to Active Directory during a Microsoft Entra Connect Sync cycle. The user's public key is written to the `msDS-KeyCredentialLink` attribute of the user object.
Before the user's Windows Hello for Business key syncs, sign-ins with Windows Hello for Business fail with the error message *That option is temporarily unavailable. For now, please use a different method to sign in.* After the key syncs successfully, the user can sign in and unlock with their PIN or enrolled biometrics.
@@ -48,14 +50,16 @@ After the initial sign-in attempt, the user's Windows Hello for Business public
To resolve the issue, update Windows Server 2016 and 2019 domain controllers with the latest patches. For Windows Server 2016, the behavior is fixed in build *14393.4104* ([KB4593226](https://support.microsoft.com/help/4593226)) and later. For Windows Server 2019, the behavior is fixed in build *17763.1637* ([KB4592440](https://support.microsoft.com/help/4592440)).
-## Azure AD joined device access to on-premises resources using key trust and third-party Certificate Authority (CA)
+
+
+## Microsoft Entra joined device access to on-premises resources using key trust and third-party Certificate Authority (CA)
Applies to:
-- Azure AD joined key trust deployments
+- Microsoft Entra joined key trust deployments
- Third-party certificate authority (CA) issuing domain controller certificates
-Windows Hello for Business uses smart-card based authentication for many operations. This type of authentication has special guidelines when using a third-party CA for certificate issuance, some of which apply to the domain controllers. Not all Windows Hello for Business deployment types require these configurations. Accessing on-premises resources from an Azure AD Joined device does require special configuration when using a third-party CA to issue domain controller certificates.
+Windows Hello for Business uses smart-card based authentication for many operations. This type of authentication has special guidelines when using a third-party CA for certificate issuance, some of which apply to the domain controllers. Not all Windows Hello for Business deployment types require these configurations. Accessing on-premises resources from a Microsoft Entra joined device does require special configuration when using a third-party CA to issue domain controller certificates.
For more information, read [Guidelines for enabling smart card sign in with third-party certification authorities](/troubleshoot/windows-server/windows-security/enabling-smart-card-logon-third-party-certification-authorities).
@@ -104,7 +108,7 @@ Domain controllers running early versions of Windows Server 2019 have an issue t
On the client, authentication with Windows Hello for Business fails with the error message, *That option is temporarily unavailable. For now, please use a different method to sign in.*
-The error is presented on hybrid Azure AD-joined devices in key trust deployments after Windows Hello for Business is provisioned, but before a user's key is synced from Azure AD to AD. If a user's key isn't synced from Azure AD and the `msDS-keycredentiallink` attribute on the user object in AD is populated for NGC, then it's possible that the error occurs.
+The error is presented on Microsoft Entra hybrid joined devices in key trust deployments after Windows Hello for Business is provisioned, but before a user's key is synced from Microsoft Entra ID to Active Directory. If a user's key isn't synced from Microsoft Entra ID and the `msDS-keycredentiallink` attribute on the user object in AD is populated for NGC, then it's possible that the error occurs.
Another indicator of the failure can be identified using network traces. If you capture network traces for a key trust sign-in event, the traces show Kerberos failing with the error *KDC_ERR_CLIENT_NAME_MISMATCH*.
diff --git a/windows/security/identity-protection/hello-for-business/hello-deployment-rdp-certs.md b/windows/security/identity-protection/hello-for-business/hello-deployment-rdp-certs.md
index 65be112a27..315ce4361f 100644
--- a/windows/security/identity-protection/hello-for-business/hello-deployment-rdp-certs.md
+++ b/windows/security/identity-protection/hello-for-business/hello-deployment-rdp-certs.md
@@ -18,13 +18,13 @@ This document describes Windows Hello for Business functionalities or scenarios
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 Azure AD-joined devices using Intune
+- 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 *hybrid Azure AD joined* devices only.
+> 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.
@@ -77,7 +77,7 @@ Follow these steps to create a certificate template:
### Request a certificate
-1. Sign in to a client that is hybrid Azure AD joined, ensuring that the client has line of sight to a domain controller and the issuing CA
+1. 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**
@@ -88,17 +88,17 @@ Follow these steps to create a certificate template:
## Deploy certificates via Intune
> [!CAUTION]
-> This process is applicable to both *Azure AD joined* and *hybrid Azure AD joined* devices that are managed via Intune.
+> 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 Azure AD joined or hybrid Azure AD 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:
+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 Azure AD joined Devices using a *Trusted root certificate* policy with Intune. For guidance, refer to [Create trusted certificate profiles in Microsoft Intune][MEM-5].
+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.
diff --git a/windows/security/identity-protection/hello-for-business/hello-errors-during-pin-creation.md b/windows/security/identity-protection/hello-for-business/hello-errors-during-pin-creation.md
index e63b129275..d048d6409f 100644
--- a/windows/security/identity-protection/hello-for-business/hello-errors-during-pin-creation.md
+++ b/windows/security/identity-protection/hello-for-business/hello-errors-during-pin-creation.md
@@ -22,15 +22,15 @@ When a user encounters an error when creating the work PIN, advise the user to t
1. Try to create the PIN again. Some errors are transient and resolve themselves.
2. Sign out, sign in, and try to create the PIN again.
3. Reboot the device and then try to create the PIN again.
-4. Unjoin the device from Azure Active Directory (Azure AD), rejoin, and then try to create the PIN again. To unjoin a device, go to **Settings > System > About > Disconnect from organization**.
+4. Unjoin the device from Microsoft Entra ID, rejoin, and then try to create the PIN again. To unjoin a device, go to **Settings > System > About > Disconnect from organization**.
If the error occurs again, check the error code against the following table to see if there is another mitigation for that error. When no mitigation is listed in the table, contact Microsoft Support for assistance.
| Hex | Cause | Mitigation |
| :--------- | :----------------------------------------------------------------- | :------------------------------------------ |
-| 0x80090005 | NTE\_BAD\_DATA | Unjoin the device from Azure AD and rejoin. |
-| 0x8009000F | The container or key already exists. | Unjoin the device from Azure AD and rejoin. |
-| 0x80090011 | The container or key was not found. | Unjoin the device from Azure AD and rejoin. |
+| 0x80090005 | NTE\_BAD\_DATA | Unjoin the device from Microsoft Entra ID and rejoin. |
+| 0x8009000F | The container or key already exists. | Unjoin the device from Microsoft Entra ID and rejoin. |
+| 0x80090011 | The container or key was not found. | Unjoin the device from Microsoft Entra ID and rejoin. |
| 0x80090029 | TPM is not set up. | Sign on with an administrator account. Select **Start**, type `tpm.msc`, and select **tpm.msc Microsoft Common Console Document**. In the **Actions** pane, select **Prepare the TPM**. |
| 0x8009002A | NTE\_NO\_MEMORY | Close programs which are taking up memory and try again. |
| 0x80090031 | NTE\_AUTHENTICATION\_IGNORED | Reboot the device. If the error occurs again after rebooting, [reset the TPM](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd851452(v=ws.11)) or run [Clear-TPM](/powershell/module/trustedplatformmodule/clear-tpm). |
@@ -50,11 +50,11 @@ If the error occurs again, check the error code against the following table to s
| 0x801C03EA | Server failed to authorize user or device. | Check if the token is valid and user has permission to register Windows Hello for Business keys. |
| 0x801C03EB | Server response http status is not valid | Sign out and then sign in again. |
| 0x801C03EC | Unhandled exception from server. | sign out and then sign in again. |
-| 0x801C03ED | Multi-factor authentication is required for a 'ProvisionKey' operation, but was not performed.
-or-
Token was not found in the Authorization header.
-or-
Failed to read one or more objects.
-or-
The request sent to the server was invalid.
-or-
User does not have permissions to join to Azure AD. | Sign out and then sign in again. If that doesn't resolve the issue, unjoin the device from Azure AD and rejoin.
Allow user(s) to join to Azure AD under Azure AD Device settings.
+| 0x801C03ED | Multi-factor authentication is required for a 'ProvisionKey' operation, but was not performed.
-or-
Token was not found in the Authorization header.
-or-
Failed to read one or more objects.
-or-
The request sent to the server was invalid.
-or-
User does not have permissions to join to Microsoft Entra ID. | Sign out and then sign in again. If that doesn't resolve the issue, unjoin the device from Azure AD and rejoin.
Allow user(s) to join to Microsoft Entra ID under Microsoft Entra Device settings.
| 0x801C03EE | Attestation failed. | Sign out and then sign in again. |
| 0x801C03EF | The AIK certificate is no longer valid. | Sign out and then sign in again. |
-| 0x801C03F2 | Windows Hello key registration failed. | ERROR\_BAD\_DIRECTORY\_REQUEST. Another object with the same value for property proxyAddresses already exists. To resolve the issue, refer to [Duplicate Attributes Prevent Dirsync](/office365/troubleshoot/administration/duplicate-attributes-prevent-dirsync). Also, if no sync conflict exists, please verify that the "Mail/Email address" in Azure Active Directory and the Primary SMTP address are the same in the proxy address.
-| 0x801C044D | Authorization token does not contain device ID. | Unjoin the device from Azure AD and rejoin. |
+| 0x801C03F2 | Windows Hello key registration failed. | ERROR\_BAD\_DIRECTORY\_REQUEST. Another object with the same value for property proxyAddresses already exists. To resolve the issue, refer to [Duplicate Attributes Prevent Dirsync](/office365/troubleshoot/administration/duplicate-attributes-prevent-dirsync). Also, if no sync conflict exists, please verify that the "Mail/Email address" in Microsoft Entra ID and the Primary SMTP address are the same in the proxy address.
+| 0x801C044D | Authorization token does not contain device ID. | Unjoin the device from Microsoft Entra ID and rejoin. |
| | Unable to obtain user token. | Sign out and then sign in again. Check network and credentials. |
| 0x801C044E | Failed to receive user credentials input. | Sign out and then sign in again. |
| 0x801C0451 | User token switch account. | Delete the Web Account Manager token broker files located in `%LOCALAPPDATA%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\AC\TokenBroker\Accounts\*.*\` and reboot.|
@@ -86,6 +86,5 @@ For errors listed in this table, contact Microsoft Support for assistance.
| 0x801C03F0 | There is no key registered for the user. |
| 0x801C03F1 | There is no UPN in the token. |
| 0x801C044C | There is no core window for the current thread. |
-| 0x801c004D | DSREG_NO_DEFAULT_ACCOUNT: NGC provisioning is unable to find the default WAM account to use to request Azure Active Directory token for provisioning. Unable to enroll a device to use a PIN for login. |
+| 0x801c004D | DSREG_NO_DEFAULT_ACCOUNT: NGC provisioning is unable to find the default WAM account to use to request Microsoft Entra token for provisioning. Unable to enroll a device to use a PIN for login. |
| 0xCAA30193 | HTTP 403 Request Forbidden: it means request left the device, however either Server, proxy or firewall generated this response. |
-
diff --git a/windows/security/identity-protection/hello-for-business/hello-faq.yml b/windows/security/identity-protection/hello-for-business/hello-faq.yml
index ca9a3ac20d..e289afe305 100644
--- a/windows/security/identity-protection/hello-for-business/hello-faq.yml
+++ b/windows/security/identity-protection/hello-for-business/hello-faq.yml
@@ -36,7 +36,7 @@ sections:
- question: What's a container?
answer: |
In the context of Windows Hello for Business, a container is a logical grouping of *key material* or data. Windows Hello uses a single container that holds user key material for personal accounts, including key material associated with the user's Microsoft account or with other consumer identity providers, and credentials associated with a workplace or school account.
- The container holds enterprise credentials only on devices that have been registered with an organization; it contains key material for the enterprise IDP, such as on-premises Active Directory or Azure AD.
+ The container holds enterprise credentials only on devices that have been registered with an organization; it contains key material for the enterprise IDP, such as on-premises Active Directory or Microsoft Entra ID.
> [!NOTE]
> There are no physical containers on disk, in the registry, or elsewhere. Containers are logical units used to group related items. The keys, certificates, and credentials that Windows Hello stores, are protected without the creation of actual containers or folders.
@@ -46,7 +46,7 @@ sections:
Containers can contain several types of key material:
- An authentication key, which is always an asymmetric public-private key pair. This key pair is generated during registration. It must be unlocked each time it's accessed, by using either the user's PIN or a biometric gesture. The authentication key exists until the user resets the PIN, at which time a new key will be generated. When the new key is generated, all the key material that the old key previously protected must be decrypted and re-encrypted using the new key.
- - The IDP key. These keys can be either symmetric or asymmetric, depending on which IDP you use. A single container may contain zero or more IDP keys, with some restrictions (for example, the enterprise container can contain zero or one IDP key). IDP keys are stored in the container. For certificate-based Windows Hello for Work, when the container is unlocked, applications that require access to the IDP key or key pair can request access. IDP keys are used to sign or encrypt authentication requests or tokens sent from this device to the IDP. IDP keys are typically long-lived but could have a shorter lifetime than the authentication key. Microsoft accounts, Active Directory accounts, and Azure AD accounts all require the use of asymmetric key pairs. The device generates public and private keys, registers the public key with the IDP (which stores it for later verification), and securely stores the private key. For enterprises, the IDP keys can be generated in two ways:
+ - The IDP key. These keys can be either symmetric or asymmetric, depending on which IDP you use. A single container may contain zero or more IDP keys, with some restrictions (for example, the enterprise container can contain zero or one IDP key). IDP keys are stored in the container. For certificate-based Windows Hello for Work, when the container is unlocked, applications that require access to the IDP key or key pair can request access. IDP keys are used to sign or encrypt authentication requests or tokens sent from this device to the IDP. IDP keys are typically long-lived but could have a shorter lifetime than the authentication key. Microsoft accounts, Active Directory accounts, and Microsoft Entra accounts all require the use of asymmetric key pairs. The device generates public and private keys, registers the public key with the IDP (which stores it for later verification), and securely stores the private key. For enterprises, the IDP keys can be generated in two ways:
- The IDP key pair can be associated with an enterprise Certificate Authority (CA) through the Windows Network Device Enrollment Service (NDES). In this case, Windows Hello requests a new certificate with the same key as the certificate from the existing PKI. This option lets organizations that have an existing PKI continue to use it where appropriate. Given that many applications, such as VPN solutions, require the use of certificates, when you deploy Windows Hello in this mode, it allows a faster transition away from user passwords while still preserving certificate-based functionality. This option also allows the enterprise to store additional certificates in the protected container.
- The IDP can generate the IDP key pair directly, which allows quick, lower-overhead deployment of Windows Hello in environments that don't have or need a PKI.
- question: How are keys protected?
@@ -54,7 +54,7 @@ sections:
Anytime key material is generated, it must be protected against attack. The most robust way to do this is through specialized hardware. There's a long history of using hardware security modules (HSMs) to generate, store, and process keys for security-critical applications. Smart cards are a special type of HSM, as are devices that are compliant with the Trusted Computing Group TPM standard. Wherever possible, the Windows Hello for Business implementation takes advantage of onboard TPM hardware to generate and protect keys. Administrators can choose to allow key operations in software, but it's recommended the use of TPM hardware. The TPM protects against a variety of known and potential attacks, including PIN brute-force attacks. The TPM provides an additional layer of protection after an account lockout, too. When the TPM has locked the key material, the user will have to reset the PIN (which means the user will have to use MFA to reauthenticate to the IDP before the IDP allows re-registration). Resetting the PIN means that all keys and certificates encrypted with the old key material will be removed.
- question: How does PIN caching work with Windows Hello for Business?
answer: |
- Windows Hello for Business provides a PIN caching user experience by using a ticketing system. Rather than caching a PIN, processes cache a ticket they can use to request private key operations. Azure AD and Active Directory sign-in keys are cached under lock. This means the keys remain available for use without prompting, as long as the user is interactively signed-in. Microsoft Account sign-in keys are transactional keys, which means the user is always prompted when accessing the key.
+ Windows Hello for Business provides a PIN caching user experience by using a ticketing system. Rather than caching a PIN, processes cache a ticket they can use to request private key operations. Microsoft Entra ID and Active Directory sign-in keys are cached under lock. This means the keys remain available for use without prompting, as long as the user is interactively signed-in. Microsoft Account sign-in keys are transactional keys, which means the user is always prompted when accessing the key.
Beginning with Windows 10, version 1709, Windows Hello for Business used as a smart card (smart card emulation that is enabled by default) provides the same user experience of default smart card PIN caching. Each process requesting a private key operation will prompt the user for the PIN on first use. Subsequent private key operations won't prompt the user for the PIN.
@@ -70,9 +70,9 @@ sections:
Since Windows Hello biometrics data is stored in encrypted format, no user, or any process other than Windows Hello has access to it.
- question: What's the difference between non-destructive and destructive PIN reset?
answer: |
- Windows Hello for Business has two types of PIN reset: non-destructive and destructive. Organizations running Windows 10 version 1903 and later and Azure Active Directory can take advantage of the Microsoft PIN Reset service. Once on-boarded to a tenant and deployed to computers, users who have forgotten their PINs can authenticate to Azure, provide a second factor of authentication, and reset their PIN without reprovisioning a new Windows Hello for Business enrollment. This flow is a non-destructive PIN reset because the user doesn't delete the current credential and obtain a new one. For more information, see [PIN Reset](hello-feature-pin-reset.md).
+ Windows Hello for Business has two types of PIN reset: non-destructive and destructive. Organizations running Windows 10 version 1903 and later and Microsoft Entra ID can take advantage of the Microsoft PIN Reset service. Once on-boarded to a tenant and deployed to computers, users who have forgotten their PINs can authenticate to Azure, provide a second factor of authentication, and reset their PIN without reprovisioning a new Windows Hello for Business enrollment. This flow is a non-destructive PIN reset because the user doesn't delete the current credential and obtain a new one. For more information, see [PIN Reset](hello-feature-pin-reset.md).
- Organizations that have the on-premises deployment of Windows Hello for Business, or those not using Windows 10 version 1903 and later can use destructive PIN reset. With destructive PIN reset, users that have forgotten their PIN can authenticate by using their password and then performing a second factor of authentication to reprovision their Windows Hello for Business credential. Reprovisioning deletes the old credential and requests a new credential and certificate. On-premises deployments need network connectivity to their domain controllers, Active Directory Federation Services, and their issuing certificate authority to perform a destructive PIN reset. For hybrid Azure Active Directory joined devices, destructive PIN reset is only supported with the certificate trust model and the latest updates to Active Directory Federation Services.
+ Organizations that have the on-premises deployment of Windows Hello for Business, or those not using Windows 10 version 1903 and later can use destructive PIN reset. With destructive PIN reset, users that have forgotten their PIN can authenticate by using their password and then performing a second factor of authentication to reprovision their Windows Hello for Business credential. Reprovisioning deletes the old credential and requests a new credential and certificate. On-premises deployments need network connectivity to their domain controllers, Active Directory Federation Services, and their issuing certificate authority to perform a destructive PIN reset. For Microsoft Entra hybrid joined devices, destructive PIN reset is only supported with the certificate trust model and the latest updates to Active Directory Federation Services.
- question: When is Windows Hello biometrics database file created? How is a user enrolled into Windows Hello face or fingerprint authentication?
answer: |
Windows Hello biometrics template database file is created on the device only when a user is enrolled into Windows Hello biometrics-based authentication. Your workplace or IT administrator may have turned certain authentication functionality, however, it is always your choice if you want to use Windows Hello or an alternative method, like a PIN. Users can check their current enrollment into Windows Hello biometrics by going to sign-in options on their device. Go to **Start > Settings > Accounts > Sign-in** options. If you don't see Windows Hello in Sign-in options, then it may not be available for your device or blocked by admin via policy. Admins can request users to enroll into Windows Hello during Autopilot or during the initial setup of the device. Admins can disallow users to enroll into biometrics via Windows Hello for Business policy configurations. However, when allowed via policy configurations, enrollment into Windows Hello biometrics is always optional for users.
@@ -123,7 +123,7 @@ sections:
No. The movement away from passwords is accomplished by gradually reducing the use of the password. In situations where you can't authenticate by using biometrics, you need a fallback mechanism that isn't a password. The PIN is the fallback mechanism. Disabling or hiding the PIN credential provider will disable the use of biometrics.
- question: What is Event ID 300?
answer: |
- This event is created when Windows Hello for Business is successfully created and registered with Azure Active Directory (Azure AD). Applications or services can trigger actions on this event. For example, a certificate provisioning service can listen to this event and trigger a certificate request. This is a normal condition and no further action is required.
+ This event is created when Windows Hello for Business is successfully created and registered with Microsoft Entra ID. Applications or services can trigger actions on this event. For example, a certificate provisioning service can listen to this event and trigger a certificate request. This is a normal condition and no further action is required.
- question: What happens when an unauthorized user gains possession of a device enrolled in Windows Hello for Business?
answer: |
The unauthorized user won't be able to utilize any biometric options and will have the only option to enter a PIN.
@@ -142,12 +142,12 @@ sections:
- question: How many users can enroll for Windows Hello for Business on a single Windows device?
answer: |
The maximum number of supported enrollments on a single device is 10. This lets 10 users each enroll their face and up to 10 fingerprints. For devices with more than 10 users, or for users that sign-in to many devices (for example, a support technician), it's recommended the use of FIDO2 security keys.
- - question: I have extended Active Directory to Azure Active Directory. Can I use the on-premises deployment model?
+ - question: I have extended Active Directory to Microsoft Entra ID. Can I use the on-premises deployment model?
answer: |
No. If your organization is using Microsoft cloud services, then you must use a hybrid deployment model. On-premises deployments are exclusive to organizations who need more time before moving to the cloud and exclusively use Active Directory.
- - question: What attributes are synchronized by Azure AD Connect with Windows Hello for Business?
+ - question: What attributes are synchronized by Microsoft Entra Connect with Windows Hello for Business?
answer: |
- Review [Azure AD Connect sync: Attributes synchronized to Azure Active Directory](/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized) for a list of attributes that sync based on scenarios. The base scenarios that include Windows Hello for Business are the [Windows 10](/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized#windows-10) scenario and the [Device writeback](/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized#device-writeback) scenario. Your environment may include other attributes.
+ Review [Microsoft Entra Connect Sync: Attributes synchronized to Microsoft Entra ID](/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized) for a list of attributes that sync based on scenarios. The base scenarios that include Windows Hello for Business are the [Windows 10](/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized#windows-10) scenario and the [Device writeback](/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized#device-writeback) scenario. Your environment may include other attributes.
- question: Can I use third-party MFA providers with Windows Hello for Business?
answer: |
Yes, if you're using federated hybrid deployment, you can use any third-party that provides an AD FS MFA adapter. A list of third-party MFA adapters can be found [here](/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs#microsoft-and-third-party-additional-authentication-methods).
@@ -170,21 +170,21 @@ sections:
- question: Can I wear a mask to enroll or unlock using Windows Hello face authentication?
answer: |
Wearing a mask to enroll is a security concern because other users wearing a similar mask may be able to unlock your device. The product group is aware of this behavior and is investigating this article further. Remove a mask if you're wearing one when you enroll or unlock with Windows Hello face authentication. If your working environment doesn't allow you to remove a mask temporarily, consider un-enrolling from face authentication and only using PIN or fingerprint.
- - question: How does Windows Hello for Business work with Azure AD registered devices?
+ - question: How does Windows Hello for Business work with Microsoft Entra registered devices?
answer: |
- A user will be prompted to set up a Windows Hello for Business key on an Azure AD registered devices if the feature is enabled by policy. If the user has an existing Windows Hello container, the Windows Hello for Business key will be enrolled in that container and will be protected using existing gestures.
+ A user will be prompted to set up a Windows Hello for Business key on a Microsoft Entra registered devices if the feature is enabled by policy. If the user has an existing Windows Hello container, the Windows Hello for Business key will be enrolled in that container and will be protected using existing gestures.
- If a user has signed into their Azure AD registered device with Windows Hello, their Windows Hello for Business key will be used to authenticate the user's work identity when they try to use Azure AD resources. The Windows Hello for Business key meets Azure AD multifactor authentication (MFA) requirements and reduces the number of MFA prompts users will see when accessing resources.
+ If a user has signed into their Microsoft Entra registered device with Windows Hello, their Windows Hello for Business key will be used to authenticate the user's work identity when they try to use Microsoft Entra resources. The Windows Hello for Business key meets Microsoft Entra multifactor authentication (MFA) requirements and reduces the number of MFA prompts users will see when accessing resources.
- It's possible to Azure AD register a domain joined device. If the domain joined device has a convenience PIN, sign in with the convenience PIN will no longer work. This configuration isn't supported by Windows Hello for Business.
+ It's possible to Microsoft Entra register a domain joined device. If the domain joined device has a convenience PIN, sign in with the convenience PIN will no longer work. This configuration isn't supported by Windows Hello for Business.
- For more information, please read [Azure AD registered devices](/azure/active-directory/devices/concept-azure-ad-register).
+ For more information, please read [Microsoft Entra registered devices](/azure/active-directory/devices/concept-azure-ad-register).
- question: Does Windows Hello for Business work with non-Windows operating systems?
answer: |
Windows Hello for Business is a feature of the Windows platform. At this time, Microsoft isn't developing clients for other platforms. However, Microsoft is open to third-parties who are interested in moving these platforms away from passwords. Interested third-parties can get more information by emailing [whfbfeedback@microsoft.com](mailto:whfbfeedback@microsoft.com?subject=collaboration).
- - question: Does Windows Hello for Business work with Azure Active Directory Domain Services (Azure AD DS) clients?
+ - question: Does Windows Hello for Business work with Microsoft Entra Domain Services clients?
answer: |
- No, Azure AD DS is a separately managed environment in Azure, and hybrid device registration with cloud Azure AD isn't available for it via Azure AD Connect. Hence, Windows Hello for Business doesn't work with Azure AD DS.
+ No, Microsoft Entra Domain Services is a separately managed environment in Azure, and hybrid device registration with cloud Microsoft Entra ID isn't available for it via Microsoft Entra Connect. Hence, Windows Hello for Business doesn't work with Microsoft Entra Domain Services.
- question: Is Windows Hello for Business considered multifactor authentication?
answer: |
Windows Hello for Business is two-factor authentication based on the observed authentication factors of: *something you have*, *something you know*, and *something that's part of you*. Windows Hello for Business incorporates two of these factors: something you have (the user's private key protected by the device's security module) and something you know (your PIN). With the proper hardware, you can enhance the user experience by introducing biometrics. By using biometrics, you can replace the "something you know" authentication factor with the "something that is part of you" factor, with the assurances that users can fall back to the "something you know factor".
@@ -200,9 +200,9 @@ sections:
- question: What is convenience PIN?
answer: |
*Convenience PIN* provides a simpler way to sign in to Windows than passwords, but it still uses a password for authentication. When the correct convenience PIN is provided to Windows, the password information is loaded from its cache and authenticates the user. Organizations using convenience PINs should move to **Windows Hello for Business**. New Windows deployments should deploy Windows Hello for Business and not convenience PINs.
- - question: Can I use a convenience PIN with Azure Active Directory?
+ - question: Can I use a convenience PIN with Microsoft Entra ID?
answer: |
- No. While it's possible to set a convenience PIN on Azure AD joined and hybrid Azure AD joined devices, convenience PIN isn't supported for Azure AD user accounts (including synchronized identities). Convenience PIN is only supported for on-premises Active Directory users and local account users.
+ No. While it's possible to set a convenience PIN on Microsoft Entra joined and Microsoft Entra hybrid joined devices, convenience PIN isn't supported for Microsoft Entra user accounts (including synchronized identities). Convenience PIN is only supported for on-premises Active Directory users and local account users.
- question: What about virtual smart cards?
answer: |
Windows Hello for Business is the modern, two-factor authentication for Windows. Microsoft will deprecate virtual smart cards in the near future. Customers using virtual smart cards are strongly encouraged to move to Windows Hello for Business. Microsoft will publish the deprecation date to ensure customers have adequate lead time to move to Windows Hello for Business. We recommend that new Windows deployments use Windows Hello for Business.
@@ -231,7 +231,7 @@ sections:
questions:
- question: What is Windows Hello for Business cloud Kerberos trust?
answer: |
- Windows Hello for Business *cloud Kerberos trust* is a *trust model* that enables Windows Hello for Business deployment using the infrastructure introduced for supporting [security key sign-in on Hybrid Azure AD-joined devices and on-premises resource access on Azure AD Joined devices](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises). Cloud Kerberos trust is the preferred deployment model if you do not need to support certificate authentication scenarios. For more information, see [cloud Kerberos trust deployment](/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust).
+ Windows Hello for Business *cloud Kerberos trust* is a *trust model* that enables Windows Hello for Business deployment using the infrastructure introduced for supporting [security key sign-in on Microsoft Entra hybrid joined devices and on-premises resource access on Microsoft Entra joined devices](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises). Cloud Kerberos trust is the preferred deployment model if you do not need to support certificate authentication scenarios. For more information, see [cloud Kerberos trust deployment](/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust).
- question: Does Windows Hello for Business cloud Kerberos trust work in my on-premises environment?
answer: |
This feature doesn't work in a pure on-premises AD domain services environment.
@@ -254,7 +254,7 @@ sections:
questions:
- question: Why does authentication fail immediately after provisioning hybrid key trust?
answer: |
- In a hybrid deployment, a user's public key must sync from Azure AD to AD before it can be used to authenticate against a domain controller. This sync is handled by Azure AD Connect and will occur during a normal sync cycle.
+ In a hybrid deployment, a user's public key must sync from Microsoft Entra ID to Active Directory before it can be used to authenticate against a domain controller. This sync is handled by Microsoft Entra Connect and will occur during a normal sync cycle.
- question: Can I use Windows Hello for Business key trust and RDP?
answer: |
Remote Desktop Protocol (RDP) doesn't currently support using key-based authentication and self-signed certificates as supplied credentials. However, you can deploy certificates in the key trust model to enable RDP. For more information, see [Deploying certificates to key trust users to enable RDP](hello-deployment-rdp-certs.md). In addition, Windows Hello for Business key trust can be also used with RDP with [Remote Credential Guard](../remote-credential-guard.md) without deploying certificates.
diff --git a/windows/security/identity-protection/hello-for-business/hello-feature-pin-reset.md b/windows/security/identity-protection/hello-for-business/hello-feature-pin-reset.md
index 1c72822304..bf642eef73 100644
--- a/windows/security/identity-protection/hello-for-business/hello-feature-pin-reset.md
+++ b/windows/security/identity-protection/hello-for-business/hello-feature-pin-reset.md
@@ -26,7 +26,7 @@ Windows Hello for Business provides the capability for users to reset forgotten
- Hybrid or cloud-only Windows Hello for Business deployments
- Windows Enterprise, Education and Pro editions. There's no licensing requirement for this feature
-When non-destructive PIN reset is enabled on a client, a *256-bit AES* key is generated locally. The key is added to a user's Windows Hello for Business container and keys as the *PIN reset protector*. This PIN reset protector is encrypted using a public key retrieved from the Microsoft PIN reset service and then stored on the client for later use during PIN reset. After a user initiates a PIN reset, completes authentication and multi-factor authentication to Azure AD, the encrypted PIN reset protector is sent to the Microsoft PIN reset service, decrypted, and returned to the client. The decrypted PIN reset protector is used to change the PIN used to authorize Windows Hello for Business keys and it's then cleared from memory.
+When non-destructive PIN reset is enabled on a client, a *256-bit AES* key is generated locally. The key is added to a user's Windows Hello for Business container and keys as the *PIN reset protector*. This PIN reset protector is encrypted using a public key retrieved from the Microsoft PIN reset service and then stored on the client for later use during PIN reset. After a user initiates a PIN reset, completes authentication and multi-factor authentication to Microsoft Entra ID, the encrypted PIN reset protector is sent to the Microsoft PIN reset service, decrypted, and returned to the client. The decrypted PIN reset protector is used to change the PIN used to authorize Windows Hello for Business keys and it's then cleared from memory.
Using Group Policy, Microsoft Intune or a compatible MDM solution, you can configure Windows devices to securely use the Microsoft PIN reset service, which enables users to reset their forgotten PIN without requiring re-enrollment.
@@ -35,15 +35,17 @@ The following table compares destructive and non-destructive PIN reset:
|Category|Destructive PIN reset|Non-Destructive PIN reset|
|--- |--- |--- |
|**Functionality**|The user's existing PIN and underlying credentials, including any keys or certificates added to their Windows Hello container, are deleted from the client and a new sign in key and PIN are provisioned.|You must deploy the Microsoft PIN reset service and client policy to enable the PIN recovery feature. During a non-destructive PIN reset, the user's Windows Hello for Business container and keys are preserved, but the user's PIN that they use to authorize key usage is changed.|
-|**Azure Active Directory Joined**|Cert Trust, Key Trust, and cloud Kerberos trust|Cert Trust, Key Trust, and cloud Kerberos trust|
-|**Hybrid Azure Active Directory Joined**|Cert Trust and cloud Kerberos trust for both settings and above the lock support destructive PIN reset. Key Trust doesn't support this option from above the lock screen. This is due to the sync delay between when a user provisions their Windows Hello for Business credential and being able to use it for sign-in. It does support from the settings page and the users must have a corporate network connectivity to the DC. |Cert Trust, Key Trust, and cloud Kerberos trust for both settings and above the lock support non-destructive PIN reset. No network connection is required for the DC.|
-|**On Premises**|If AD FS is used for on premises deployments, users must have a corporate network connectivity to federation services. |The PIN reset service relies on Azure Active Directory identities, so it's only available for hybrid Azure AD joined and Azure AD Joined devices.|
+|**Microsoft Entra joined**|Cert Trust, Key Trust, and cloud Kerberos trust|Cert Trust, Key Trust, and cloud Kerberos trust|
+|**Microsoft Entra hybrid joined**|Cert Trust and cloud Kerberos trust for both settings and above the lock support destructive PIN reset. Key Trust doesn't support this option from above the lock screen. This is due to the sync delay between when a user provisions their Windows Hello for Business credential and being able to use it for sign-in. It does support from the settings page and the users must have a corporate network connectivity to the DC. |Cert Trust, Key Trust, and cloud Kerberos trust for both settings and above the lock support non-destructive PIN reset. No network connection is required for the DC.|
+|**On Premises**|If AD FS is used for on premises deployments, users must have a corporate network connectivity to federation services. |The PIN reset service relies on Microsoft Entra identities, so it's only available for Microsoft Entra hybrid joined and Microsoft Entra joined devices.|
|**Additional configuration required**|Supported by default and doesn't require configuration|Deploy the Microsoft PIN reset service and client policy to enable the PIN recovery feature.|
|**MSA/Enterprise**|MSA and Enterprise|Enterprise only.|
-## Enable the Microsoft PIN Reset Service in your Azure AD tenant
+
-Before you can use non-destructive PIN reset, you must register two applications in your Azure Active Directory tenant:
+## Enable the Microsoft PIN Reset Service in your Microsoft Entra tenant
+
+Before you can use non-destructive PIN reset, you must register two applications in your Microsoft Entra tenant:
- Microsoft Pin Reset Service Production
- Microsoft Pin Reset Client Production
@@ -52,7 +54,7 @@ To register the applications, follow these steps:
:::row:::
:::column span="3":::
- 1. Go to the [Microsoft PIN Reset Service Production website][APP-1], and sign in using a *Global Administrator* account you use to manage your Azure Active Directory tenant. Review the permissions requested by the *Microsoft Pin Reset Service Production* application and select **Accept** to give consent to the application to access your organization
+ 1. Go to the [Microsoft PIN Reset Service Production website][APP-1], and sign in using a *Global Administrator* account you use to manage your Microsoft Entra tenant. Review the permissions requested by the *Microsoft Pin Reset Service Production* application and select **Accept** to give consent to the application to access your organization
:::column-end:::
:::column span="1":::
:::image type="content" alt-text="Screenshot showing the PIN reset service permissions page." source="images/pinreset/pin-reset-service-prompt.png" lightbox="images/pinreset/pin-reset-service-prompt.png" border="true":::
@@ -60,7 +62,7 @@ To register the applications, follow these steps:
:::row-end:::
:::row:::
:::column span="3":::
- 2. Go to the [Microsoft PIN Reset Client Production website][APP-2], and sign in using a *Global Administrator* account you use to manage your Azure Active Directory tenant. Review the permissions requested by the *Microsoft Pin Reset Client Production* application, and select **Next**.
+ 2. Go to the [Microsoft PIN Reset Client Production website][APP-2], and sign in using a *Global Administrator* account you use to manage your Microsoft Entra tenant. Review the permissions requested by the *Microsoft Pin Reset Client Production* application, and select **Next**.
:::column-end:::
:::column span="1":::
:::image type="content" alt-text="Screenshot showing the PIN reset client permissions page." source="images/pinreset/pin-reset-client-prompt.png" lightbox="images/pinreset/pin-reset-client-prompt.png" border="true":::
@@ -80,7 +82,7 @@ To register the applications, follow these steps:
### Confirm that the two PIN Reset service principals are registered in your tenant
1. Sign in to the [Microsoft Entra Manager admin center](https://entra.microsoft.com)
-1. Select **Azure Active Directory > Applications > Enterprise applications**
+1. Select **Microsoft Entra ID > Applications > Enterprise applications**
1. Search by application name "Microsoft PIN" and verify that both **Microsoft Pin Reset Service Production** and **Microsoft Pin Reset Client Production** are in the list
:::image type="content" alt-text="PIN reset service permissions page." source="images/pinreset/pin-reset-applications.png" lightbox="images/pinreset/pin-reset-applications-expanded.png":::
@@ -116,7 +118,7 @@ Alternatively, you can configure devices using a [custom policy][INT-1] with the
| `./Vendor/MSFT/Policy/PassportForWork/`*TenantId*`/Policies/EnablePinRecovery`| Boolean | True |
>[!NOTE]
-> You must replace `TenantId` with the identifier of your Azure Active Directory tenant. To look up your Tenant ID, see [How to find your Azure Active Directory tenant ID](/azure/active-directory/fundamentals/how-to-find-tenant) or try the following, ensuring to sign-in with your organization's account::
+> You must replace `TenantId` with the identifier of your Microsoft Entra tenant. 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
@@ -177,12 +179,14 @@ The _PIN reset_ configuration can be viewed by running [**dsregcmd /status**](/a
+----------------------------------------------------------------------+
```
-## Configure allowed URLs for federated identity providers on Azure AD joined devices
+
-**Applies to:** Azure AD joined devices
+## Configure allowed URLs for federated identity providers on Microsoft Entra joined devices
-PIN reset on Azure AD-joined devices uses a flow called *web sign-in* to authenticate users in the lock screen. Web sign-in only allows navigation to specific domains. If web sign-in attempts to navigate to a domain that isn't allowed, it displays a page with the error message: *"We can't open that page right now"*.\
-If you have a federated environment and authentication is handled using AD FS or a third-party identity provider, then you must configure your devices with a policy to allow a list of domains that can be reached during PIN reset flows. When set, it ensures that authentication pages from that identity provider can be used during Azure AD joined PIN reset.
+**Applies to:** Microsoft Entra joined devices
+
+PIN reset on Microsoft Entra joined devices uses a flow called *web sign-in* to authenticate users in the lock screen. Web sign-in only allows navigation to specific domains. If web sign-in attempts to navigate to a domain that isn't allowed, it displays a page with the error message: *"We can't open that page right now"*.\
+If you have a federated environment and authentication is handled using AD FS or a third-party identity provider, then you must configure your devices with a policy to allow a list of domains that can be reached during PIN reset flows. When set, it ensures that authentication pages from that identity provider can be used during Microsoft Entra joined PIN reset.
[!INCLUDE [intune-settings-catalog-1](../../../../includes/configure/intune-settings-catalog-1.md)]
@@ -199,14 +203,14 @@ Alternatively, you can configure devices using a [custom policy][INT-1] with the
| - OMA-URI: `./Vendor/MSFT/Policy/Config/Authentication/ConfigureWebSignInAllowedUrls`
- Data type: String
- Value: Provide a semicolon delimited list of domains needed for authentication during the PIN reset scenario. An example value would be **signin.contoso.com;portal.contoso.com**
|
> [!NOTE]
-> For Azure Government, there is a known issue with PIN reset on Azure AD Joined devices failing. When the user attempts to launch PIN reset, the PIN reset UI shows an error page that says, *"We can't open that page right now"*. The ConfigureWebSignInAllowedUrls policy can be used to work around this issue. If you are experiencing this problem and you are using Azure US Government cloud, set **login.microsoftonline.us** as the value for the ConfigureWebSignInAllowedUrls policy.
+> For Azure Government, there is a known issue with PIN reset on Microsoft Entra joined devices failing. When the user attempts to launch PIN reset, the PIN reset UI shows an error page that says, *"We can't open that page right now"*. The ConfigureWebSignInAllowedUrls policy can be used to work around this issue. If you are experiencing this problem and you are using Azure US Government cloud, set **login.microsoftonline.us** as the value for the ConfigureWebSignInAllowedUrls policy.
## Use PIN reset
Destructive and non-destructive PIN reset scenarios use the same steps for initiating a PIN reset. If users have forgotten their PINs, but have an alternate sign-in method, they can navigate to Sign-in options in *Settings* and initiate a PIN reset from the PIN options. If users don't have an alternate way to sign into their devices, PIN reset can also be initiated from the Windows lock screen with the *PIN credential provider*. Users must authenticate and complete multi-factor authentication to reset their PIN. After PIN reset is complete, users can sign in using their new PIN.
>[!IMPORTANT]
->For hybrid Azure AD-joined devices, users must have corporate network connectivity to domain controllers to complete destructive PIN reset. If AD FS is being used for certificate trust or for on-premises only deployments, users must also have corporate network connectivity to federation services to reset their PIN.
+>For Microsoft Entra hybrid joined devices, users must have corporate network connectivity to domain controllers to complete destructive PIN reset. If AD FS is being used for certificate trust or for on-premises only deployments, users must also have corporate network connectivity to federation services to reset their PIN.
### Reset PIN from Settings
@@ -216,7 +220,7 @@ Destructive and non-destructive PIN reset scenarios use the same steps for initi
### Reset PIN from the lock screen
-For Azure AD-joined devices:
+For Microsoft Entra joined devices:
1. If the PIN credential provider isn't selected, expand the **Sign-in options** link, and select the PIN pad icon
1. Select **I forgot my PIN** from the PIN credential provider
@@ -226,7 +230,7 @@ For Azure AD-joined devices:
:::image type="content" alt-text="Animation showing the PIN reset experience from the lock screen." source="images/pinreset/pin-reset.gif" border="false":::
-For Hybrid Azure AD-joined devices:
+For Microsoft Entra hybrid joined devices:
1. If the PIN credential provider isn't selected, expand the **Sign-in options** link, and select the PIN pad icon
1. Select **I forgot my PIN** from the PIN credential provider
@@ -235,9 +239,9 @@ For Hybrid Azure AD-joined devices:
1. When finished, unlock your desktop using your newly created PIN
> [!NOTE]
-> Key trust on hybrid Azure AD-joined devices doesn't support destructive PIN reset from above the Lock Screen. This is due to the sync delay between when a user provisions their Windows Hello for Business credential and being able to use it for sign-in. For this deployment model, you must deploy non-destructive PIN reset for above lock PIN reset to work.
+> Key trust on Microsoft Entra hybrid joined devices doesn't support destructive PIN reset from above the Lock Screen. This is due to the sync delay between when a user provisions their Windows Hello for Business credential and being able to use it for sign-in. For this deployment model, you must deploy non-destructive PIN reset for above lock PIN reset to work.
-You may find that PIN reset from Settings only works post sign in. Also, the lock screen PIN reset function doesn't work if you have any matching limitation of self-service password reset from the lock screen. For more information, see [Enable Azure Active Directory self-service password reset at the Windows sign-in screen](/azure/active-directory/authentication/howto-sspr-windows#general-limitations).
+You may find that PIN reset from Settings only works post sign in. Also, the lock screen PIN reset function doesn't work if you have any matching limitation of self-service password reset from the lock screen. For more information, see [Enable Microsoft Entra self-service password reset at the Windows sign-in screen](/azure/active-directory/authentication/howto-sspr-windows#general-limitations).
diff --git a/windows/security/identity-protection/hello-for-business/hello-feature-remote-desktop.md b/windows/security/identity-protection/hello-for-business/hello-feature-remote-desktop.md
index 58e5c14636..8e7e89b38e 100644
--- a/windows/security/identity-protection/hello-for-business/hello-feature-remote-desktop.md
+++ b/windows/security/identity-protection/hello-for-business/hello-feature-remote-desktop.md
@@ -12,7 +12,7 @@ ms.collection:
**Requirements**
- Hybrid and On-premises Windows Hello for Business deployments
-- Azure AD joined, Hybrid Azure AD joined, and Enterprise joined devices
+- 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.
@@ -23,7 +23,7 @@ Microsoft continues to investigate supporting using keys trust for supplied cred
**Requirements**
- Hybrid and On-premises Windows Hello for Business deployments
-- Azure AD joined, Hybrid Azure AD joined, and Enterprise joined devices
+- 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.
diff --git a/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md b/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md
index 313d215066..36755630f0 100644
--- a/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md
+++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md
@@ -6,75 +6,87 @@ ms.topic: reference
---
# Windows Hello for Business authentication
-Windows Hello for Business authentication is a passwordless, two-factor authentication. Authenticating with Windows Hello for Business provides a convenient sign-in experience that authenticates the user to both Azure Active Directory and Active Directory resources.
+Windows Hello for Business authentication is a passwordless, two-factor authentication. Authenticating with Windows Hello for Business provides a convenient sign-in experience that authenticates the user to both Microsoft Entra ID and Active Directory resources.
-Azure AD-joined devices authenticate to Azure AD during sign-in and can, optionally, authenticate to Active Directory. Hybrid Azure AD-joined devices authenticate to Active Directory during sign-in, and authenticate to Azure AD in the background.
+Microsoft Entra joined devices authenticate to Microsoft Entra ID during sign-in and can, optionally, authenticate to Active Directory. Microsoft Entra hybrid joined devices authenticate to Active Directory during sign-in, and authenticate to Microsoft Entra ID in the background.
-## Azure AD join authentication to Azure AD
+
-
+## Microsoft Entra join authentication to Microsoft Entra ID
+
+
> [!NOTE]
-> All Azure AD-joined devices authenticate with Windows Hello for Business to Azure AD the same way. The Windows Hello for Business trust type only impacts how the device authenticates to on-premises AD.
+> All Microsoft Entra joined devices authenticate with Windows Hello for Business to Microsoft Entra ID the same way. The Windows Hello for Business trust type only impacts how the device authenticates to on-premises AD.
| Phase | Description |
| :----: | :----------- |
|A | Authentication begins when the user dismisses the lock screen, which triggers Winlogon to show the Windows Hello for Business credential provider. The user provides their Windows Hello gesture (PIN or biometrics). The credential provider packages these credentials and returns them to Winlogon. Winlogon passes the collected credentials to lsass. Lsass passes the collected credentials to the Cloud Authentication security support provider, referred to as the Cloud AP provider.|
-|B | The Cloud AP provider requests a nonce from Azure Active Directory. Azure AD returns a nonce. The Cloud AP provider signs the nonce using the user's private key and returns the signed nonce to the Azure Active Directory.|
-|C | Azure Active Directory validates the signed nonce using the user's securely registered public key against the nonce signature. Azure AD then validates the returned signed nonce, and creates a PRT with session key that is encrypted to the device's transport key and returns it to the Cloud AP provider.|
+|B | The Cloud AP provider requests a nonce from Microsoft Entra ID. Microsoft Entra ID returns a nonce. The Cloud AP provider signs the nonce using the user's private key and returns the signed nonce to the Microsoft Entra ID.|
+|C | Microsoft Entra ID validates the signed nonce using the user's securely registered public key against the nonce signature. Microsoft Entra ID then validates the returned signed nonce, and creates a PRT with session key that is encrypted to the device's transport key and returns it to the Cloud AP provider.|
|D | The Cloud AP provider receives the encrypted PRT with session key. Using the device's private transport key, the Cloud AP provider decrypt the session key and protects the session key using the device's TPM.|
|E | The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT, and informs Winlogon of the success authentication. Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.|
-## Azure AD join authentication to Active Directory using cloud Kerberos trust
+
-
+## Microsoft Entra join authentication to Active Directory using cloud Kerberos trust
+
+
| Phase | Description |
| :----: | :----------- |
-|A | Authentication to Active Directory from an Azure AD joined device begins with the user first attempts to use a resource that needs Kerberos authentication. The Kerberos security support provider, hosted in lsass, uses metadata from the Windows Hello for Business key to get a hint of the user's domain. Using the hint, the provider uses the DClocator service to locate a 2016 domain controller.
-|B | After locating a domain controller, the Kerberos provider sends a partial TGT that it received from Azure AD from a previous Azure AD authentication to the domain controller. The partial TGT contains only the user SID, and it's signed by Azure AD Kerberos. The domain controller verifies that the partial TGT is valid. On success, the KDC returns a TGT to the client.|
+|A | Authentication to Active Directory from a Microsoft Entra joined device begins with the user first attempts to use a resource that needs Kerberos authentication. The Kerberos security support provider, hosted in lsass, uses metadata from the Windows Hello for Business key to get a hint of the user's domain. Using the hint, the provider uses the DClocator service to locate a 2016 domain controller.
+|B | After locating a domain controller, the Kerberos provider sends a partial TGT that it received from Microsoft Entra ID from a previous Microsoft Entra authentication to the domain controller. The partial TGT contains only the user SID, and it's signed by Microsoft Entra Kerberos. The domain controller verifies that the partial TGT is valid. On success, the KDC returns a TGT to the client.|
-## Azure AD join authentication to Active Directory using a key
+
-
+## Microsoft Entra join authentication to Active Directory using a key
+
+
| Phase | Description |
| :----: | :----------- |
-|A | Authentication to Active Directory from an Azure AD joined device begins with the user first attempts to use a resource that needs Kerberos authentication. The Kerberos security support provider, hosted in lsass, uses metadata from the Windows Hello for Business key to get a hint of the user's domain. Using the hint, the provider uses the DClocator service to locate a 2016 domain controller. After the provider locates a domain controller, the provider uses the private key to sign the Kerberos preauthentication data.|
+|A | Authentication to Active Directory from a Microsoft Entra joined device begins with the user first attempts to use a resource that needs Kerberos authentication. The Kerberos security support provider, hosted in lsass, uses metadata from the Windows Hello for Business key to get a hint of the user's domain. Using the hint, the provider uses the DClocator service to locate a 2016 domain controller. After the provider locates a domain controller, the provider uses the private key to sign the Kerberos preauthentication data.|
|B | The Kerberos provider sends the signed preauthentication data and its public key (in the form of a self-signed certificate) to the Key Distribution Center (KDC) service running on the 2016 domain controller in the form of a KERB_AS_REQ.
The 2016 domain controller determines the certificate is a self-signed certificate. It retrieves the public key from the certificate included in the KERB_AS_REQ and searches for the public key in Active Directory. It validates the UPN for authentication request matches the UPN registered in Active Directory and validates the signed preauthentication data using the public key from Active Directory. On success, the KDC returns a TGT to the client with its certificate in a KERB_AS_REP.|
|C | The Kerberos provider ensures it can trust the response from the domain controller. First, it ensures the KDC certificate chains to a root certificate that is trusted by the device. Next, it ensures the certificate is within its validity period and that it hasn't been revoked. The Kerberos provider then verifies the certificate has the KDC Authentication present and that the subject alternate name listed in the KDC's certificate matches the domain name to which the user is authenticating. After passing this criteria, Kerberos returns the TGT to lsass, where it's cached and used for subsequent service ticket requests.|
> [!NOTE]
-> You might have an on-premises domain federated with Azure AD. Once you have successfully provisioned Windows Hello for Business PIN/Bio on the Azure AD joined device, any future login of Windows Hello for Business (PIN/Bio) sign-in will directly authenticate against Azure AD to get PRT and trigger authenticate against your DC (if LOS to DC is available) to get Kerberos. It no longer uses AD FS to authenticate for Windows Hello for Business sign-ins.
+> You might have an on-premises domain federated with Microsoft Entra ID. Once you have successfully provisioned Windows Hello for Business PIN/Bio on the Microsoft Entra joined device, any future login of Windows Hello for Business (PIN/Bio) sign-in will directly authenticate against Microsoft Entra ID to get PRT and trigger authenticate against your DC (if LOS to DC is available) to get Kerberos. It no longer uses AD FS to authenticate for Windows Hello for Business sign-ins.
-## Azure AD join authentication to Active Directory using a certificate
+
-
+## Microsoft Entra join authentication to Active Directory using a certificate
+
+
| Phase | Description |
| :----: | :----------- |
-|A | Authentication to Active Directory from an Azure AD joined device begins with the user first attempts to use a resource that needs Kerberos authentication. The Kerberos security support provider, hosted in lsass, uses information from the certificate to get a hint of the user's domain. Kerberos can use the distinguished name of the user found in the subject of the certificate, or it can use the user principal name of the user found in the subject alternate name of the certificate. Using the hint, the provider uses the DClocator service to locate a domain controller. After the provider locates an active domain controller, the provider uses the private key to sign the Kerberos preauthentication data.|
+|A | Authentication to Active Directory from a Microsoft Entra joined device begins with the user first attempts to use a resource that needs Kerberos authentication. The Kerberos security support provider, hosted in lsass, uses information from the certificate to get a hint of the user's domain. Kerberos can use the distinguished name of the user found in the subject of the certificate, or it can use the user principal name of the user found in the subject alternate name of the certificate. Using the hint, the provider uses the DClocator service to locate a domain controller. After the provider locates an active domain controller, the provider uses the private key to sign the Kerberos preauthentication data.|
|B | The Kerberos provider sends the signed preauthentication data and user's certificate, which includes the public key, to the Key Distribution Center (KDC) service running on the domain controller in the form of a KERB_AS_REQ.
The domain controller determines the certificate isn't self-signed certificate. The domain controller ensures the certificate chains to trusted root certificate, is within its validity period, can be used for authentication, and hasn't been revoked. It retrieves the public key and UPN from the certificate included in the KERB_AS_REQ and searches for the UPN in Active Directory. It validates the signed preauthentication data using the public key from the certificate. On success, the KDC returns a TGT to the client with its certificate in a KERB_AS_REP.|
|C | The Kerberos provider ensures it can trust the response from the domain controller. First, it ensures the KDC certificate chains to a root certificate that is trusted by the device. Next, it ensures the certificate is within its validity period and that it hasn't been revoked. The Kerberos provider then verifies the certificate has the KDC Authentication present and that the subject alternate name listed in the KDC's certificate matches the domain name to which the user is authenticating. After passing this criteria, Kerberos returns the TGT to lsass, where it's cached and used for subsequent service ticket requests.|
> [!NOTE]
-> You may have an on-premises domain federated with Azure AD. Once you have successfully provisioned Windows Hello for Business PIN/Bio on, any future login of Windows Hello for Business (PIN/Bio) sign-in will directly authenticate against Azure AD to get PRT, as well as authenticate against your DC (if LOS to DC is available) to get Kerberos as mentioned previously. AD FS federation is used only when Enterprise PRT calls are placed from the client. You need to have device write-back enabled to get "Enterprise PRT" from your federation.
+> You may have an on-premises domain federated with Microsoft Entra ID. Once you have successfully provisioned Windows Hello for Business PIN/Bio on, any future login of Windows Hello for Business (PIN/Bio) sign-in will directly authenticate against Microsoft Entra ID to get PRT, as well as authenticate against your DC (if LOS to DC is available) to get Kerberos as mentioned previously. AD FS federation is used only when Enterprise PRT calls are placed from the client. You need to have device write-back enabled to get "Enterprise PRT" from your federation.
-## Hybrid Azure AD join authentication using cloud Kerberos trust
+
-
+## Microsoft Entra hybrid join authentication using cloud Kerberos trust
+
+
| Phase | Description |
| :----: | :----------- |
-|A | Authentication begins when the user dismisses the lock screen, which triggers Winlogon to show the Windows Hello for Business credential provider. The user provides their Windows Hello gesture (PIN or biometrics). The credential provider packages these credentials and returns them to Winlogon. Winlogon passes the collected credentials to lsass. Lsass queries Windows Hello for Business policy to check if cloud Kerberos trust is enabled. If cloud Kerberos trust is enabled, Lsass passes the collected credentials to the Cloud Authentication security support provider, or Cloud AP. Cloud AP requests a nonce from Azure Active Directory. Azure AD returns a nonce.
-|B | Cloud AP signs the nonce using the user's private key and returns the signed nonce to Azure AD.
-|C | Azure AD validates the signed nonce using the user's securely registered public key against the nonce signature. After validating the signature, Azure AD then validates the returned signed nonce. After validating the nonce, Azure AD creates a PRT with session key that is encrypted to the device's transport key and creates a Partial TGT from Azure AD Kerberos and returns them to Cloud AP.
+|A | Authentication begins when the user dismisses the lock screen, which triggers Winlogon to show the Windows Hello for Business credential provider. The user provides their Windows Hello gesture (PIN or biometrics). The credential provider packages these credentials and returns them to Winlogon. Winlogon passes the collected credentials to lsass. Lsass queries Windows Hello for Business policy to check if cloud Kerberos trust is enabled. If cloud Kerberos trust is enabled, Lsass passes the collected credentials to the Cloud Authentication security support provider, or Cloud AP. Cloud AP requests a nonce from Microsoft Entra ID. Microsoft Entra ID returns a nonce.
+|B | Cloud AP signs the nonce using the user's private key and returns the signed nonce to Microsoft Entra ID.
+|C | Microsoft Entra ID validates the signed nonce using the user's securely registered public key against the nonce signature. After validating the signature, Microsoft Entra ID then validates the returned signed nonce. After validating the nonce, Microsoft Entra ID creates a PRT with session key that is encrypted to the device's transport key and creates a Partial TGT from Microsoft Entra Kerberos and returns them to Cloud AP.
|D | Cloud AP receives the encrypted PRT with session key. Using the device's private transport key, Cloud AP decrypts the session key and protects the session key using the device's TPM (if available). Cloud AP returns a successful authentication response to lsass. Lsass caches the PRT and the Partial TGT.
-|E | The Kerberos security support provider, hosted in lsass, uses metadata from the Windows Hello for Business key to get a hint of the user's domain. Using the hint, the provider uses the DClocator service to locate a 2016 domain controller. After locating an active 2016 domain controller, the Kerberos provider sends the partial TGT that it received from Azure AD to the domain controller. The partial TGT contains only the user SID and is signed by Azure AD Kerberos. The domain controller verifies that the partial TGT is valid. On success, the KDC returns a TGT to the client. Kerberos returns the TGT to lsass, where it's cached and used for subsequent service ticket requests. Lsass informs Winlogon of the success authentication. Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.|
+|E | The Kerberos security support provider, hosted in lsass, uses metadata from the Windows Hello for Business key to get a hint of the user's domain. Using the hint, the provider uses the DClocator service to locate a 2016 domain controller. After locating an active 2016 domain controller, the Kerberos provider sends the partial TGT that it received from Microsoft Entra ID to the domain controller. The partial TGT contains only the user SID and is signed by Microsoft Entra Kerberos. The domain controller verifies that the partial TGT is valid. On success, the KDC returns a TGT to the client. Kerberos returns the TGT to lsass, where it's cached and used for subsequent service ticket requests. Lsass informs Winlogon of the success authentication. Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.|
-## Hybrid Azure AD join authentication using a key
+
-
+## Microsoft Entra hybrid join authentication using a key
+
+
| Phase | Description |
| :----: | :----------- |
@@ -83,15 +95,17 @@ Azure AD-joined devices authenticate to Azure AD during sign-in and can, optiona
|C | The Kerberos provider ensures it can trust the response from the domain controller. First, it ensures the KDC certificate chains to a root certificate that is trusted by the device. Next, it ensures the certificate is within its validity period and that it hasn't been revoked. The Kerberos provider then verifies the certificate has the KDC Authentication present and that the subject alternate name listed in the KDC's certificate matches the domain name to which the user is authenticating.
|D | After passing this criteria, Kerberos returns the TGT to lsass, where it's cached and used for subsequent service ticket requests.|
|E | Lsass informs Winlogon of the success authentication. Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.|
-|F | While Windows loads the user's desktop, lsass passes the collected credentials to the Cloud Authentication security support provider, referred to as the Cloud AP provider. The Cloud AP provider requests a nonce from Azure Active Directory. Azure AD returns a nonce.|
-|G | The Cloud AP provider signs the nonce using the user's private key and returns the signed nonce to the Azure Active Directory. Azure Active Directory validates the signed nonce using the user's securely registered public key against the nonce signature. After validating the signature, Azure AD then validates the returned signed nonce. After validating the nonce, Azure AD creates a PRT with session key that is encrypted to the device's transport key and returns it to the Cloud AP provider.
The Cloud AP provider receives the encrypted PRT with session key. Using the device's private transport key, the Cloud AP provider decrypt the session key and protects the session key using the device's TPM.
The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT.|
+|F | While Windows loads the user's desktop, lsass passes the collected credentials to the Cloud Authentication security support provider, referred to as the Cloud AP provider. The Cloud AP provider requests a nonce from Microsoft Entra ID. Microsoft Entra ID returns a nonce.|
+|G | The Cloud AP provider signs the nonce using the user's private key and returns the signed nonce to the Microsoft Entra ID. Microsoft Entra ID validates the signed nonce using the user's securely registered public key against the nonce signature. After validating the signature, Microsoft Entra ID then validates the returned signed nonce. After validating the nonce, Microsoft Entra ID creates a PRT with session key that is encrypted to the device's transport key and returns it to the Cloud AP provider.
The Cloud AP provider receives the encrypted PRT with session key. Using the device's private transport key, the Cloud AP provider decrypt the session key and protects the session key using the device's TPM.
The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT.|
> [!IMPORTANT]
-> In the above deployment model, a newly provisioned user will not be able to sign in using Windows Hello for Business until (a) Azure AD Connect successfully synchronizes the public key to the on-premises Active Directory and (b) device has line of sight to the domain controller for the first time.
+> In the above deployment model, a newly provisioned user will not be able to sign in using Windows Hello for Business until (a) Microsoft Entra Connect successfully synchronizes the public key to the on-premises Active Directory and (b) device has line of sight to the domain controller for the first time.
-## Hybrid Azure AD join authentication using a certificate
+
-
+## Microsoft Entra hybrid join authentication using a certificate
+
+
| Phase | Description |
| :----: | :----------- |
@@ -100,8 +114,8 @@ Azure AD-joined devices authenticate to Azure AD during sign-in and can, optiona
|C | The Kerberos provider ensures it can trust the response from the domain controller. First, it ensures the KDC certificate chains to a root certificate that is trusted by the device. Next, it ensures the certificate is within its validity period and that it hasn't been revoked. The Kerberos provider then verifies the certificate has the KDC Authentication present and that the subject alternate name listed in the KDC's certificate matches the domain name to which the user is authenticating.
|D | After passing this criteria, Kerberos returns the TGT to lsass, where it's cached and used for subsequent service ticket requests.|
|E | Lsass informs Winlogon of the success authentication. Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.|
-|F | While Windows loads the user's desktop, lsass passes the collected credentials to the Cloud Authentication security support provider, referred to as the Cloud AP provider. The Cloud AP provider requests a nonce from Azure Active Directory. Azure AD returns a nonce.|
-|G | The Cloud AP provider signs the nonce using the user's private key and returns the signed nonce to the Azure Active Directory. Azure Active Directory validates the signed nonce using the user's securely registered public key against the nonce signature. After validating the signature, Azure AD then validates the returned signed nonce. After validating the nonce, Azure AD creates a PRT with session key that is encrypted to the device's transport key and returns it to the Cloud AP provider.
The Cloud AP provider receives the encrypted PRT with session key. Using the device's private transport key, the Cloud AP provider decrypt the session key and protects the session key using the device's TPM.
The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT.|
+|F | While Windows loads the user's desktop, lsass passes the collected credentials to the Cloud Authentication security support provider, referred to as the Cloud AP provider. The Cloud AP provider requests a nonce from Microsoft Entra ID. Microsoft Entra ID returns a nonce.|
+|G | The Cloud AP provider signs the nonce using the user's private key and returns the signed nonce to the Microsoft Entra ID. Microsoft Entra ID validates the signed nonce using the user's securely registered public key against the nonce signature. After validating the signature, Microsoft Entra ID then validates the returned signed nonce. After validating the nonce, Microsoft Entra ID creates a PRT with session key that is encrypted to the device's transport key and returns it to the Cloud AP provider.
The Cloud AP provider receives the encrypted PRT with session key. Using the device's private transport key, the Cloud AP provider decrypt the session key and protects the session key using the device's TPM.
The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT.|
> [!IMPORTANT]
> In the above deployment model, a **newly provisioned** user will not be able to sign in using Windows Hello for Business unless the device has line of sight to the domain controller.
diff --git a/windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md b/windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md
index ee7ba7e558..dc5f922db7 100644
--- a/windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md
+++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md
@@ -8,100 +8,110 @@ ms.topic: overview
Windows Hello for Business provisioning enables a user to enroll a new, strong, two-factor credential that they can use for passwordless authentication. Provisioning experience vary based on:
-- How the device is joined to Azure Active Directory
+- How the device is joined to Microsoft Entra ID
- The Windows Hello for Business deployment type
- If the environment is managed or federated
List of provisioning flows:
-- [Azure AD joined provisioning in a managed environment](#azure-ad-joined-provisioning-in-a-managed-environment)
-- [Azure AD joined provisioning in a federated environment](#azure-ad-joined-provisioning-in-a-federated-environment)
-- [Hybrid Azure AD joined provisioning in a cloud Kerberos trust deployment in a managed environment](#hybrid-azure-ad-joined-provisioning-in-a-cloud-kerberos-trust-deployment-in-a-managed-environment)
-- [Hybrid Azure AD joined provisioning in a key trust deployment in a managed environment](#hybrid-azure-ad-joined-provisioning-in-a-key-trust-deployment-in-a-managed-environment)
-- [Hybrid Azure AD joined provisioning in a synchronous certificate trust deployment in a federated environment](#hybrid-azure-ad-joined-provisioning-in-a-synchronous-certificate-trust-deployment-in-a-federated-environment)
+- [Microsoft Entra joined provisioning in a managed environment](#azure-ad-joined-provisioning-in-a-managed-environment)
+- [Microsoft Entra joined provisioning in a federated environment](#azure-ad-joined-provisioning-in-a-federated-environment)
+- [Microsoft Entra hybrid joined provisioning in a cloud Kerberos trust deployment in a managed environment](#hybrid-azure-ad-joined-provisioning-in-a-cloud-kerberos-trust-deployment-in-a-managed-environment)
+- [Microsoft Entra hybrid joined provisioning in a key trust deployment in a managed environment](#hybrid-azure-ad-joined-provisioning-in-a-key-trust-deployment-in-a-managed-environment)
+- [Microsoft Entra hybrid joined provisioning in a synchronous certificate trust deployment in a federated environment](#hybrid-azure-ad-joined-provisioning-in-a-synchronous-certificate-trust-deployment-in-a-federated-environment)
- [Domain joined provisioning in an On-premises key trust deployment](#domain-joined-provisioning-in-an-on-premises-key-trust-deployment)
- [Domain joined provisioning in an On-premises certificate trust deployment](#domain-joined-provisioning-in-an-on-premises-certificate-trust-deployment)
> [!NOTE]
> The flows in this section are not exhaustive for every possible scenario. For example, Federated Key Trust is also a supported configuration.
-## Azure AD joined provisioning in a managed environment
+
-
+## Microsoft Entra joined provisioning in a managed environment
+
+
[Full size image](images/howitworks/prov-aadj-managed.png)
| Phase | Description |
| :----: | :----------- |
-| A|The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.
Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. The Azure MFA service provides the second factor of authentication. If the user has performed Azure MFA within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they are not prompted for MFA because the current MFA remains valid.
Azure Active Directory validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
+| A|The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Microsoft Entra Web Account Manager plug-in.
Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. The Azure MFA service provides the second factor of authentication. If the user has performed Azure MFA within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they are not prompted for MFA because the current MFA remains valid.
Microsoft Entra ID validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
|B | After receiving an ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data. This is the user key (ukpub/ukpriv).|
-|C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates the MFA claim remains current. On successful validation, Azure DRS locates the user's object in Azure Active Directory, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Azure Active Directory returns a key ID to the application which signals the end of user provisioning and the application exits.|
+|C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates the MFA claim remains current. On successful validation, Azure DRS locates the user's object in Microsoft Entra ID, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Microsoft Entra ID returns a key ID to the application which signals the end of user provisioning and the application exits.|
[Return to top](#windows-hello-for-business-provisioning)
-## Azure AD joined provisioning in a federated environment
+
-
+## Microsoft Entra joined provisioning in a federated environment
+
+
[Full size image](images/howitworks/prov-aadj-federated.png)
| Phase | Description |
| :----: | :----------- |
-| A|The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.
In a federated environment, the plug-in sends the token request to the on-premises STS, such as Active Directory Federation Services. The on-premises STS authenticates the user and determines if the user should perform another factor of authentication.
Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. The Azure MFA service provides the second factor of authentication. If the user has performed Azure MFA within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they are not prompted for MFA because the current MFA remains valid.
The on-premises STS server issues an enterprise token on successful MFA. The application sends the token to Azure Active Directory.
Azure Active Directory validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
+| A|The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Microsoft Entra Web Account Manager plug-in.
In a federated environment, the plug-in sends the token request to the on-premises STS, such as Active Directory Federation Services. The on-premises STS authenticates the user and determines if the user should perform another factor of authentication.
Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. The Azure MFA service provides the second factor of authentication. If the user has performed Azure MFA within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they are not prompted for MFA because the current MFA remains valid.
The on-premises STS server issues an enterprise token on successful MFA. The application sends the token to Microsoft Entra ID.
Microsoft Entra ID validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
|B | After receiving an ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data. This is the user key (ukpub/ukpriv).|
-|C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates MFA claim remains current. On successful validation, Azure DRS locates the user's object in Azure Active Directory, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Azure Active Directory returns key ID to the application which signals the end of user provisioning and the application exits.|
+|C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates MFA claim remains current. On successful validation, Azure DRS locates the user's object in Microsoft Entra ID, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Microsoft Entra ID returns key ID to the application which signals the end of user provisioning and the application exits.|
[Return to top](#windows-hello-for-business-provisioning)
-## Hybrid Azure AD joined provisioning in a cloud Kerberos trust deployment in a managed environment
+
-
+## Microsoft Entra hybrid joined provisioning in a cloud Kerberos trust deployment in a managed environment
+
+
[Full size image](images/howitworks/prov-haadj-cloudtrust-managed.png)
| Phase | Description |
|:-----:|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| A | The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.
Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. The Azure MFA service provides the second factor of authentication. If the user has performed Azure MFA within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they are not prompted for MFA because the current MFA remains valid.
Azure Active Directory validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
+| A | The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Microsoft Entra Web Account Manager plug-in.
Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. The Azure MFA service provides the second factor of authentication. If the user has performed Azure MFA within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they are not prompted for MFA because the current MFA remains valid.
Microsoft Entra ID validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
| B | After receiving an ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data. This is the user key (ukpub/ukpriv). |
-| C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates the MFA claim remains current. On successful validation, Azure DRS locates the user's object in Azure Active Directory, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Azure Active Directory returns a key ID to the application which signals the end of user provisioning and the application exits. |
+| C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates the MFA claim remains current. On successful validation, Azure DRS locates the user's object in Microsoft Entra ID, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Microsoft Entra ID returns a key ID to the application which signals the end of user provisioning and the application exits. |
> [!NOTE]
-> Windows Hello for Business cloud Kerberos trust does not require users' keys to be synced from Azure AD to AD. Users can immediately authenticate to Azure Active Directory and AD after provisioning their credential.
+> Windows Hello for Business cloud Kerberos trust does not require users' keys to be synced from Microsoft Entra ID to Active Directory. Users can immediately authenticate to Microsoft Entra ID and AD after provisioning their credential.
[Return to top](#windows-hello-for-business-provisioning)
-## Hybrid Azure AD joined provisioning in a key trust deployment in a managed environment
+
-
+## Microsoft Entra hybrid joined provisioning in a key trust deployment in a managed environment
+
+
[Full size image](images/howitworks/prov-haadj-keytrust-managed.png)
| Phase | Description |
|:-----:|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| A | The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.
Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. The Azure MFA service provides the second factor of authentication. If the user has performed Azure MFA within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they are not prompted for MFA because the current MFA remains valid.
Azure Active Directory validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
+| A | The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Microsoft Entra Web Account Manager plug-in.
Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. The Azure MFA service provides the second factor of authentication. If the user has performed Azure MFA within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they are not prompted for MFA because the current MFA remains valid.
Microsoft Entra ID validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
| B | After receiving an ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data. This is the user key (ukpub/ukpriv). |
-| C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates the MFA claim remains current. On successful validation, Azure DRS locates the user's object in Azure Active Directory, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Azure Active Directory returns a key ID to the application which signals the end of user provisioning and the application exits. |
-| D | Azure AD Connect requests updates on its next synchronization cycle. Azure Active Directory sends the user's public key that was securely registered through provisioning. Azure Active Directory Connect receives the public key and writes it to user's msDS-KeyCredentialLink attribute in Active Directory. |
+| C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates the MFA claim remains current. On successful validation, Azure DRS locates the user's object in Microsoft Entra ID, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Microsoft Entra ID returns a key ID to the application which signals the end of user provisioning and the application exits. |
+| D | Microsoft Entra Connect requests updates on its next synchronization cycle. Microsoft Entra ID sends the user's public key that was securely registered through provisioning. Microsoft Entra Connect receives the public key and writes it to user's msDS-KeyCredentialLink attribute in Active Directory. |
> [!IMPORTANT]
-> The newly provisioned user will not be able to sign in using Windows Hello for Business until Azure AD Connect successfully synchronizes the public key to the on-premises Active Directory.
+> The newly provisioned user will not be able to sign in using Windows Hello for Business until Microsoft Entra Connect successfully synchronizes the public key to the on-premises Active Directory.
[Return to top](#windows-hello-for-business-provisioning)
-## Hybrid Azure AD joined provisioning in a synchronous certificate trust deployment in a federated environment
+
-
+## Microsoft Entra hybrid joined provisioning in a synchronous certificate trust deployment in a federated environment
+
+
[Full size image](images/howitworks/prov-haadj-instant-certtrust-federated.png)
| Phase | Description |
|:-----:|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| A | The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.
In a federated environment, the plug-in sends the token request to the on-premises STS, such as Active Directory Federation Services. The on-premises STS authenticates the user and determines if the user should perform another factor of authentication.
Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. The Azure MFA service (or a third party MFA service) provides the second factor of authentication.
The on-premises STS server issues an enterprise token on successful MFA. The application sends the token to Azure Active Directory.
Azure Active Directory validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
+| A | The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Microsoft Entra Web Account Manager plug-in.
In a federated environment, the plug-in sends the token request to the on-premises STS, such as Active Directory Federation Services. The on-premises STS authenticates the user and determines if the user should perform another factor of authentication.
Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. The Azure MFA service (or a third party MFA service) provides the second factor of authentication.
The on-premises STS server issues an enterprise token on successful MFA. The application sends the token to Microsoft Entra ID.
Microsoft Entra ID validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
| B | After receiving an ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data. This is the user key (ukpub/ukpriv). |
-| C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates the MFA claim remains current. On successful validation, Azure DRS locates the user's object in Azure Active Directory, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Azure Active Directory returns a key ID and a key receipt to the application, which represents the end of user key registration. |
+| C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates the MFA claim remains current. On successful validation, Azure DRS locates the user's object in Microsoft Entra ID, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Microsoft Entra ID returns a key ID and a key receipt to the application, which represents the end of user key registration. |
| D | The certificate request portion of provisioning begins after the application receives a successful response from key registration. The application creates a PKCS#10 certificate request. The key used in the certificate request is the same key that was securely provisioned.
The application sends the key receipt and certificate request, which includes the public key, to the certificate registration authority hosted on the Active Directory Federation Services (AD FS) farm.
After receiving the certificate request, the certificate registration authority queries Active Directory for the msDS-KeyCredentialsLink for a list of registered public keys. |
| E | The registration authority validates the public key in the certificate request matches a registered key for the user.
If the public key in the certificate is not found in the list of registered public keys, it then validates the key receipt to confirm the key was securely registered with Azure.
After validating the key receipt or public key, the registration authority signs the certificate request using its enrollment agent certificate. |
| F | The registration authority sends the certificate request to the enterprise issuing certificate authority. The certificate authority validates the certificate request is signed by a valid enrollment agent and, on success, issues a certificate and returns it to the registration authority that then returns the certificate to the application. |
| G | The application receives the newly issued certificate and installs it into the Personal store of the user. This signals the end of provisioning. |
> [!IMPORTANT]
-> Synchronous certificate enrollment does not depend on Azure AD Connect to synchronize the user's public key to issue the Windows Hello for Business authentication certificate. Users can sign-in using the certificate immediately after provisioning completes. Azure AD Connect continues to synchronize the public key to Active Directory, but is not shown in this flow.
+> Synchronous certificate enrollment does not depend on Microsoft Entra Connect to synchronize the user's public key to issue the Windows Hello for Business authentication certificate. Users can sign-in using the certificate immediately after provisioning completes. Microsoft Entra Connect continues to synchronize the public key to Active Directory, but is not shown in this flow.
[Return to top](#windows-hello-for-business-provisioning)
## Domain joined provisioning in an On-premises Key Trust deployment
@@ -110,7 +120,7 @@ List of provisioning flows:
| Phase | Description |
| :----: | :----------- |
-|A| The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Enterprise Device Registration Service (EDRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.
In an on-premises deployment, the plug-in sends the token request to the on-premises STS, such as Active Directory Federation Services. The on-premises STS authenticates the user and determines if the user should perform another factor of authentication.
Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. Azure MFA server (or a third party MFA service) provides the second factor of authentication.
The on-premises STS server issues an enterprise DRS token on successful MFA.|
+|A| The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Enterprise Device Registration Service (EDRS). The application makes the request using the Microsoft Entra Web Account Manager plug-in.
In an on-premises deployment, the plug-in sends the token request to the on-premises STS, such as Active Directory Federation Services. The on-premises STS authenticates the user and determines if the user should perform another factor of authentication.
Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. Azure MFA server (or a third party MFA service) provides the second factor of authentication.
The on-premises STS server issues an enterprise DRS token on successful MFA.|
| B| After receiving an EDRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data. This is the user key (ukpub/ukpriv).|
|C | The application sends the EDRS token, ukpub, attestation data, and device information to the Enterprise DRS for user key registration. Enterprise DRS validates the MFA claim remains current. On successful validation, the Enterprise DRS locates the user's object in Active Directory, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. The Enterprise DRS returns a key ID to the application, which represents the end of user key registration.|
@@ -122,7 +132,7 @@ List of provisioning flows:
| Phase | Description |
| :----: | :----------- |
-|A| The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Enterprise Device Registration Service (EDRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.
In an on-premises deployment, the plug-in sends the token request to the on-premises STS, such as Active Directory Federation Services. The on-premises STS authenticates the user and determines if the user should perform another factor of authentication.
Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. Azure MFA server (or a third party MFA service) provides the second factor of authentication.
The on-premises STS server issues an enterprise DRS token on successful MFA.|
+|A| The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Enterprise Device Registration Service (EDRS). The application makes the request using the Microsoft Entra Web Account Manager plug-in.
In an on-premises deployment, the plug-in sends the token request to the on-premises STS, such as Active Directory Federation Services. The on-premises STS authenticates the user and determines if the user should perform another factor of authentication.
Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. Azure MFA server (or a third party MFA service) provides the second factor of authentication.
The on-premises STS server issues an enterprise DRS token on successful MFA.|
| B| After receiving an EDRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data. This is the user key (ukpub/ukpriv).|
|C | The application sends the EDRS token, ukpub, attestation data, and device information to the Enterprise DRS for user key registration. Enterprise DRS validates the MFA claim remains current. On successful validation, the Enterprise DRS locates the user's object in Active Directory, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. The Enterprise DRS returns a key ID to the application, which represents the end of user key registration.|
|D | The certificate request portion of provisioning begins after the application receives a successful response from key registration. The application creates a PKCS#10 certificate request. The key used in the certificate request is the same key that was securely provisioned.
The application sends the certificate request, which includes the public key, to the certificate registration authority hosted on the Active Directory Federation Services (AD FS) farm.
After receiving the certificate request, the certificate registration authority queries Active Directory for the msDS-KeyCredentialsLink for a list of registered public keys.|
diff --git a/windows/security/identity-protection/hello-for-business/hello-how-it-works-technology.md b/windows/security/identity-protection/hello-for-business/hello-how-it-works-technology.md
index 8c6856a2da..be3cce3029 100644
--- a/windows/security/identity-protection/hello-for-business/hello-how-it-works-technology.md
+++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works-technology.md
@@ -32,32 +32,44 @@ In the issued AIK certificate, a special OID is added to attest that endorsement
- [Windows client certificate enrollment protocol: glossary](/openspecs/windows_protocols/ms-wcce/719b890d-62e6-4322-b9b1-1f34d11535b4#gt_70efa425-6b46-462f-911d-d399404529ab)
- [TPM library specification](https://trustedcomputinggroup.org/resource/tpm-library-specification/)
-## Azure Active Directory join
+
-Azure Active Directory (Azure AD) join is intended for organizations that desire to be cloud-first or cloud-only. There's no restriction on the size or type of organizations that can deploy Azure AD join. Azure AD join also works in a hybrid environment and can enable access to on-premises applications and resources.
+## Microsoft Entra join
-### Related to Azure AD join
+Microsoft Entra join is intended for organizations that desire to be cloud-first or cloud-only. There's no restriction on the size or type of organizations that can deploy Microsoft Entra join. Microsoft Entra join also works in a hybrid environment and can enable access to on-premises applications and resources.
+
+
+
+### Related to Microsoft Entra join
- [Join type](#join-type)
-- [Hybrid Azure AD join](#hybrid-azure-ad-join)
+- [Microsoft Entra hybrid join](#hybrid-azure-ad-join)
-### More information about Azure AD join
+
-[Introduction to device identity in Azure AD](/azure/active-directory/devices/overview).
+### More information about Microsoft Entra join
-## Azure AD registration
+[Introduction to device identity in Microsoft Entra ID](/azure/active-directory/devices/overview).
-The goal of Azure AD-registered devices is to provide you with support for the _bring your own device_ (BYOD) scenario. In this scenario, a user can access your organization's Azure AD-controlled resources using a personal device.
+
-### Related to Azure AD registration
+## Microsoft Entra registration
-- [Azure AD join](#azure-active-directory-join)
-- [Hybrid Azure AD join](#hybrid-azure-ad-join)
+The goal of Microsoft Entra registered devices is to provide you with support for the _bring your own device_ (BYOD) scenario. In this scenario, a user can access your organization's Microsoft Entra ID-controlled resources using a personal device.
+
+
+
+### Related to Microsoft Entra registration
+
+- [Microsoft Entra join](#azure-active-directory-join)
+- [Microsoft Entra hybrid join](#hybrid-azure-ad-join)
- [Join type](#join-type)
-### More information about Azure AD registration
+
-[Introduction to device identity in Azure AD](/azure/active-directory/devices/overview).
+### More information about Microsoft Entra registration
+
+[Introduction to device identity in Microsoft Entra ID](/azure/active-directory/devices/overview).
## Certificate trust
@@ -66,7 +78,7 @@ The certificate trust model uses a securely issued certificate based on the user
### Related to certificate trust
- [Deployment type](#deployment-type)
-- [Hybrid Azure AD join](#hybrid-azure-ad-join)
+- [Microsoft Entra hybrid join](#hybrid-azure-ad-join)
- [Hybrid deployment](#hybrid-deployment)
- [Cloud Kerberos trust](#cloud-kerberos-trust)
- [Key trust](#key-trust)
@@ -79,18 +91,18 @@ The certificate trust model uses a securely issued certificate based on the user
## Cloud deployment
-The Windows Hello for Business cloud deployment is exclusively for organizations using cloud-based identities and resources. Device management is accomplished using Intune or a modern management alternative. Cloud deployments use Azure AD-joined or Azure AD-registered devices.
+The Windows Hello for Business cloud deployment is exclusively for organizations using cloud-based identities and resources. Device management is accomplished using Intune or a modern management alternative. Cloud deployments use Microsoft Entra joined or Microsoft Entra registered devices.
### Related to cloud deployment
-- [Azure AD join](#azure-active-directory-join)
-- [Azure AD registration](#azure-ad-registration)
+- [Microsoft Entra join](#azure-active-directory-join)
+- [Microsoft Entra registration](#azure-ad-registration)
- [Deployment type](#deployment-type)
- [Join type](#join-type)
## Cloud experience host
-In Windows 10 and Windows 11, cloud experience host is an application used while joining the workplace environment or Azure AD for rendering the experience when collecting your company-provided credentials. Once you enroll your device to your workplace environment or Azure AD, your organization will be able to manage your PC and collect information about you (including your location). It might add or remove apps or content, change settings, disable features, prevent you from removing your company account, or reset your PC.
+In Windows 10 and Windows 11, cloud experience host is an application used while joining the workplace environment or Microsoft Entra ID for rendering the experience when collecting your company-provided credentials. Once you enroll your device to your workplace environment or Microsoft Entra ID, your organization will be able to manage your PC and collect information about you (including your location). It might add or remove apps or content, change settings, disable features, prevent you from removing your company account, or reset your PC.
### Related to cloud experience host
@@ -111,7 +123,7 @@ Giving the simplicity offered by this model, cloud Kerberos trust is the recomme
### Related to cloud Kerberos trust
- [Deployment type](#deployment-type)
-- [Hybrid Azure AD join](#hybrid-azure-ad-join)
+- [Microsoft Entra hybrid join](#hybrid-azure-ad-join)
- [Hybrid deployment](#hybrid-deployment)
- [Key trust](#key-trust)
- [On-premises deployment](#on-premises-deployment)
@@ -168,7 +180,7 @@ For certain devices that use firmware-based TPM produced by Intel or Qualcomm, t
## Federated environment
-Primarily for large enterprise organizations with more complex authentication requirements, on-premises directory objects are synchronized with Azure AD and users accounts are managed on-premises. With AD FS, users have the same password on-premises and in the cloud and they don't have to sign in again to use Microsoft cloud services. This federated authentication model can provide extra authentication requirements, such as smart card-based authentication or a third-party multi-factor authentication and is typically required when organizations have an authentication requirement not natively supported by Azure AD.
+Primarily for large enterprise organizations with more complex authentication requirements, on-premises directory objects are synchronized with Microsoft Entra ID and users accounts are managed on-premises. With AD FS, users have the same password on-premises and in the cloud and they don't have to sign in again to use Microsoft cloud services. This federated authentication model can provide extra authentication requirements, such as smart card-based authentication or a third-party multi-factor authentication and is typically required when organizations have an authentication requirement not natively supported by Microsoft Entra ID.
### Related to federated environment
@@ -179,9 +191,11 @@ Primarily for large enterprise organizations with more complex authentication re
### More information about federated environment
-[Choose the right authentication method for your Azure AD hybrid identity solution](/azure/active-directory/hybrid/choose-ad-authn)
+[Choose the right authentication method for your Microsoft Entra hybrid identity solution](/azure/active-directory/hybrid/choose-ad-authn)
-## Hybrid Azure AD join
+
+
+## Microsoft Entra hybrid join
For more than a decade, many organizations have used the domain join to their on-premises Active Directory to enable:
@@ -190,27 +204,31 @@ For more than a decade, many organizations have used the domain join to their on
Typically, organizations with an on-premises footprint rely on imaging methods to provision devices, and they often use or group policy to manage them.
-If your environment has an on-premises AD footprint and you also want benefit from the capabilities provided by Azure AD, you can implement hybrid Azure AD-joined devices. These devices are joined to both your on-premises Active Directory and your Azure AD.
+If your environment has an on-premises AD footprint and you also want benefit from the capabilities provided by Microsoft Entra ID, you can implement Microsoft Entra hybrid joined devices. These devices are joined to both your on-premises Active Directory and your Microsoft Entra ID.
-### Related to hybrid Azure AD join
+
-- [Azure AD join](#azure-active-directory-join)
-- [Azure AD registration](#azure-ad-registration)
+### Related to Microsoft Entra hybrid join
+
+- [Microsoft Entra join](#azure-active-directory-join)
+- [Microsoft Entra registration](#azure-ad-registration)
- [Hybrid deployment](#hybrid-deployment)
-### More information about hybrid Azure AD join
+
-[Introduction to device identity in Azure AD](/azure/active-directory/devices/overview)
+### More information about Microsoft Entra hybrid join
+
+[Introduction to device identity in Microsoft Entra ID](/azure/active-directory/devices/overview)
## Hybrid deployment
-The Windows Hello for Business hybrid deployment is for organizations that have both on-premises and cloud resources that are accessed using a managed or federated identity that's synchronized with Azure AD. Hybrid deployments support devices that are Azure AD-registered, Azure AD-joined, and hybrid Azure AD-joined. The Hybrid deployment model supports three trust types for on-premises authentication: cloud Kerberos trust, key trust and certificate trust.
+The Windows Hello for Business hybrid deployment is for organizations that have both on-premises and cloud resources that are accessed using a managed or federated identity that's synchronized with Microsoft Entra ID. Hybrid deployments support devices that are Microsoft Entra registered, Microsoft Entra joined, and Microsoft Entra hybrid joined. The Hybrid deployment model supports three trust types for on-premises authentication: cloud Kerberos trust, key trust and certificate trust.
### Related to hybrid deployment
-- [Azure AD join](#azure-active-directory-join)
-- [Azure AD registration](#azure-ad-registration)
-- [Hybrid Azure AD join](#hybrid-azure-ad-join)
+- [Microsoft Entra join](#azure-active-directory-join)
+- [Microsoft Entra registration](#azure-ad-registration)
+- [Microsoft Entra hybrid join](#hybrid-azure-ad-join)
### More information about hybrid deployment
@@ -218,23 +236,23 @@ The Windows Hello for Business hybrid deployment is for organizations that have
## Join type
-Join type is how devices are associated with Azure AD. For a device to authenticate to Azure AD it must be registered or joined.
+Join type is how devices are associated with Microsoft Entra ID. For a device to authenticate to Microsoft Entra it must be registered or joined.
-Registering a device to Azure AD enables you to manage a device's identity. When a device is registered, Azure AD device registration provides the device with an identity that is used to authenticate the device when a user signs-in to Azure AD. You can use the identity to enable or disable a device.
+Registering a device to Microsoft Entra ID enables you to manage a device's identity. When a device is registered, Microsoft Entra device registration provides the device with an identity that is used to authenticate the device when a user signs-in to Microsoft Entra ID. You can use the identity to enable or disable a device.
-When combined with a mobile device management (MDM) solution such as Microsoft Intune, the device attributes in Azure AD are updated with additional information about the device. This behavior allows you to create conditional access rules that enforce access from devices to meet your standards for security and compliance. For more information on enrolling devices in Microsoft Intune, see Enroll devices for management in Intune.
+When combined with a mobile device management (MDM) solution such as Microsoft Intune, the device attributes in Microsoft Entra ID are updated with additional information about the device. This behavior allows you to create conditional access rules that enforce access from devices to meet your standards for security and compliance. For more information on enrolling devices in Microsoft Intune, see Enroll devices for management in Intune.
Joining a device is an extension to registering a device. This method provides you with all the benefits of registering a device, and changes the local state of a device. Changing the local state enables your users to sign-in to a device using an organizational work or school account instead of a personal account.
### Related to join type
-- [Azure AD join](#azure-active-directory-join)
-- [Azure AD registration](#azure-ad-registration)
-- [Hybrid Azure AD join](#hybrid-azure-ad-join)
+- [Microsoft Entra join](#azure-active-directory-join)
+- [Microsoft Entra registration](#azure-ad-registration)
+- [Microsoft Entra hybrid join](#hybrid-azure-ad-join)
### More information about join type
-[Introduction to device identity in Azure AD](/azure/active-directory/devices/overview)
+[Introduction to device identity in Microsoft Entra ID](/azure/active-directory/devices/overview)
## Key trust
@@ -245,7 +263,7 @@ The key trust model uses the user's Windows Hello for Business identity to authe
- [Cloud Kerberos trust](#cloud-kerberos-trust)
- [Certificate trust](#certificate-trust)
- [Deployment type](#deployment-type)
-- [Hybrid Azure AD join](#hybrid-azure-ad-join)
+- [Microsoft Entra hybrid join](#hybrid-azure-ad-join)
- [Hybrid deployment](#hybrid-deployment)
- [On-premises deployment](#on-premises-deployment)
- [Trust type](#trust-type)
@@ -256,7 +274,7 @@ The key trust model uses the user's Windows Hello for Business identity to authe
## Managed environment
-Managed environments are for non-federated environments where Azure AD manages the authentication using technologies such as Password Hash Synchronization and Pass-through Authentication rather than a federation service such as Active Directory Federation Services (ADFS).
+Managed environments are for non-federated environments where Microsoft Entra ID manages the authentication using technologies such as Password Hash Synchronization and Pass-through Authentication rather than a federation service such as Active Directory Federation Services (ADFS).
### Related to managed environment
@@ -280,7 +298,7 @@ The Windows Hello for Business on-premises deployment is for organizations that
## Pass-through authentication
-Pass-through authentication provides a simple password validation for Azure AD authentication services. It uses a software agent that runs on one or more on-premises servers to validate the users directly with your on-premises Active Directory. With pass-through authentication (PTA), you synchronize on-premises Active Directory user account objects with Azure AD and manage your users on-premises. Allows your users to sign in to both on-premises and Microsoft cloud resources and applications using their on-premises account and password. This configuration validates users' passwords directly against your on-premises Active Directory without sending password hashes to Azure AD. Companies with a security requirement to immediately enforce on-premises user account states, password policies, and sign-in hours would use this authentication method. With seamless single sign-on, users are automatically signed in to Azure AD when they are on their corporate devices and connected to your corporate network.
+Pass-through authentication provides a simple password validation for Microsoft Entra authentication services. It uses a software agent that runs on one or more on-premises servers to validate the users directly with your on-premises Active Directory. With pass-through authentication (PTA), you synchronize on-premises Active Directory user account objects with Microsoft Entra ID and manage your users on-premises. Allows your users to sign in to both on-premises and Microsoft cloud resources and applications using their on-premises account and password. This configuration validates users' passwords directly against your on-premises Active Directory without sending password hashes to Microsoft Entra ID. Companies with a security requirement to immediately enforce on-premises user account states, password policies, and sign-in hours would use this authentication method. With seamless single sign-on, users are automatically signed in to Microsoft Entra ID when they are on their corporate devices and connected to your corporate network.
### Related to pass-through authentication
@@ -290,11 +308,11 @@ Pass-through authentication provides a simple password validation for Azure AD a
### More information about pass-through authentication
-[Choose the right authentication method for your Azure AD hybrid identity solution](/azure/active-directory/hybrid/choose-ad-authn)
+[Choose the right authentication method for your Microsoft Entra hybrid identity solution](/azure/active-directory/hybrid/choose-ad-authn)
## Password hash sync
-Password hash sync is the simplest way to enable authentication for on-premises directory objects in Azure AD. With password hash sync (PHS), you synchronize your on-premises Active Directory user account objects with Azure AD and manage your users on-premises. Hashes of user passwords are synchronized from your on-premises Active Directory to Azure AD so that the users have the same password on-premises and in the cloud. When passwords are changed or reset on-premises, the new password hashes are synchronized to Azure AD so that your users can always use the same password for cloud resources and on-premises resources. The passwords are never sent to Azure AD or stored in Azure AD in clear text. Some premium features of Azure AD, such as Identity Protection, require PHS regardless of which authentication method is selected. With seamless single sign-on, users are automatically signed in to Azure AD when they are on their corporate devices and connected to your corporate network.
+Password hash sync is the simplest way to enable authentication for on-premises directory objects in Microsoft Entra ID. With password hash sync (PHS), you synchronize your on-premises Active Directory user account objects with Microsoft Entra ID and manage your users on-premises. Hashes of user passwords are synchronized from your on-premises Active Directory to Microsoft Entra ID so that the users have the same password on-premises and in the cloud. When passwords are changed or reset on-premises, the new password hashes are synchronized to Microsoft Entra ID so that your users can always use the same password for cloud resources and on-premises resources. The passwords are never sent to Microsoft Entra ID or stored in Microsoft Entra ID in clear text. Some premium features of Microsoft Entra ID, such as Identity Protection, require PHS regardless of which authentication method is selected. With seamless single sign-on, users are automatically signed in to Microsoft Entra ID when they are on their corporate devices and connected to your corporate network.
### Related to password hash sync
@@ -304,13 +322,13 @@ Password hash sync is the simplest way to enable authentication for on-premises
### More information about password hash sync
-[Choose the right authentication method for your Azure AD hybrid identity solution](/azure/active-directory/hybrid/choose-ad-authn)
+[Choose the right authentication method for your Microsoft Entra hybrid identity solution](/azure/active-directory/hybrid/choose-ad-authn)
## Primary refresh token
-Single sign on (SSO) relies on special tokens obtained for each of the types of applications above. These special tokens are then used to obtain access tokens to specific applications. In the traditional Windows Integrated authentication case using Kerberos, this token is a Kerberos TGT (ticket-granting ticket). For Azure AD and AD FS applications, this token is a _primary refresh token_ (PRT). It's a [JSON Web Token](https://openid.net/specs/draft-jones-json-web-token-07.html) that contains claims about both the user and the device.
+Single sign on (SSO) relies on special tokens obtained for each of the types of applications above. These special tokens are then used to obtain access tokens to specific applications. In the traditional Windows Integrated authentication case using Kerberos, this token is a Kerberos TGT (ticket-granting ticket). For Microsoft Entra ID and AD FS applications, this token is a _primary refresh token_ (PRT). It's a [JSON Web Token](https://openid.net/specs/draft-jones-json-web-token-07.html) that contains claims about both the user and the device.
-The PRT is initially obtained during Windows user sign-in or unlock in a similar way the Kerberos TGT is obtained. This behavior is true for both Azure AD joined and hybrid Azure AD-joined devices. For personal devices registered with Azure AD, the PRT is initially obtained upon Add Work or School Account. For a personal device the account to unlock the device isn't the work account, but a consumer account. For example, hotmail.com, live.com, or outlook.com.
+The PRT is initially obtained during Windows user sign-in or unlock in a similar way the Kerberos TGT is obtained. This behavior is true for both Microsoft Entra joined and Microsoft Entra hybrid joined devices. For personal devices registered with Microsoft Entra ID, the PRT is initially obtained upon Add Work or School Account. For a personal device the account to unlock the device isn't the work account, but a consumer account. For example, hotmail.com, live.com, or outlook.com.
The PRT is needed for SSO. Without it, the user will be prompted for credentials when accessing applications every time. The PRT also contains information about the device. If you have any [device-based conditional access](/azure/active-directory/conditional-access/concept-conditional-access-grant) policy set on an application, without the PRT, access will be denied.
@@ -330,7 +348,7 @@ The storage root key (SRK) is also an asymmetric key pair (RSA with a minimum of
## Trust type
-The trust type determines how a user authenticates to the Active Directory to access on-premises resources. There are two trust types, key trust and certificate trust. The hybrid and on-premises deployment models support both trust types. The trust type doesn't affect authentication to Azure AD. Windows Hello for Business authentication to Azure AD always uses the key, not a certificate (excluding smart card authentication in a federated environment).
+The trust type determines how a user authenticates to the Active Directory to access on-premises resources. There are two trust types, key trust and certificate trust. The hybrid and on-premises deployment models support both trust types. The trust type doesn't affect authentication to Microsoft Entra ID. Windows Hello for Business authentication to Microsoft Entra ID always uses the key, not a certificate (excluding smart card authentication in a federated environment).
### Related to trust type
diff --git a/windows/security/identity-protection/hello-for-business/hello-how-it-works.md b/windows/security/identity-protection/hello-for-business/hello-how-it-works.md
index a39e31f06f..ee893787c7 100644
--- a/windows/security/identity-protection/hello-for-business/hello-how-it-works.md
+++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works.md
@@ -6,7 +6,7 @@ ms.topic: overview
---
# How Windows Hello for Business works in Windows Devices
-Windows Hello for Business is a two-factor credential that is a more secure alternative to passwords. Whether you are cloud or on-premises, Windows Hello for Business has a deployment option for you. For cloud deployments, you can use Windows Hello for Business with Azure Active Directory-joined, Hybrid Azure Active Directory-joined, or Azure AD registered devices. Windows Hello for Business also works for domain joined devices.
+Windows Hello for Business is a two-factor credential that is a more secure alternative to passwords. Whether you are cloud or on-premises, Windows Hello for Business has a deployment option for you. For cloud deployments, you can use Windows Hello for Business with Microsoft Entra joined, Microsoft Entra hybrid joined, or Microsoft Entra registered devices. Windows Hello for Business also works for domain joined devices.
Watch this quick video where Pieter Wigleven gives a simple explanation of how Windows Hello for Business works and some of its supporting features.
> [!VIDEO https://www.youtube.com/embed/G-GJuDWbBE8]
@@ -17,7 +17,7 @@ Windows Hello for Business is a distributed system that uses several components
### Device Registration
-Registration is a fundamental prerequisite for Windows Hello for Business. Without registration, Windows Hello for Business provisioning cannot start. Registration is where the device **registers** its identity with the identity provider. For cloud and hybrid deployments, the identity provider is Azure Active Directory and the device registers with the Azure Device Registration Service (ADRS). For on-premises deployments, the identity provider is Active Directory Federation Services (AD FS), and the device registers with the enterprise device registration service hosted on the federation servers (AD FS).
+Registration is a fundamental prerequisite for Windows Hello for Business. Without registration, Windows Hello for Business provisioning cannot start. Registration is where the device **registers** its identity with the identity provider. For cloud and hybrid deployments, the identity provider is Microsoft Entra ID and the device registers with the Azure Device Registration Service (ADRS). For on-premises deployments, the identity provider is Active Directory Federation Services (AD FS), and the device registers with the enterprise device registration service hosted on the federation servers (AD FS).
For more information, read [how device registration works](/azure/active-directory/devices/device-registration-how-it-works).
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md
index 3eeb4f536d..fab3db4894 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md
@@ -1,6 +1,6 @@
---
-title: Use Certificates to enable SSO for Azure AD join devices
-description: If you want to use certificates for on-premises single-sign on for Azure Active Directory-joined devices, then follow these additional steps.
+title: Use Certificates to enable SSO for Microsoft Entra join devices
+description: If you want to use certificates for on-premises single-sign on for Microsoft Entra joined devices, then follow these additional steps.
ms.date: 08/19/2018
ms.topic: how-to
---
@@ -9,14 +9,14 @@ ms.topic: how-to
[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-cert-trust-aad.md)]
-If you plan to use certificates for on-premises single-sign on, then follow these **additional** steps to configure the environment to enroll Windows Hello for Business certificates for Azure AD-joined devices.
+If you plan to use certificates for on-premises single-sign on, then follow these **additional** steps to configure the environment to enroll Windows Hello for Business certificates for Microsoft Entra joined devices.
> [!IMPORTANT]
-> Ensure you have performed the configurations in [Azure AD-joined devices for On-premises Single-Sign On](/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso) before you continue.
+> Ensure you have performed the configurations in [Microsoft Entra joined devices for On-premises Single-Sign On](/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso) before you continue.
Steps you'll perform include:
-- [Prepare Azure AD Connect](#prepare-azure-ad-connect)
+- [Prepare Microsoft Entra Connect](#prepare-azure-ad-connect)
- [Prepare the Network Device Enrollment Services Service Account](#prepare-the-network-device-enrollment-services-ndes-service-account)
- [Prepare Active Directory Certificate Services](#prepare-active-directory-certificate-authority)
- [Install the Network Device Enrollment Services Role](#install-and-configure-the-ndes-role)
@@ -26,7 +26,7 @@ Steps you'll perform include:
## Requirements
-You need to install and configure additional infrastructure to provide Azure AD-joined devices with on-premises single-sign on.
+You need to install and configure additional infrastructure to provide Microsoft Entra joined devices with on-premises single-sign on.
- An existing Windows Server 2012 R2 or later Enterprise Certificate Authority
- A Windows Server 2012 R2 domain joined server that hosts the Network Device Enrollment Services role
@@ -43,29 +43,33 @@ The Network Device Enrollment Service (NDES) server role can issue up to three u
- Encryption
- Signature and Encryption
-If you need to deploy more than three types of certificates to the Azure AD joined device, you need additional NDES servers. Alternatively, consider consolidating certificate templates to reduce the number of certificate templates.
+If you need to deploy more than three types of certificates to the Microsoft Entra joined device, you need additional NDES servers. Alternatively, consider consolidating certificate templates to reduce the number of certificate templates.
### Network Requirements
All communication occurs securely over port 443.
-## Prepare Azure AD Connect
+
+
+## Prepare Microsoft Entra Connect
Successful authentication to on-premises resources using a certificate requires the certificate to provide a hint about the on-premises domain. The hint can be the user's Active Directory distinguished name as the subject of the certificate, or the hint can be the user's user principal name where the suffix matches the Active Directory domain name.
Most environments change the user principal name suffix to match the organization's external domain name (or vanity domain), which prevents the user principal name as a hint to locate a domain controller. Therefore, the certificate needs the user's on-premises distinguished name in the subject to properly locate a domain controller.
-To include the on-premises distinguished name in the certificate's subject, Azure AD Connect must replicate the Active Directory **distinguishedName** attribute to the Azure Active Directory **onPremisesDistinguishedName** attribute. Azure AD Connect version 1.1.819 includes the proper synchronization rules needed for these attributes.
+To include the on-premises distinguished name in the certificate's subject, Microsoft Entra Connect must replicate the Active Directory **distinguishedName** attribute to the Microsoft Entra ID **onPremisesDistinguishedName** attribute. Microsoft Entra Connect version 1.1.819 includes the proper synchronization rules needed for these attributes.
-### Verify Azure Active Directory Connect version
+
-Sign-in to computer running Azure AD Connect with access equivalent to _local administrator_.
+### Verify Microsoft Entra Connect version
-1. Open **Synchronization Services** from the **Azure AD Connect** folder.
+Sign-in to computer running Microsoft Entra Connect with access equivalent to _local administrator_.
+
+1. Open **Synchronization Services** from the **Microsoft Entra Connect** folder.
2. In the **Synchronization Service Manager**, select **Help** and then select **About**.
-3. If the version number isn't **1.1.819** or later, then upgrade Azure AD Connect to the latest version.
+3. If the version number isn't **1.1.819** or later, then upgrade Microsoft Entra Connect to the latest version.
### Verify the onPremisesDistinguishedName attribute is synchronized
@@ -80,7 +84,7 @@ The easiest way to verify that the onPremisesDistingushedNamne attribute is sync
3. Select **Modify permissions (Preview)**. Scroll down and locate **User.Read.All** (or any other required permission) and select **Consent**. You'll now be prompted for delegated permissions consent.
-4. In the Graph Explorer URL, enter `https://graph.microsoft.com/v1.0/users/[userid]?$select=displayName,userPrincipalName,onPremisesDistinguishedName`, where **[userid]** is the user principal name of a user in Azure Active Directory. Select **Run query**.
+4. In the Graph Explorer URL, enter `https://graph.microsoft.com/v1.0/users/[userid]?$select=displayName,userPrincipalName,onPremisesDistinguishedName`, where **[userid]** is the user principal name of a user in Microsoft Entra ID. Select **Run query**.
> [!NOTE]
> Because the v1.0 endpoint of the Graph API only provides a limited set of parameters, we will use the $select [Optional OData query parameter](/graph/api/user-get?). For convenience, it is possible to switch the API version selector from **v1.0** to **beta** before performing the query. This will provide all available user information, but remember, **beta** endpoint queries should not be used in production scenarios.
@@ -232,7 +236,7 @@ You must prepare the public key infrastructure and the issuing certificate autho
- Configure the certificate authority to let Intune provide validity periods
- Create an NDES-Intune Authentication Certificate template
-- Create an Azure AD joined Windows Hello for Business authentication certificate template
+- Create a Microsoft Entra joined Windows Hello for Business authentication certificate template
- Publish certificate templates
### Configure the certificate authority to let Intune provide validity periods
@@ -283,7 +287,9 @@ Sign-in to the issuing certificate authority or management workstations with _Do
11. Select on the **Apply** to save changes and close the console.
-### Create an Azure AD joined Windows Hello for Business authentication certificate template
+
+
+### Create a Microsoft Entra joined Windows Hello for Business authentication certificate template
During Windows Hello for Business provisioning, Windows requests an authentication certificate from Microsoft Intune, which requests the authentication certificate on behalf of the user. This task configures the Windows Hello for Business authentication certificate template. You use the name of the certificate template when configuring the NDES Server.
@@ -455,13 +461,13 @@ Sign-in a domain controller with a minimum access equivalent to _Domain Admins_.
5. Select **Add**.
-6. Select **Users or Computers...** Type the name of the _NDES Server_ you use to issue Windows Hello for Business authentication certificates to Azure AD-joined devices. From the **Available services** list, select **HOST**. Select **OK**.
+6. Select **Users or Computers...** Type the name of the _NDES Server_ you use to issue Windows Hello for Business authentication certificates to Microsoft Entra joined devices. From the **Available services** list, select **HOST**. Select **OK**.
7. Repeat steps 5 and 6 for each NDES server using this service account. Select **Add**.
-8. Select **Users or computers...** Type the name of the issuing certificate authority this NDES service account uses to issue Windows Hello for Business authentication certificates to Azure AD-joined devices. From the **Available services** list, select **dcom**. Hold the **CTRL** key and select **HOST**. Select **OK**.
+8. Select **Users or computers...** Type the name of the issuing certificate authority this NDES service account uses to issue Windows Hello for Business authentication certificates to Microsoft Entra joined devices. From the **Available services** list, select **dcom**. Hold the **CTRL** key and select **HOST**. Select **OK**.
9. Repeat steps 8 and 9 for each issuing certificate authority from which one or more NDES servers request certificates.
@@ -534,7 +540,7 @@ Sign-in to the NDES Server with _local administrator_ equivalent credentials.
1. Open an elevated command prompt.
-2. Using the table above, decide which registry value name you'll use to request Windows Hello for Business authentication certificates for Azure AD-joined devices.
+2. Using the table above, decide which registry value name you'll use to request Windows Hello for Business authentication certificates for Microsoft Entra joined devices.
3. Type the following command:
@@ -542,7 +548,7 @@ Sign-in to the NDES Server with _local administrator_ equivalent credentials.
reg add HKLM\Software\Microsoft\Cryptography\MSCEP /v [registryValueName] /t REG_SZ /d [certificateTemplateName]
```
- where **registryValueName** is one of the three value names from the above table and where **certificateTemplateName** is the name of the certificate template you created for Windows Hello for Business Azure AD-joined devices. Example:
+ where **registryValueName** is one of the three value names from the above table and where **certificateTemplateName** is the name of the certificate template you created for Windows Hello for Business Microsoft Entra joined devices. Example:
```console
reg add HKLM\Software\Microsoft\Cryptography\MSCEP /v SignatureTemplate /t REG_SZ /d AADJWHFBAuthentication
@@ -557,13 +563,13 @@ Sign-in to the NDES Server with _local administrator_ equivalent credentials.
### Create a Web Application Proxy for the internal NDES URL.
-Certificate enrollment for Azure AD-joined devices occurs over the Internet. As a result, the internal NDES URLs must be accessible externally. You can do this easily and securely using Azure Active Directory Application Proxy. Azure AD Application Proxy provides single sign-on and secure remote access for web applications hosted on-premises, such as Network Device Enrollment Services.
+Certificate enrollment for Microsoft Entra joined devices occurs over the Internet. As a result, the internal NDES URLs must be accessible externally. You can do this easily and securely using Microsoft Entra application proxy. Microsoft Entra application proxy provides single sign-on and secure remote access for web applications hosted on-premises, such as Network Device Enrollment Services.
-Ideally, you configure your Microsoft Intune SCEP certificate profile to use multiple external NDES URLs. This enables Microsoft Intune to round-robin load balance the certificate requests to identically configured NDES Servers (each NDES server can accommodate approximately 300 concurrent requests). Microsoft Intune sends these requests to Azure AD Application Proxies.
+Ideally, you configure your Microsoft Intune SCEP certificate profile to use multiple external NDES URLs. This enables Microsoft Intune to round-robin load balance the certificate requests to identically configured NDES Servers (each NDES server can accommodate approximately 300 concurrent requests). Microsoft Intune sends these requests to Microsoft Entra Application Proxies.
-Azure AD Application proxies are serviced by lightweight Application Proxy Connector agents. See [What is Application Proxy](/azure/active-directory/manage-apps/application-proxy#what-is-application-proxy) for more details. These agents are installed on your on-premises, domain joined devices and make authenticated secure outbound connection to Azure, waiting to process requests from Azure AD Application Proxies. You can create connector groups in Azure Active Directory to assign specific connectors to service specific applications.
+Microsoft Entra Application proxies are serviced by lightweight Application Proxy Connector agents. See [What is Application Proxy](/azure/active-directory/manage-apps/application-proxy#what-is-application-proxy) for more details. These agents are installed on your on-premises, domain joined devices and make authenticated secure outbound connection to Azure, waiting to process requests from Microsoft Entra Application Proxies. You can create connector groups in Microsoft Entra ID to assign specific connectors to service specific applications.
-Connector group automatically round-robin, load balance the Azure AD Application proxy requests to the connectors within the assigned connector group. This ensures Windows Hello for Business certificate requests have multiple dedicated Azure AD Application Proxy connectors exclusively available to satisfy enrollment requests. Load balancing the NDES servers and connectors should ensure users enroll their Windows Hello for Business certificates in a timely manner.
+Connector group automatically round-robin, load balance the Microsoft Entra application proxy requests to the connectors within the assigned connector group. This ensures Windows Hello for Business certificate requests have multiple dedicated Microsoft Entra application proxy connectors exclusively available to satisfy enrollment requests. Load balancing the NDES servers and connectors should ensure users enroll their Windows Hello for Business certificates in a timely manner.
#### Download and Install the Application Proxy Connector Agent
@@ -571,7 +577,7 @@ Sign-in a workstation with access equivalent to a _domain user_.
1. Sign-in to the [Azure portal](https://portal.azure.com/) with access equivalent to **Global Administrator**.
-2. Select **All Services**. Type **Azure Active Directory** to filter the list of services. Under **SERVICES**, select **Azure Active Directory**.
+2. Select **All Services**. Type **Microsoft Entra ID** to filter the list of services. Under **SERVICES**, select **Microsoft Entra ID**.
3. Under **MANAGE**, select **Application proxy**.
@@ -582,7 +588,7 @@ Sign-in a workstation with access equivalent to a _domain user_.
5. Sign-in the computer that will run the connector with access equivalent to a _domain user_.
> [!IMPORTANT]
- > Install a minimum of two Azure Active Directory Proxy connectors for each NDES Application Proxy. Strategically locate Azure AD application proxy connectors throughout your organization to ensure maximum availability. Remember, devices running the connector must be able to communicate with Azure and the on-premises NDES servers.
+ > Install a minimum of two Microsoft Entra ID Proxy connectors for each NDES Application Proxy. Strategically locate Microsoft Entra application proxy connectors throughout your organization to ensure maximum availability. Remember, devices running the connector must be able to communicate with Azure and the on-premises NDES servers.
6. Start **AADApplicationProxyConnectorInstaller.exe**.
@@ -598,7 +604,7 @@ Sign-in a workstation with access equivalent to a _domain user_.
-10. Repeat steps 5 - 10 for each device that will run the Azure AD Application Proxy connector for Windows Hello for Business certificate deployments.
+10. Repeat steps 5 - 10 for each device that will run the Microsoft Entra application proxy connector for Windows Hello for Business certificate deployments.
#### Create a Connector Group
@@ -606,7 +612,7 @@ Sign-in a workstation with access equivalent to a _domain user_.
1. Sign-in to the [Azure portal](https://portal.azure.com/) with access equivalent to **Global Administrator**.
-2. Select **All Services**. Type **Azure Active Directory** to filter the list of services. Under **SERVICES**, select **Azure Active Directory**.
+2. Select **All Services**. Type **Microsoft Entra ID** to filter the list of services. Under **SERVICES**, select **Microsoft Entra ID**.
3. Under **MANAGE**, select **Application proxy**.
@@ -626,17 +632,17 @@ Sign-in a workstation with access equivalent to a _domain user_.
1. Sign-in to the [Azure portal](https://portal.azure.com/) with access equivalent to **Global Administrator**.
-2. Select **All Services**. Type **Azure Active Directory** to filter the list of services. Under **SERVICES**, select **Azure Active Directory**.
+2. Select **All Services**. Type **Microsoft Entra ID** to filter the list of services. Under **SERVICES**, select **Microsoft Entra ID**.
3. Under **MANAGE**, select **Application proxy**.
4. Select **Configure an app**.
-5. Under **Basic Settings** next to **Name**, type **WHFB NDES 01**. Choose a name that correlates this Azure AD Application Proxy setting with the on-premises NDES server. Each NDES server must have its own Azure AD Application Proxy as two NDES servers can't share the same internal URL.
+5. Under **Basic Settings** next to **Name**, type **WHFB NDES 01**. Choose a name that correlates this Microsoft Entra application proxy setting with the on-premises NDES server. Each NDES server must have its own Microsoft Entra application proxy as two NDES servers can't share the same internal URL.
-6. Next to **Internal URL**, type the internal, fully qualified DNS name of the NDES server associated with this Azure AD Application Proxy. For example, ```https://ndes.corp.mstepdemo.net```. You need to match the primary host name (AD Computer Account name) of the NDES server, and prefix the URL with **https**.
+6. Next to **Internal URL**, type the internal, fully qualified DNS name of the NDES server associated with this Microsoft Entra application proxy. For example, ```https://ndes.corp.mstepdemo.net```. You need to match the primary host name (AD Computer Account name) of the NDES server, and prefix the URL with **https**.
-7. Under **Internal URL**, select **https://** from the first list. In the text box next to **https://**, type the hostname you want to use as your external hostname for the Azure AD Application Proxy. In the list next to the hostname you typed, select a DNS suffix you want to use externally for the Azure AD Application Proxy. It's recommended to use the default, -[tenantName].msapproxy.net where **[tenantName]** is your current Azure Active Directory tenant name (-mstephendemo.msappproxy.net).
+7. Under **Internal URL**, select **https://** from the first list. In the text box next to **https://**, type the hostname you want to use as your external hostname for the Microsoft Entra application proxy. In the list next to the hostname you typed, select a DNS suffix you want to use externally for the Microsoft Entra application proxy. It's recommended to use the default, -[tenantName].msapproxy.net where **[tenantName]** is your current Microsoft Entra tenant name (-mstephendemo.msappproxy.net).
@@ -681,7 +687,7 @@ Sign-in the NDES server with access equivalent to _local administrators_.
10. Select **Enroll**
-11. Repeat these steps for all NDES Servers used to request Windows Hello for Business authentication certificates for Azure AD-joined devices.
+11. Repeat these steps for all NDES Servers used to request Windows Hello for Business authentication certificates for Microsoft Entra joined devices.
### Configure the Web Server Role
@@ -824,7 +830,7 @@ Sign-in a workstation with access equivalent to a _domain user_.
1. Sign-in to the [Azure portal](https://portal.azure.com/) with access equivalent to **Global Administrator**.
-2. Select **All Services**. Type **Azure Active Directory** to filter the list of services. Under **SERVICES**, select **Azure Active Directory**.
+2. Select **All Services**. Type **Microsoft Entra ID** to filter the list of services. Under **SERVICES**, select **Microsoft Entra ID**.
3. Select **Groups**. Select **New group**.
@@ -836,7 +842,7 @@ Sign-in a workstation with access equivalent to a _domain user_.
7. Select **Assigned** from the **Membership type** list.
- 
+ 
8. Select **Members**. Use the **Select members** pane to add members to this group. When finished, select **Select**.
@@ -889,7 +895,7 @@ Sign-in a workstation with access equivalent to a _domain user_.
-17. Under **SCEP Server URLs**, type the fully qualified external name of the Azure AD Application proxy you configured. Append to the name **/certsrv/mscep/mscep.dll**. For example, ```https://ndes-mtephendemo.msappproxy.net/certsrv/mscep/mscep.dll```. Select **Add**. Repeat this step for each additional NDES Azure AD Application Proxy you configured to issue Windows Hello for Business certificates. Microsoft Intune round-robin load balances requests among the URLs listed in the SCEP certificate profile.
+17. Under **SCEP Server URLs**, type the fully qualified external name of the Microsoft Entra application proxy you configured. Append to the name **/certsrv/mscep/mscep.dll**. For example, ```https://ndes-mtephendemo.msappproxy.net/certsrv/mscep/mscep.dll```. Select **Add**. Repeat this step for each additional NDES Microsoft Entra application proxy you configured to issue Windows Hello for Business certificates. Microsoft Intune round-robin load balances requests among the URLs listed in the SCEP certificate profile.
18. Select **Next**.
@@ -924,7 +930,7 @@ You have successfully completed the configuration. Add users that need to enrol
> [!div class="checklist"]
> - Requirements
-> - Prepare Azure AD Connect
+> - Prepare Microsoft Entra Connect
> - Prepare the Network Device Enrollment Services (NDES) Service Account
> - Prepare Active Directory Certificate Authority
> - Install and Configure the NDES Role
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso.md
index b512d1a236..e4c13dae5d 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso.md
@@ -1,21 +1,21 @@
---
-title: Configure single sign-on (SSO) for Azure AD joined devices
-description: Learn how to configure single sign-on to on-premises resources for Azure AD-joined devices, using Windows Hello for Business.
+title: Configure single sign-on (SSO) for Microsoft Entra joined devices
+description: Learn how to configure single sign-on to on-premises resources for Microsoft Entra joined devices, using Windows Hello for Business.
ms.date: 12/30/2022
ms.topic: how-to
---
-# Configure single sign-on for Azure AD joined devices
+# Configure single sign-on for Microsoft Entra joined devices
[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-keycert-trust-aad.md)]
-Windows Hello for Business combined with Azure AD-joined devices makes it easy for users to securely access cloud-based resources using a strong, two-factor credential. Some resources may remain on-premises as enterprises transition resources to the cloud and Azure AD-joined devices may need to access these resources. With additional configurations to the hybrid deployment, you can provide single sign-on to on-premises resources for Azure AD-joined devices using Windows Hello for Business, using a key or a certificate.
+Windows Hello for Business combined with Microsoft Entra joined devices makes it easy for users to securely access cloud-based resources using a strong, two-factor credential. Some resources may remain on-premises as enterprises transition resources to the cloud and Microsoft Entra joined devices may need to access these resources. With additional configurations to the hybrid deployment, you can provide single sign-on to on-premises resources for Microsoft Entra joined devices using Windows Hello for Business, using a key or a certificate.
> [!NOTE]
> These steps are not needed when using the cloud Kerberos trust model.
## Prerequisites
-Unlike hybrid Azure AD-joined devices, Azure AD-joined devices don't have a relationship with your Active Directory domain. This factor changes the way in which users authenticate to Active Directory. Validate the following configurations to ensure they support Azure AD-joined devices:
+Unlike Microsoft Entra hybrid joined devices, Microsoft Entra joined devices don't have a relationship with your Active Directory domain. This factor changes the way in which users authenticate to Active Directory. Validate the following configurations to ensure they support Microsoft Entra joined devices:
> [!div class="checklist"]
> - Certificate Revocation List (CRL) Distribution Point
@@ -29,9 +29,9 @@ During certificate validation, Windows compares the current certificate with inf
-The preceding domain controller certificate shows a *CRL distribution point* (CDP) in Active Directory. The value in the URL begins with *ldap*. Using Active Directory for domain joined devices provides a highly available CRL distribution point. However, Azure AD joined devices can't read data from Active Directory, and certificate validation doesn't provide an opportunity to authenticate prior to reading the CRL. The authentication becomes a circular problem: the user is attempting to authenticate, but must read Active Directory to complete the authentication, but the user can't read Active Directory because they haven't authenticated.
+The preceding domain controller certificate shows a *CRL distribution point* (CDP) in Active Directory. The value in the URL begins with *ldap*. Using Active Directory for domain joined devices provides a highly available CRL distribution point. However, Microsoft Entra joined devices can't read data from Active Directory, and certificate validation doesn't provide an opportunity to authenticate prior to reading the CRL. The authentication becomes a circular problem: the user is attempting to authenticate, but must read Active Directory to complete the authentication, but the user can't read Active Directory because they haven't authenticated.
-To resolve this issue, the CRL distribution point must be a location accessible by Azure AD joined devices that doesn't require authentication. The easiest solution is to publish the CRL distribution point on a web server that uses HTTP (not HTTPS).
+To resolve this issue, the CRL distribution point must be a location accessible by Microsoft Entra joined devices that doesn't require authentication. The easiest solution is to publish the CRL distribution point on a web server that uses HTTP (not HTTPS).
If your CRL distribution point doesn't list an HTTP distribution point, then you need to reconfigure the issuing certificate authority to include an HTTP CRL distribution point, preferably first, in the list of distribution points.
@@ -40,11 +40,11 @@ If your CRL distribution point doesn't list an HTTP distribution point, then you
### Domain controller certificates
-Certificate authorities write CDP information in certificates as they're issued. If the distribution point changes, then previously issued certificates must be reissued for the certificate authority to include the new CDP. The domain controller certificate is one the critical components of Azure AD-joined devices authenticating to Active Directory.
+Certificate authorities write CDP information in certificates as they're issued. If the distribution point changes, then previously issued certificates must be reissued for the certificate authority to include the new CDP. The domain controller certificate is one the critical components of Microsoft Entra joined devices authenticating to Active Directory.
#### Why does Windows need to validate the domain controller certificate?
-Windows Hello for Business enforces the strict KDC validation security feature when authenticating from an Azure AD joined device to a domain. This enforcement imposes more restrictive criteria that must be met by the Key Distribution Center (KDC). When authenticating using Windows Hello for Business on an Azure AD joined device, the Windows client validates the reply from the domain controller by ensuring all of the following are met:
+Windows Hello for Business enforces the strict KDC validation security feature when authenticating from a Microsoft Entra joined device to a domain. This enforcement imposes more restrictive criteria that must be met by the Key Distribution Center (KDC). When authenticating using Windows Hello for Business on a Microsoft Entra joined device, the Windows client validates the reply from the domain controller by ensuring all of the following are met:
- The domain controller has the private key for the certificate provided
- The root CA that issued the domain controller's certificate is in the device's *Trusted Root Certificate Authorities*
@@ -54,7 +54,7 @@ Windows Hello for Business enforces the strict KDC validation security feature w
- The domain controller's certificate's signature hash algorithm is **sha256**
- The domain controller's certificate's public key is **RSA (2048 Bits)**
-Authenticating from a Hybrid Azure AD joined device to a domain using Windows Hello for Business doesn't enforce that the domain controller certificate includes the *KDC Authentication* EKU. If you're adding Azure AD-joined devices to an existing domain environment, make sure to verify that your domain controller certificate has been updated to include the *KDC Authentication* EKU.
+Authenticating from a Microsoft Entra hybrid joined device to a domain using Windows Hello for Business doesn't enforce that the domain controller certificate includes the *KDC Authentication* EKU. If you're adding Microsoft Entra joined devices to an existing domain environment, make sure to verify that your domain controller certificate has been updated to include the *KDC Authentication* EKU.
## Configure a CRL distribution point for an issuing CA
@@ -62,7 +62,7 @@ Use this set of procedures to update the CA that issues domain controller certif
### Configure Internet Information Services to host CRL distribution point
-You need to host your new certificate revocation list on a web server so Azure AD-joined devices can easily validate certificates without authentication. You can host these files on web servers many ways. The following steps are just one and may be useful for admins unfamiliar with adding a new CRL distribution point.
+You need to host your new certificate revocation list on a web server so Microsoft Entra joined devices can easily validate certificates without authentication. You can host these files on web servers many ways. The following steps are just one and may be useful for admins unfamiliar with adding a new CRL distribution point.
> [!IMPORTANT]
> Do not configure the IIS server hosting your CRL distribution point to use https or a server authentication certificate. Clients should access the distribution point using http.
@@ -217,9 +217,11 @@ With the CA properly configured with a valid HTTP-based CRL distribution point,
1. Review the information below the list of fields to confirm the new URL for the CRL distribution point is present in the certificate. Select **OK**
-## Deploy the root CA certificate to Azure AD-joined devices
+
-The domain controllers have a certificate that includes the new CRL distribution point. Next, you need the enterprise root certificate so you can deploy it to Azure AD-joined devices. When you deploy the enterprise root certificates to a device, it ensures the device trusts any certificates issued by the certificate authority. Without the certificate, Azure AD-joined devices don't trust domain controller certificates and authentication fails.
+## Deploy the root CA certificate to Microsoft Entra joined devices
+
+The domain controllers have a certificate that includes the new CRL distribution point. Next, you need the enterprise root certificate so you can deploy it to Microsoft Entra joined devices. When you deploy the enterprise root certificates to a device, it ensures the device trusts any certificates issued by the certificate authority. Without the certificate, Microsoft Entra joined devices don't trust domain controller certificates and authentication fails.
### Export the enterprise root certificate
@@ -250,4 +252,4 @@ To configure devices with Microsoft Intune, use a custom policy:
1. Under **Assignment**, select a security group that contains as members the devices or users that you want to configure > **Next**
1. Review the policy configuration and select **Create**
-If you plan on using certificates for on-premises single-sign on, perform the additional steps in [Using Certificates for On-premises Single-sign On](hello-hybrid-aadj-sso-cert.md). Otherwise, you can sign in to an Azure AD joined device with Windows Hello for Business and test SSO to an on-premises resource.
+If you plan on using certificates for on-premises single-sign on, perform the additional steps in [Using Certificates for On-premises Single-sign On](hello-hybrid-aadj-sso-cert.md). Otherwise, you can sign in to a Microsoft Entra joined device with Windows Hello for Business and test SSO to an on-premises resource.
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-validate-pki.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-validate-pki.md
index 662e259872..e3340a65c2 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-validate-pki.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-validate-pki.md
@@ -25,12 +25,12 @@ Hybrid certificate trust deployments issue users a sign-in certificate, enabling
[!INCLUDE [dc-certificate-template](includes/dc-certificate-template.md)]
> [!NOTE]
-> Inclusion of the *KDC Authentication* OID in domain controller certificate is not required for hybrid Azure AD-joined devices. The OID is required for enabling authentication with Windows Hello for Business to on-premises resources by Azure AD-joined devices.
+> Inclusion of the *KDC Authentication* OID in domain controller certificate is not required for Microsoft Entra hybrid joined devices. The OID is required for enabling authentication with Windows Hello for Business to on-premises resources by Microsoft Entra joined devices.
> [!IMPORTANT]
-> For Azure AD joined devices to authenticate to on-premises resources, ensure to:
+> 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 Azure AD-joined devices, such as a web-based URL
+> - Publish your certificate revocation list to a location that is available to Microsoft Entra joined devices, such as a web-based URL
[!INCLUDE [dc-certificate-template-supersede](includes/dc-certificate-supersede.md)]
@@ -54,7 +54,7 @@ Sign in to the CA or management workstations with **Enterprise Admin** equivalen
1. Close the console
> [!IMPORTANT]
-> If you plan to deploy **Azure AD joined** devices, and require single sign-on (SSO) to on-premises resources when signing in with Windows Hello for Business, follow the procedures to [update your CA to include an http-based CRL distribution point](hello-hybrid-aadj-sso.md).
+> 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
@@ -82,4 +82,4 @@ Before moving to the next section, ensure the following steps are complete:
> [Next: configure AD FS >](hello-hybrid-cert-whfb-settings-adfs.md)
-[SERV-1]: /troubleshoot/windows-server/windows-security/requirements-domain-controller
\ No newline at end of file
+[SERV-1]: /troubleshoot/windows-server/windows-security/requirements-domain-controller
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust.md
index eabb6ec24d..754b52a3a5 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust.md
@@ -15,7 +15,7 @@ ms.topic: how-to
[!INCLUDE [hello-hybrid-cert-trust](./includes/hello-hybrid-cert-trust.md)]
-Hybrid environments are distributed systems that enable organizations to use on-premises and Azure AD-protected resources. Windows Hello for Business uses the existing distributed system as a foundation on which organizations can provide two-factor authentication and single sign-on to modern resources.
+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.
@@ -29,10 +29,10 @@ The following prerequisites must be met for a hybrid certificate trust deploymen
> [!div class="checklist"]
> * Directories and directory synchronization
-> * Federated authentication to Azure AD
+> * Federated authentication to Microsoft Entra ID
> * Device registration
> * Public Key Infrastructure
-> * Multi-factor authentication
+> * Multifactor authentication
> * Device management
### Directories and directory synchronization
@@ -40,21 +40,23 @@ The following prerequisites must be met for a hybrid certificate trust deploymen
Hybrid Windows Hello for Business needs two directories:
- An on-premises Active Directory
-- An Azure Active Directory tenant with an Azure AD Premium subscription
+- A Microsoft Entra tenant with a Microsoft Entra ID P1 or P2 subscription
-The two directories must be synchronized with [Azure AD Connect Sync][AZ-1], which synchronizes user accounts from the on-premises Active Directory to Azure AD.
-The hybrid-certificate trust deployment needs an *Azure Active Directory Premium* subscription because it uses the device write-back synchronization feature.
+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.
> [!NOTE]
-> Windows Hello for Business hybrid certificate trust is not supported if the users' on-premises UPN suffix cannot be added as a verified domain in Azure AD.
+> 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.
> [!IMPORTANT]
-> Windows Hello for Business is tied between a user and a device. Both the user and device object must be synchronized between Azure Active Directory and Active Directory.
+> 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.
-### Federated authentication to Azure AD
+
-Windows Hello for Business hybrid certificate trust doesn't support Azure AD *Pass-through Authentication* (PTA) or *password hash sync* (PHS).\
-Windows Hello for Business hybrid certificate trust requires Active Directory to be federated with Azure Active Directory using AD FS. Additionally, you need to configure your AD FS farm to support Azure registered devices.
+### 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).\
+Windows Hello for Business hybrid certificate trust requires Active Directory to be federated with Microsoft Entra ID using AD FS. Additionally, you need to configure your AD FS farm to support Azure registered devices.
If you're new to AD FS and federation services:
@@ -69,18 +71,18 @@ The AD FS farm used with Windows Hello for Business must be Windows Server 2016
### Device registration and device write-back
-Windows devices must be registered in Azure AD. Devices can be registered in Azure AD using either *Azure AD join* or *hybrid Azure AD join*.\
-For hybrid Azure AD joined devices, review the guidance on the [plan your hybrid Azure Active Directory join implementation][AZ-8] page.
+Windows devices must be registered in Microsoft Entra ID. Devices can be registered in Microsoft Entra ID using either *Microsoft Entra join* or *Microsoft Entra hybrid join*.\
+For Microsoft Entra hybrid joined devices, review the guidance on the [plan your Microsoft Entra hybrid join implementation][AZ-8] page.
-Refer to the [Configure hybrid Azure Active Directory join for federated domains][AZ-10] guide to learn more about using Azure AD Connect Sync to configure Azure AD device registration.\
-For a **manual configuration** of your AD FS farm to support device registration, review the [Configure AD FS for Azure AD device registration][AZ-11] guide.
+Refer to the [Configure Microsoft Entra hybrid join for federated domains][AZ-10] guide to learn more about using Microsoft Entra Connect Sync to configure Microsoft Entra device registration.\
+For a **manual configuration** of your AD FS farm to support device registration, review the [Configure AD FS for Microsoft Entra device registration][AZ-11] guide.
Hybrid certificate trust deployments require the *device write-back* feature. Authentication to AD FS needs both the user and the device to authenticate. Typically the users are synchronized, but not devices. This prevents AD FS from authenticating the device and results in Windows Hello for Business certificate enrollment failures. For this reason, Windows Hello for Business deployments need device write-back.
> [!NOTE]
-> Windows Hello for Business is tied between a user and a device. Both the user and device need to be synchronized between Azure Active Directory and Active Directory. Device write-back is used to update the *msDS-KeyCredentialLink* attribute on the computer object.
+> Windows Hello for Business is tied between a user and a device. Both the user and device need to be synchronized between Microsoft Entra ID and Active Directory. Device write-back is used to update the *msDS-KeyCredentialLink* attribute on the computer object.
-If you manually configured AD FS, or if you ran Azure AD Connect Sync using *Custom Settings*, you must ensure that you have configured **device write-back** and **device authentication** in your AD FS farm. For more information, see [Configure Device Write Back and Device Authentication][SER-5].
+If you manually configured AD FS, or if you ran Microsoft Entra Connect Sync using *Custom Settings*, you must ensure that you have configured **device write-back** and **device authentication** in your AD FS farm. For more information, see [Configure Device Write Back and Device Authentication][SER-5].
### Public Key Infrastructure
@@ -89,16 +91,18 @@ 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.
-### Multi-factor authentication
+
+
+### 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.\
Hybrid deployments can use:
-- [Azure AD Multi-Factor Authentication][AZ-2]
-- A multi-factor authentication provided by AD FS, which includes an adapter model that enables third parties to integrate their MFA into AD FS
+- [Microsoft Entra multifactor authentication][AZ-2]
+- A multifactor authentication provided by AD FS, which includes an adapter model that enables third parties to integrate their MFA into AD FS
-For more information how to configure Azure AD Multi-Factor Authentication, see [Configure Azure AD Multi-Factor Authentication settings][AZ-3].\
-For more information how to configure AD FS to provide multi-factor authentication, see [Configure Azure MFA as authentication provider with AD FS][SER-1].
+For more information how to configure Microsoft Entra multifactor authentication, see [Configure Microsoft Entra multifactor authentication settings][AZ-3].\
+For more information how to configure AD FS to provide multifactor authentication, see [Configure Azure MFA as authentication provider with AD FS][SER-1].
### Device management
@@ -113,7 +117,7 @@ Once the prerequisites are met, deploying Windows Hello for Business with a hybr
> * Configure AD FS
> * Configure Windows Hello for Business settings
> * Provision Windows Hello for Business on Windows clients
-> * Configure single sign-on (SSO) for Azure AD joined devices
+> * 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)
@@ -135,4 +139,4 @@ Once the prerequisites are met, deploying Windows Hello for Business with a hybr
[SER-2]: /windows-server/identity/ad-fs/deployment/deploying-a-federation-server-farm
[SER-3]: /windows-server/identity/ad-fs/technical-reference/understanding-key-ad-fs-concepts
[SER-4]: /windows-server/identity/ad-fs/design/ad-fs-design-guide-in-windows-server-2012-r2
-[SER-5]: /windows-server/identity/ad-fs/operations/configure-device-based-conditional-access-on-premises#configure-device-write-back-and-device-authentication
\ No newline at end of file
+[SER-5]: /windows-server/identity/ad-fs/operations/configure-device-based-conditional-access-on-premises#configure-device-write-back-and-device-authentication
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-provision.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-provision.md
index 934a3f70de..0d5ed158f7 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-provision.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-provision.md
@@ -16,9 +16,9 @@ After the prerequisites are met and the PKI and AD FS configurations are validat
#### [:::image type="icon" source="../../images/icons/group-policy.svg"::: **GPO**](#tab/gpo)
> [!IMPORTANT]
-> The information in this section applies to hybrid Azure AD joined devices only.
+> The information in this section applies to Microsoft Entra hybrid joined devices only.
-For hybrid Azure AD joined devices, you can use group policies to configure Windows Hello for Business.
+For Microsoft Entra hybrid joined devices, you can use group policies to configure Windows Hello for Business.
It is suggested to create a security group (for example, *Windows Hello for Business Users*) to make it easy to deploy Windows Hello for Business in phases. You assign the **Group Policy** and **Certificate template permissions** to this group to simplify the deployment by adding the users to the group. This provides users with the proper permissions to provision Windows Hello for Business and to enroll in the Windows Hello for Business authentication certificate.
### Enable Windows Hello for Business group policy setting
@@ -95,11 +95,11 @@ Users (or devices) must receive the Windows Hello for Business group policy sett
## Configure Windows Hello for Business using Microsoft Intune
> [!IMPORTANT]
-> The information in this section applies to Azure AD joined devices managed by Intune. Before proceeding, ensure that you completed the steps described in:
-> - [Configure single sign-on for Azure AD joined devices](hello-hybrid-aadj-sso.md)
+> 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)
-For Azure AD joined devices enrolled in Intune, you can use Intune policies to manage Windows Hello for Business.
+For Microsoft Entra joined devices enrolled in Intune, you can use Intune policies to manage Windows Hello for Business.
There are different ways to enable and configure Windows Hello for Business in Intune:
@@ -163,19 +163,19 @@ This is the process that occurs after a user signs in, to enroll in Windows Hell
1. The user is prompted with a full screen page to use Windows Hello with the organization account. The user selects **OK**
1. The provisioning flow proceeds to the multi-factor authentication portion of the enrollment. Provisioning informs the user that it's actively attempting to contact the user through their configured form of MFA. The provisioning process doesn't proceed until authentication succeeds, fails or times out. A failed or timeout MFA results in an error and asks the user to retry
1. After a successful MFA, the provisioning flow asks the user to create and validate a PIN. This PIN must observe any PIN complexity policies configured on the device
-1. The remainder of the provisioning includes Windows Hello for Business requesting an asymmetric key pair for the user, preferably from the TPM (or required if explicitly set through policy). Once the key pair is acquired, Windows communicates with Azure Active Directory to register the public key. When key registration completes, Windows Hello for Business provisioning informs the user they can use their PIN to sign-in. The user may close the provisioning application and see their desktop. While the user has completed provisioning, Azure AD Connect synchronizes the user's key to Active Directory
+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.":::
> [!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 Azure Active Directory to the on-premises Active Directory is 30 minutes. The Azure AD Connect scheduler controls the synchronization interval.
+> The minimum time needed to synchronize the user's public key from 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 [Azure AD Connect sync: Scheduler](/azure/active-directory/connect/active-directory-aadconnectsync-feature-scheduler) to view and adjust the **synchronization cycle** for your organization.
+> 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.
>
> [!NOTE]
-> Windows Server 2016 update [KB4088889 (14393.2155)](https://support.microsoft.com/help/4088889) provides synchronous certificate enrollment during hybrid certificate trust provisioning. With this update, users no longer need to wait for Azure AD Connect to sync their public key on-premises. Users enroll their certificate during provisioning and can use the certificate for sign-in immediately after completing the provisioning. The update needs to be installed on the federation servers.
+> Windows Server 2016 update [KB4088889 (14393.2155)](https://support.microsoft.com/help/4088889) provides synchronous certificate enrollment during hybrid certificate trust provisioning. With this update, users no longer need to wait for Microsoft Entra Connect to sync their public key on-premises. Users enroll their certificate during provisioning and can use the certificate for sign-in immediately after completing the provisioning. The update needs to be installed on the federation servers.
After a successful key registration, Windows creates a certificate request using the same key pair to request a certificate. Windows send the certificate request to the AD FS server for certificate enrollment.
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust-provision.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust-provision.md
index 4765ae8d4e..7b4394d51f 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust-provision.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust-provision.md
@@ -14,18 +14,20 @@ ms.topic: tutorial
Deploying Windows Hello for Business cloud Kerberos trust consists of two steps:
-1. Set up Azure AD Kerberos.
+1. Set up Microsoft Entra Kerberos.
1. Configure a Windows Hello for Business policy and deploy it to the devices.
-### Deploy Azure AD Kerberos
+
-If you've already deployed on-premises SSO for passwordless security key sign-in, then you've already deployed Azure AD Kerberos in your hybrid environment. You don't need to redeploy or change your existing Azure AD Kerberos deployment to support Windows Hello for Business and you can skip this section.
+### Deploy Microsoft Entra Kerberos
-If you haven't deployed Azure AD Kerberos, follow the instructions in the [Enable passwordless security key sign-in to on-premises resources by using Azure AD][AZ-2] documentation. This page includes information on how to install and use the Azure AD Kerberos PowerShell module. Use the module to create an Azure AD Kerberos Server object for the domains where you want to use Windows Hello for Business cloud Kerberos trust.
+If you've already deployed on-premises SSO for passwordless security key sign-in, then you've already deployed Microsoft Entra Kerberos in your hybrid environment. You don't need to redeploy or change your existing Microsoft Entra Kerberos deployment to support Windows Hello for Business and you can skip this section.
+
+If you haven't deployed Microsoft Entra Kerberos, follow the instructions in the [Enable passwordless security key sign-in to on-premises resources by using Microsoft Entra ID][AZ-2] documentation. This page includes information on how to install and use the Microsoft Entra Kerberos PowerShell module. Use the module to create a Microsoft Entra Kerberos server object for the domains where you want to use Windows Hello for Business cloud Kerberos trust.
### Configure Windows Hello for Business policy
-After setting up the Azure AD Kerberos object, Windows Hello for business cloud Kerberos trust must be enabled on your Windows devices. Follow the instructions below to configure your devices using either Microsoft Intune or group policy (GPO).
+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)
@@ -99,7 +101,7 @@ To configure the cloud Kerberos trust policy:
- Value: **True**
> [!IMPORTANT]
- > *Tenant ID* in the OMA-URI must be replaced with the tenant ID for your Azure AD tenant. See [How to find your Azure AD tenant ID][AZ-3] for instructions on looking up your tenant ID.
+ > *Tenant ID* in the OMA-URI must be replaced with the tenant ID for your Microsoft Entra tenant. See [How to find your Microsoft Entra tenant ID][AZ-3] for instructions on looking up your tenant ID.
:::image type="content" alt-text ="Intune custom-device configuration policy creation" source="images/hello-cloud-trust-intune.png" lightbox="images/hello-cloud-trust-intune-large.png":::
@@ -107,7 +109,7 @@ To configure the cloud Kerberos trust policy:
#### [:::image type="icon" source="../../images/icons/group-policy.svg"::: **GPO**](#tab/gpo)
-Hybrid Azure AD 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.
+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.
The Enable Windows Hello for Business Group Policy setting is used by Windows to determine if a user should attempt to enroll a credential. A user will only attempt enrollment if this policy is configured to enabled.
@@ -142,17 +144,17 @@ You can configure Windows Hello for Business cloud Kerberos trust using a Group
## Provision Windows Hello for Business
-The Windows Hello for Business provisioning process begins immediately after a user has signed in if certain prerequisite checks are passed. Windows Hello for Business *cloud Kerberos trust* adds a prerequisite check for Hybrid Azure AD-joined devices when cloud Kerberos trust is enabled by policy.
+The Windows Hello for Business provisioning process begins immediately after a user has signed in if certain prerequisite checks are passed. Windows Hello for Business *cloud Kerberos trust* adds a prerequisite check for Microsoft Entra hybrid joined devices when cloud Kerberos trust is enabled by policy.
You can determine the status of the prerequisite check by viewing the **User Device Registration** admin log under **Applications and Services Logs** > **Microsoft** > **Windows**.\
This information is also available using the `dsregcmd /status` command from a console. For more information, see [dsregcmd][AZ-4].
:::image type="content" alt-text="Cloud Kerberos trust prerequisite check in the user device registration log" source="images/cloud-trust-prereq-check.png" lightbox="images/cloud-trust-prereq-check.png":::
-The cloud Kerberos trust prerequisite check detects whether the user has a partial TGT before allowing provisioning to start. The purpose of this check is to validate whether Azure AD Kerberos is set up for the user's domain and tenant. If Azure AD Kerberos is set up, the user will receive a partial TGT during sign-in with one of their other unlock methods. This check has three states: Yes, No, and Not Tested. The *Not Tested* state is reported if cloud Kerberos trust isn't being enforced by policy or if the device is Azure AD joined.
+The cloud Kerberos trust prerequisite check detects whether the user has a partial TGT before allowing provisioning to start. The purpose of this check is to validate whether Microsoft Entra Kerberos is set up for the user's domain and tenant. If Microsoft Entra Kerberos is set up, the user will receive a partial TGT during sign-in with one of their other unlock methods. This check has three states: Yes, No, and Not Tested. The *Not Tested* state is reported if cloud Kerberos trust isn't being enforced by policy or if the device is Microsoft Entra joined.
> [!NOTE]
-> The cloud Kerberos trust prerequisite check isn't done on Azure AD-joined devices. If Azure AD Kerberos isn't provisioned, a user on an Azure AD joined device will still be able to sign in, but won't have SSO to on-premises resources secured by Active Directory.
+> The cloud Kerberos trust prerequisite check isn't done on Microsoft Entra joined devices. If Microsoft Entra Kerberos isn't provisioned, a user on a Microsoft Entra joined device will still be able to sign in, but won't have SSO to on-premises resources secured by Active Directory.
### PIN Setup
@@ -166,18 +168,18 @@ After a user signs in, this is the process that occurs to enroll in Windows Hell
### Sign-in
-Once a user has set up a PIN with cloud Kerberos trust, it can be used **immediately** for sign-in. On a Hybrid Azure AD joined device, the first use of the PIN requires line of sight to a DC. Once the user has signed in or unlocked with the DC, cached sign-in can be used for subsequent unlocks without line of sight or network connectivity.
+Once a user has set up a PIN with cloud Kerberos trust, it can be used **immediately** for sign-in. On a Microsoft Entra hybrid joined device, the first use of the PIN requires line of sight to a DC. Once the user has signed in or unlocked with the DC, cached sign-in can be used for subsequent unlocks without line of sight or network connectivity.
## Migrate from key trust deployment model to cloud Kerberos trust
If you deployed Windows Hello for Business using the key trust model, and want to migrate to the cloud Kerberos trust model, follow these steps:
-1. [Set up Azure AD Kerberos in your hybrid environment](#deploy-azure-ad-kerberos).
+1. [Set up Microsoft Entra Kerberos in your hybrid environment](#deploy-azure-ad-kerberos).
1. [Enable cloud Kerberos trust via Group Policy or Intune](#configure-windows-hello-for-business-policy).
-1. For Azure AD joined devices, sign out and sign in to the device using Windows Hello for Business.
+1. For Microsoft Entra joined devices, sign out and sign in to the device using Windows Hello for Business.
> [!NOTE]
-> For hybrid Azure AD joined devices, users must perform the first sign in with new credentials while having line of sight to a DC.
+> For Microsoft Entra hybrid joined devices, users must perform the first sign in with new credentials while having line of sight to a DC.
## Migrate from certificate trust deployment model to cloud Kerberos trust
@@ -193,7 +195,7 @@ If you deployed Windows Hello for Business using the certificate trust model, an
1. Provision Windows Hello for Business using a method of your choice.
> [!NOTE]
-> For hybrid Azure AD joined devices, users must perform the first sign-in with new credentials while having line of sight to a DC.
+> For Microsoft Entra hybrid joined devices, users must perform the first sign-in with new credentials while having line of sight to a DC.
## Frequently Asked Questions
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md
index 23b6c288e5..464e918a1e 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md
@@ -16,34 +16,36 @@ Windows Hello for Business replaces password sign-in with strong authentication,
The goal of Windows Hello for Business cloud Kerberos trust is to bring the simplified deployment experience of [*passwordless security key sign-in*][AZ-1] to Windows Hello for Business, and it can be used for new or existing Windows Hello for Business deployments.
-Windows Hello for Business cloud Kerberos trust uses *Azure AD Kerberos*, which enables a simpler deployment when compared to the *key trust model*:
+Windows Hello for Business cloud Kerberos trust uses *Microsoft Entra Kerberos*, which enables a simpler deployment when compared to the *key trust model*:
- No need to deploy a public key infrastructure (PKI) or to change an existing PKI
-- No need to synchronize public keys between Azure AD and Active Directory for users to access on-premises resources. There isn't any delay between the user's Windows Hello for Business provisioning, and being able to authenticate to Active Directory
+- No need to synchronize public keys between Microsoft Entra ID and Active Directory for users to access on-premises resources. There isn't any delay between the user's Windows Hello for Business provisioning, and being able to authenticate to Active Directory
- [Passwordless security key sign-in][AZ-1] can be deployed with minimal extra setup
> [!NOTE]
> Windows Hello for Business cloud Kerberos trust is the recommended deployment model when compared to the *key trust model*. It is also the preferred deployment model if you do not need to support certificate authentication scenarios.
-## Azure AD Kerberos and cloud Kerberos trust authentication
+
+
+## Microsoft Entra Kerberos and cloud Kerberos trust authentication
*Key trust* and *certificate trust* use certificate authentication-based Kerberos for requesting kerberos ticket-granting-tickets (TGTs) for on-premises authentication. This type of authentication requires a PKI for DC certificates, and requires end-user certificates for certificate trust.
-Cloud Kerberos trust uses Azure AD Kerberos, which doesn't require a PKI to request TGTs.\
-With Azure AD Kerberos, Azure AD can issue TGTs for one or more AD domains. Windows can request a TGT from Azure AD when authenticating with Windows Hello for Business, and use the returned TGT for sign-in or to access AD-based resources. The on-premises domain controllers are still responsible for Kerberos service tickets and authorization.
+Cloud Kerberos trust uses Microsoft Entra Kerberos, which doesn't require a PKI to request TGTs.\
+With Microsoft Entra Kerberos, Microsoft Entra ID can issue TGTs for one or more AD domains. Windows can request a TGT from Microsoft Entra ID when authenticating with Windows Hello for Business, and use the returned TGT for sign-in or to access AD-based resources. The on-premises domain controllers are still responsible for Kerberos service tickets and authorization.
-When Azure AD Kerberos is enabled in an Active Directory domain, an *AzureADKerberos* computer object is created in the domain. This object:
+When Microsoft Entra Kerberos is enabled in an Active Directory domain, an *AzureADKerberos* computer object is created in the domain. This object:
- Appears as a Read Only Domain Controller (RODC) object, but isn't associated with any physical servers
-- Is only used by Azure AD to generate TGTs for the Active Directory domain
+- Is only used by Microsoft Entra ID to generate TGTs for the Active Directory domain
> [!NOTE]
> Similar rules and restrictions used for RODCs apply to the AzureADKerberos computer object. For example, users that are direct or indirect members of priviliged built-in security groups won't be able to use cloud Kerberos trust.
-:::image type="content" source="images/azuread-kerberos-object.png" alt-text="Active Directory Users and Computers console, showing the computer object representing the Azure AD Kerberos server ":::
+:::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 Azure AD 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 Azure AD 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 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).
> [!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].
@@ -52,10 +54,10 @@ For more information about how Azure AD Kerberos works with Windows Hello for Bu
| Requirement | Notes |
| --- | --- |
-| Multi-factor Authentication | This requirement can be met using [Azure AD multi-factor authentication](/azure/active-directory/authentication/howto-mfa-getstarted), multi-factor authentication provided through AD FS, or a comparable solution. |
-| Windows 10, version 21H2 or Windows 11 and later | If you're using Windows 10 21H2, KB5010415 must be installed. If you're using Windows 11 21H2, KB5010414 must be installed. There's no Windows version support difference between Azure AD joined and Hybrid Azure AD-joined devices. |
+| Multifactor authentication | This requirement can be met using [Microsoft Entra multifactor authentication](/azure/active-directory/authentication/howto-mfa-getstarted), multifactor authentication provided through AD FS, or a comparable solution. |
+| Windows 10, version 21H2 or Windows 11 and later | If you're using Windows 10 21H2, KB5010415 must be installed. If you're using Windows 11 21H2, KB5010414 must be installed. There's no Windows version support difference between Microsoft Entra joined and Microsoft Entra hybrid joined devices. |
| Windows Server 2016 or later Domain Controllers | If you're using Windows Server 2016, [KB3534307][SUP-1] must be installed. If you're using Server 2019, [KB4534321][SUP-2] must be installed. |
-| Azure AD Kerberos PowerShell module | This module is used for enabling and managing Azure AD Kerberos. It's available through the [PowerShell Gallery](https://www.powershellgallery.com/packages/AzureADHybridAuthenticationManagement).|
+| Microsoft Entra Kerberos PowerShell module | This module is used for enabling and managing Microsoft Entra Kerberos. It's available through the [PowerShell Gallery](https://www.powershellgallery.com/packages/AzureADHybridAuthenticationManagement).|
| Device management | Windows Hello for Business cloud Kerberos trust can be managed with group policy or through mobile device management (MDM) policy. This feature is disabled by default and must be enabled using policy. |
### Unsupported scenarios
@@ -65,19 +67,19 @@ The following scenarios aren't supported using Windows Hello for Business cloud
- On-premises only deployments
- RDP/VDI scenarios using supplied credentials (RDP/VDI can be used with Remote Credential Guard or if a certificate is enrolled into the Windows Hello for Business container)
- Using cloud Kerberos trust for "Run as"
-- Signing in with cloud Kerberos trust on a Hybrid Azure AD joined device without previously signing in with DC connectivity
+- Signing in with cloud Kerberos trust on a Microsoft Entra hybrid joined device without previously signing in with DC connectivity
> [!NOTE]
> The default *Password Replication Policy* configured on the AzureADKerberos computer object doesn't allow to sign high privilege accounts on to on-premises resources with cloud Kerberos trust or FIDO2 security keys.
>
-> Due to possible attack vectors from Azure AD to Active Directory, it **isn't recommended** to unblock these accounts by relaxing the Password Replication Policy of the computer object `CN=AzureADKerberos,OU=Domain Controllers,`.
+> Due to possible attack vectors from Microsoft Entra ID to Active Directory, it **isn't recommended** to unblock these accounts by relaxing the Password Replication Policy of the computer object `CN=AzureADKerberos,OU=Domain Controllers,`.
## Next steps
Once the prerequisites are met, deploying Windows Hello for Business with a cloud Kerberos trust model consists of the following steps:
> [!div class="checklist"]
-> * Deploy Azure AD Kerberos
+> * Deploy Microsoft Entra Kerberos
> * Configure Windows Hello for Business settings
> * Provision Windows Hello for Business on Windows clients
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-provision.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-provision.md
index 7c2d96a0d1..dc8d3d3a24 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-provision.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-provision.md
@@ -15,7 +15,7 @@ After the prerequisites are met and the PKI configuration is validated, Windows
## Configure Windows Hello for Business using Microsoft Intune
-For Azure AD joined devices and hybrid Azure AD joined devices enrolled in Intune, you can use Intune policies to manage Windows Hello for Business.
+For Microsoft Entra joined devices and Microsoft Entra hybrid joined devices enrolled in Intune, you can use Intune policies to manage Windows Hello for Business.
There are different ways to enable and configure Windows Hello for Business in Intune:
@@ -66,7 +66,7 @@ To configure Windows Hello for Business using an *account protection* policy:
## Configure Windows Hello for Business using group policies
-For hybrid Azure AD joined devices, you can use group policies to configure Windows Hello for Business.
+For Microsoft Entra hybrid joined devices, you can use group policies to configure Windows Hello for Business.
It's suggested to create a security group (for example, *Windows Hello for Business Users*) to make it easy to deploy Windows Hello for Business in phases. You assign **Group Policy permissions** to this group to simplify the deployment by adding the users to the group.
The Windows Hello for Business Group Policy object delivers the correct Group Policy settings to the user, which enables them to enroll and use Windows Hello for Business to authenticate to Azure and Active Directory
@@ -144,14 +144,14 @@ The following process occurs after a user signs in, to enroll in Windows Hello f
1. The user is prompted with a full screen page to use Windows Hello with the organization account. The user selects **OK**
1. The enrollment flow proceeds to the multi-factor authentication phase. The process informs the user that there's an MFA contact attempt, using the configured form of MFA. The provisioning process doesn't proceed until authentication succeeds, fails or times out. A failed or timeout MFA results in an error and asks the user to retry
1. After a successful MFA, the provisioning flow asks the user to create and validate a PIN. This PIN must observe any PIN complexity policies configured on the device
-1. The remainder of the provisioning includes Windows Hello for Business requesting an asymmetric key pair for the user, preferably from the TPM (or required if explicitly set through policy). Once the key pair is acquired, Windows communicates with Azure Active Directory to register the public key. When key registration completes, Windows Hello for Business provisioning informs the user they can use their PIN to sign-in. The user may close the provisioning application and see their desktop. While the user has completed provisioning, Azure AD Connect synchronizes the user's key to Active Directory
+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.":::
> [!IMPORTANT]
-> The minimum time needed to synchronize the user's public key from Azure Active Directory to the on-premises Active Directory is 30 minutes. The Azure AD Connect scheduler controls the synchronization interval.
+> The minimum time needed to synchronize the user's public key from 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 [Azure AD Connect sync: Scheduler][AZ-5] to view and adjust the **synchronization cycle** for your organization.
+> Read [Microsoft Entra Connect Sync: Scheduler][AZ-5] to view and adjust the **synchronization cycle** for your organization.
[AZ-4]: /azure/active-directory/devices/troubleshoot-device-dsregcmd
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md
index c4248ffb62..f39545b8e8 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md
@@ -16,7 +16,7 @@ ms.topic: tutorial
Windows Hello for Business must have a Public Key Infrastructure (PKI) when using the *key trust* model. The domain controllers must have a certificate, which serves as a *root of trust* for clients. The certificate ensures that clients don't communicate with rogue domain controllers.
-Key trust deployments do not need client-issued certificates for on-premises authentication. Active Directory user accounts are configured for public key mapping by *Azure AD Connect Sync*, which synchronizes the public key of the Windows Hello for Business credential to an attribute on the user's Active Directory object (`msDS-KeyCredentialLink`).
+Key trust deployments do not need client-issued certificates for on-premises authentication. Active Directory user accounts are configured for public key mapping by *Microsoft Entra Connect Sync*, which synchronizes the public key of the Windows Hello for Business credential to an attribute on the user's Active Directory object (`msDS-KeyCredentialLink`).
A Windows Server-based PKI or a third-party Enterprise certification authority can be used. The requirements for the domain controller certificate are shown below. For more details, see [Requirements for domain controller certificates from a third-party CA][SERV-1].
@@ -49,12 +49,12 @@ Sign in using *Enterprise Administrator* equivalent credentials on a Windows Ser
[!INCLUDE [dc-certificate-template](includes/dc-certificate-template.md)]
> [!NOTE]
-> Inclusion of the *KDC Authentication* OID in domain controller certificate is not required for hybrid Azure AD-joined devices. The OID is required for enabling authentication with Windows Hello for Business to on-premises resources by Azure AD-joined devices.
+> Inclusion of the *KDC Authentication* OID in domain controller certificate is not required for Microsoft Entra hybrid joined devices. The OID is required for enabling authentication with Windows Hello for Business to on-premises resources by Microsoft Entra joined devices.
> [!IMPORTANT]
-> For Azure AD joined devices to authenticate to on-premises resources, ensure to:
+> 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 Azure AD-joined devices, such as a web-based URL
+> - Publish your certificate revocation list to a location that is available to Microsoft Entra joined devices, such as a web-based URL
[!INCLUDE [dc-certificate-template-supersede](includes/dc-certificate-supersede.md)]
@@ -74,7 +74,7 @@ Sign in to the CA or management workstations with **Enterprise Admin** equivalen
1. Close the console
> [!IMPORTANT]
-> If you plan to deploy **Azure AD joined** devices, and require single sign-on (SSO) to on-premises resources when signing in with Windows Hello for Business, follow the procedures to [update your CA to include an http-based CRL distribution point](hello-hybrid-aadj-sso.md).
+> 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
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
index 8ab43e5406..d9716ad230 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
@@ -14,7 +14,7 @@ ms.topic: how-to
[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-key-trust.md)]
-Hybrid environments are distributed systems that enable organizations to use on-premises and Azure AD-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.
+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.
@@ -29,10 +29,10 @@ The following prerequisites must be met for a hybrid key trust deployment:
> [!div class="checklist"]
> * Directories and directory synchronization
-> * Authentication to Azure AD
+> * Authentication to Microsoft Entra ID
> * Device registration
> * Public Key Infrastructure
-> * Multi-factor authentication
+> * Multifactor authentication
> * Device management
### Directories and directory synchronization
@@ -40,40 +40,44 @@ The following prerequisites must be met for a hybrid key trust deployment:
Hybrid Windows Hello for Business needs two directories:
- An on-premises Active Directory
-- An Azure Active Directory tenant
+- A Microsoft Entra tenant
-The two directories must be synchronized with [Azure AD Connect Sync][AZ-1], which synchronizes user accounts from the on-premises Active Directory to Azure AD.\
-During the Window Hello for Business provisioning process, users register the public portion of their Windows Hello for Business credential with Azure AD. *Azure AD Connect Sync* synchronizes the Windows Hello for Business public key to Active Directory.
+The two directories must be synchronized with [Microsoft Entra Connect Sync][AZ-1], which synchronizes user accounts from the on-premises Active Directory to Azure AD.\
+During the Window Hello for Business provisioning process, users register the public portion of their Windows Hello for Business credential with Microsoft Entra ID. *Microsoft Entra Connect Sync* synchronizes the Windows Hello for Business public key to Active Directory.
> [!NOTE]
-> Windows Hello for Business hybrid key trust is not supported if the users' on-premises UPN suffix cannot be added as a verified domain in Azure AD.
+> Windows Hello for Business hybrid key trust is not supported if the users' on-premises UPN suffix cannot be added as a verified domain in Microsoft Entra ID.
-### Authentication to Azure AD
+
-Authentication to Azure AD can be configured with or without federation:
+### Authentication to Microsoft Entra ID
-- [Password hash synchronization][AZ-6] or [Azure Active Directory pass-through-authentication][AZ-7] is required for non-federated environments
+Authentication to Microsoft Entra ID can be configured with or without federation:
+
+- [Password hash synchronization][AZ-6] or [Microsoft Entra pass-through authentication][AZ-7] is required for non-federated environments
- Active Directory Federation Services (AD FS) or a third-party federation service is required for federated environments
### Device registration
-The Windows devices must be registered in Azure AD. Devices can be registered in Azure AD using either *Azure AD join* or *hybrid Azure AD join*.\
-For *hybrid Azure AD joined* devices, review the guidance on the [Plan your hybrid Azure Active Directory join implementation][AZ-8] page.
+The Windows devices must be registered in Microsoft Entra ID. Devices can be registered in Microsoft Entra ID using either *Microsoft Entra join* or *Microsoft Entra hybrid join*.\
+For *Microsoft Entra hybrid joined* devices, review the guidance on the [Plan your Microsoft Entra hybrid join implementation][AZ-8] page.
### Public Key Infrastructure
An enterprise PKI is required as *trust anchor* for authentication. Domain controllers require a certificate for Windows clients to trust them.
-### Multi-factor authentication
+
+
+### 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.\
Hybrid deployments can use:
-- [Azure AD Multi-Factor Authentication][AZ-2]
-- A multi-factor authentication provided by AD FS, which includes an adapter model that enables third parties to integrate their MFA into AD FS
+- [Microsoft Entra multifactor authentication][AZ-2]
+- A multifactor authentication provided by AD FS, which includes an adapter model that enables third parties to integrate their MFA into AD FS
-For more information how to configure Azure AD Multi-Factor Authentication, see [Configure Azure AD Multi-Factor Authentication settings][AZ-3].\
-For more information how to configure AD FS to provide multi-factor authentication, see [Configure Azure MFA as authentication provider with AD FS][SER-1].
+For more information how to configure Microsoft Entra multifactor authentication, see [Configure Microsoft Entra multifactor authentication settings][AZ-3].\
+For more information how to configure AD FS to provide multifactor authentication, see [Configure Azure MFA as authentication provider with AD FS][SER-1].
### Device management
@@ -87,7 +91,7 @@ Once the prerequisites are met, deploying Windows Hello for Business with a hybr
> * Configure and validate the PKI
> * Configure Windows Hello for Business settings
> * Provision Windows Hello for Business on Windows clients
-> * Configure single sign-on (SSO) for Azure AD joined devices
+> * 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)
@@ -102,4 +106,4 @@ Once the prerequisites are met, deploying Windows Hello for Business with a hybr
[AZ-7]: /azure/active-directory/connect/active-directory-aadconnect-pass-through-authentication
[AZ-8]: /azure/active-directory/devices/hybrid-azuread-join-plan
-[SER-1]: /windows-server/identity/ad-fs/operations/configure-ad-fs-2016-and-azure-mfa
\ No newline at end of file
+[SER-1]: /windows-server/identity/ad-fs/operations/configure-ad-fs-2016-and-azure-mfa
diff --git a/windows/security/identity-protection/hello-for-business/hello-identity-verification.md b/windows/security/identity-protection/hello-for-business/hello-identity-verification.md
index c3d9210b98..ea4c5a3119 100644
--- a/windows/security/identity-protection/hello-for-business/hello-identity-verification.md
+++ b/windows/security/identity-protection/hello-for-business/hello-identity-verification.md
@@ -17,12 +17,14 @@ appliesto:
This article lists the infrastructure requirements for the different deployment models for Windows Hello for Business.
-## Azure AD Cloud Only Deployment
+
-- Azure Active Directory
-- Azure AD Multifactor Authentication
+## Microsoft Entra Cloud Only Deployment
+
+- Microsoft Entra ID
+- Microsoft Entra multifactor authentication
- Device management solution (Intune or supported third-party MDM), *optional*
-- Azure AD Premium subscription - *optional*, needed for automatic MDM enrollment when the device joins Azure Active Directory
+- Microsoft Entra ID P1 or P2 subscription - *optional*, needed for automatic MDM enrollment when the device joins Microsoft Entra ID
## Hybrid Deployments
@@ -37,8 +39,8 @@ The table shows the minimum requirements for each deployment. For key trust in a
| **Certificate Authority**| Not required |Any supported Windows Server versions | Any supported Windows Server versions | Any supported Windows Server versions |
| **AD FS Version** | Not required | Not required | Any supported Windows Server versions | Any supported Windows Server versions |
| **MFA Requirement** | Azure MFA, or
AD FS w/Azure MFA adapter, or
AD FS w/Azure MFA Server adapter, or
AD FS w/3rd Party MFA Adapter | Azure MFA tenant, or
AD FS w/Azure MFA adapter, or
AD FS w/Azure MFA Server adapter, or
AD FS w/3rd Party MFA Adapter | Azure MFA tenant, or
AD FS w/Azure MFA adapter, or
AD FS w/Azure MFA Server adapter, or
AD FS w/3rd Party MFA Adapter | Azure MFA tenant, or
AD FS w/Azure MFA adapter, or
AD FS w/Azure MFA Server adapter, or
AD FS w/3rd Party MFA Adapter |
-| **Azure AD Connect** | Not required. It's recommended to use [Microsoft Entra Connect cloud sync](/azure/active-directory/hybrid/cloud-sync/what-is-cloud-sync) | Required | Required | Required |
-| **Azure AD License** | Azure AD Premium, optional | Azure AD Premium, optional | Azure AD Premium, needed for device write-back | Azure AD Premium, optional. Intune license required |
+| **Microsoft Entra Connect** | Not required. It's recommended to use [Microsoft Entra Connect cloud sync](/azure/active-directory/hybrid/cloud-sync/what-is-cloud-sync) | Required | Required | Required |
+| **Microsoft Entra ID license** | Microsoft Entra ID P1 or P2, optional | Microsoft Entra ID P1 or P2, optional | Microsoft Entra ID P1 or P2, needed for device write-back | Microsoft Entra ID P1 or P2, optional. Intune license required |
## On-premises Deployments
@@ -52,4 +54,4 @@ The table shows the minimum requirements for each deployment.
| **Domain Controller Version**| Any supported Windows Server versions | Any supported Windows Server versions |
| **Certificate Authority**| Any supported Windows Server versions | Any supported Windows Server versions |
| **AD FS Version**| Any supported Windows Server versions | Any supported Windows Server versions |
-| **MFA Requirement**| AD FS with 3rd Party MFA Adapter | AD FS with 3rd Party MFA Adapter |
\ No newline at end of file
+| **MFA Requirement**| AD FS with 3rd Party MFA Adapter | AD FS with 3rd Party MFA Adapter |
diff --git a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-deploy-mfa.md b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-deploy-mfa.md
index 61aece97e7..52c64523e9 100644
--- a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-deploy-mfa.md
+++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-deploy-mfa.md
@@ -1,6 +1,6 @@
---
title: Validate and Deploy MFA for Windows Hello for Business with key trust
-description: Validate and deploy multi-factor authentication (MFA) for Windows Hello for Business in an on-premises key trust model.
+description: Validate and deploy multifactor authentication (MFA) for Windows Hello for Business in an on-premises key trust model.
ms.date: 09/07/2023
appliesto:
- ✅ Windows 11
@@ -11,22 +11,22 @@ appliesto:
ms.topic: tutorial
---
-# Validate and deploy multi-factor authentication - on-premises key trust
+# Validate and deploy multifactor authentication - on-premises key trust
[!INCLUDE [hello-on-premises-key-trust](./includes/hello-on-premises-key-trust.md)]
-Windows Hello for Business requires users perform multi-factor authentication (MFA) prior to enroll in the service. On-premises deployments can use, as MFA option:
+Windows Hello for Business requires users perform multifactor authentication (MFA) prior to enroll in the service. On-premises deployments can use, as MFA option:
- certificates
- third-party authentication providers for AD FS
- custom authentication provider for AD FS
> [!IMPORTANT]
-> As of July 1, 2019, Microsoft will no longer offer MFA Server for new deployments. New customers who would like to require multi-factor authentication from their users should use cloud-based Azure AD Multi-Factor Authentication. Existing customers who have activated MFA Server prior to July 1 will be able to download the latest version, future updates and generate activation credentials as usual.
+> As of July 1, 2019, Microsoft will no longer offer MFA Server for new deployments. New customers who would like to require multifactor authentication from their users should use cloud-based Microsoft Entra multifactor authentication. Existing customers who have activated MFA Server prior to July 1 will be able to download the latest version, future updates and generate activation credentials as usual.
For information on available third-party authentication methods see [Configure Additional Authentication Methods for AD FS](/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs). For creating a custom authentication method see [Build a Custom Authentication Method for AD FS in Windows Server](/windows-server/identity/ad-fs/development/ad-fs-build-custom-auth-method)
-Follow the integration and deployment guide for the authentication provider you select to integrate and deploy it to AD FS. Make sure that the authentication provider is selected as a multi-factor authentication option in the AD FS authentication policy. For information on configuring AD FS authentication policies see [Configure Authentication Policies](/windows-server/identity/ad-fs/operations/configure-authentication-policies).
+Follow the 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)
\ No newline at end of file
+> [Next: configure Windows Hello for Business Policy settings](hello-key-trust-policy-settings.md)
diff --git a/windows/security/identity-protection/hello-for-business/hello-manage-in-organization.md b/windows/security/identity-protection/hello-for-business/hello-manage-in-organization.md
index fa22c012a0..999b35f45b 100644
--- a/windows/security/identity-protection/hello-for-business/hello-manage-in-organization.md
+++ b/windows/security/identity-protection/hello-for-business/hello-manage-in-organization.md
@@ -13,7 +13,7 @@ ms.topic: reference
You can create a Group Policy or mobile device management (MDM) policy to configure Windows Hello for Business on Windows devices.
>[!IMPORTANT]
->Windows Hello as a convenience PIN is disabled by default on all domain joined and Azure AD joined devices. To enable a convenience PIN, enable the Group Policy setting **Turn on convenience PIN sign-in**.
+>Windows Hello as a convenience PIN is disabled by default on all domain joined and Microsoft Entra joined devices. To enable a convenience PIN, enable the Group Policy setting **Turn on convenience PIN sign-in**.
>
>Use **PIN Complexity** policy settings to manage PINs for Windows Hello for Business.
diff --git a/windows/whats-new/deprecated-features.md b/windows/whats-new/deprecated-features.md
index 881e004c0c..75c9ea7697 100644
--- a/windows/whats-new/deprecated-features.md
+++ b/windows/whats-new/deprecated-features.md
@@ -1,7 +1,7 @@
---
title: Deprecated features in the Windows client
description: Review the list of features that Microsoft is no longer actively developing in Windows 10 and Windows 11.
-ms.date: 10/09/2023
+ms.date: 10/18/2023
ms.prod: windows-client
ms.technology: itpro-fundamentals
ms.localizationpriority: medium
@@ -36,6 +36,7 @@ The features in this article are no longer being actively developed, and might b
|Feature | Details and mitigation | Deprecation announced |
| ----------- | --------------------- | ---- |
+| Timeline for Microsoft Entra accounts | Cross-device syncing of Microsoft Entra user activity history will stop starting in January 2024. Microsoft will stop storing this data in the cloud, aligning with [the previous change for Microsoft accounts (MSA)](https://blogs.windows.com/windows-insider/2021/04/14/announcing-windows-10-insider-preview-build-21359) in 2021. The timeline user experience was retired in Windows 11, although it remains in Windows 10. The timeline user experience and all your local activity history still remains on Windows 10 devices. Users can access web history using their browser and access recent files through OneDrive and Office. | October 2023 |
| VBScript | VBScript is being deprecated. In future releases of Windows, VBScript will be available as a feature on demand before its removal from the operating system. For more information, see [Resources for deprecated features](deprecated-features-resources.md#vbscript). | October 2023 |
| WordPad | WordPad is no longer being updated and will be removed in a future release of Windows. We recommend Microsoft Word for rich text documents like .doc and .rtf and Windows Notepad for plain text documents like .txt. | September 1, 2023 |
| AllJoyn | Microsoft's implementation of AllJoyn which included the [Windows.Devices.AllJoyn API namespace](/uwp/api/windows.devices.alljoyn), a [Win32 API](/windows/win32/api/_alljoyn/), a [management configuration service provider (CSP)](/windows/client-management/mdm/alljoynmanagement-csp), and an [Alljoyn Router Service](/windows-server/security/windows-services/security-guidelines-for-disabling-system-services-in-windows-server#alljoyn-router-service) has been deprecated. [AllJoyn](https://openconnectivity.org/technology/reference-implementation/alljoyn/), sponsored by AllSeen Alliance, was an open source discovery and communication protocol for Internet of Things scenarios such as turning on/off lights or reading temperatures.AllSeen Alliance promoted the AllJoyn project from 2013 until 2016 when it merged with the Open Connectivity Foundation (OCF), the sponsors of [Iotivity.org](https://iotivity.org/), another protocol for Internet of Things scenarios. Customers should refer to the [Iotivity.org](https://iotivity.org/) website for alternatives such as [Iotivity Lite](https://github.com/iotivity/iotivity-lite) or [Iotivity](https://github.com/iotivity/iotivity). | August 17, 2023 |
@@ -52,7 +53,7 @@ The features in this article are no longer being actively developed, and might b
| Microsoft Edge | The legacy version of Microsoft Edge is no longer being developed.| 2004 |
| Companion Device Framework | The [Companion Device Framework](/windows-hardware/design/device-experiences/windows-hello-companion-device-framework) is no longer under active development.| 2004 |
| Dynamic Disks | The [Dynamic Disks](/windows/win32/fileio/basic-and-dynamic-disks#dynamic-disks) feature is no longer being developed. This feature will be fully replaced by [Storage Spaces](/windows-server/storage/storage-spaces/overview) in a future release.| 2004 |
-| Microsoft BitLocker Administration and Monitoring (MBAM)| [Microsoft BitLocker Administration and Monitoring (MBAM)](/microsoft-desktop-optimization-pack/mbam-v25/), part of the [Microsoft Desktop Optimization Pack (MDOP)](/lifecycle/announcements/mdop-extended) is no longer being developed. | September, 2019 |
+| Microsoft BitLocker Administration and Monitoring (MBAM)| [Microsoft BitLocker Administration and Monitoring (MBAM)](/microsoft-desktop-optimization-pack/mbam-v25/), part of the [Microsoft Desktop Optimization Pack (MDOP)](/lifecycle/announcements/mdop-extended) is no longer being developed. | September 2019 |
| Language Community tab in Feedback Hub | The Language Community tab will be removed from the Feedback Hub. The standard feedback process: [Feedback Hub - Feedback](feedback-hub://?newFeedback=true&feedbackType=2) is the recommended way to provide translation feedback. | 1909 |
| My People / People in the Shell | My People is no longer being developed. It may be removed in a future update. | 1909 |
| Package State Roaming (PSR) | PSR will be removed in a future update. PSR allows non-Microsoft developers to access roaming data on devices, enabling developers of UWP applications to write data to Windows and synchronize it to other instantiations of Windows for that user.
The recommended replacement for PSR is [Azure App Service](/azure/app-service/). Azure App Service is widely supported, well documented, reliable, and supports cross-platform/cross-ecosystem scenarios such as iOS, Android and web.
PSR was removed in Windows 11.| 1909 |
diff --git a/windows/whats-new/windows-11-prepare.md b/windows/whats-new/windows-11-prepare.md
index 6e9047c606..fb11714e70 100644
--- a/windows/whats-new/windows-11-prepare.md
+++ b/windows/whats-new/windows-11-prepare.md
@@ -19,7 +19,7 @@ appliesto:
# Prepare for Windows 11
-Windows 10 and Windows 11 are designed to coexist, so that you can use the same familiar tools and process to manage both operating systems. Using a single management infrastructure that supports common applications across both Windows 10 and Windows 11 helps to simplify the migration process. You can analyze endpoints, determine application compatibility, and manage Windows 11 deployments in the same way that you do with Windows 10.
+Windows 10 and Windows 11 are designed to coexist so that you can use the same familiar tools and processes to manage both operating systems. Using a single management infrastructure that supports common applications across both Windows 10 and Windows 11 helps to simplify the migration process. You can analyze endpoints, determine application compatibility, and manage Windows 11 deployments in the same way that you do with Windows 10.
After you evaluate your hardware to see if it meets [requirements](windows-11-requirements.md) for Windows 11, it's a good time to review your deployment infrastructure, tools, and overall endpoint and update management processes and look for opportunities to simplify and optimize. This article provides some helpful guidance to accomplish these tasks.
@@ -32,7 +32,7 @@ The tools that you use for core workloads during Windows 10 deployments can stil
#### On-premises solutions
-- If you use [Windows Server Update Service (WSUS)](/windows-server/administration/windows-server-update-services/get-started/windows-server-update-services-wsus), you'll need to sync the new **Windows 11** product category. After you sync the product category, you'll see Windows 11 offered as an option. If you would like to validate Windows 11 prior to release, you can sync the **Windows Insider Pre-release** category as well.
+- If you use [Windows Server Update Services (WSUS)](/windows-server/administration/windows-server-update-services/get-started/windows-server-update-services-wsus), you'll need to sync the new Windows 11 product category. After you sync the product category, you'll see Windows 11 offered as an option. If you would like to validate Windows 11 prior to release, you can sync the **Windows Insider Pre-release** category as well.
> [!NOTE]
> During deployment, you will be prompted to agree to the Microsoft Software License Terms on behalf of your users. Additionally, you will not see an x86 option because Windows 11 is not supported on 32-bit architecture.
@@ -44,25 +44,25 @@ The tools that you use for core workloads during Windows 10 deployments can stil
#### Cloud-based solutions
-- If you use Windows Update for Business policies, you'll need to use the **Target Version** capability (either through policy or the Windows Update for Business deployment service) rather than using feature update deferrals alone to upgrade from Windows 10 to Windows 11. Feature update deferrals are great to move to newer versions of your current product (for example, Windows 10, version 20H2 to 21H1), but won't automatically devices move between products (Windows 10 to Windows 11).
+- If you use Windows Update for Business policies, you'll need to use the **Target Version** capability (either through policy or the Windows Update for Business deployment service) rather than using feature update deferrals alone to upgrade from Windows 10 to Windows 11. Feature update deferrals are great for moving to newer versions of your current product (for example, Windows 10, version 20H2 to 21H1), but won't automatically move devices between products (Windows 10 to **Windows 11**).
- If you use Microsoft Intune and have a Microsoft 365 E3 license, you'll be able to use the [feature update deployments](/mem/intune/protect/windows-10-feature-updates) page to select **Windows 11, version 21H2** and upgrade Windows 10 devices to Windows 11. You can also continue using the same update experience controls to manage Windows 10 and Windows 11 on the **Update Rings** page in Intune. If you aren’t ready to move to Windows 11, keep the feature update version set at the version you're currently on. When you're ready to start upgrading devices, change the feature update deployment setting to specify Windows 11.
- In Group Policy, **Select target Feature Update version** has two entry fields after taking the 9/1/2021 optional update ([KB5005101](https://support.microsoft.com/topic/september-1-2021-kb5005101-os-builds-19041-1202-19042-1202-and-19043-1202-preview-82a50f27-a56f-4212-96ce-1554e8058dc1)) or a later update: **Product Version** and **Target Version**.
- The product field must specify Windows 11 in order for devices to upgrade to Windows 11. If only the target version field is configured, the device will be offered matching versions of the same product.
- For example, if a device is running Windows 10, version 2004 and only the target version is configured to 21H1, this device will be offered version Windows 10, version 21H1, even if multiple products have a 21H1 version.
- Quality update deferrals will continue to work the same across both Windows 10 and Windows 11, which is true regardless of which management tool you use to configure Windows Update for Business policies.
-- If you use Microsoft Intune and have a Microsoft 365 E3 license, you'll be able to use [feature update deployments](/mem/intune/protect/windows-10-feature-updates) to easily update devices from one release of Windows 10 to another, or to upgrade Windows 10 devices to Windows 11. You can also continue using the same update experience controls to manage Windows 10 and Windows 11. If you aren’t ready to move to Windows 11, keep the feature update version set at the version you're currently on. When you're ready to start upgrading devices, change the feature update deployment setting to specify Windows 11.
+- If you use Microsoft Intune and have a Microsoft 365 E3 license, you'll be able to use [feature update deployments](/mem/intune/protect/windows-10-feature-updates) to easily update devices from one release of Windows 10 to another, or to upgrade Windows 10 devices to Windows 11. You can also continue using the same update experience controls to manage Windows 10 and Windows 11. If you aren’t ready to move to Windows 11, keep the feature update version set at the version you're currently on. When you're ready to start upgrading devices, change the feature update deployment setting to specify **Windows 11**.
> [!NOTE]
> Endpoints managed by Windows Update for Business will not automatically upgrade to Windows 11 unless an administrator explicitly configures a **Target Version** using the [TargetReleaseVersion](/windows/client-management/mdm/policy-csp-update#update-targetreleaseversion) setting using a Windows CSP, a [feature update profile](/mem/intune/protect/windows-10-feature-updates) in Intune, or the [Select target Feature Update version setting](/windows/deployment/update/waas-wufb-group-policy#i-want-to-stay-on-a-specific-version) in a group policy.
## Cloud-based management
-If you aren’t already taking advantage of cloud-based management capabilities, like those available in the [Microsoft Intune family of products](/mem/endpoint-manager-overview), it's worth considering. In addition to consolidating device management and endpoint security into a single platform, Microsoft Intune can better support the diverse bring-your-own-device (BYOD) ecosystem that is increasingly the norm with hybrid work scenarios. It can also enable you to track your progress against compliance and business objectives, while protecting user privacy.
+If you aren’t already taking advantage of cloud-based management capabilities, like those available in the [Microsoft Intune family of products](/mem/endpoint-manager-overview), it's worth considering. In addition to consolidating device management and endpoint security into a single platform, Microsoft Intune can better support the diverse bring-your-own-device (BYOD) ecosystem that is increasingly the norm with hybrid work scenarios. It can also enable you to track your progress against compliance and business objectives while protecting user privacy.
-The following are some common use cases and the corresponding Microsoft Intune capabilities that support them:
+The following are some common use cases and the corresponding [Microsoft Intune](/mem/intune/fundamentals/what-is-intune) capabilities that support them:
-- **Provision and pre-configure new Windows 11 devices**: [Windows Autopilot](/mem/autopilot/windows-autopilot) enables you to deploy new Windows 11 devices in a “business-ready” state that includes your desired applications, settings, and policies. It can also be used to change the edition of Windows. For example, you can upgrade from Pro to Enterprise edition and gain the use of advanced features. The [Windows Autopilot diagnostics page](/mem/autopilot/windows-autopilot-whats-new#preview-windows-autopilot-diagnostics-page) is new feature that is available when you use in Windows Autopilot to deploy Windows 11.
+- **Provision and pre-configure new Windows 11 devices**: [Windows Autopilot](/mem/autopilot/windows-autopilot) enables you to deploy new Windows 11 devices in a “business-ready” state that includes your desired applications, settings, and policies. It can also be used to change the edition of Windows. For example, you can upgrade from Professional to Enterprise edition and gain the use of advanced features. The [Windows Autopilot diagnostics page](/mem/autopilot/windows-autopilot-whats-new#preview-windows-autopilot-diagnostics-page) is a new feature that is available when you use in Windows Autopilot to deploy Windows 11.
- **Configure rules and control settings for users, apps, and devices**: When you enroll devices in [Microsoft Intune](/mem/intune/fundamentals/what-is-intune), administrators have full control over apps, settings, features, and security for both Windows 11 and Windows 10. You can also use app protection policies to require multifactor authentication (MFA) for specific apps.
- **Streamline device management for frontline, remote, and onsite workers**: Introduced with Windows 10, [cloud configuration](/mem/intune/fundamentals/cloud-configuration) is a standard, easy-to-manage, device configuration that is cloud-optimized for users with specific workflow needs. It can be deployed to devices running the Pro, Enterprise, and Education editions of Windows 11 by using Microsoft Intune.
@@ -74,7 +74,7 @@ Every organization will transition to Windows 11 at its own pace. Microsoft is c
When you think of operating system updates as an ongoing process, you'll automatically improve your ability to deploy updates. This approach enables you to stay current with less effort, and less impact on productivity. To begin, think about how you roll out Windows feature updates today: which devices, and at what pace.
-Next, craft a deployment plan for Windows 11 that includes deployment groups, rings, users, or devices. There are no absolute rules for exactly how many rings to have for your deployments, but a common structure is:
+Next, craft a deployment plan for **Windows 11** that includes deployment groups, rings, users, or devices. There are no absolute rules for exactly how many rings to have for your deployments, but a common structure is:
- Preview (first or canary): Planning and development
- Limited (fast or early adopters): Pilot and validation
- Broad (users or critical): Wide deployment
@@ -87,9 +87,9 @@ Review deployment-related policies, taking into consideration your organization'
#### Validate apps and infrastructure
-To validate that your apps, infrastructure, and deployment processes are ready for Windows 11, join the [Windows Insider Program for Business](https://insider.windows.com/for-business-getting-started), and opt in to the [Release Preview Channel](/windows-insider/business/validate-Release-Preview-Channel).
+To validate that your apps, infrastructure, and deployment processes are ready for Windows 11, join the [Windows Insider Program for Business](https://insider.windows.com/for-business-getting-started), and opt into the [Release Preview Channel](/windows-insider/business/validate-Release-Preview-Channel).
-If you use Windows Server Update Services, you can deploy directly from the Windows Insider Pre-release category using one of the following processes:
+If you use [Windows Server Update Services (WSUS)](/windows-server/administration/windows-server-update-services/get-started/windows-server-update-services-wsus), you can deploy directly from the Windows Insider Pre-release category using one of the following processes:
- Set **Manage Preview Builds** to **Release Preview** in Windows Update for Business.
- Use Azure Virtual Desktop and Azure Marketplace images.
@@ -119,7 +119,7 @@ At a high level, the tasks involved are:
## User readiness
-Don't overlook the importance of user readiness to deliver an effective, enterprise-wide deployment of Windows 11. Windows 11 has a familiar design, but your users will see several enhancements to the overall user interface. They'll also need to adapt to changes in menus and settings pages. Therefore, consider the following tasks to prepare users and your IT support staff Windows 11:
+Don't overlook the importance of user readiness to deliver an effective, enterprise-wide deployment of Windows 11. Windows 11 has a familiar design, but your users will see several enhancements to the overall user interface. They'll also need to adapt to changes in menus and settings pages. Therefore, consider the following tasks to prepare users and your IT support staff for Windows 11:
- Create a communications schedule to ensure that you provide the right message at the right time to the right groups of users, based on when they'll see the changes.
- Draft concise emails that inform users of what changes they can expect to see. Offer tips on how to use or customize their experience. Include information about support and help desk options.