- 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/media/windows-autopatch-device-registration-overview.png b/windows/deployment/windows-autopatch/media/windows-autopatch-device-registration-overview.png
index f77684b8c4..2098b9cd0c 100644
Binary files a/windows/deployment/windows-autopatch/media/windows-autopatch-device-registration-overview.png and b/windows/deployment/windows-autopatch/media/windows-autopatch-device-registration-overview.png differ
diff --git a/windows/deployment/windows-autopatch/media/windows-autopatch-device-registration-workflow-diagram.png b/windows/deployment/windows-autopatch/media/windows-autopatch-device-registration-workflow-diagram.png
index abd0c884b1..d59d22d90c 100644
Binary files a/windows/deployment/windows-autopatch/media/windows-autopatch-device-registration-workflow-diagram.png and b/windows/deployment/windows-autopatch/media/windows-autopatch-device-registration-workflow-diagram.png differ
diff --git a/windows/deployment/windows-autopatch/media/windows-autopatch-groups-high-level-architecture-diagram.png b/windows/deployment/windows-autopatch/media/windows-autopatch-groups-high-level-architecture-diagram.png
index 1be4b61b37..2c476a2e64 100644
Binary files a/windows/deployment/windows-autopatch/media/windows-autopatch-groups-high-level-architecture-diagram.png and b/windows/deployment/windows-autopatch/media/windows-autopatch-groups-high-level-architecture-diagram.png differ
diff --git a/windows/deployment/windows-autopatch/media/windows-autopatch-post-device-registration-readiness-checks.png b/windows/deployment/windows-autopatch/media/windows-autopatch-post-device-registration-readiness-checks.png
index c6abcd6790..75dc395038 100644
Binary files a/windows/deployment/windows-autopatch/media/windows-autopatch-post-device-registration-readiness-checks.png and b/windows/deployment/windows-autopatch/media/windows-autopatch-post-device-registration-readiness-checks.png differ
diff --git a/windows/deployment/windows-autopatch/media/windows-autopatch-prerequisite-check-workflow-diagram.png b/windows/deployment/windows-autopatch/media/windows-autopatch-prerequisite-check-workflow-diagram.png
index d340ccdecd..9e01c36d3b 100644
Binary files a/windows/deployment/windows-autopatch/media/windows-autopatch-prerequisite-check-workflow-diagram.png and b/windows/deployment/windows-autopatch/media/windows-autopatch-prerequisite-check-workflow-diagram.png differ
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-feature-update-summary-dashboard.md b/windows/deployment/windows-autopatch/operate/windows-autopatch-groups-windows-feature-update-summary-dashboard.md
index 37d261d766..6f8527fdc9 100644
--- a/windows/deployment/windows-autopatch/operate/windows-autopatch-groups-windows-feature-update-summary-dashboard.md
+++ b/windows/deployment/windows-autopatch/operate/windows-autopatch-groups-windows-feature-update-summary-dashboard.md
@@ -1,7 +1,7 @@
---
title: Windows feature update summary dashboard
description: Provides a broader view of the current Windows OS upgrade status for all devices registered with Windows Autopatch.
-ms.date: 07/25/2023
+ms.date: 10/11/2023
ms.prod: windows-client
ms.technology: itpro-updates
ms.topic: how-to
@@ -17,19 +17,19 @@ ms.collection:
# Windows feature update summary dashboard
-The summary dashboard provides a broader view of the current Windows OS update status for all devices registered with Windows Autopatch.
+The Summary dashboard provides a broader view of the current Windows OS update status for all devices registered with Windows Autopatch.
-The first part of the summary dashboard provides you with an all-devices trend report where you can follow the deployment trends within your organization. You can view if updates were successfully installed, failing, in progress, not ready or have their Windows feature update paused.
+The first part of the Summary dashboard provides you with an all-devices trend report where you can follow the deployment trends within your organization. You can view if updates were successfully installed, failing, in progress, not ready or have their Windows feature update paused.
-**To view a generated summary dashboard for your Windows feature update deployments:**
+**To view a generated Summary dashboard for your Windows feature update deployments:**
1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
1. Select **Reports** from the left navigation menu.
-1. Under the **Windows Autopatch** section, select **Windows feature updates (preview)**.
+1. Under the **Windows Autopatch** section, select **Windows feature updates**.
## Report information
-The following information is available in the summary dashboard:
+The following information is available in the Summary dashboard:
| Column name | Description |
| ----- | ----- |
@@ -48,5 +48,5 @@ The following options are available:
| Option | Description |
| ----- | ----- |
-| Refresh | The option to **Refresh** the summary dashboard is available at the top of the page. This process will ensure that the summary dashboard view is updated to the latest available dataset from within the last 24-hour period. |
+| Refresh | The option to **Refresh** the Summary dashboard is available at the top of the page. This process ensures that the Summary dashboard view is updated to the latest available dataset from within the last 24-hour period. |
| Summary links | Each column represents the summary of included devices. Select the hyperlinked number to produce a filtered report in a new browser tab. |
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-groups-windows-quality-update-summary-dashboard.md b/windows/deployment/windows-autopatch/operate/windows-autopatch-groups-windows-quality-update-summary-dashboard.md
index 154e93fb08..e744f0c407 100644
--- a/windows/deployment/windows-autopatch/operate/windows-autopatch-groups-windows-quality-update-summary-dashboard.md
+++ b/windows/deployment/windows-autopatch/operate/windows-autopatch-groups-windows-quality-update-summary-dashboard.md
@@ -1,7 +1,7 @@
---
title: Windows quality update summary dashboard
description: Provides a summary view of the current update status for all devices enrolled into Windows Autopatch with Autopatch groups
-ms.date: 07/25/2023
+ms.date: 10/04/2023
ms.prod: windows-client
ms.technology: itpro-updates
ms.topic: how-to
@@ -17,7 +17,7 @@ ms.collection:
# Windows quality update summary dashboard
-The summary dashboard provides a summary view of the current update status for all devices enrolled into Windows Autopatch.
+The Summary dashboard provides a summary view of the current update status for all devices enrolled into Windows Autopatch.
**To view the current update status for all your enrolled devices:**
@@ -29,7 +29,7 @@ The summary dashboard provides a summary view of the current update status for a
## Report information
-The following information is available in the summary dashboard:
+The following information is available in the Summary dashboard:
| Column name | Description |
| ----- | ----- |
@@ -47,5 +47,5 @@ The following options are available:
| Option | Description |
| ----- | ----- |
-| Refresh | The option to **Refresh** the summary dashboard is available at the top of the page. This process will ensure that the summary dashboard view is updated to the latest available dataset from within the last 24-hour period. |
+| Refresh | The option to **Refresh** the Summary dashboard is available at the top of the page. This process ensures that the Summary dashboard view is updated to the latest available dataset from within the last 24-hour period. |
| Summary links | Each column represents the summary of included devices. Select the hyperlinked number to produce a filtered report in a new browser tab. |
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-microsoft-365-apps-enterprise.md b/windows/deployment/windows-autopatch/operate/windows-autopatch-microsoft-365-apps-enterprise.md
index 06e2e12c09..3120c809f3 100644
--- a/windows/deployment/windows-autopatch/operate/windows-autopatch-microsoft-365-apps-enterprise.md
+++ b/windows/deployment/windows-autopatch/operate/windows-autopatch-microsoft-365-apps-enterprise.md
@@ -1,7 +1,7 @@
---
title: Microsoft 365 Apps for enterprise
description: This article explains how Windows Autopatch manages Microsoft 365 Apps for enterprise updates
-ms.date: 06/23/2023
+ms.date: 10/27/2023
ms.prod: windows-client
ms.technology: itpro-updates
ms.topic: how-to
@@ -81,7 +81,15 @@ Windows Autopatch doesn't allow you to pause or roll back an update in the Micro
## Allow or block Microsoft 365 App updates
-For organizations seeking greater control, you can allow or block Microsoft 365 App updates for Windows Autopatch-enrolled devices. When the Microsoft 365 App update setting is set to **Block**, Windows Autopatch doesn't provide Microsoft 365 App updates on your behalf, and your organizations have full control over these updates. For example, you can continue to receive updates from [channels](/deployoffice/overview-update-channels) other than the default [Monthly Enterprise Channel](/deployoffice/overview-update-channels#monthly-enterprise-channel-overview).
+> [!IMPORTANT]
+> You must be an Intune Administrator to make changes to the setting.
+
+For organizations seeking greater control, you can allow or block Microsoft 365 App updates for Windows Autopatch-enrolled devices.
+
+| Microsoft 365 App setting | Description |
+| ----- | ----- |
+| **Allow** | When set to **Allow**, Windows Autopatch moves all Autopatch managed devices to the [Monthly Enterprise Channel](/deployoffice/overview-update-channels#monthly-enterprise-channel-overview) and manages updates automatically. To manage updates manually, set the Microsoft 365 App update setting to **Block**. |
+| **Block** | When set to **Block**, Windows Autopatch doesn't provide Microsoft 365 App updates on your behalf, and your organizations have full control over these updates. You can continue to receive updates from [channels](/deployoffice/overview-update-channels) other than the default [Monthly Enterprise Channel](/deployoffice/overview-update-channels#monthly-enterprise-channel-overview). |
**To allow or block Microsoft 365 App updates:**
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 66e6fd2e1d..54d107d92d 100644
--- a/windows/deployment/windows-autopatch/overview/windows-autopatch-faq.yml
+++ b/windows/deployment/windows-autopatch/overview/windows-autopatch-faq.yml
@@ -31,10 +31,10 @@ 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 suppported.
+ 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.
- question: What if I enrolled into Windows Autopatch using the promo code? Will I still have access to the service?
answer: |
Yes. For those who used the promo code to access Windows Autopatch during public preview, you'll continue to have access to Windows Autopatch even when the promo code expires. There's no additional action you have to take to continue using Windows Autopatch.
@@ -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..24650e3a33 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/27/2023
ms.prod: windows-client
ms.technology: itpro-updates
ms.topic: whats-new
@@ -21,6 +21,20 @@ 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 feature releases or updates
+
+| Article | Description |
+| ----- | ----- |
+| [Microsoft 365 Apps for enterprise](../operate/windows-autopatch-microsoft-365-apps-enterprise.md#microsoft-365-apps-for-enterprise-update-controls) | Added more information about the Allow setting in the [Microsoft 365 Apps for enterprise update controls](../operate/windows-autopatch-microsoft-365-apps-enterprise.md#microsoft-365-apps-for-enterprise-update-controls) section |
+
+## 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/privacy/docfx.json b/windows/privacy/docfx.json
index 44e5b9392e..35522da4b4 100644
--- a/windows/privacy/docfx.json
+++ b/windows/privacy/docfx.json
@@ -57,7 +57,10 @@
"jborsecnik",
"tiburd",
"garycentric",
- "beccarobins"
+ "beccarobins",
+ "Stacyrch140",
+ "v-stsavell",
+ "American-Dipper"
]
},
"searchScope": ["Windows 10"]
diff --git a/windows/security/application-security/application-control/windows-defender-application-control/applocker/using-event-viewer-with-applocker.md b/windows/security/application-security/application-control/windows-defender-application-control/applocker/using-event-viewer-with-applocker.md
index 35cecd0bee..f237a5b23c 100644
--- a/windows/security/application-security/application-control/windows-defender-application-control/applocker/using-event-viewer-with-applocker.md
+++ b/windows/security/application-security/application-control/windows-defender-application-control/applocker/using-event-viewer-with-applocker.md
@@ -38,24 +38,24 @@ The following table contains information about the events that you can use to de
| Event ID | Level | Event message | Description |
| --- | --- | --- | --- |
-| 8000 | Error| Application Identity Policy conversion failed. Status * <%1> *| Indicates that the policy wasn't applied correctly to the computer. The status message is provided for troubleshooting purposes.|
+| 8000 | Error| AppID policy conversion failed. Status * <%1> *| Indicates that the policy wasn't applied correctly to the computer. The status message is provided for troubleshooting purposes.|
| 8001 | Information| The AppLocker policy was applied successfully to this computer.| Indicates that the AppLocker policy was successfully applied to the computer.|
| 8002 | Information| *<File name> * was allowed to run.| Specifies that the .exe or .dll file is allowed by an AppLocker rule.|
-| 8003 | Warning| *<File name> * was allowed to run but would have been prevented from running if the AppLocker policy was enforced.| Applied only when the **Audit only** enforcement mode is enabled. Specifies that the .exe or .dll file would be blocked if the **Enforce rules** enforcement mode were enabled. |
-| 8004 | Error| *<File name> * was not allowed to run.| Access to *<file name>* is restricted by the administrator. Applied only when the **Enforce rules** enforcement mode is set either directly or indirectly through Group Policy inheritance. The .exe or .dll file can't run.|
+| 8003 | Warning| *<File name> * was allowed to run but would have been prevented from running if the AppLocker policy were enforced.| Applied only when the **Audit only** enforcement mode is enabled. Specifies that the .exe or .dll file would be blocked if the **Enforce rules** enforcement mode were enabled. |
+| 8004 | Error| *<File name> * was prevented from running.| Access to *<file name>* is restricted by the administrator. Applied only when the **Enforce rules** enforcement mode is set either directly or indirectly through Group Policy inheritance. The .exe or .dll file can't run.|
| 8005| Information| *<File name> * was allowed to run.| Specifies that the script or .msi file is allowed by an AppLocker rule.|
-| 8006 | Warning| *<File name> * was allowed to run but would have been prevented from running if the AppLocker policy was enforced.| Applied only when the **Audit only** enforcement mode is enabled. Specifies that the script or .msi file would be blocked if the **Enforce rules** enforcement mode were enabled. |
-| 8007 | Error| *<File name> * was not allowed to run.| Access to *<file name>* is restricted by the administrator. Applied only when the **Enforce rules** enforcement mode is set either directly or indirectly through Group Policy inheritance. The script or .msi file can't run.|
-| 8008| Error| AppLocker disabled on the SKU.| Added in Windows Server 2012 and Windows 8.|
-| 8020| Information| Packaged app allowed.| Added in Windows Server 2012 and Windows 8.|
-| 8021| Information| Packaged app audited.| Added in Windows Server 2012 and Windows 8.|
-| 8022| Information| Packaged app disabled.| Added in Windows Server 2012 and Windows 8.|
-| 8023 | Information| Packaged app installation allowed.| Added in Windows Server 2012 and Windows 8.|
-| 8024 | Information| Packaged app installation audited.| Added in Windows Server 2012 and Windows 8.|
-| 8025 | Warning| Packaged app installation disabled.| Added in Windows Server 2012 and Windows 8.|
-| 8027 | Warning| No Packaged app rule configured.| Added in Windows Server 2012 and Windows 8.|
-| 8028 | Warning | * was allowed to run but would have been prevented if the Config CI policy was enforced.| Added in Windows Server 2016 and Windows 10.|
-| 8029 | Error | * was prevented from running due to Config CI policy.| Added in Windows Server 2016 and Windows 10.|
+| 8006 | Warning| *<File name> * was allowed to run but would have been prevented from running if the AppLocker policy were enforced.| Applied only when the **Audit only** enforcement mode is enabled. Specifies that the script or .msi file would be blocked if the **Enforce rules** enforcement mode were enabled. |
+| 8007 | Error| *<File name> * was prevented from running.| Access to *<file name>* is restricted by the administrator. Applied only when the **Enforce rules** enforcement mode is set either directly or indirectly through Group Policy inheritance. The script or .msi file can't run.|
+| 8008| Warning| *<File name> *: AppLocker component not available on this SKU.| Added in Windows Server 2012 and Windows 8.|
+| 8020| Information| *<File name> * was allowed to run.| Added in Windows Server 2012 and Windows 8.|
+| 8021| Warning| *<File name> * was allowed to run but would have been prevented from running if the AppLocker policy were enforced.| Added in Windows Server 2012 and Windows 8.|
+| 8022| Error| *<File name> * was prevented from running.| Added in Windows Server 2012 and Windows 8.|
+| 8023 | Information| *<File name> * was allowed to be installed.| Added in Windows Server 2012 and Windows 8.|
+| 8024 | Warning| *<File name> * was allowed to run but would have been prevented from running if the AppLocker policy were enforced.| Added in Windows Server 2012 and Windows 8.|
+| 8025 | Error| *<File name> * was prevented from running.| Added in Windows Server 2012 and Windows 8.|
+| 8027 | Error| No packaged apps can be executed while Exe rules are being enforced and no Packaged app rules have been configured.| Added in Windows Server 2012 and Windows 8.|
+| 8028 | Warning | *<File name> * was allowed to run but would have been prevented if the Config CI policy were enforced.| Added in Windows Server 2016 and Windows 10.|
+| 8029 | Error | *<File name> * was prevented from running due to Config CI policy.| Added in Windows Server 2016 and Windows 10.|
| 8030 | Information | ManagedInstaller check SUCCEEDED during Appid verification of * | Added in Windows Server 2016 and Windows 10.|
| 8031 | Information | SmartlockerFilter detected file * being written by process * | Added in Windows Server 2016 and Windows 10.|
| 8032 | Error | ManagedInstaller check FAILED during Appid verification of * | Added in Windows Server 2016 and Windows 10.|
@@ -63,9 +63,9 @@ The following table contains information about the events that you can use to de
| 8034 | Information | ManagedInstaller Script check FAILED during Appid verification of * | Added in Windows Server 2016 and Windows 10.|
| 8035 | Error | ManagedInstaller Script check SUCCEEDED during Appid verification of * | Added in Windows Server 2016 and Windows 10.|
| 8036 | Error | * was prevented from running due to Config CI policy | Added in Windows Server 2016 and Windows 10.|
-| 8037 | Information | * passed Config CI policy and was allowed to run | Added in Windows Server 2016 and Windows 10.|
+| 8037 | Information | * passed Config CI policy and was allowed to run.| Added in Windows Server 2016 and Windows 10.|
| 8038 | Information | Publisher info: Subject: * Issuer: * Signature index * (* total) | Added in Windows Server 2016 and Windows 10.|
-| 8039 | Warning | * passed Config CI policy and was allowed to run | Added in Windows Server 2016 and Windows 10.|
+| 8039 | Warning | Package family name * version * was allowed to install or update but would have been prevented if the Config CI policy | Added in Windows Server 2016 and Windows 10.|
| 8040 | Error | Package family name * version * was prevented from installing or updating due to Config CI policy | Added in Windows Server 2016 and Windows 10.|
diff --git a/windows/security/application-security/application-control/windows-defender-application-control/design/microsoft-recommended-driver-block-rules.md b/windows/security/application-security/application-control/windows-defender-application-control/design/microsoft-recommended-driver-block-rules.md
index 398a529b8e..3eac346b20 100644
--- a/windows/security/application-security/application-control/windows-defender-application-control/design/microsoft-recommended-driver-block-rules.md
+++ b/windows/security/application-security/application-control/windows-defender-application-control/design/microsoft-recommended-driver-block-rules.md
@@ -81,7 +81,7 @@ To check that the policy was successfully applied on your computer:
```xml
- 10.0.25930.0
+ 10.0.25965.0
{2E07F7E4-194C-4D20-B7C9-6F44A6C5A234}
@@ -662,6 +662,10 @@ To check that the policy was successfully applied on your computer:
+
+
+
+
@@ -691,6 +695,90 @@ To check that the policy was successfully applied on your computer:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -889,6 +977,26 @@ To check that the policy was successfully applied on your computer:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -915,6 +1023,22 @@ To check that the policy was successfully applied on your computer:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -1171,6 +1295,56 @@ To check that the policy was successfully applied on your computer:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -1213,10 +1387,10 @@ To check that the policy was successfully applied on your computer:
-
+
-
+
@@ -1225,7 +1399,7 @@ To check that the policy was successfully applied on your computer:
-
+
@@ -1241,6 +1415,7 @@ To check that the policy was successfully applied on your computer:
+
@@ -1353,6 +1528,7 @@ To check that the policy was successfully applied on your computer:
+
@@ -1476,6 +1652,7 @@ To check that the policy was successfully applied on your computer:
+
@@ -1994,6 +2171,11 @@ To check that the policy was successfully applied on your computer:
+
+
+
+
+
@@ -2195,6 +2377,7 @@ To check that the policy was successfully applied on your computer:
+
@@ -2811,6 +2994,10 @@ To check that the policy was successfully applied on your computer:
+
+
+
+
@@ -2840,6 +3027,90 @@ To check that the policy was successfully applied on your computer:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -3039,6 +3310,26 @@ To check that the policy was successfully applied on your computer:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -3065,6 +3356,22 @@ To check that the policy was successfully applied on your computer:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -3325,6 +3632,56 @@ To check that the policy was successfully applied on your computer:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -3357,7 +3714,7 @@ To check that the policy was successfully applied on your computer:
- 10.0.25930.0
+ 10.0.25965.0
diff --git a/windows/security/application-security/application-control/windows-defender-application-control/design/select-types-of-rules-to-create.md b/windows/security/application-security/application-control/windows-defender-application-control/design/select-types-of-rules-to-create.md
index a5798f2f02..68d101d832 100644
--- a/windows/security/application-security/application-control/windows-defender-application-control/design/select-types-of-rules-to-create.md
+++ b/windows/security/application-security/application-control/windows-defender-application-control/design/select-types-of-rules-to-create.md
@@ -47,6 +47,7 @@ You can set several rule options within a WDAC policy. Table 1 describes each ru
| **18 Disabled:Runtime FilePath Rule Protection** | This option disables the default runtime check that only allows FilePath rules for paths that are only writable by an administrator.
NOTE: This option is only supported on Windows 10, version 1903 and later, or Windows Server 2022 and later. | Yes |
| **19 Enabled:Dynamic Code Security** | Enables policy enforcement for .NET applications and dynamically loaded libraries.
NOTE: This option is only supported on Windows 10, version 1803 and later, or Windows Server 2019 and later. | No |
| **20 Enabled:Revoked Expired As Unsigned** | Use this option to treat binaries signed with revoked certificates, or expired certificates with the Lifetime Signing EKU on the signature, as "Unsigned binaries" for user-mode process/components, under enterprise signing scenarios. | No |
+| **Enabled:Developer Mode Dynamic Code Trust** | Use this option to trust UWP apps that are [debugged in Visual Studio](/visualstudio/debugger/run-windows-store-apps-on-a-remote-machine) or deployed through device portal when Developer Mode is enabled on the system. | No |
## Windows Defender Application Control file rule levels
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/docfx.json b/windows/security/docfx.json
index 817a43769a..040348819b 100644
--- a/windows/security/docfx.json
+++ b/windows/security/docfx.json
@@ -65,7 +65,10 @@
"dstrome",
"v-dihans",
"garycentric",
- "beccarobins"
+ "beccarobins",
+ "Stacyrch140",
+ "v-stsavell",
+ "American-Dipper"
],
"searchScope": [
"Windows 10"
@@ -235,4 +238,4 @@
"dest": "security",
"markdownEngineName": "markdig"
}
-}
\ No newline at end of file
+}
diff --git a/windows/security/hardware-security/enable-virtualization-based-protection-of-code-integrity.md b/windows/security/hardware-security/enable-virtualization-based-protection-of-code-integrity.md
index 17cc685415..a3404e644a 100644
--- a/windows/security/hardware-security/enable-virtualization-based-protection-of-code-integrity.md
+++ b/windows/security/hardware-security/enable-virtualization-based-protection-of-code-integrity.md
@@ -49,8 +49,6 @@ To enable memory integrity on Windows devices with supporting hardware throughou
Beginning with Windows 11 22H2, **Windows Security** shows a warning if memory integrity is turned off. The warning indicator also appears on the Windows Security icon in the Windows Taskbar and in the Windows Notification Center. The user can dismiss the warning from within **Windows Security**.
-To proactively dismiss the memory integrity warning, you can set the **Hardware_HVCI_Off** (DWORD) registry value under `HKLM\SOFTWARE\Microsoft\Windows Security Health\State` to 0. After you change the registry value, you must restart the device for the change to take effect.
-
### Enable memory integrity using Intune
Enabling in Intune requires using the Code Integrity node in the [VirtualizationBasedTechnology CSP](/windows/client-management/mdm/policy-csp-virtualizationbasedtechnology). You can configure these settings by using the [settings catalog](/mem/intune/configuration/settings-catalog).
diff --git a/windows/security/hardware-security/how-hardware-based-root-of-trust-helps-protect-windows.md b/windows/security/hardware-security/how-hardware-based-root-of-trust-helps-protect-windows.md
index 077e6473de..d5451404d1 100644
--- a/windows/security/hardware-security/how-hardware-based-root-of-trust-helps-protect-windows.md
+++ b/windows/security/hardware-security/how-hardware-based-root-of-trust-helps-protect-windows.md
@@ -1,8 +1,8 @@
---
-title: How a Windows Defender System Guard helps protect Windows
-description: Windows Defender System Guard reorganizes the existing Windows system integrity features under one roof. Learn how it works.
+title: How Windows Defender System Guard helps protect Windows
+description: Learn how Windows Defender System Guard reorganizes the existing Windows system integrity features under one roof.
ms.localizationpriority: medium
-ms.date: 03/01/2019
+ms.date: 10/25/2023
ms.topic: conceptual
---
@@ -19,15 +19,11 @@ Windows Defender System Guard reorganizes the existing Windows system integrity
### Static Root of Trust for Measurement (SRTM)
-With Windows 7, one of the means attackers would use to persist and evade detection was to install what is often referred to as a bootkit or rootkit on the system.
-This malicious software would start before Windows started, or during the boot process itself, enabling it to start with the highest level of privilege.
+With Windows 7, one of the means attackers would use to persist and evade detection was to install what is often referred to as a bootkit or rootkit on the system. This malicious software would start before Windows started, or during the boot process itself, enabling it to start with the highest level of privilege.
-With Windows 10 running on modern hardware (that is, Windows 8-certified or greater) a hardware-based root of trust helps ensure that no unauthorized firmware or software (such as a bootkit) can start before the Windows bootloader.
-This hardware-based root of trust comes from the device's Secure Boot feature, which is part of the Unified Extensible Firmware Interface (UEFI).
-This technique of measuring the static early boot UEFI components is called the Static Root of Trust for Measurement (SRTM).
+With Windows 10 running on modern hardware, a hardware-based root of trust helps ensure that no unauthorized firmware or software (such as a bootkit) can start before the Windows bootloader. This hardware-based root of trust comes from the device's Secure Boot feature, which is part of the Unified Extensible Firmware Interface (UEFI). This technique of measuring the static early boot UEFI components is called the Static Root of Trust for Measurement (SRTM).
-As there are thousands of PC vendors that produce many models with different UEFI BIOS versions, there becomes an incredibly large number of SRTM measurements upon bootup.
-Two techniques exist to establish trust here—either maintain a list of known 'bad' SRTM measurements (also known as a blocklist), or a list of known 'good' SRTM measurements (also known as an allowlist).
+As there are thousands of PC vendors that produce many models with different UEFI BIOS versions, there becomes an incredibly large number of SRTM measurements upon bootup. Two techniques exist to establish trust here—either maintain a list of known 'bad' SRTM measurements (also known as a blocklist), or a list of known 'good' SRTM measurements (also known as an allowlist).
Each option has a drawback:
@@ -37,9 +33,7 @@ Also, a bug fix for UEFI code can take a long time to design, build, retest, val
### Secure Launch—the Dynamic Root of Trust for Measurement (DRTM)
-[Windows Defender System Guard Secure Launch](system-guard-secure-launch-and-smm-protection.md), first introduced in Windows 10 version 1809, aims to alleviate these issues by leveraging a technology known as the Dynamic Root of Trust for Measurement (DRTM).
-DRTM lets the system freely boot into untrusted code initially, but shortly after launches the system into a trusted state by taking control of all CPUs and forcing them down a well-known and measured code path.
-This has the benefit of allowing untrusted early UEFI code to boot the system, but then being able to securely transition into a trusted and measured state.
+[Windows Defender System Guard Secure Launch](system-guard-secure-launch-and-smm-protection.md), first introduced in Windows 10 version 1809, aims to alleviate these issues by leveraging a technology known as the Dynamic Root of Trust for Measurement (DRTM). DRTM lets the system freely boot into untrusted code initially, but shortly after launches the system into a trusted state by taking control of all CPUs and forcing them down a well-known and measured code path. This has the benefit of allowing untrusted early UEFI code to boot the system, but then being able to securely transition into a trusted and measured state.
@@ -47,9 +41,7 @@ Secure Launch simplifies management of SRTM measurements because the launch code
### System Management Mode (SMM) protection
-System Management Mode (SMM) is a special-purpose CPU mode in x86 microcontrollers that handles power management, hardware configuration, thermal monitoring, and anything else the manufacturer deems useful.
-Whenever one of these system operations is requested, a non-maskable interrupt (SMI) is invoked at runtime, which executes SMM code installed by the BIOS.
-SMM code executes in the highest privilege level and is invisible to the OS, which makes it an attractive target for malicious activity. Even if System Guard Secure Launch is used to late launch, SMM code can potentially access hypervisor memory and change the hypervisor.
+System Management Mode (SMM) is a special-purpose CPU mode in x86 microcontrollers that handles power management, hardware configuration, thermal monitoring, and anything else the manufacturer deems useful. Whenever one of these system operations is requested, a non-maskable interrupt (SMI) is invoked at runtime, which executes SMM code installed by the BIOS. SMM code executes in the highest privilege level and is invisible to the OS, which makes it an attractive target for malicious activity. Even if System Guard Secure Launch is used to late launch, SMM code can potentially access hypervisor memory and change the hypervisor.
To defend against this, two techniques are used:
@@ -60,14 +52,13 @@ Paging protection can be implemented to lock certain code tables to be read-only
A hardware-enforced processor feature known as a supervisor SMI handler can monitor the SMM and make sure it doesn't access any part of the address space that it isn't supposed to.
-SMM protection is built on top of the Secure Launch technology and requires it to function.
-In the future, Windows 10 will also measure this SMI Handler's behavior and attest that no OS-owned memory has been tampered with.
+SMM protection is built on top of the Secure Launch technology and requires it to function. In the future, Windows 10 will also measure this SMI Handler's behavior and attest that no OS-owned memory has been tampered with.
## Validating platform integrity after Windows is running (run time)
While Windows Defender System Guard provides advanced protection that will help protect and maintain the integrity of the platform during boot and at run time, the reality is that we must apply an "assume breach" mentality to even our most sophisticated security technologies. We can trust that the technologies are successfully doing their jobs, but we also need the ability to verify that they were successful in achieving their goals. For platform integrity, we can't just trust the platform, which potentially could be compromised, to self-attest to its security state. So Windows Defender System Guard includes a series of technologies that enable remote analysis of the device's integrity.
-As Windows 10 boots, a series of integrity measurements are taken by Windows Defender System Guard using the device's Trusted Platform Module 2.0 (TPM 2.0). System Guard Secure Launch won't support earlier TPM versions, such as TPM 1.2. This process and data are hardware-isolated away from Windows to help ensure that the measurement data isn't subject to the type of tampering that could happen if the platform was compromised. From here, the measurements can be used to determine the integrity of the device's firmware, hardware configuration state, and Windows boot-related components, just to name a few.
+As Windows boots, a series of integrity measurements are taken by Windows Defender System Guard using the device's Trusted Platform Module 2.0 (TPM 2.0). System Guard Secure Launch doesn't support earlier TPM versions, such as TPM 1.2. This process and data are hardware-isolated away from Windows to help ensure that the measurement data isn't subject to the type of tampering that could happen if the platform was compromised. From here, the measurements can be used to determine the integrity of the device's firmware, hardware configuration state, and Windows boot-related components, to name a few.
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/considerations-known-issues.md b/windows/security/identity-protection/credential-guard/considerations-known-issues.md
index 26ee36124b..dbf52336f8 100644
--- a/windows/security/identity-protection/credential-guard/considerations-known-issues.md
+++ b/windows/security/identity-protection/credential-guard/considerations-known-issues.md
@@ -209,19 +209,6 @@ The following issue affects the Java GSS API. See the following Oracle bug datab
When Credential Guard is enabled on Windows, the Java GSS API doesn't authenticate. Credential Guard blocks specific application authentication capabilities and doesn't provide the TGT session key to applications, regardless of registry key settings. For more information, see [Application requirements](index.md#application-requirements).
-The following issue affects McAfee Application and Change Control (MACC):
-
-- [KB88869 Windows machines exhibit high CPU usage with McAfee Application and Change Control (MACC) installed when Credential Guard is enabled](https://kcm.trellix.com/corporate/index?page=content&id=KB88869)
-
-The following issue affects Citrix applications:
-
-- Windows machines exhibit high CPU usage with Citrix applications installed when Credential Guard is enabled.
-
-> [!NOTE]
-> Products that connect to Virtualization Based Security (VBS) protected processes can cause Credential Guard-enabled devices to exhibit high CPU usage. For technical and troubleshooting information, see [KB4032786 High CPU usage in the LSAISO process on Windows](/troubleshoot/windows-client/performance/lsaiso-process-high-cpu-usage).
->
-> For more technical information on LSAISO.exe, see [Isolated User Mode (IUM) Processes](/windows/win32/procthread/isolated-user-mode--ium--processes).
-
#### Vendor support
The following products and services don't support Credential Guard:
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..661971662b 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,27 +170,27 @@ 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".
> [!NOTE]
- > 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. For more information, see [What is a Primary Refresh Token](/azure/active-directory/devices/concept-primary-refresh-token#when-does-a-prt-get-an-mfa-claim).
+ > 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. For more information, see [What is a Primary Refresh Token](/azure/active-directory/devices/concept-primary-refresh-token#when-does-a-prt-get-an-mfa-claim).
- question: Which is a better or more secure for of authentication, key or certificate?
answer: |
Both types of authentication provide the same security; one is not more secure than the other.
@@ -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 ab35e717f2..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":::
@@ -70,7 +72,7 @@ To register the applications, follow these steps:
:::column span="3":::
3. Review the permissions requested by the *Microsoft Pin Reset Service Production* application and select **Accept** to confirm consent to both applications to access your organization.
>[!NOTE]
- >After accepance, the redirect page will show a blank page. This is a known behavior.
+ >After acceptance, the redirect page will show a blank page. This is a known behavior.
:::column-end:::
:::column span="1":::
:::image type="content" alt-text="Screenshot showing the PIN reset service permissions final page." source="images/pinreset/pin-reset-service-prompt-2.png" lightbox="images/pinreset/pin-reset-service-prompt-2.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..af0ff0de5a 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..a0a36f2cc0 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 Microsoft Entra ID.\
+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 663d6662dc..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,19 +39,19 @@ 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
The table shows the minimum requirements for each deployment.
-| Key trust
Group Policy managed | Certificate trust
Group Policy managed|
-| --- | --- |
-|Any supported Windows client versions|Any supported Windows client versions|
-| Windows Server 2016 Schema | Windows Server 2016 Schema|
-| Windows Server 2008 R2 Domain/Forest functional level | Windows Server 2008 R2 Domain/Forest functional level |
-| Any supported Windows Server versions | Any supported Windows Server versions |
-| Any supported Windows Server versions | Any supported Windows Server versions |
-| Any supported Windows Server versions | Any supported Windows Server versions |
-| AD FS with 3rd Party MFA Adapter | AD FS with 3rd Party MFA Adapter |
\ No newline at end of file
+| Requirement | Key trust
Group Policy managed | Certificate trust
Group Policy managed|
+| --- | --- | ---|
+| **Windows Version** | Any supported Windows client versions|Any supported Windows client versions|
+| **Schema Version**| Windows Server 2016 Schema | Windows Server 2016 Schema|
+| **Domain and Forest Functional Level**| Windows Server 2008 R2 Domain/Forest functional level | Windows Server 2008 R2 Domain/Forest functional level |
+| **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 |
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/security/identity-protection/hello-for-business/hello-planning-guide.md b/windows/security/identity-protection/hello-for-business/hello-planning-guide.md
index 8375e0ebd3..e12ac5c2e7 100644
--- a/windows/security/identity-protection/hello-for-business/hello-planning-guide.md
+++ b/windows/security/identity-protection/hello-for-business/hello-planning-guide.md
@@ -6,7 +6,7 @@ ms.topic: overview
---
# Planning a Windows Hello for Business Deployment
-Congratulations! You are taking the first step forward in helping move your organizations away from password to a two-factor, convenience authentication for Windows — Windows Hello for Business. This planning guide helps you understand the different topologies, architectures, and components that encompass a Windows Hello for Business infrastructure.
+Congratulations! You're taking the first step forward in helping move your organizations away from password to a two-factor, convenience authentication for Windows — Windows Hello for Business. This planning guide helps you understand the different topologies, architectures, and components that encompass a Windows Hello for Business infrastructure.
This guide explains the role of each component within Windows Hello for Business and how certain deployment decisions affect other aspects of the infrastructure. Armed with your planning worksheet, you'll use that information to select the correct deployment guide for your needs.
@@ -15,7 +15,7 @@ This guide explains the role of each component within Windows Hello for Business
## Using this guide
-There are many options from which you can choose when deploying Windows Hello for Business. Providing multiple options ensures nearly every organization can deploy Windows Hello for Business. Providing many options makes the deployment appear complex, however, most organization will realize they've already implemented most of the infrastructure on which the Windows Hello for Business deployment depends. It is important to understand that Windows Hello for Business is a distributed system and does take proper planning across multiple teams within an organization.
+There are many options from which you can choose when deploying Windows Hello for Business. Providing multiple options ensures nearly every organization can deploy Windows Hello for Business. Providing many options makes the deployment appear complex, however, most organization will realize they've already implemented most of the infrastructure on which the Windows Hello for Business deployment depends. It's important to understand that Windows Hello for Business is a distributed system and does take proper planning across multiple teams within an organization.
This guide removes the appearance of complexity by helping you make decisions on each aspect of your Windows Hello for Business deployment and the options you'll need to consider. Using this guide also identifies the information needed to help you make decisions about the deployment that best suits your environment. Download the [Windows Hello for Business planning worksheet](https://go.microsoft.com/fwlink/?linkid=852514) from the Microsoft Download Center to help track your progress and make your planning easier.
@@ -52,9 +52,9 @@ The cloud only deployment model is for organizations who only have cloud identit
The hybrid deployment model is for organizations that:
-- Are federated with Azure Active Directory
-- Have identities synchronized to Azure Active Directory using Azure Active Directory Connect
-- Use applications hosted in Azure Active Directory, and want a single sign-in user experience for both on-premises and Azure Active Directory resources
+- Are federated with Microsoft Entra ID
+- Have identities synchronized to Microsoft Entra ID using Microsoft Entra Connect
+- Use applications hosted in Microsoft Entra ID, and want a single sign-in user experience for both on-premises and Microsoft Entra resources
> [!Important]
> Hybrid deployments support non-destructive PIN reset that works with both the certificate trust and key trust models.
@@ -64,7 +64,7 @@ The hybrid deployment model is for organizations that:
> - Reset above lock screen (_I forgot my PIN_ link) - Windows 10, version 1903
##### On-premises
-The on-premises deployment model is for organizations that do not have cloud identities or use applications hosted in Azure Active Directory.
+The on-premises deployment model is for organizations that do not have cloud identities or use applications hosted in Microsoft Entra ID.
> [!Important]
> On-premises deployments support destructive PIN reset that works with both the certificate trust and the key trust models.
@@ -81,9 +81,9 @@ It's fundamentally important to understand which deployment model to use for a s
A deployment's trust type defines how each Windows Hello for Business client authenticates to the on-premises Active Directory. There are two trust types: key trust and certificate trust.
> [!NOTE]
-> Windows Hello for Business introduced a new trust model called cloud Kerberos trust, in early 2022. This model enables deployment of Windows Hello for Business 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). For more information, see [Hybrid Cloud Kerberos Trust Deployment](hello-hybrid-cloud-kerberos-trust.md).
+> Windows Hello for Business introduced a new trust model called cloud Kerberos trust, in early 2022. This model enables deployment of Windows Hello for Business 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). For more information, see [Hybrid Cloud Kerberos Trust Deployment](hello-hybrid-cloud-kerberos-trust.md).
-The key trust type does not require issuing authentication certificates to end users. Users authenticate using a hardware-bound key created during the built-in provisioning experience. This requires an adequate distribution of Windows Server 2016 or later domain controllers relative to your existing authentication and the number of users included in your Windows Hello for Business deployment. Read the [Planning an adequate number of Windows Server 2016 or later Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) to learn more.
+The key trust type doesn't require issuing authentication certificates to end users. Users authenticate using a hardware-bound key created during the built-in provisioning experience. This requires an adequate distribution of Windows Server 2016 or later domain controllers relative to your existing authentication and the number of users included in your Windows Hello for Business deployment. Read the [Planning an adequate number of Windows Server 2016 or later Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) to learn more.
The certificate trust type issues authentication certificates to end users. Users authenticate using a certificate requested using a hardware-bound key created during the built-in provisioning experience. Unlike key trust, certificate trust does not require Windows Server 2016 domain controllers (but still requires [Windows Server 2016 or later Active Directory schema](/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust#directories)). Users can use their certificate to authenticate to any Windows Server 2008 R2, or later, domain controller.
@@ -92,33 +92,33 @@ The certificate trust type issues authentication certificates to end users. Use
#### Device registration
-All devices included in the Windows Hello for Business deployment must go through device registration. Device registration enables devices to authenticate to identity providers. For cloud only and hybrid deployment, the identity provider is Azure Active Directory. For on-premises deployments, the identity provider is the on-premises server running the Windows Server 2016 Active Directory Federation Services (AD FS) role.
+All devices included in the Windows Hello for Business deployment must go through device registration. Device registration enables devices to authenticate to identity providers. For cloud only and hybrid deployment, the identity provider is Microsoft Entra ID. For on-premises deployments, the identity provider is the on-premises server running the Windows Server 2016 Active Directory Federation Services (AD FS) role.
#### Key registration
-The built-in Windows Hello for Business provisioning experience creates a hardware bound asymmetric key pair as their user's credentials. The private key is protected by the device's security modules; however, the credential is a user key (not a device key). The provisioning experience registers the user's public key with the identity provider. For cloud only and hybrid deployments, the identity provider is Azure Active Directory. For on-premises deployments, the identity provider is the on-premises server running Windows Server 2016 Active Directory Federation Services (AD FS) role.
+The built-in Windows Hello for Business provisioning experience creates a hardware bound asymmetric key pair as their user's credentials. The private key is protected by the device's security modules; however, the credential is a user key (not a device key). The provisioning experience registers the user's public key with the identity provider. For cloud only and hybrid deployments, the identity provider is Microsoft Entra ID. For on-premises deployments, the identity provider is the on-premises server running Windows Server 2016 Active Directory Federation Services (AD FS) role.
#### Multifactor authentication
> [!IMPORTANT]
-> As of July 1, 2019, Microsoft will no longer offer MFA Server for new deployments. New customers who require multi-factor authentication for their users should use cloud-based Azure AD Multi-Factor Authentication. Existing customers who have activated MFA Server prior to July 1, 2019 will be able to download the latest version, future updates and generate activation credentials as usual. See [Getting started with the Azure AD Multi-Factor Authentication Server](/azure/active-directory/authentication/howto-mfaserver-deploy) for more details.
+> As of July 1, 2019, Microsoft will no longer offer MFA Server for new deployments. New customers who require multifactor authentication for their users should use cloud-based Microsoft Entra multifactor authentication. Existing customers who have activated MFA Server prior to July 1, 2019 will be able to download the latest version, future updates and generate activation credentials as usual. See [Getting started with the Azure Multi-Factor Authentication Server](/azure/active-directory/authentication/howto-mfaserver-deploy) for more details.
-The goal of Windows Hello for Business is to move organizations away from passwords by providing them a strong credential that provides easy two-factor authentication. The built-in provisioning experience accepts the user's weak credentials (username and password) as the first factor authentication; however, the user must provide a second factor of authentication before Windows provisions a strong credential.
+The goal of Windows Hello for Business is to move organizations away from passwords by providing them a with strong credential that provides easy two-factor authentication. The built-in provisioning experience accepts the user's weak credentials (username and password) as the first factor authentication; however, the user must provide a second factor of authentication before Windows provisions a strong credential.
-Cloud only and hybrid deployments provide many choices for multi-factor authentication. On-premises deployments must use a multi-factor authentication that provides an AD FS multi-factor adapter to be used in conjunction with the on-premises Windows Server 2016 AD FS server role. Organizations can use the on-premises Azure AD Multi-Factor Authentication server, or choose from several third parties (Read [Microsoft and third-party additional authentication methods](/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs#microsoft-and-third-party-additional-authentication-methods) for more information).
+Cloud only and hybrid deployments provide many choices for multifactor authentication. On-premises deployments must use a multifactor authentication that provides an AD FS multifactor adapter to be used in conjunction with the on-premises Windows Server 2016 AD FS server role. Organizations can use the on-premises Azure Multi-Factor Authentication Server, or choose from several third parties (Read [Microsoft and third-party additional authentication methods](/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs#microsoft-and-third-party-additional-authentication-methods) for more information).
> [!NOTE]
-> Azure AD Multi-Factor Authentication is available through:
+> Microsoft Entra multifactor authentication is available through:
> * Microsoft Enterprise Agreement
> * Open Volume License Program
> * Cloud Solution Providers program
> * Bundled with
-> * Azure Active Directory Premium
+> * Microsoft Entra ID P1 or P2
> * Enterprise Mobility Suite
> * Enterprise Cloud Suite
#### Directory synchronization
-Hybrid and on-premises deployments use directory synchronization, however, each for a different purpose. Hybrid deployments use Azure Active Directory Connect to synchronize Active Directory identities or credentials between itself and Azure Active Directory. This helps enable single sign-on to Azure Active Directory and its federated components. On-premises deployments use directory synchronization to import users from Active Directory to the Azure MFA Server, which sends data to the Azure MFA cloud service to perform the verification.
+Hybrid and on-premises deployments use directory synchronization, however, each for a different purpose. Hybrid deployments use Microsoft Entra Connect to synchronize Active Directory identities or credentials between itself and Microsoft Entra ID. This helps enable single sign-on to Microsoft Entra ID and its federated components. On-premises deployments use directory synchronization to import users from Active Directory to the Azure MFA Server, which sends data to the Azure MFA cloud service to perform the verification.
### Management
@@ -136,7 +136,7 @@ Modern management is an emerging device management paradigm that leverages the c
Windows Hello for Business is an exclusive Windows 10 and Windows 11 feature. As part of the Windows as a Service strategy, Microsoft has improved the deployment, management, and user experience with each new release of Windows and introduced support for new scenarios.
-Most deployment scenarios require a minimum of Windows 10, version 1511, also known as the November Update. The client requirement may change based on different components in your existing infrastructure, or other infrastructure choices made later in planning your deployment. Those components and choices may require a minimum client running Windows 10, version 1703, also known as the Creators Update.
+Most deployment scenarios require a minimum of Windows 10, version 1511, also known as the November Update. The client requirement might change based on different components in your existing infrastructure, or other infrastructure choices made later in planning your deployment. Those components and choices might require a minimum client running Windows 10, version 1703, also known as the Creators Update.
### Active Directory
@@ -145,11 +145,11 @@ Hybrid and on-premises deployments include Active Directory as part of their inf
### Public Key Infrastructure
-The Windows Hello for Business deployment depends on an enterprise public key infrastructure as a trust anchor for authentication. Domain controllers for hybrid and on-premises deployments need a certificate in order for Windows devices to trust the domain controller as legitimate. Deployments using the certificate trust type need an enterprise public key infrastructure and a certificate registration authority to issue authentication certificates to users. Hybrid deployments may need to issue VPN certificates to users to enable connectivity on-premises resources.
+The Windows Hello for Business deployment depends on an enterprise public key infrastructure as a trust anchor for authentication. Domain controllers for hybrid and on-premises deployments need a certificate in order for Windows devices to trust the domain controller as legitimate. Deployments using the certificate trust type need an enterprise public key infrastructure and a certificate registration authority to issue authentication certificates to users. Hybrid deployments might need to issue VPN certificates to users to enable connectivity on-premises resources.
### Cloud
-Some deployment combinations require an Azure account, and some require Azure Active Directory for user identities. These cloud requirements may only need an Azure account while other features need an Azure Active Directory Premium subscription. The planning process identifies and differentiates the components that are needed from those that are optional.
+Some deployment combinations require an Azure account, and some require Microsoft Entra ID for user identities. These cloud requirements may only need an Azure account while other features need a Microsoft Entra ID P1 or P2 subscription. The planning process identifies and differentiates the components that are needed from those that are optional.
## Planning a Deployment
@@ -173,13 +173,13 @@ If your organization does not have cloud resources, write **On-Premises** in box
### Trust type
-Hybrid Azure AD-joined devices managed by Group Policy need the Windows Server 2016 AD FS role to issue certificates. Hybrid Azure AD-joined devices and Azure AD-joined devices managed by Intune or a compatible MDM need the Windows Server NDES server role to issue certificates.
+Microsoft Entra hybrid joined devices managed by Group Policy need the Windows Server 2016 AD FS role to issue certificates. Microsoft Entra hybrid joined devices and Microsoft Entra joined devices managed by Intune or a compatible MDM need the Windows Server NDES server role to issue certificates.
Choose a trust type that is best suited for your organizations. Remember, the trust type determines two things. Whether you issue authentication certificates to your users and if your deployment needs Windows Server 2016 domain controllers.
One trust model is not more secure than the other. The major difference is based on the organization comfort with deploying Windows Server 2016 domain controllers and not enrolling users with end entity certificates (key-trust) against using existing domain controllers and needing to enroll certificates for all their users (certificate trust).
-Because the certificate trust types issues certificates, there is more configuration and infrastructure needed to accommodate user certificate enrollment, which could also be a factor to consider in your decision. Additional infrastructure needed for certificate-trust deployments includes a certificate registration authority. In a federated environment, you need to activate the Device Writeback option in Azure AD Connect.
+Because the certificate trust types issues certificates, there is more configuration and infrastructure needed to accommodate user certificate enrollment, which could also be a factor to consider in your decision. Additional infrastructure needed for certificate-trust deployments includes a certificate registration authority. In a federated environment, you need to activate the Device Writeback option in Microsoft Entra Connect.
If your organization wants to use the key trust type, write **key trust** in box **1b** on your planning worksheet. Write **Windows Server 2016** in box **4d**. Write **N/A** in box **5b**.
@@ -203,17 +203,17 @@ If box **1a** on your planning worksheet reads **on-premises**, write **AD FS**
### Directory Synchronization
-Windows Hello for Business is strong user authentication, which usually means there is an identity (a user or username) and a credential (typically a key pair). Some operations require writing or reading user data to or from the directory. For example, reading the user's phone number to perform multi-factor authentication during provisioning or writing the user's public key.
+Windows Hello for Business is strong user authentication, which usually means there is an identity (a user or username) and a credential (typically a key pair). Some operations require writing or reading user data to or from the directory. For example, reading the user's phone number to perform multifactor authentication during provisioning or writing the user's public key.
-If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **1e**. User information is written directly to Azure Active Directory and there is not another directory with which the information must be synchronized.
+If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **1e**. User information is written directly to Microsoft Entra ID and there is not another directory with which the information must be synchronized.
-If box **1a** on your planning worksheet reads **hybrid**, then write **Azure AD Connect** in box **1e** on your planning worksheet.
+If box **1a** on your planning worksheet reads **hybrid**, then write **Microsoft Entra Connect** in box **1e** on your planning worksheet.
-If box **1a** on your planning worksheet reads **on-premises**, then write **Azure MFA Server**. This deployment exclusively uses Active Directory for user information with the exception of the multi-factor authentication. The on-premises Azure MFA server synchronizes a subset of the user information, such as phone number, to provide multi-factor authentication while the user's credentials remain on the on-premises network.
+If box **1a** on your planning worksheet reads **on-premises**, then write **Azure MFA Server**. This deployment exclusively uses Active Directory for user information with the exception of the multifactor authentication. The on-premises Azure MFA server synchronizes a subset of the user information, such as phone number, to provide multifactor authentication while the user's credentials remain on the on-premises network.
-### Multifactor Authentication
+### Multifactor authentication
-The goal of Windows Hello for Business is to move user authentication away from passwords to a strong, key-based user authentication. Passwords are weak credentials and cannot be trusted by themselves as an attacker with a stolen password could be attempting to enroll in Windows Hello for Business. To keep the transition from a weak to a strong credential secure, Windows Hello for Business relies on multi-factor authentication during provisioning to have some assurances that the user identity provisioning a Windows Hello for Business credential is the proper identity.
+The goal of Windows Hello for Business is to move user authentication away from passwords to a strong, key-based user authentication. Passwords are weak credentials and cannot be trusted by themselves as an attacker with a stolen password could be attempting to enroll in Windows Hello for Business. To keep the transition from a weak to a strong credential secure, Windows Hello for Business relies on multifactor authentication during provisioning to have some assurances that the user identity provisioning a Windows Hello for Business credential is the proper identity.
If box **1a** on your planning worksheet reads **cloud only**, then your only option is to use the Azure MFA cloud service. Write **Azure MFA** in box **1f** on your planning worksheet.
@@ -225,7 +225,7 @@ If box **1a** on your planning worksheet reads **hybrid**, then you have a few o
You can directly use the Azure MFA cloud service for the second factor of authentication. Users contacting the service must authenticate to Azure prior to using the service.
-If your Azure AD Connect is configured to synchronize identities (usernames only), then your users are redirected to your local on-premises federation server for authentication and then redirected back to the Azure MFA cloud service. Otherwise, your Azure AD Connect is configured to synchronize credentials (username and passwords), which enables your users to authenticate to Azure Active Directory and use the Azure MFA cloud service. If you choose to use the Azure MFA cloud service directly, write **Azure MFA** in box **1f** on your planning worksheet.
+If your Microsoft Entra Connect is configured to synchronize identities (usernames only), then your users are redirected to your local on-premises federation server for authentication and then redirected back to the Azure MFA cloud service. Otherwise, your Microsoft Entra Connect is configured to synchronize credentials (username and passwords), which enables your users to authenticate to Microsoft Entra ID and use the Azure MFA cloud service. If you choose to use the Azure MFA cloud service directly, write **Azure MFA** in box **1f** on your planning worksheet.
You can configure your on-premises Windows Server 2016 AD FS role to use the Azure MFA service adapter. In this configuration, users are redirected to the on premises AD FS server (synchronizing identities only). The AD FS server uses the MFA adapter to communicate to the Azure MFA service to perform the second factor of authentication. If you choose to use AD FS with the Azure MFA cloud service adapter, write **AD FS with Azure MFA cloud adapter** in box **1f** on your planning worksheet.
@@ -241,10 +241,10 @@ If you choose to use AD FS with the Azure MFA server adapter, write **AD FS with
Windows Hello for Business provides organizations with many policy settings and granular control on how these settings may be applied to both computers and users. The type of policy management you can use depends on your selected deployment and trust models.
-If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **2a** on your planning worksheet. You have the option to manage non-domain joined devices. If you choose to manage Azure Active Directory-joined devices, write **modern management** in box **2b** on your planning worksheet. Otherwise, write** N/A** in box **2b**.
+If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **2a** on your planning worksheet. You have the option to manage non-domain joined devices. If you choose to manage Microsoft Entra joined devices, write **modern management** in box **2b** on your planning worksheet. Otherwise, write** N/A** in box **2b**.
> [!NOTE]
-> Azure Active Directory-joined devices without modern management automatically enroll in Windows Hello for Business using the default policy settings. Use modern management to adjust policy settings to match the business needs of your organization.
+> Microsoft Entra joined devices without modern management automatically enroll in Windows Hello for Business using the default policy settings. Use modern management to adjust policy settings to match the business needs of your organization.
If box **1a** on your planning worksheet reads **on-prem**, write **GP** in box **2a** on your planning worksheet. Write **N/A** in box **2b** on your worksheet.
@@ -260,7 +260,7 @@ Windows Hello for Business is a feature exclusive to Windows 10 and Windows 11.
If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **3a** on your planning worksheet. Optionally, you may write **1511 or later** in box **3b** on your planning worksheet if you plan to manage non-domain joined devices.
> [!NOTE]
-> Azure Active Directory-joined devices without modern management automatically enroll in Windows Hello for Business using the default policy settings. Use modern management to adjust policy settings to match the business needs of your organization.
+> Microsoft Entra joined devices without modern management automatically enroll in Windows Hello for Business using the default policy settings. Use modern management to adjust policy settings to match the business needs of your organization.
Write **1511 or later** in box **3a** on your planning worksheet if any of the following are true.
* Box **2a** on your planning worksheet read **modern management**.
@@ -288,7 +288,7 @@ If box **1a** on your planning worksheet reads **cloud only**, ignore the public
If box **1b** on your planning worksheet reads **key trust**, write **N/A** in box **5b** on your planning worksheet. Key trust doesn't require any change in public key infrastructure, skip this part and go to **Cloud** section.
-The registration authority only relates to certificate trust deployments and the management used for domain and non-domain joined devices. Hybrid Azure AD-joined devices managed by Group Policy need the Windows Server 2016 AD FS role to issue certificates. Hybrid Azure AD-joined devices and Azure AD-joined devices managed by Intune or a compatible MDM need the Windows Server NDES server role to issue certificates.
+The registration authority only relates to certificate trust deployments and the management used for domain and non-domain joined devices. Microsoft Entra hybrid joined devices managed by Group Policy need the Windows Server 2016 AD FS role to issue certificates. Microsoft Entra hybrid joined devices and Microsoft Entra joined devices managed by Intune or a compatible MDM need the Windows Server NDES server role to issue certificates.
If box **2a** reads **GP** and box **2b** reads **modern management**, write **AD FS RA and NDES** in box **5b** on your planning worksheet. In box **5c**, write the following certificate templates names and issuances:
@@ -323,18 +323,18 @@ If box **1a** on your planning worksheet reads **cloud only** or **hybrid**, wri
If box **1a** on your planning worksheet reads **on-premises**, and box **1f** reads **AD FS with third party**, write **No** in box **6a** on your planning worksheet. Otherwise, write **Yes** in box **6a** as you need an Azure account for per-consumption MFA billing. Write **No** in box **6b** on your planning worksheet—on-premises deployments do not use the cloud directory.
-Windows Hello for Business does not require an Azure AD premium subscription. However, some dependencies, such as [MDM automatic enrollment](/mem/intune/enrollment/quickstart-setup-auto-enrollment) and [Conditional Access](/azure/active-directory/conditional-access/overview) do.
+Windows Hello for Business does not require a Microsoft Entra ID P1 or P2 subscription. However, some dependencies, such as [MDM automatic enrollment](/mem/intune/enrollment/quickstart-setup-auto-enrollment) and [Conditional Access](/azure/active-directory/conditional-access/overview) do.
If box **1a** on your planning worksheet reads **on-premises**, write **No** in box **6c** on your planning worksheet.
-If box **1a** on your planning worksheet reads **hybrid** and box **1b** reads **key trust**, write **No** in box **6c** on your planning worksheet. You can deploy Windows Hello for Business using the Azure Active Directory free tier. All Azure Active Directory free accounts can use Azure AD Multi-Factor Authentication through the use of security defaults. Some Azure AD Multi-Factor Authentication features require a license. For more details, see [Features and licenses for Azure AD Multi-Factor Authentication](/azure/active-directory/authentication/concept-mfa-licensing).
+If box **1a** on your planning worksheet reads **hybrid** and box **1b** reads **key trust**, write **No** in box **6c** on your planning worksheet. You can deploy Windows Hello for Business using the Microsoft Entra ID Free tier. All Microsoft Entra ID Free accounts can use Microsoft Entra multifactor authentication through the use of security defaults. Some Microsoft Entra multifactor authentication features require a license. For more details, see [Features and licenses for Microsoft Entra multifactor authentication](/azure/active-directory/authentication/concept-mfa-licensing).
-If box **5b** on your planning worksheet reads **AD FS RA**, write **Yes** in box **6c** on your planning worksheet. Enrolling a certificate using the AD FS registration authority requires devices to authenticate to the AD FS server, which requires device write-back, an Azure AD Premium feature.
+If box **5b** on your planning worksheet reads **AD FS RA**, write **Yes** in box **6c** on your planning worksheet. Enrolling a certificate using the AD FS registration authority requires devices to authenticate to the AD FS server, which requires device write-back, a Microsoft Entra ID P1 or P2 feature.
-Modern managed devices do not require an Azure AD premium subscription. By forgoing the subscription, your users must manually enroll devices in the modern management software, such as Intune or a supported third-party MDM.
+Modern managed devices do not require a Microsoft Entra ID P1 or P2 subscription. By forgoing the subscription, your users must manually enroll devices in the modern management software, such as Intune or a supported third-party MDM.
If boxes **2a** or **2b** read **modern management** and you want devices to automatically enroll in your modern management software, write **Yes** in box **6c** on your planning worksheet. Otherwise, write **No** in box **6c**.
## Congratulations, You're Done
-Your Windows Hello for Business planning worksheet should be complete. This guide provided understanding of the components used in the Windows Hello for Business infrastructure and rationalization of why they are used. The worksheet gives you an overview of the requirements needed to continue the next phase of the deployment. With this worksheet, you'll be able to identify key elements of your Windows Hello for Business deployment.
+Your Windows Hello for Business planning worksheet should be complete. This guide provided understanding of the components used in the Windows Hello for Business infrastructure and rationalization of why they're used. The worksheet gives you an overview of the requirements needed to continue the next phase of the deployment. With this worksheet, you'll be able to identify key elements of your Windows Hello for Business deployment.
diff --git a/windows/security/identity-protection/hello-for-business/hello-prepare-people-to-use.md b/windows/security/identity-protection/hello-for-business/hello-prepare-people-to-use.md
index 96c1df3462..87cd5f6ea5 100644
--- a/windows/security/identity-protection/hello-for-business/hello-prepare-people-to-use.md
+++ b/windows/security/identity-protection/hello-for-business/hello-prepare-people-to-use.md
@@ -10,7 +10,7 @@ When you set a policy to require Windows Hello for Business in the workplace, yo
After enrollment in Hello, users should use their gesture (such as a PIN or fingerprint) for access to corporate resources. Their gesture is only valid on the enrolled device.
-Although the organization may require users to change their Active Directory or Azure Active Directory (AD) account password at regular intervals, changes to their passwords have no effect on Hello.
+Although the organization may require users to change their Active Directory or Microsoft Entra account password at regular intervals, changes to their passwords have no effect on Hello.
People who are currently using virtual or physical smart cards for authentication can use their virtual smart card to verify their identity when they set up Hello.
@@ -52,4 +52,3 @@ If your policy allows it, people can use biometrics (fingerprint, iris, and faci
- [Windows Hello errors during PIN creation](hello-errors-during-pin-creation.md)
- [Event ID 300 - Windows Hello successfully created](/windows/security/identity-protection/hello-for-business/hello-faq)
- [Windows Hello biometrics in the enterprise](hello-biometrics-in-enterprise.md)
-
diff --git a/windows/security/identity-protection/hello-for-business/includes/hello-deployment-cloud.md b/windows/security/identity-protection/hello-for-business/includes/hello-deployment-cloud.md
index a9b2685f07..17dc33d7c4 100644
--- a/windows/security/identity-protection/hello-for-business/includes/hello-deployment-cloud.md
+++ b/windows/security/identity-protection/hello-for-business/includes/hello-deployment-cloud.md
@@ -3,4 +3,4 @@ ms.date: 12/08/2022
ms.topic: include
---
-[cloud :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#cloud-deployment "For organizations using Azure AD-only identities. Device management is usually done via Intune/MDM")
\ No newline at end of file
+[cloud :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#cloud-deployment "For organizations using Microsoft Entra-only identities. Device management is usually done via Intune/MDM")
diff --git a/windows/security/identity-protection/hello-for-business/includes/hello-deployment-hybrid.md b/windows/security/identity-protection/hello-for-business/includes/hello-deployment-hybrid.md
index b6ba025722..a67cb2cf2b 100644
--- a/windows/security/identity-protection/hello-for-business/includes/hello-deployment-hybrid.md
+++ b/windows/security/identity-protection/hello-for-business/includes/hello-deployment-hybrid.md
@@ -3,4 +3,4 @@ ms.date: 12/08/2022
ms.topic: include
---
-[hybrid :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#hybrid-deployment "For organizations using Active Directory identities synchronized to Azure AD. Device management is usually done via Group Policy or Intune/MDM")
\ No newline at end of file
+[hybrid :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#hybrid-deployment "For organizations using Active Directory identities synchronized to Microsoft Entra ID. Device management is usually done via Group Policy or Intune/MDM")
diff --git a/windows/security/identity-protection/hello-for-business/includes/hello-deployment-onpremises.md b/windows/security/identity-protection/hello-for-business/includes/hello-deployment-onpremises.md
index 5426da4561..c33f3da2de 100644
--- a/windows/security/identity-protection/hello-for-business/includes/hello-deployment-onpremises.md
+++ b/windows/security/identity-protection/hello-for-business/includes/hello-deployment-onpremises.md
@@ -3,4 +3,4 @@ ms.date: 12/08/2022
ms.topic: include
---
-[on-premises :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#on-premises-deployment "For organizations using Active Directory identities, not synchronized to Azure AD. Device management is usually done via Group Policy")
\ No newline at end of file
+[on-premises :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#on-premises-deployment "For organizations using Active Directory identities, not synchronized to Microsoft Entra ID. Device management is usually done via Group Policy")
diff --git a/windows/security/identity-protection/hello-for-business/includes/hello-join-aad.md b/windows/security/identity-protection/hello-for-business/includes/hello-join-aad.md
index 82f5f99a23..29b890c78b 100644
--- a/windows/security/identity-protection/hello-for-business/includes/hello-join-aad.md
+++ b/windows/security/identity-protection/hello-for-business/includes/hello-join-aad.md
@@ -3,4 +3,4 @@ ms.date: 12/08/2022
ms.topic: include
---
-[Azure AD join :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#azure-active-directory-join "Devices that are Azure AD joined do not have any dependencies on Active Directory. Only local users accounts and Azure AD users can sign in to these devices")
\ No newline at end of file
+[Microsoft Entra join :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#azure-active-directory-join "Devices that are Microsoft Entra joined do not have any dependencies on Active Directory. Only local users accounts and Microsoft Entra users can sign in to these devices")
diff --git a/windows/security/identity-protection/hello-for-business/includes/hello-join-hybrid.md b/windows/security/identity-protection/hello-for-business/includes/hello-join-hybrid.md
index ba8b5df65a..80f9992cb8 100644
--- a/windows/security/identity-protection/hello-for-business/includes/hello-join-hybrid.md
+++ b/windows/security/identity-protection/hello-for-business/includes/hello-join-hybrid.md
@@ -3,4 +3,4 @@ ms.date: 12/08/2022
ms.topic: include
---
-[hybrid Azure AD join :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#hybrid-azure-ad-join "Devices that are hybrid Azure AD joined don't have any dependencies on Azure AD. Only local users accounts and Active Directory users can sign in to these devices. Active Directory users that are synchronized to Azure AD will have single-sign on to both Active Directory and Azure AD-protected resources")
\ No newline at end of file
+[Microsoft Entra hybrid join :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#hybrid-azure-ad-join "Devices that are Microsoft Entra hybrid joined don't have any dependencies on Microsoft Entra ID. Only local users accounts and Active Directory users can sign in to these devices. Active Directory users that are synchronized to Microsoft Entra ID will have single-sign on to both Active Directory and Microsoft Entra protected resources")
diff --git a/windows/security/identity-protection/hello-for-business/index.md b/windows/security/identity-protection/hello-for-business/index.md
index e0d3b1306e..953074993d 100644
--- a/windows/security/identity-protection/hello-for-business/index.md
+++ b/windows/security/identity-protection/hello-for-business/index.md
@@ -25,7 +25,7 @@ Windows Hello lets users authenticate to:
- A Microsoft account.
- An Active Directory account.
-- A Microsoft Azure Active Directory (Azure AD) account.
+- A Microsoft Entra account.
- Identity Provider Services or Relying Party Services that support [Fast ID Online (FIDO) v2.0](https://fidoalliance.org/) authentication.
After an initial two-step verification of the user during enrollment, Windows Hello is set up on the user's device and Windows asks the user to set a gesture, which can be a biometric, such as a fingerprint, or a PIN. The user provides the gesture to verify their identity. Windows then uses Windows Hello to authenticate users.
@@ -71,7 +71,7 @@ Windows Hello helps protect user identities and user credentials. Because the us
- Windows Hello credentials are based on certificate or asymmetrical key pair. Windows Hello credentials can be bound to the device, and the token that is obtained using the credential is also bound to the device.
-- An identity provider validates the user identity and maps the Windows Hello public key to a user account during the registration step. Example providers are Active Directory, Azure AD, or a Microsoft account.
+- An identity provider validates the user identity and maps the Windows Hello public key to a user account during the registration step. Example providers are Active Directory, Microsoft Entra ID, or a Microsoft account.
- Keys can be generated in hardware (TPM 1.2 or 2.0 for enterprises, and TPM 2.0 for consumers) or software, based on the policy. To guarantee that keys are generated in hardware, you must set policy.
@@ -81,7 +81,7 @@ Windows Hello helps protect user identities and user credentials. Because the us
- PIN entry and biometric gesture both trigger Windows 10 and later to use the private key to cryptographically sign data that is sent to the identity provider. The identity provider verifies the user's identity and authenticates the user.
-- Personal (Microsoft account) and corporate (Active Directory or Azure AD) accounts use a single container for keys. All keys are separated by identity providers' domains to help ensure user privacy.
+- Personal (Microsoft account) and corporate (Active Directory or Microsoft Entra ID) accounts use a single container for keys. All keys are separated by identity providers' domains to help ensure user privacy.
- Certificate private keys can be protected by the Windows Hello container and the Windows Hello gesture.
@@ -89,7 +89,7 @@ For details, see [How Windows Hello for Business works](hello-how-it-works.md).
## Comparing key-based and certificate-based authentication
-Windows Hello for Business can use either keys (hardware or software) or certificates in hardware or software. Enterprises that have a public key infrastructure (PKI) for issuing and managing end user certificates can continue to use PKI in combination with Windows Hello for Business. Enterprises that don't use PKI or want to reduce the effort associated with managing user certificates can rely on key-based credentials for Windows Hello. This functionality still uses certificates on the domain controllers as a root of trust. Starting with Windows 10 version 21H2, there's a feature called cloud Kerberos trust for hybrid deployments, which uses Azure AD as the root of trust. cloud Kerberos trust uses key-based credentials for Windows Hello but doesn't require certificates on the domain controller.
+Windows Hello for Business can use either keys (hardware or software) or certificates in hardware or software. Enterprises that have a public key infrastructure (PKI) for issuing and managing end user certificates can continue to use PKI in combination with Windows Hello for Business. Enterprises that don't use PKI or want to reduce the effort associated with managing user certificates can rely on key-based credentials for Windows Hello. This functionality still uses certificates on the domain controllers as a root of trust. Starting with Windows 10 version 21H2, there's a feature called cloud Kerberos trust for hybrid deployments, which uses Microsoft Entra ID as the root of trust. cloud Kerberos trust uses key-based credentials for Windows Hello but doesn't require certificates on the domain controller.
Windows Hello for Business with a key, including cloud Kerberos trust, doesn't support supplied credentials for RDP. RDP doesn't support authentication with a key or a self signed certificate. RDP with Windows Hello for Business is supported with certificate based deployments as a supplied credential. Windows Hello for Business with a key credential can be used with [Remote Credential Guard](../remote-credential-guard.md).
diff --git a/windows/security/identity-protection/hello-for-business/passwordless-strategy.md b/windows/security/identity-protection/hello-for-business/passwordless-strategy.md
index c3a0d37737..a66a69f90c 100644
--- a/windows/security/identity-protection/hello-for-business/passwordless-strategy.md
+++ b/windows/security/identity-protection/hello-for-business/passwordless-strategy.md
@@ -17,7 +17,7 @@ Over the past few years, Microsoft has continued their commitment to enabling a
### 1. Develop a password replacement offering
-Before you move away from passwords, you need something to replace them. With Windows 10 and Windows 11, Microsoft introduced Windows Hello for Business, a strong, hardware protected two-factor credential that enables single sign-on to Azure Active Directory and Active Directory.
+Before you move away from passwords, you need something to replace them. With Windows 10 and Windows 11, Microsoft introduced Windows Hello for Business, a strong, hardware protected two-factor credential that enables single sign-on to Microsoft Entra ID and Active Directory.
Deploying Windows Hello for Business is the first step towards a password-less environment. Windows Hello for Business coexists nicely with existing password-based security. Users are likely to use Windows Hello for Business because of its convenience, especially when combined with biometrics. However, some workflows and applications may still need passwords. This early stage is about implementing an alternative and getting users used to it.
@@ -147,7 +147,7 @@ After successfully moving a work persona to password freedom, you can prioritize
### Password-less replacement offering (step 1)
-The first step to password freedom is providing an alternative to passwords. Windows 10 and Windows 11 provide an affordable and easy in-box alternative to passwords, Windows Hello for Business, a strong, two-factor authentication to Azure Active Directory and Active Directory.
+The first step to password freedom is providing an alternative to passwords. Windows 10 and Windows 11 provide an affordable and easy in-box alternative to passwords, Windows Hello for Business, a strong, two-factor authentication to Microsoft Entra ID and Active Directory.
#### Identify test users that represent the targeted work persona
@@ -160,7 +160,7 @@ Next, you'll want to plan your Windows Hello for Business deployment. Your test
With the Windows Hello for Business infrastructure in place, you can limit Windows Hello for Business enrollments to the targeted work personas. The great news is that you'll only need to deploy the infrastructure once. When other targeted work personas need to start using Windows Hello for Business, add them to a group. You'll use the first work persona to validate your Windows Hello for Business deployment.
> [!NOTE]
-> There are many different ways to connect a device to Azure. Deployments may vary based on how the device is joined to Azure Active Directory. Review your planning guide and deployment guide to ensure additional infrastructure is not needed for an additional Azure joined devices.
+> There are many different ways to connect a device to Azure. Deployments may vary based on how the device is joined to Microsoft Entra ID. Review your planning guide and deployment guide to ensure additional infrastructure is not needed for an additional Azure joined devices.
#### Validate that passwords and Windows Hello for Business work
@@ -206,7 +206,7 @@ Start mitigating password usages based on the workflows of your targeted persona
Mitigating password usage with applications is one of the more challenging obstacles in the password-less journey. If your organization develops the application, then you are in better shape the common-off-the-shelf software (COTS).
-The ideal mitigation for applications that prompt the user for a password is to enable those applications to use an existing authenticated identity, such as Azure Active Directory or Active Directory. Work with the applications vendors to have them add support for Azure identities. For on-premises applications, have the application use Windows integrated authentication. The goal for your users should be a seamless single sign-on experience where each user authenticates once when they sign-in to Windows. Use this same strategy for applications that store their own identities in their own databases.
+The ideal mitigation for applications that prompt the user for a password is to enable those applications to use an existing authenticated identity, such as Microsoft Entra ID or Active Directory. Work with the applications vendors to have them add support for Azure identities. For on-premises applications, have the application use Windows integrated authentication. The goal for your users should be a seamless single sign-on experience where each user authenticates once when they sign-in to Windows. Use this same strategy for applications that store their own identities in their own databases.
Each scenario on your list should now have a problem statement, an investigation as to why the password was used, and a mitigation plan on how to make the password usage go away. Armed with this data, one-by-one, close the gaps on user-visible passwords. Change policies and procedures as needed, make infrastructure changes where possible. Convert in-house applications to use federated identities or Windows integrated authentication. Work with third-party software vendors to update their software to support federated identities or Windows integrated authentication.
diff --git a/windows/security/identity-protection/hello-for-business/toc.yml b/windows/security/identity-protection/hello-for-business/toc.yml
index cc9f23c50f..ee0f2774a8 100644
--- a/windows/security/identity-protection/hello-for-business/toc.yml
+++ b/windows/security/identity-protection/hello-for-business/toc.yml
@@ -41,7 +41,7 @@ items:
- name: Configure and provision Windows Hello for Business
href: hello-hybrid-key-trust-provision.md
displayName: key trust
- - name: Configure SSO for Azure AD joined devices
+ - name: Configure SSO for Microsoft Entra joined devices
href: hello-hybrid-aadj-sso.md
displayName: key trust
- name: Certificate trust deployment
@@ -58,10 +58,10 @@ items:
- name: Configure and provision Windows Hello for Business
href: hello-hybrid-cert-whfb-provision.md
displayName: certificate trust
- - name: Configure SSO for Azure AD joined devices
+ - name: Configure SSO for Microsoft Entra joined devices
href: hello-hybrid-aadj-sso.md
displayName: certificate trust
- - name: Deploy certificates to Azure AD joined devices
+ - name: Deploy certificates to Microsoft Entra joined devices
href: hello-hybrid-aadj-sso-cert.md
displayName: certificate trust
- name: On-premises deployments
diff --git a/windows/security/identity-protection/passwordless-experience/index.md b/windows/security/identity-protection/passwordless-experience/index.md
index d42f5fb84f..7ea73c4603 100644
--- a/windows/security/identity-protection/passwordless-experience/index.md
+++ b/windows/security/identity-protection/passwordless-experience/index.md
@@ -24,7 +24,7 @@ With Windows passwordless experience, users who sign in with Windows Hello or a
>[!NOTE]
>Users can reset their password using CTRL+ALT+DEL > **Manage your account**
-Windows passwordless experience doesn't affect the initial sign-in experience and local accounts. It only applies to subsequent sign-ins for Microsoft Entra ID accounts. It also doesn't prevent a user from signing in with a password when using the *Other user* option in the lock screen.\
+Windows passwordless experience doesn't affect the initial sign-in experience and local accounts. It only applies to subsequent sign-ins for Microsoft Entra accounts. It also doesn't prevent a user from signing in with a password when using the *Other user* option in the lock screen.\
The password credential provider is hidden only for the last signed in user who signed in Windows Hello or a FIDO2 security key. Windows passwordless experience isn't about preventing users from using passwords, rather to guide and educate them to not use passwords.
This article explains how to enable Windows passwordless experience and describes the user experiences.
@@ -122,7 +122,7 @@ Here's a list of recommendations to consider before enabling Windows passwordles
- If Windows Hello for Business is enabled, configure the [PIN reset](../hello-for-business/hello-feature-pin-reset.md) feature to allow users to reset their PIN from the lock screen. The PIN reset experience is improved starting in Windows 11, version 22H2 with [KB5030310][KB-1]
- Don't configure the security policy *Interactive logon: Don't display last signed-in*, as it prevents Windows passwordless experience from working
- Don't disable the password credential provider using the *Exclude credential providers* policy. The key differences between the two policies are:
- - The Exclude credential providers policy disables passwords for *all accounts*, including local accounts. Windows passwordless experience only applies to Microsoft Entra ID accounts that sign in with Windows Hello or a FIDO2 security key. It also excludes *Other User* from the policy, so users have a backup sign in option
+ - The Exclude credential providers policy disables passwords for *all accounts*, including local accounts. Windows passwordless experience only applies to Microsoft Entra accounts that sign in with Windows Hello or a FIDO2 security key. It also excludes *Other User* from the policy, so users have a backup sign in option
- Exclude credential providers policy prevents the use of passwords for RDP and *Run as* authentication scenarios
- To facilitate helpdesk support operations, consider enabling the local administrator account or create a separate one, randomizing its password using the [Windows Local Administrator Password Solution (LAPS)][SERV-1]
diff --git a/windows/security/identity-protection/remote-credential-guard.md b/windows/security/identity-protection/remote-credential-guard.md
index 7351dd93ae..5c99653fe4 100644
--- a/windows/security/identity-protection/remote-credential-guard.md
+++ b/windows/security/identity-protection/remote-credential-guard.md
@@ -211,8 +211,8 @@ For more information about LAPS, see [What is Windows LAPS][LEARN-1].
Here are some additional considerations for Remote Credential Guard:
- Remote Credential Guard doesn't support compound authentication. For example, if you're trying to access a file server from a remote host that requires a device claim, access will be denied
-- Remote Credential Guard can be used only when connecting to a device that is joined to an Active Directory domain. It can't be used when connecting to remote devices joined to Azure Active Directory (Azure AD)
-- Remote Credential Guard can be used from an Azure AD joined client to connect to an Active Directory joined remote host, as long as the client can authenticate using Kerberos
+- Remote Credential Guard can be used only when connecting to a device that is joined to an Active Directory domain. It can't be used when connecting to remote devices joined to Microsoft Entra ID
+- Remote Credential Guard can be used from a Microsoft Entra joined client to connect to an Active Directory joined remote host, as long as the client can authenticate using Kerberos
- Remote Credential Guard only works with the RDP protocol
- No credentials are sent to the target device, but the target device still acquires Kerberos Service Tickets on its own
- The server and client must authenticate using Kerberos
diff --git a/windows/security/identity-protection/smart-cards/smart-card-group-policy-and-registry-settings.md b/windows/security/identity-protection/smart-cards/smart-card-group-policy-and-registry-settings.md
index f3f0e7de99..81d22a9785 100644
--- a/windows/security/identity-protection/smart-cards/smart-card-group-policy-and-registry-settings.md
+++ b/windows/security/identity-protection/smart-cards/smart-card-group-policy-and-registry-settings.md
@@ -411,7 +411,7 @@ The following smart card-related Group Policy settings are in Computer Configura
| Group Policy setting and registry key | Default | Description |
|------------------------------------------|------------|---------------|
-| Interactive logon: Require smart card
**scforceoption** | Disabled | This security policy setting requires users to sign in to a computer by using a smart card.
**Enabled** Users can sign in to the computer only by using a smart card.
**Disabled** Users can sign in to the computer by using any method. |
+| Interactive logon: Require smart card
**scforceoption** | Disabled | This security policy setting requires users to sign in to a computer by using a smart card.
**Enabled** Users can sign in to the computer only by using a smart card.
**Disabled** Users can sign in to the computer by using any method.
NOTE: the Windows LAPS-managed local account is exempted from this policy when Enabled. For more information see [Windows LAPS integration with smart card policy](/windows-server/identity/laps/laps-concepts#windows-laps-integration-with-smart-card-policy).
|
| Interactive logon: Smart card removal behavior
**scremoveoption** | This policy setting isn't defined, which means that the system treats it as **No Action**. | This setting determines what happens when the smart card for a signed-in user is removed from the smart card reader. The options are:
**No Action**
**Lock Workstation**: The workstation is locked when the smart card is removed, so users can leave the area, take their smart card with them, and still maintain a protected session.
**Force Logoff**: The user is automatically signed out when the smart card is removed.
**Disconnect if a Remote Desktop Services session**: Removal of the smart card disconnects the session without signing out the user. The user can reinsert the smart card and resume the session later, or at another computer that's equipped with a smart card reader, without having to sign in again. If the session is local, this policy setting functions identically to the **Lock Workstation** option.
**Note**: In earlier versions of Windows Server, Remote Desktop Services was called Terminal Services. |
From the Local Security Policy Editor (secpol.msc), you can edit and apply system policies to manage credential delegation for local or domain computers.
diff --git a/windows/security/identity-protection/web-sign-in/index.md b/windows/security/identity-protection/web-sign-in/index.md
index 80f4e2403f..f13acff6dd 100644
--- a/windows/security/identity-protection/web-sign-in/index.md
+++ b/windows/security/identity-protection/web-sign-in/index.md
@@ -25,7 +25,7 @@ This article describes how to configure Web sign-in and the supported key scenar
To use web sign-in, the clients must meet the following prerequisites:
- Windows 11, version 22H2 with [5030310][KB-1], or later
-- Must be Microsoft Entra joined
+- Must be [Microsoft Entra joined](/entra/identity/devices/concept-directory-join)
- Must have Internet connectivity, as the authentication is done over the Internet
[!INCLUDE [federated-sign-in](../../../../includes/licensing/web-sign-in.md)]
@@ -128,7 +128,7 @@ For more information, see [Use a Temporary Access Pass][AAD-3].
:::row:::
:::column span="3":::
- If the Microsoft Entra ID tenant is federated with a third-party SAML-P identity provider (IdP), federated users can sign using the Web sign-in credential provider.
+ If the Microsoft Entra tenant is federated with a third-party SAML-P identity provider (IdP), federated users can sign using the Web sign-in credential provider.
:::column-end:::
:::column span="1":::
:::image type="content" source="images/web-sign-in-federated-auth.png" border="false" lightbox="images/web-sign-in-federated-auth.gif" alt-text="Animation of the sign in experience with a federated user.":::
@@ -138,7 +138,7 @@ For more information, see [Use a Temporary Access Pass][AAD-3].
> [!TIP]
> To improve the user experience for federated identities:
>
-> - Configure the *preferred Azure AD tenant name* feature, which allows users to select the domain name during the sign-in process. The users are then automatically redirected to the identity provider sign-in page.
+> - Configure the *preferred Microsoft Entra tenant name* feature, which allows users to select the domain name during the sign-in process. The users are then automatically redirected to the identity provider sign-in page.
> - Enable Windows Hello for Business. Once the user signs in, the user can enroll in Windows Hello for Business and then use it to sign in to the device
For more information about preferred tenant name, see [Authentication CSP - PreferredAadTenantDomainName][WIN-1].
diff --git a/windows/security/includes/sections/cloud-services.md b/windows/security/includes/sections/cloud-services.md
index 4e338bf4cd..efde3a725d 100644
--- a/windows/security/includes/sections/cloud-services.md
+++ b/windows/security/includes/sections/cloud-services.md
@@ -9,7 +9,7 @@ ms.topic: include
| Feature name | Description |
|:---|:---|
-| **[Active Directory domain join, Microsoft Entra join, and Microsoft Entra Hybrid join with single sign-on (SSO)](/azure/active-directory/devices/concept-directory-join)** | Microsoft Entra ID is a comprehensive cloud-based identity management solution that helps enable secure access to applications, networks, and other resources and guard against threats. |
+| **[Active Directory domain join, Microsoft Entra join, and Microsoft Entra hybrid join with single sign-on (SSO)](/azure/active-directory/devices/concept-directory-join)** | Microsoft Entra ID is a comprehensive cloud-based identity management solution that helps enable secure access to applications, networks, and other resources and guard against threats. |
| **[Security baselines](/windows/security/operating-system-security/device-management/windows-security-configuration-framework/windows-security-baselines)** | Windows 11 supports modern device management so that IT pros can manage company security policies and business applications without compromising user privacy on corporate or employee-owned devices. With MDM solutions, IT can manage Windows 11 using industry-standard protocols. To simplify setup for users, management features are built directly into Windows, eliminating the need for a separate MDM client.
Windows 11 can be configured with Microsoft's MDM security baseline backed by ADMX policies, which functions like the Microsoft GP-based security baseline. The security baseline enables IT administrators to easily address security concerns and compliance needs for modern cloud-managed devices. |
| **[Remote wipe](/windows/client-management/mdm/remotewipe-csp)** | When a device is lost or stolen, IT administrators may want to remotely wipe data stored on the device. A helpdesk agent may also want to reset devices to fix issues encountered by remote workers.
With the Remote Wipe configuration service provider (CSP), an MDM solution can remotely initiate any of the following operations on a Windows device: reset the device and remove user accounts and data, reset the device and clean the drive, reset the device but persist user accounts and data. |
| **[Modern device management through (MDM)](/windows/client-management/mdm-overview)** | Windows 11 supports modern device management through mobile device management (MDM) protocols.
IT pros can manage company security policies and business applications without compromising user privacy on corporate or employee-owned devices. With MDM solutions, IT can manage Windows 11 using industry-standard protocols.
To simplify setup for users, management features are built directly into Windows, eliminating the need for a separate MDM client. |
diff --git a/windows/security/includes/sections/identity.md b/windows/security/includes/sections/identity.md
index 557e813ec5..5a643de599 100644
--- a/windows/security/includes/sections/identity.md
+++ b/windows/security/includes/sections/identity.md
@@ -23,7 +23,7 @@ ms.topic: include
|:---|:---|
| **[Web sign-in](/windows/security/identity-protection/web-sign-in)** | Web sign-in is a credential provider initially introduced in Windows 10 with support for Temporary Access Pass (TAP) only. With the release of Windows 11, the supported scenarios and capabilities of Web sign-in have been expanded. For example, users can sign-in to Windows using the Microsoft Authenticator app or with a federated identity. |
| **[Federated sign-in](/education/windows/federated-sign-in)** | Windows 11 Education editions support federated sign-in with third-party identity providers. Federated sign-in enables secure sign in through methods like QR codes or pictures. |
-| **[Windows LAPS](/windows-server/identity/laps/laps-overview)** | Windows Local Administrator Password Solution (Windows LAPS) is a Windows feature that automatically manages and backs up the password of a local administrator account on your Microsoft Entra ID-joined or Windows Server Active Directory-joined devices. You also can use Windows LAPS to automatically manage and back up the Directory Services Restore Mode (DSRM) account password on your Windows Server Active Directory domain controllers. An authorized administrator can retrieve the DSRM password and use it. |
+| **[Windows LAPS](/windows-server/identity/laps/laps-overview)** | Windows Local Administrator Password Solution (Windows LAPS) is a Windows feature that automatically manages and backs up the password of a local administrator account on your Microsoft Entra joined or Windows Server Active Directory-joined devices. You also can use Windows LAPS to automatically manage and back up the Directory Services Restore Mode (DSRM) account password on your Windows Server Active Directory domain controllers. An authorized administrator can retrieve the DSRM password and use it. |
| **[Account Lockout Policy](/windows/security/threat-protection/security-policy-settings/account-lockout-policy)** | Account Lockout Policy settings control the response threshold for failed logon attempts and the actions to be taken after the threshold is reached. |
| **[Enhanced phishing protection with SmartScreen](/windows/security/operating-system-security/virus-and-threat-protection/microsoft-defender-smartscreen/enhanced-phishing-protection)** | Users who are still using passwords can benefit from powerful credential protection. Microsoft Defender SmartScreen includes enhanced phishing protection to automatically detect when a user enters their Microsoft password into any app or website. Windows then identifies if the app or site is securely authenticating to Microsoft and warns if the credentials are at risk. Since users are alerted at the moment of potential credential theft, they can take preemptive action before their password is used against them or their organization. |
| **[Access Control (ACL/SACL)](/windows/security/identity-protection/access-control/access-control)** | Access control in Windows ensures that shared resources are available to users and groups other than the resource's owner and are protected from unauthorized use. IT administrators can manage users', groups', and computers' access to objects and assets on a network or computer. After a user is authenticated, the Windows operating system implements the second phase of protecting resources by using built-in authorization and access control technologies to determine if an authenticated user has the correct permissions.
Access Control Lists (ACL) describe the permissions for a specific object and can also contain System Access Control Lists (SACL). SACLs provide a way to audit specific system level events, such as when a user attempt to access file system objects. These events are essential for tracking activity for objects that are sensitive or valuable and require extra monitoring. Being able to audit when a resource attempts to read or write part of the operating system is critical to understanding a potential attack. |
diff --git a/windows/security/information-protection/windows-information-protection/create-and-verify-an-efs-dra-certificate.md b/windows/security/information-protection/windows-information-protection/create-and-verify-an-efs-dra-certificate.md
index 303f8c3057..d730747292 100644
--- a/windows/security/information-protection/windows-information-protection/create-and-verify-an-efs-dra-certificate.md
+++ b/windows/security/information-protection/windows-information-protection/create-and-verify-an-efs-dra-certificate.md
@@ -122,18 +122,18 @@ It's possible that you might revoke data from an unenrolled device only to later
## Auto-recovery of encryption keys
Starting with Windows 10, version 1709, WIP includes a data recovery feature that lets your employees auto-recover access to work files if the encryption key is lost and the files are no longer accessible. This typically happens if an employee reimages the operating system partition, removing the WIP key info, or if a device is reported as lost and you mistakenly target the wrong device for unenrollment.
-To help make sure employees can always access files, WIP creates an auto-recovery key that's backed up to their Azure Active Directory (Azure AD) identity.
+To help make sure employees can always access files, WIP creates an auto-recovery key that's backed up to their Microsoft Entra identity.
-The employee experience is based on signing in with an Azure AD work account. The employee can either:
+The employee experience is based on signing in with a Microsoft Entra ID work account. The employee can either:
- Add a work account through the **Windows Settings > Accounts > Access work or school > Connect** menu.
-OR-
-- Open **Windows Settings > Accounts > Access work or school > Connect** and choose the **Join this device to Azure Active Directory** link, under **Alternate actions**.
+- Open **Windows Settings > Accounts > Access work or school > Connect** and choose the **Join this device to Microsoft Entra ID** link, under **Alternate actions**.
>[!Note]
- >To perform an Azure AD Domain Join from the Settings page, the employee must have administrator privileges to the device.
+ >To perform a Microsoft Entra Domain Join from the Settings page, the employee must have administrator privileges to the device.
After signing in, the necessary WIP key info is automatically downloaded and employees are able to access the files again.
@@ -147,7 +147,7 @@ After signing in, the necessary WIP key info is automatically downloaded and emp
The **Access work or school settings** page appears.
-3. Sign-in to Azure AD as the employee and verify that the files now open
+3. Sign-in to Microsoft Entra ID as the employee and verify that the files now open
## Related topics
diff --git a/windows/security/information-protection/windows-information-protection/create-vpn-and-wip-policy-using-intune-azure.md b/windows/security/information-protection/windows-information-protection/create-vpn-and-wip-policy-using-intune-azure.md
index 709de2a54d..c3badb03b9 100644
--- a/windows/security/information-protection/windows-information-protection/create-vpn-and-wip-policy-using-intune-azure.md
+++ b/windows/security/information-protection/windows-information-protection/create-vpn-and-wip-policy-using-intune-azure.md
@@ -52,7 +52,7 @@ After you've created your VPN policy, you'll need to deploy it to the same group
1. On the **App policy** blade, select your newly created policy, select **User groups** from the menu that appears, and then select **Add user group**.
- A list of user groups, made up of all of the security groups in your Azure Active Directory, appear in the **Add user group** blade.
+ A list of user groups, made up of all of the security groups in your Microsoft Entra ID, appear in the **Add user group** blade.
2. Choose the group you want your policy to apply to, and then select **Select** to deploy the policy.
diff --git a/windows/security/information-protection/windows-information-protection/create-wip-policy-using-intune-azure.md b/windows/security/information-protection/windows-information-protection/create-wip-policy-using-intune-azure.md
index 6cb50dc76b..c73eda005f 100644
--- a/windows/security/information-protection/windows-information-protection/create-wip-policy-using-intune-azure.md
+++ b/windows/security/information-protection/windows-information-protection/create-wip-policy-using-intune-azure.md
@@ -27,23 +27,23 @@ You can create an app protection policy in Intune either with device enrollment
- MAM has more **Access** settings for Windows Hello for Business.
- MAM can [selectively wipe company data](/intune/apps-selective-wipe) from a user's personal device.
-- MAM requires an [Azure Active Directory (Azure AD) Premium license](/azure/active-directory/fundamentals/active-directory-whatis#what-are-the-azure-ad-licenses).
-- An Azure AD Premium license is also required for WIP auto-recovery, where a device can re-enroll and regain access to protected data. WIP auto-recovery depends on Azure AD registration to back up the encryption keys, which requires device auto-enrollment with MDM.
+- MAM requires an [Microsoft Entra ID P1 or P2 license](/azure/active-directory/fundamentals/active-directory-whatis#what-are-the-azure-ad-licenses).
+- A Microsoft Entra ID P1 or P2 license is also required for WIP auto-recovery, where a device can re-enroll and regain access to protected data. WIP auto-recovery depends on Microsoft Entra registration to back up the encryption keys, which requires device auto-enrollment with MDM.
- MAM supports only one user per device.
- MAM can only manage [enlightened apps](enlightened-microsoft-apps-and-wip.md).
- Only MDM can use [BitLocker CSP](/windows/client-management/mdm/bitlocker-csp) policies.
-- If the same user and device are targeted for both MDM and MAM, the MDM policy will be applied to devices joined to Azure AD. For personal devices that are workplace-joined (that is, added by using **Settings** > **Email & accounts** > **Add a work or school account**), the MAM-only policy will be preferred but it's possible to upgrade the device management to MDM in **Settings**. Windows Home edition only supports WIP for MAM-only; upgrading to MDM policy on Home edition will revoke WIP-protected data access.
+- If the same user and device are targeted for both MDM and MAM, the MDM policy will be applied to devices joined to Microsoft Entra ID. For personal devices that are workplace-joined (that is, added by using **Settings** > **Email & accounts** > **Add a work or school account**), the MAM-only policy will be preferred but it's possible to upgrade the device management to MDM in **Settings**. Windows Home edition only supports WIP for MAM-only; upgrading to MDM policy on Home edition will revoke WIP-protected data access.
## Prerequisites
-Before you can create a WIP policy using Intune, you need to configure an MDM or MAM provider in Azure Active Directory (Azure AD). MAM requires an [Azure Active Directory (Azure AD) Premium license](/azure/active-directory/fundamentals/active-directory-whatis#what-are-the-azure-ad-licenses). An Azure AD Premium license is also required for WIP auto-recovery, where a device can re-enroll and regain access to protected data. WIP auto-recovery relies on Azure AD registration to back up the encryption keys, which requires device auto-enrollment with MDM.
+Before you can create a WIP policy using Intune, you need to configure an MDM or MAM provider in Microsoft Entra ID. MAM requires an [Microsoft Entra ID P1 or P2 license](/azure/active-directory/fundamentals/active-directory-whatis#what-are-the-azure-ad-licenses). A Microsoft Entra ID P1 or P2 license is also required for WIP auto-recovery, where a device can re-enroll and regain access to protected data. WIP auto-recovery relies on Microsoft Entra registration to back up the encryption keys, which requires device auto-enrollment with MDM.
## Configure the MDM or MAM provider
1. Sign in to the Azure portal.
-2. Select **Azure Active Directory** > **Mobility (MDM and MAM)** > **Microsoft Intune**.
+2. Select **Microsoft Entra ID** > **Mobility (MDM and MAM)** > **Microsoft Intune**.
3. Select **Restore Default URLs** or enter the settings for MDM or MAM user scope and select **Save**:
@@ -431,7 +431,7 @@ For example:
URL <,proxy>|URL <,proxy>|/*AppCompat*/
```
-When you use this string, we recommend that you also turn on [Azure Active Directory Conditional Access](/azure/active-directory/active-directory-conditional-access), using the **Domain joined or marked as compliant** option, which blocks apps from accessing any enterprise cloud resources that are protected by conditional access.
+When you use this string, we recommend that you also turn on [Microsoft Entra Conditional Access](/azure/active-directory/active-directory-conditional-access), using the **Domain joined or marked as compliant** option, which blocks apps from accessing any enterprise cloud resources that are protected by conditional access.
Value format with proxy:
diff --git a/windows/security/introduction.md b/windows/security/introduction.md
index 69e2193bf2..92105b512d 100644
--- a/windows/security/introduction.md
+++ b/windows/security/introduction.md
@@ -25,7 +25,7 @@ A Zero Trust security model gives the right people the right access at the right
1. When verified, give people and devices access to only necessary resources for the necessary amount of time
1. Use continuous analytics to drive threat detection and improve defenses
-For Windows 11, the Zero Trust principle of *verify explicitly* applies to risks introduced by both devices and people. Windows 11 provides *chip-to-cloud security*, enabling IT administrators to implement strong authorization and authentication processes with features like [Windows Hello for Business](identity-protection/hello-for-business/index.md). IT administrators also gain attestation and measurements for determining if a device meets requirements and can be trusted. Windows 11 works out-of-the-box with Microsoft Intune and Azure Active Directory, which enables timely and seamless access decisions. Furthermore, IT administrators can easily customize Windows to meet specific user and policy requirements for access, privacy, compliance, and more.
+For Windows 11, the Zero Trust principle of *verify explicitly* applies to risks introduced by both devices and people. Windows 11 provides *chip-to-cloud security*, enabling IT administrators to implement strong authorization and authentication processes with features like [Windows Hello for Business](identity-protection/hello-for-business/index.md). IT administrators also gain attestation and measurements for determining if a device meets requirements and can be trusted. Windows 11 works out-of-the-box with Microsoft Intune and Microsoft Entra ID, which enables timely and seamless access decisions. Furthermore, IT administrators can easily customize Windows to meet specific user and policy requirements for access, privacy, compliance, and more.
### Security, by default
@@ -49,7 +49,7 @@ Passwords have been an important part of digital security for a long time, and t
### Connecting to cloud services
-Microsoft offers comprehensive cloud services for identity, storage, and access management in addition to the tools needed to attest that Windows devices connecting to your network are trustworthy. You can also enforce compliance and conditional access with a modern device management (MDM) service such as Microsoft Intune, which works with Azure Active Directory and Microsoft Azure Attestation to control access to applications and data through the cloud.
+Microsoft offers comprehensive cloud services for identity, storage, and access management in addition to the tools needed to attest that Windows devices connecting to your network are trustworthy. You can also enforce compliance and conditional access with a modern device management (MDM) service such as Microsoft Intune, which works with Microsoft Entra ID and Microsoft Azure Attestation to control access to applications and data through the cloud.
## Next steps
diff --git a/windows/security/operating-system-security/data-protection/bitlocker/bitlocker-basic-deployment.md b/windows/security/operating-system-security/data-protection/bitlocker/bitlocker-basic-deployment.md
index 52cc2816b8..16a611c770 100644
--- a/windows/security/operating-system-security/data-protection/bitlocker/bitlocker-basic-deployment.md
+++ b/windows/security/operating-system-security/data-protection/bitlocker/bitlocker-basic-deployment.md
@@ -59,7 +59,7 @@ For the operating system volume the **BitLocker Drive Encryption Wizard** presen
The recovery key can be stored using the following methods:
- - **Save to your Azure AD account** (if applicable)
+ - **Save to your Microsoft Entra account** (if applicable)
- **Save to a USB flash drive**
- **Save to a file** - the file needs to be saved to a location that isn't on the computer itself such as a network folder or OneDrive
- **Print the recovery key**
@@ -126,7 +126,7 @@ Encrypting data volumes using the BitLocker control panel works in a similar fas
3. The **BitLocker Drive Encryption Wizard** presents options for storage of the recovery key. These options are the same as for operating system volumes:
- - **Save to your Azure AD account** (if applicable)
+ - **Save to your Microsoft Entra account** (if applicable)
- **Save to a USB flash drive**
- **Save to a file** - the file needs to be saved to a location that isn't on the computer itself such as a network folder or OneDrive
- **Print the recovery key**
diff --git a/windows/security/operating-system-security/data-protection/bitlocker/bitlocker-deployment-comparison.md b/windows/security/operating-system-security/data-protection/bitlocker/bitlocker-deployment-comparison.md
index 1654153fec..dd95d6dbc5 100644
--- a/windows/security/operating-system-security/data-protection/bitlocker/bitlocker-deployment-comparison.md
+++ b/windows/security/operating-system-security/data-protection/bitlocker/bitlocker-deployment-comparison.md
@@ -16,7 +16,7 @@ This article depicts the BitLocker deployment comparison chart.
| *Minimum client operating system version* | Windows 11 and Windows 10 | Windows 11, Windows 10, and Windows 8.1 | Windows 7, Windows 8, Windows 8.1, Windows 10, Windows 10 IoT, and Windows 11 |
| *Supported Windows SKUs* | Enterprise, Pro, Education | Enterprise, Pro, Education | Enterprise |
| *Minimum Windows version* | 1909 | None | None |
-| *Supported domain-joined status* | Microsoft Azure Active Directory (Azure AD) joined, hybrid Azure AD joined | Active Directory-joined, hybrid Azure AD joined | Active Directory-joined |
+| *Supported domain-joined status* | Microsoft Entra joined, Microsoft Entra hybrid joined | Active Directory-joined, Microsoft Entra hybrid joined | Active Directory-joined |
| *Permissions required to manage policies* | Endpoint security manager or custom | Full administrator or custom | Domain Admin or Delegated GPO access |
| *Cloud or on premises* | Cloud | On premises | On premises |
| Server components required? | | ✅ | ✅ |
@@ -31,16 +31,16 @@ This article depicts the BitLocker deployment comparison chart.
| *Select cipher strength and algorithms for fixed drives* | ✅ | ✅ | ✅ |
| *Select cipher strength and algorithms for removable drives* | ✅ | ✅ | ✅ |
| *Select cipher strength and algorithms for operating environment drives* | ✅ | ✅ | ✅ |
-| *Standard recovery password storage location* | Azure AD or Active Directory | Configuration Manager site database | MBAM database |
-| *Store recovery password for operating system and fixed drives to Azure AD or Active Directory* | Yes (Active Directory and Azure AD) | Yes (Active Directory only) | Yes (Active Directory only) |
+| *Standard recovery password storage location* | Microsoft Entra ID or Active Directory | Configuration Manager site database | MBAM database |
+| *Store recovery password for operating system and fixed drives to Microsoft Entra ID or Active Directory* | Yes (Active Directory and Microsoft Entra ID) | Yes (Active Directory only) | Yes (Active Directory only) |
| *Customize preboot message and recovery link* | ✅ | ✅ | ✅ |
| *Allow/deny key file creation* | ✅ | ✅ | ✅ |
| *Deny Write permission to unprotected drives* | ✅ | ✅ | ✅ |
| *Can be administered outside company network* | ✅ | ✅ | |
| *Support for organization unique IDs* | | ✅ | ✅ |
-| *Self-service recovery* | Yes (through Azure AD or Company Portal app) | ✅ | ✅ |
+| *Self-service recovery* | Yes (through Microsoft Entra ID or Company Portal app) | ✅ | ✅ |
| *Recovery password rotation for fixed and operating environment drives* | Yes (Windows 10, version 1909 and later) | ✅ | ✅ |
-| *Wait to complete encryption until recovery information is backed up to Azure AD* | ✅ | | |
+| *Wait to complete encryption until recovery information is backed up to Microsoft Entra ID* | ✅ | | |
| *Wait to complete encryption until recovery information is backed up to Active Directory* | | ✅ | ✅ |
| *Allow or deny Data Recovery Agent* | ✅ | ✅ | ✅ |
| *Unlock a volume using certificate with custom object identifier* | | ✅ | ✅ |
diff --git a/windows/security/operating-system-security/data-protection/bitlocker/bitlocker-device-encryption-overview-windows-10.md b/windows/security/operating-system-security/data-protection/bitlocker/bitlocker-device-encryption-overview-windows-10.md
index d93426076e..7b8887a82c 100644
--- a/windows/security/operating-system-security/data-protection/bitlocker/bitlocker-device-encryption-overview-windows-10.md
+++ b/windows/security/operating-system-security/data-protection/bitlocker/bitlocker-device-encryption-overview-windows-10.md
@@ -67,7 +67,7 @@ Unlike a standard BitLocker implementation, BitLocker Device Encryption is enabl
With this configuration, the recovery password is created automatically when the computer joins the domain, and then the recovery key is backed up to AD DS, the TPM protector is created, and the clear key is removed.
-- Similar to signing in with a domain account, the clear key is removed when the user signs in to an Azure AD account on the device. As described in the bullet point above, the recovery password is created automatically when the user authenticates to Azure AD. Then, the recovery key is backed up to Azure AD, the TPM protector is created, and the clear key is removed.
+- Similar to signing in with a domain account, the clear key is removed when the user signs in to a Microsoft Entra account on the device. As described in the bullet point above, the recovery password is created automatically when the user authenticates to Microsoft Entra ID. Then, the recovery key is backed up to Microsoft Entra ID, the TPM protector is created, and the clear key is removed.
Microsoft recommends automatically enabling BitLocker Device Encryption on any systems that support it. However, the automatic BitLocker Device Encryption process can be prevented by changing the following registry setting:
@@ -160,4 +160,4 @@ Part of the Microsoft Desktop Optimization Pack, Microsoft BitLocker Administrat
Going forward, the functionality of MBAM will be incorporated into Configuration Manager. For more information, see [Plan for BitLocker management](/mem/configmgr/protect/plan-design/bitlocker-management).
-Enterprises not using Configuration Manager can use the built-in features of Azure AD and Microsoft Intune for administration and monitoring. For more information, see [Monitor device encryption with Intune](/mem/intune/protect/encryption-monitor).
+Enterprises not using Configuration Manager can use the built-in features of Microsoft Entra ID and Microsoft Intune for administration and monitoring. For more information, see [Monitor device encryption with Intune](/mem/intune/protect/encryption-monitor).
diff --git a/windows/security/operating-system-security/data-protection/bitlocker/bitlocker-management-for-enterprises.md b/windows/security/operating-system-security/data-protection/bitlocker/bitlocker-management-for-enterprises.md
index c88b6cde1e..e9c661179f 100644
--- a/windows/security/operating-system-security/data-protection/bitlocker/bitlocker-management-for-enterprises.md
+++ b/windows/security/operating-system-security/data-protection/bitlocker/bitlocker-management-for-enterprises.md
@@ -17,22 +17,24 @@ Though much Windows [BitLocker documentation](index.md) has been published, cust
Companies that image their own computers using Configuration Manager can use an existing task sequence to [pre-provision BitLocker](/configmgr/osd/understand/task-sequence-steps#BKMK_PreProvisionBitLocker) encryption while in Windows Preinstallation Environment (WinPE) and can then [enable protection](/configmgr/osd/understand/task-sequence-steps#BKMK_EnableBitLocker). These steps during an operating system deployment can help ensure that computers are encrypted from the start, even before users receive them. As part of the imaging process, a company could also decide to use Configuration Manager to pre-set any desired [BitLocker Group Policy](bitlocker-group-policy-settings.md).
-Enterprises can use [Microsoft BitLocker Administration and Monitoring (MBAM)](/microsoft-desktop-optimization-pack/mbam-v25/) to manage client computers with BitLocker that are domain-joined on-premises until [mainstream support ends in July 2019](/lifecycle/products/?alpha=Microsoft%20BitLocker%20Administration%20and%20Monitoring%202.5%20Service%20Pack%201%2F) or they can receive extended support until April 2026. Thus, over the next few years, a good strategy for enterprises will be to plan and move to cloud-based management for BitLocker. Refer to the [PowerShell examples](#powershell-examples) to see how to store recovery keys in Azure Active Directory (Azure AD).
+Enterprises can use [Microsoft BitLocker Administration and Monitoring (MBAM)](/microsoft-desktop-optimization-pack/mbam-v25/) to manage client computers with BitLocker that are domain-joined on-premises until [mainstream support ends in July 2019](/lifecycle/products/?alpha=Microsoft%20BitLocker%20Administration%20and%20Monitoring%202.5%20Service%20Pack%201%2F) or they can receive extended support until April 2026. Thus, over the next few years, a good strategy for enterprises will be to plan and move to cloud-based management for BitLocker. Refer to the [PowerShell examples](#powershell-examples) to see how to store recovery keys in Microsoft Entra ID.
> [!IMPORTANT]
> Microsoft BitLocker Administration and Monitoring (MBAM) capabilities are offered through Configuration Manager BitLocker Management. See [Plan for BitLocker management](/mem/configmgr/protect/plan-design/bitlocker-management) in the Configuration Manager documentation for additional information.
-## Managing devices joined to Azure Active Directory
+
-Devices joined to Azure AD are managed using Mobile Device Management (MDM) policy from an MDM solution such as Microsoft Intune. Prior to Windows 10, version 1809, only local administrators can enable BitLocker via Intune policy. Starting with Windows 10, version 1809, Intune can enable BitLocker for standard users. [BitLocker Device Encryption](bitlocker-device-encryption-overview-windows-10.md#bitlocker-device-encryption) status can be queried from managed machines via the [Policy Configuration Settings Provider (CSP)](/windows/client-management/mdm/policy-configuration-service-provider/), which reports on whether BitLocker Device Encryption is enabled on the device. Compliance with BitLocker Device Encryption policy can be a requirement for [Conditional Access](https://www.microsoft.com/cloud-platform/conditional-access/) to services like Exchange Online and SharePoint Online.
+## Managing devices joined to Microsoft Entra ID
+
+Devices joined to Microsoft Entra ID are managed using Mobile Device Management (MDM) policy from an MDM solution such as Microsoft Intune. Prior to Windows 10, version 1809, only local administrators can enable BitLocker via Intune policy. Starting with Windows 10, version 1809, Intune can enable BitLocker for standard users. [BitLocker Device Encryption](bitlocker-device-encryption-overview-windows-10.md#bitlocker-device-encryption) status can be queried from managed machines via the [Policy Configuration Settings Provider (CSP)](/windows/client-management/mdm/policy-configuration-service-provider/), which reports on whether BitLocker Device Encryption is enabled on the device. Compliance with BitLocker Device Encryption policy can be a requirement for [Conditional Access](https://www.microsoft.com/cloud-platform/conditional-access/) to services like Exchange Online and SharePoint Online.
Starting with Windows 10 version 1703, the enablement of BitLocker can be triggered over MDM either by the [Policy CSP](/windows/client-management/mdm/policy-configuration-service-provider/) or the [BitLocker CSP](/windows/client-management/mdm/bitlocker-csp/). The BitLocker CSP adds policy options that go beyond ensuring that encryption has occurred, and is available on computers that run Windows 11, Windows 10, and on Windows phones.
-For hardware that is compliant with Modern Standby and HSTI, when using either of these features, [BitLocker Device Encryption](bitlocker-device-encryption-overview-windows-10.md#bitlocker-device-encryption) is automatically turned on whenever the user joins a device to Azure AD. Azure AD provides a portal where recovery keys are also backed up, so users can retrieve their own recovery key for self-service, if necessary. For older devices that aren't yet encrypted, beginning with Windows 10 version 1703, admins can use the [BitLocker CSP](/windows/client-management/mdm/bitlocker-csp/) to trigger encryption and store the recovery key in Azure AD. This process and feature is applicable to Azure Hybrid AD as well.
+For hardware that is compliant with Modern Standby and HSTI, when using either of these features, [BitLocker Device Encryption](bitlocker-device-encryption-overview-windows-10.md#bitlocker-device-encryption) is automatically turned on whenever the user joins a device to Microsoft Entra ID. Microsoft Entra ID provides a portal where recovery keys are also backed up, so users can retrieve their own recovery key for self-service, if necessary. For older devices that aren't yet encrypted, beginning with Windows 10 version 1703, admins can use the [BitLocker CSP](/windows/client-management/mdm/bitlocker-csp/) to trigger encryption and store the recovery key in Microsoft Entra ID. This process and feature is applicable to Azure Hybrid AD as well.
## Managing workplace-joined PCs and phones
-For Windows PCs and Windows Phones that are enrolled using **Connect to work or school account**, BitLocker Device Encryption is managed over MDM, the same as devices joined to Azure AD.
+For Windows PCs and Windows Phones that are enrolled using **Connect to work or school account**, BitLocker Device Encryption is managed over MDM, the same as devices joined to Microsoft Entra ID.
## Managing servers
@@ -47,9 +49,9 @@ If a server is being installed manually, such as a stand-alone server, then choo
## PowerShell examples
-For Azure AD-joined computers, including virtual machines, the recovery password should be stored in Azure AD.
+For Microsoft Entra joined computers, including virtual machines, the recovery password should be stored in Microsoft Entra ID.
-**Example**: *Use PowerShell to add a recovery password and back it up to Azure AD before enabling BitLocker*
+**Example**: *Use PowerShell to add a recovery password and back it up to Microsoft Entra ID before enabling BitLocker*
```powershell
Add-BitLockerKeyProtector -MountPoint "C:" -RecoveryPasswordProtector
diff --git a/windows/security/operating-system-security/data-protection/bitlocker/bitlocker-recovery-guide-plan.md b/windows/security/operating-system-security/data-protection/bitlocker/bitlocker-recovery-guide-plan.md
index c934ae7570..a2bf3f755c 100644
--- a/windows/security/operating-system-security/data-protection/bitlocker/bitlocker-recovery-guide-plan.md
+++ b/windows/security/operating-system-security/data-protection/bitlocker/bitlocker-recovery-guide-plan.md
@@ -344,7 +344,7 @@ BitLocker metadata has been enhanced starting in Windows 10, version 1903, to in
> [!IMPORTANT]
-> It is not recommend to print recovery keys or saving them to a file. Instead, use Active Directory backup or a cloud-based backup. Cloud-based backup includes Azure Active Directory (Azure AD) and Microsoft account.
+> It is not recommend to print recovery keys or saving them to a file. Instead, use Active Directory backup or a cloud-based backup. Cloud-based backup includes Microsoft Entra ID and Microsoft account.
There are rules governing which hint is shown during the recovery (in the order of processing):
@@ -356,7 +356,7 @@ There are rules governing which hint is shown during the recovery (in the order
4. Prioritize keys with successful backup over keys that have never been backed up.
-5. Prioritize backup hints in the following order for remote backup locations: **Microsoft Account > Azure AD > Active Directory**.
+5. Prioritize backup hints in the following order for remote backup locations: **Microsoft Account > Microsoft Entra ID > Active Directory**.
6. If a key has been printed and saved to file, display a combined hint, "Look for a printout or a text file with the key," instead of two separate hints.
@@ -371,7 +371,7 @@ There are rules governing which hint is shown during the recovery (in the order
| Custom URL | Yes |
|----------------------|------------|
| Saved to Microsoft Account | Yes |
-| Saved to Azure AD | No |
+| Saved to Microsoft Entra ID | No |
| Saved to Active Directory | No |
| Printed | No |
| Saved to file | No |
@@ -385,7 +385,7 @@ There are rules governing which hint is shown during the recovery (in the order
| Custom URL | Yes |
|----------------------|------------|
| Saved to Microsoft Account | No |
-| Saved to Azure AD | No |
+| Saved to Microsoft Entra ID | No |
| Saved to Active Directory | Yes |
| Printed | No |
| Saved to file | No |
@@ -399,7 +399,7 @@ There are rules governing which hint is shown during the recovery (in the order
| Custom URL | No |
|----------------------|------------|
| Saved to Microsoft Account | Yes |
-| Saved to Azure AD | Yes |
+| Saved to Microsoft Entra ID | Yes |
| Saved to Active Directory | No |
| Printed | Yes |
| Saved to file | Yes |
@@ -413,7 +413,7 @@ There are rules governing which hint is shown during the recovery (in the order
| Custom URL | No |
|----------------------|-----------------|
| Saved to Microsoft Account | No |
-| Saved to Azure AD | No |
+| Saved to Microsoft Entra ID | No |
| Saved to Active Directory | No |
| Printed | No |
| Saved to file | Yes |
@@ -426,7 +426,7 @@ There are rules governing which hint is shown during the recovery (in the order
| Custom URL | No |
|----------------------|-----------------|
| Saved to Microsoft Account | No |
-| Saved to Azure AD | No |
+| Saved to Microsoft Entra ID | No |
| Saved to Active Directory | No |
| Printed | No |
| Saved to file | No |
@@ -442,7 +442,7 @@ There are rules governing which hint is shown during the recovery (in the order
| Custom URL | No |
|----------------------|-----------------|
| Saved to Microsoft Account | Yes |
-| Saved to Azure AD | Yes |
+| Saved to Microsoft Entra ID | Yes |
| Saved to Active Directory | No |
| Printed | No |
| Saved to file | No |
@@ -452,7 +452,7 @@ There are rules governing which hint is shown during the recovery (in the order
| Custom URL | No |
|----------------------|-----------------|
| Saved to Microsoft Account | No |
-| Saved to Azure AD | Yes |
+| Saved to Microsoft Entra ID | Yes |
| Saved to Active Directory | No |
| Printed | No |
| Saved to file | No |
diff --git a/windows/security/operating-system-security/data-protection/bitlocker/faq.yml b/windows/security/operating-system-security/data-protection/bitlocker/faq.yml
index 9af21917f8..7f560a14b9 100644
--- a/windows/security/operating-system-security/data-protection/bitlocker/faq.yml
+++ b/windows/security/operating-system-security/data-protection/bitlocker/faq.yml
@@ -473,4 +473,4 @@ sections:
- question: |
Can I use BitLocker with virtual machines (VMs)?
answer: |
- Yes. Password protectors and virtual TPMs can be used with BitLocker to protect virtual machines. VMs can be domain joined, Azure AD-joined, or workplace-joined (via **Settings** > **Accounts** > **Access work or school** > **Connect**) to receive policy. Encryption can be enabled either while creating the VM or by using other existing management tools such as the BitLocker CSP, or even by using a startup script or sign-in script delivered by Group Policy. Windows Server 2016 also supports [Shielded VMs and guarded fabric](/windows-server/virtualization/guarded-fabric-shielded-vm/guarded-fabric-and-shielded-vms-top-node) to protect VMs from malicious administrators.
+ Yes. Password protectors and virtual TPMs can be used with BitLocker to protect virtual machines. VMs can be domain joined, Microsoft Entra joined, or workplace-joined (via **Settings** > **Accounts** > **Access work or school** > **Connect**) to receive policy. Encryption can be enabled either while creating the VM or by using other existing management tools such as the BitLocker CSP, or even by using a startup script or sign-in script delivered by Group Policy. Windows Server 2016 also supports [Shielded VMs and guarded fabric](/windows-server/virtualization/guarded-fabric-shielded-vm/guarded-fabric-and-shielded-vms-top-node) to protect VMs from malicious administrators.
diff --git a/windows/security/operating-system-security/data-protection/personal-data-encryption/configure.md b/windows/security/operating-system-security/data-protection/personal-data-encryption/configure.md
index 7a7277136f..dc6e715410 100644
--- a/windows/security/operating-system-security/data-protection/personal-data-encryption/configure.md
+++ b/windows/security/operating-system-security/data-protection/personal-data-encryption/configure.md
@@ -32,7 +32,7 @@ The following table lists the recommended settings to improve PDE's security.
|Kernel-mode crash dumps and live dumps|Kernel-mode crash dumps and live dumps can potentially cause the keys used by PDE to protect content to be exposed. For greatest security, disable kernel-mode crash dumps and live dumps.|
|Windows Error Reporting (WER)/user-mode crash dumps|Disabling Windows Error Reporting prevents user-mode crash dumps. User-mode crash dumps can potentially cause the keys used by PDE to protect content to be exposed. For greatest security, disable user-mode crash dumps.|
|Hibernation|Hibernation files can potentially cause the keys used by Personal Data Encryption (PDE) to protect content to be exposed. For greatest security, disable hibernation.|
-|Allow users to select when a password is required when resuming from connected standby |When this policy isn't configured on Azure AD joined devices, users on a Connected Standby device can change the amount of time after the device´s screen turns off before a password is required to wake the device. During the time when the screen turns off but a password isn't required, the keys used by PDE to protect content could potentially be exposed. It's recommended to explicitly disable this policy on Azure AD joined devices.|
+|Allow users to select when a password is required when resuming from connected standby |When this policy isn't configured on Microsoft Entra joined devices, users on a Connected Standby device can change the amount of time after the device´s screen turns off before a password is required to wake the device. During the time when the screen turns off but a password isn't required, the keys used by PDE to protect content could potentially be exposed. It's recommended to explicitly disable this policy on Microsoft Entra joined devices.|
## Configure PDE with Microsoft Intune
diff --git a/windows/security/operating-system-security/data-protection/personal-data-encryption/index.md b/windows/security/operating-system-security/data-protection/personal-data-encryption/index.md
index 0608ea1a7c..14df705407 100644
--- a/windows/security/operating-system-security/data-protection/personal-data-encryption/index.md
+++ b/windows/security/operating-system-security/data-protection/personal-data-encryption/index.md
@@ -25,7 +25,7 @@ Unlike BitLocker that releases data encryption keys at boot, PDE doesn't release
To use PDE, the following prerequisites must be met:
- Windows 11, version 22H2 and later
-- The devices must be [Azure AD joined][AAD-1]. Domain-joined and hybrid Azure AD joined devices aren't supported
+- The devices must be [Microsoft Entra joined][AAD-1]. Domain-joined and Microsoft Entra hybrid joined devices aren't supported
- Users must sign in using [Windows Hello for Business](../../../identity-protection/hello-for-business/index.md)
> [!IMPORTANT]
diff --git a/windows/security/operating-system-security/network-security/vpn/how-to-use-single-sign-on-sso-over-vpn-and-wi-fi-connections.md b/windows/security/operating-system-security/network-security/vpn/how-to-use-single-sign-on-sso-over-vpn-and-wi-fi-connections.md
index ae9673a74d..f61993984e 100644
--- a/windows/security/operating-system-security/network-security/vpn/how-to-use-single-sign-on-sso-over-vpn-and-wi-fi-connections.md
+++ b/windows/security/operating-system-security/network-security/vpn/how-to-use-single-sign-on-sso-over-vpn-and-wi-fi-connections.md
@@ -74,8 +74,8 @@ If the credentials are certificate-based, then the elements in the following tab
|------------------|---------------|
| SubjectName | The user's distinguished name (DN) where the domain components of the distinguished name reflect the internal DNS namespace when the SubjectAlternativeName does not have the fully qualified UPN required to find the domain controller. This requirement is relevant in multi-forest environments as it ensures a domain controller can be located. |
| SubjectAlternativeName | The user's fully qualified UPN where a domain name component of the user's UPN matches the organizations internal domain's DNS namespace. This requirement is relevant in multi-forest environments as it ensures a domain controller can be located when the SubjectName does not have the DN required to find the domain controller. |
-| Key Storage Provider (KSP) | If the device is joined to Azure AD, a discrete SSO certificate is used. |
-| EnhancedKeyUsage | One or more of the following EKUs is required: - Client Authentication (for the VPN)
- EAP Filtering OID (for Windows Hello for Business)
- SmartCardLogon (for Azure AD-joined devices)
If the domain controllers require smart card EKU either:- SmartCardLogon
- id-pkinit-KPClientAuth (1.3.6.1.5.2.3.4)
Otherwise:- TLS/SSL Client Authentication (1.3.6.1.5.5.7.3.2)
|
+| Key Storage Provider (KSP) | If the device is joined to Microsoft Entra ID, a discrete SSO certificate is used. |
+| EnhancedKeyUsage | One or more of the following EKUs is required: - Client Authentication (for the VPN)
- EAP Filtering OID (for Windows Hello for Business)
- SmartCardLogon (for Microsoft Entra joined devices)
If the domain controllers require smart card EKU either:- SmartCardLogon
- id-pkinit-KPClientAuth (1.3.6.1.5.2.3.4)
Otherwise:- TLS/SSL Client Authentication (1.3.6.1.5.5.7.3.2)
|
## NDES server configuration
diff --git a/windows/security/operating-system-security/network-security/vpn/vpn-conditional-access.md b/windows/security/operating-system-security/network-security/vpn/vpn-conditional-access.md
index 26738c946b..2606196671 100644
--- a/windows/security/operating-system-security/network-security/vpn/vpn-conditional-access.md
+++ b/windows/security/operating-system-security/network-security/vpn/vpn-conditional-access.md
@@ -1,25 +1,25 @@
---
title: VPN and conditional access
-description: Learn how to integrate the VPN client with the Conditional Access platform, and how to create access rules for Azure Active Directory (Azure AD) connected apps.
+description: Learn how to integrate the VPN client with the Conditional Access platform, and how to create access rules for Microsoft Entra connected apps.
ms.date: 08/03/2023
ms.topic: conceptual
---
# VPN and conditional access
-The VPN client is now able to integrate with the cloud-based Conditional Access Platform to provide a device compliance option for remote clients. Conditional Access is a policy-based evaluation engine that lets you create access rules for any Azure Active Directory (Azure AD) connected application.
+The VPN client is now able to integrate with the cloud-based Conditional Access Platform to provide a device compliance option for remote clients. Conditional Access is a policy-based evaluation engine that lets you create access rules for any Microsoft Entra connected application.
>[!NOTE]
->Conditional Access is an Azure AD Premium feature.
+>Conditional Access is a Microsoft Entra ID P1 or P2 feature.
Conditional Access Platform components used for Device Compliance include the following cloud-based services:
- [Conditional Access Framework](/archive/blogs/tip_of_the_day/tip-of-the-day-the-conditional-access-framework-and-device-compliance-for-vpn)
-- [Azure AD Connect Health](/azure/active-directory/connect-health/active-directory-aadconnect-health)
+- [Microsoft Entra Connect Health](/azure/active-directory/connect-health/active-directory-aadconnect-health)
- [Windows Health Attestation Service](../../system-security/protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices.md) (optional)
-- Azure AD Certificate Authority - It's a requirement that the client certificate used for the cloud-based device compliance solution be issued by an Azure Active Directory-based Certificate Authority (CA). An Azure AD CA is essentially a mini-CA cloud tenant in Azure. The Azure AD CA can't be configured as part of an on-premises Enterprise CA.
+- Microsoft Entra Certificate Authority - It's a requirement that the client certificate used for the cloud-based device compliance solution be issued by a Microsoft Entra ID-based Certificate Authority (CA). A Microsoft Entra CA is essentially a mini-CA cloud tenant in Azure. The Microsoft Entra CA can't be configured as part of an on-premises Enterprise CA.
See also [Always On VPN deployment for Windows Server and Windows 10](/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/always-on-vpn-deploy).
-- Azure AD-issued short-lived certificates - When a VPN connection attempt is made, the Azure AD Token Broker on the local device communicates with Azure Active Directory, which then checks for health based on compliance rules. If compliant, Azure AD sends back a short-lived certificate that is used to authenticate the VPN. Note that certificate authentication methods such as EAP-TLS can be used. When the client reconnects and determines that the certificate has expired, the client will again check with Azure AD for health validation before a new certificate is issued.
+- Microsoft Entra ID-issued short-lived certificates - When a VPN connection attempt is made, the Microsoft Entra Token Broker on the local device communicates with Microsoft Entra ID, which then checks for health based on compliance rules. If compliant, Microsoft Entra ID sends back a short-lived certificate that is used to authenticate the VPN. Note that certificate authentication methods such as EAP-TLS can be used. When the client reconnects and determines that the certificate has expired, the client will again check with Microsoft Entra ID for health validation before a new certificate is issued.
- [Microsoft Intune device compliance policies](/mem/intune/protect/device-compliance-get-started): Cloud-based device compliance uses Microsoft Intune Compliance Policies, which are capable of querying the device state and define compliance rules for the following, among other things.
- Antivirus status
- Auto-update status and update compliance
@@ -35,12 +35,12 @@ The following client-side components are also required:
## VPN device compliance
-At this time, the Azure AD certificates issued to users don't contain a CRL Distribution Point (CDP) and aren't suitable for Key Distribution Centers (KDCs) to issue Kerberos tokens. For users to gain access to on-premises resources such as files on a network share, client authentication certificates must be deployed to the Windows profiles of the users, and their VPNv2 profiles must contain the <SSO> section.
+At this time, the Microsoft Entra certificates issued to users don't contain a CRL Distribution Point (CDP) and aren't suitable for Key Distribution Centers (KDCs) to issue Kerberos tokens. For users to gain access to on-premises resources such as files on a network share, client authentication certificates must be deployed to the Windows profiles of the users, and their VPNv2 profiles must contain the <SSO> section.
Server-side infrastructure requirements to support VPN device compliance include:
- The VPN server should be configured for certificate authentication.
-- The VPN server should trust the tenant-specific Azure AD CA.
+- The VPN server should trust the tenant-specific Microsoft Entra CA.
- For client access using Kerberos/NTLM, a domain-trusted certificate is deployed to the client device and is configured to be used for single sign-on (SSO).
After the server side is set up, VPN admins can add the policy settings for conditional access to the VPN profile using the VPNv2 DeviceCompliance node.
@@ -48,7 +48,7 @@ After the server side is set up, VPN admins can add the policy settings for cond
Two client-side configuration service providers are leveraged for VPN device compliance.
- VPNv2 CSP DeviceCompliance settings:
- - **Enabled**: enables the Device Compliance flow from the client. If marked as **true**, the VPN client attempts to communicate with Azure AD to get a certificate to use for authentication. The VPN should be set up to use certificate authentication and the VPN server must trust the server returned by Azure AD.
+ - **Enabled**: enables the Device Compliance flow from the client. If marked as **true**, the VPN client attempts to communicate with Microsoft Entra ID to get a certificate to use for authentication. The VPN should be set up to use certificate authentication and the VPN server must trust the server returned by Microsoft Entra ID.
- **Sso**: entries under SSO should be used to direct the VPN client to use a certificate other than the VPN authentication certificate when accessing resources that require Kerberos authentication.
- **Sso/Enabled**: if this field is set to **true**, the VPN client looks for a separate certificate for Kerberos authentication.
- **Sso/IssuerHash**: hashes for the VPN client to look for the correct certificate for Kerberos authentication.
@@ -71,20 +71,22 @@ The VPN client side connection flow works as follows:
When a VPNv2 Profile is configured with \ \true<\/Enabled> the VPN client uses this connection flow:
-1. The VPN client calls into Windows 10's or Windows 11's Azure AD Token Broker, identifying itself as a VPN client.
-1. The Azure AD Token Broker authenticates to Azure AD and provides it with information about the device trying to connect. The Azure AD Server checks if the device is in compliance with the policies.
-1. If compliant, Azure AD requests a short-lived certificate.
-1. Azure AD pushes down a short-lived certificate to the Certificate Store via the Token Broker. The Token Broker then returns control back over to the VPN client for further connection processing.
-1. The VPN client uses the Azure AD-issued certificate to authenticate with the VPN server.
+1. The VPN client calls into Windows 10's or Windows 11's Microsoft Entra Token Broker, identifying itself as a VPN client.
+1. The Microsoft Entra Token Broker authenticates to Microsoft Entra ID and provides it with information about the device trying to connect. The Microsoft Entra Server checks if the device is in compliance with the policies.
+1. If compliant, Microsoft Entra ID requests a short-lived certificate.
+1. Microsoft Entra ID pushes down a short-lived certificate to the Certificate Store via the Token Broker. The Token Broker then returns control back over to the VPN client for further connection processing.
+1. The VPN client uses the Microsoft Entra ID-issued certificate to authenticate with the VPN server.
## Configure conditional access
See [VPN profile options](vpn-profile-options.md) and [VPNv2 CSP](/windows/client-management/mdm/vpnv2-csp) for XML configuration.
-## Learn more about Conditional Access and Azure AD Health
+
-- [Azure Active Directory conditional access](/azure/active-directory/conditional-access/overview)
-- [Getting started with Azure Active Directory Conditional Access](/azure/active-directory/authentication/tutorial-enable-azure-mfa)
+## Learn more about Conditional Access and Microsoft Entra Health
+
+- [Microsoft Entra Conditional Access](/azure/active-directory/conditional-access/overview)
+- [Getting started with Microsoft Entra Conditional Access](/azure/active-directory/authentication/tutorial-enable-azure-mfa)
- [Control the health of Windows devices](../../system-security/protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices.md)
- [Tip of the Day: The Conditional Access Framework and Device Compliance for VPN (Part 1)](/archive/blogs/tip_of_the_day/tip-of-the-day-the-conditional-access-framework-and-device-compliance-for-vpn)
- [Tip of the Day: The Conditional Access Framework and Device Compliance for VPN (Part 2)](/archive/blogs/tip_of_the_day/tip-of-the-day-the-conditional-access-framework-and-device-compliance-for-vpn-part-2)
diff --git a/windows/security/operating-system-security/network-security/vpn/vpn-guide.md b/windows/security/operating-system-security/network-security/vpn/vpn-guide.md
index cd91bd8540..f4b96d4267 100644
--- a/windows/security/operating-system-security/network-security/vpn/vpn-guide.md
+++ b/windows/security/operating-system-security/network-security/vpn/vpn-guide.md
@@ -23,7 +23,7 @@ To create a Windows VPN device configuration profile see: [Windows device settin
| [VPN connection types](vpn-connection-type.md) | Select a VPN client and tunneling protocol |
| [VPN routing decisions](vpn-routing.md) | Choose between split tunnel and force tunnel configuration |
| [VPN authentication options](vpn-authentication.md) | Select a method for Extensible Authentication Protocol (EAP) authentication. |
-| [VPN and conditional access](vpn-conditional-access.md) | Use Azure Active Directory policy evaluation to set access policies for VPN connections. |
+| [VPN and conditional access](vpn-conditional-access.md) | Use Microsoft Entra policy evaluation to set access policies for VPN connections. |
| [VPN name resolution](vpn-name-resolution.md) | Decide how name resolution should work |
| [VPN auto-triggered profile options](vpn-auto-trigger-profile.md) | Set a VPN profile to connect automatically by app or by name, to be "always on", and to not trigger VPN on trusted networks |
| [VPN security features](vpn-security-features.md) | Configure traffic filtering, connect a VPN profile to Windows Information Protection (WIP), and more |
diff --git a/windows/security/operating-system-security/network-security/windows-firewall/best-practices-configuring.md b/windows/security/operating-system-security/network-security/windows-firewall/best-practices-configuring.md
index a61bf25eec..c0f7eb352f 100644
--- a/windows/security/operating-system-security/network-security/windows-firewall/best-practices-configuring.md
+++ b/windows/security/operating-system-security/network-security/windows-firewall/best-practices-configuring.md
@@ -105,7 +105,7 @@ To determine why some applications are blocked from communicating in the network
Creation of application rules at runtime can also be prohibited by administrators using the Settings app or Group Policy.
-
+:::image type="content" alt-text="Windows Firewall prompt." source="images/fw04-userquery.png":::
*Figure 4: Dialog box to allow access*
@@ -185,7 +185,7 @@ incoming connections, including those in the list of allowed apps** setting foun
*Figure 6: Windows settings App/Windows Security/Firewall Protection/Network Type*
-
+:::image type="content" alt-text="Firewall cpl." source="images/fw07-legacy.png":::
*Figure 7: Legacy firewall.cpl*
@@ -208,3 +208,24 @@ For tasks related to creating outbound rules, see [Checklist: Creating Outbound
## Document your changes
When creating an inbound or outbound rule, you should specify details about the app itself, the port range used, and important notes like creation date. Rules must be well-documented for ease of review both by you and other admins. We highly encourage taking the time to make the work of reviewing your firewall rules at a later date easier. And *never* create unnecessary holes in your firewall.
+
+## Configure Windows Firewall rules with WDAC tagging policies
+
+Windows Firewall now supports the use of Windows Defender Application Control (WDAC) Application ID (AppID) tags in firewall rules. With this capability, Windows Firewall rules can now be scoped to an application or a group of applications by referencing process tags, without using absolute path or sacrificing security. There are two steps for this configuration:
+
+### Step 1: Deploy WDAC AppId Tagging Policies
+
+A Windows Defender Application Control (WDAC) policy needs to be deployed which specifies individual applications or groups of applications to apply a PolicyAppId tag to the process token(s). Then, the admin can define firewall rules which are scoped to all processes tagged with the matching PolicyAppId.
+
+Follow the detailed [WDAC Application ID (AppId) Tagging Guide](/windows/security/threat-protection/windows-defender-application-control/appidtagging/windows-defender-application-control-appid-tagging-guide) to create, deploy, and test an AppID (Application ID) policy to tag applications.
+
+### Step 2: Configure Firewall Rules using PolicyAppId Tags
+
+- **Deploy firewall rules with Intune:** When creating firewall rules with Intune Microsoft Defender Firewall Rules, provide the AppId tag in the Policy App ID setting. The properties come directly from the [Firewall configuration service provider ](/windows/client-management/mdm/firewall-csp)(CSP) and apply to the Windows platform.
+You can do this through the Intune admin center under Endpoint security > Firewall. Policy templates can be found via Create policy > Windows 10, Windows 11, and Windows Server > Microsoft Defender Firewall or Microsoft Defender Firewall Rules.
+
+OR
+
+- **Create local firewall rules with PowerShell**: You can use PowerShell to configure by adding a Firewall rule using [New-NetFirewallRule](/powershell/module/netsecurity/new-netfirewallrule) and specify the `–PolicyAppId` tag. You can specify one tag at a time while creating firewall rules. Multiple User Ids are supported.
+
+
diff --git a/windows/security/operating-system-security/system-security/protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices.md b/windows/security/operating-system-security/system-security/protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices.md
index 65b3843328..90f2ed2f75 100644
--- a/windows/security/operating-system-security/system-security/protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices.md
+++ b/windows/security/operating-system-security/system-security/protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices.md
@@ -83,11 +83,11 @@ This section is an overview that describes different parts of the end-to-end sec
| Number | Part of the solution | Description |
| - | - | - |
-| **1** | Windows-based device | The first time a Windows-based device is powered on, the out-of-box experience (OOBE) screen is displayed. During setup, the device can be automatically registered into Azure Active Directory (AD) and enrolled in MDM.
A Windows-based device with TPM can report health status at any time by using the Health Attestation Service available with all supported editions of Windows.|
-| **2** | Identity provider | Azure AD contains users, registered devices, and registered application of organization's tenant. A device always belongs to a user and a user can have multiple devices. A device is represented as an object with different attributes like the compliance status of the device. A trusted MDM can update the compliance status.
Azure AD is more than a repository. Azure AD is able to authenticate users and devices and can also authorize access to managed resources. Azure AD has a conditional access control engine that uses the identity of the user, the location of the device and also the compliance status of the device when making a trusted access decision.|
+| **1** | Windows-based device | The first time a Windows-based device is powered on, the out-of-box experience (OOBE) screen is displayed. During setup, the device can be automatically registered into Microsoft Entra ID and enrolled in MDM.
A Windows-based device with TPM can report health status at any time by using the Health Attestation Service available with all supported editions of Windows.|
+| **2** | Identity provider | Microsoft Entra ID contains users, registered devices, and registered application of organization's tenant. A device always belongs to a user and a user can have multiple devices. A device is represented as an object with different attributes like the compliance status of the device. A trusted MDM can update the compliance status.
Microsoft Entra ID is more than a repository. Microsoft Entra ID is able to authenticate users and devices and can also authorize access to managed resources. Microsoft Entra ID has a conditional access control engine that uses the identity of the user, the location of the device and also the compliance status of the device when making a trusted access decision.|
| **3**|Mobile device management| Windows has MDM support that enables the device to be managed out-of-box without deploying any agent.
MDM can be Microsoft Intune or any third-party MDM solution that is compatible with Windows.|
| **4** | Remote health attestation | The Health Attestation Service is a trusted cloud service operated by Microsoft that performs a series of health checks and reports to MDM what Windows security features are enabled on the device.
Security verification includes boot state (WinPE, Safe Mode, Debug/test modes) and components that manage security and integrity of runtime operations (BitLocker, Device Guard).|
-| **5** | Enterprise managed asset | Enterprise managed asset is the resource to protect.
For example, the asset can be Office 365, other cloud apps, on-premises web resources published by Azure AD, or even VPN access.|
+| **5** | Enterprise managed asset | Enterprise managed asset is the resource to protect.
For example, the asset can be Office 365, other cloud apps, on-premises web resources published by Microsoft Entra ID, or even VPN access.|
The combination of Windows-based devices, identity provider, MDM, and remote health attestation creates a robust end-to-end-solution that provides validation of health and compliance of devices that access high-value assets.
@@ -613,7 +613,7 @@ Windows has an MDM client that ships as part of the operating system. This MDM c
### Third-party MDM server support
-Third-party MDM servers can manage Windows by using the MDM protocol. The built-in management client is able to communicate with a compatible server that supports the OMA-DM protocol to perform enterprise management tasks. For more information, see [Azure Active Directory integration with MDM](/windows/client-management/mdm/azure-active-directory-integration-with-mdm).
+Third-party MDM servers can manage Windows by using the MDM protocol. The built-in management client is able to communicate with a compatible server that supports the OMA-DM protocol to perform enterprise management tasks. For more information, see [Microsoft Entra integration with MDM](/windows/client-management/mdm/azure-active-directory-integration-with-mdm).
> [!NOTE]
> MDM servers do not need to create or download a client to manage Windows. For more information, see [Mobile device management](/windows/client-management/mdm/).
@@ -628,70 +628,70 @@ For more information on how to manage Windows security and system settings with
### Conditional access control
-On most platforms, the Azure Active Directory (Azure AD) device registration happens automatically during enrollment. The device states are written by the MDM solution into Azure AD, and then read by Office 365 (or by any authorized Windows app that interacts with Azure AD) the next time the client tries to access an Office 365 compatible workload.
+On most platforms, the Microsoft Entra device registration happens automatically during enrollment. The device states are written by the MDM solution into Microsoft Entra ID, and then read by Office 365 (or by any authorized Windows app that interacts with Microsoft Entra ID) the next time the client tries to access an Office 365 compatible workload.
If the device isn't registered, the user will get a message with instructions on how to register (also known as enrolling). If the device isn't compliant, the user will get a different message that redirects them to the MDM web portal where they can get more information on the compliance problem and how to resolve it.
-**Azure AD** authenticates the user and the device, **MDM** manages the compliance and conditional access policies, and the **Health Attestation Service** reports about the health of the device in an attested way.
+**Microsoft Entra ID** authenticates the user and the device, **MDM** manages the compliance and conditional access policies, and the **Health Attestation Service** reports about the health of the device in an attested way.
:::image type="content" alt-text="figure 11." source="images/hva-fig10-conditionalaccesscontrol.png":::
### Office 365 conditional access control
-Azure AD enforces conditional access policies to secure access to Office 365 services. A tenant admin can create a conditional access policy that blocks a user on a non-compliant device from accessing an Office 365 service. The user must conform to the company's device policies before access can be granted to the service. Alternately, the admin can also create a policy that requires users to just enroll their devices to gain access to an Office 365 service. Policies may be applied to all users of an organization, or limited to a few target groups and enhanced over time to include more
+Microsoft Entra ID enforces conditional access policies to secure access to Office 365 services. A tenant admin can create a conditional access policy that blocks a user on a non-compliant device from accessing an Office 365 service. The user must conform to the company's device policies before access can be granted to the service. Alternately, the admin can also create a policy that requires users to just enroll their devices to gain access to an Office 365 service. Policies may be applied to all users of an organization, or limited to a few target groups and enhanced over time to include more
target groups.
-When a user requests access to an Office 365 service from a supported device platform, Azure AD authenticates the user and device from which the user launches the request; and grants access to the service only when the user conforms to the policy set for the service. Users that don't have their device enrolled are given remediation instructions on how to enroll and become compliant to access corporate Office 365 services.
+When a user requests access to an Office 365 service from a supported device platform, Microsoft Entra authenticates the user and device from which the user launches the request; and grants access to the service only when the user conforms to the policy set for the service. Users that don't have their device enrolled are given remediation instructions on how to enroll and become compliant to access corporate Office 365 services.
-When a user enrolls, the device is registered with Azure AD, and enrolled with a compatible MDM solution like Intune.
+When a user enrolls, the device is registered with Microsoft Entra ID, and enrolled with a compatible MDM solution like Intune.
> [!NOTE]
-> Microsoft is working with third-party MDM ISVs to support automated MDM enrollment and policy based access checks. Steps to turn on auto-MDM enrollment with Azure AD and Intune are explained in the [Windows, Azure AD And Microsoft Intune: Automatic MDM Enrollment Powered By The Cloud!](https://techcommunity.microsoft.com/t5/azure-active-directory-identity/windows-10-azure-ad-and-microsoft-intune-automatic-mdm/ba-p/244067) blog post.
+> Microsoft is working with third-party MDM ISVs to support automated MDM enrollment and policy based access checks. Steps to turn on auto-MDM enrollment with Microsoft Entra ID and Intune are explained in the [Windows, Microsoft Entra ID And Microsoft Intune: Automatic MDM Enrollment Powered By The Cloud!](https://techcommunity.microsoft.com/t5/azure-active-directory-identity/windows-10-azure-ad-and-microsoft-intune-automatic-mdm/ba-p/244067) blog post.
-When a user enrolls a device successfully, the device becomes trusted. Azure AD provides single-sign-on to access company applications and enforces conditional access policy to grant access to a service not only the first time the user requests access, but every time the user requests to renew access.
+When a user enrolls a device successfully, the device becomes trusted. Microsoft Entra ID provides single-sign-on to access company applications and enforces conditional access policy to grant access to a service not only the first time the user requests access, but every time the user requests to renew access.
The user will be denied access to services when sign-in credentials are changed, a device is lost/stolen, or the compliance policy isn't met at the time of request for renewal.
-Depending on the type of email application that employees use to access Exchange online, the path to establish secured access to email can be slightly different. However, the key components: Azure AD, Office 365/Exchange Online, and Intune, are the same. The IT experience and end-user experience also are similar.
+Depending on the type of email application that employees use to access Exchange online, the path to establish secured access to email can be slightly different. However, the key components: Microsoft Entra ID, Office 365/Exchange Online, and Intune, are the same. The IT experience and end-user experience also are similar.
:::image type="content" alt-text="figure 12." source="images/hva-fig11-office365.png":::
Clients that attempt to access Office 365 will be evaluated for the following properties:
- Is the device managed by an MDM?
-- Is the device registered with Azure AD?
+- Is the device registered with Microsoft Entra ID?
- Is the device compliant?
To get to a compliant state, the Windows-based device needs to:
- Enroll with an MDM solution.
-- Register with Azure AD.
+- Register with Microsoft Entra ID.
- Be compliant with the device policies set by the MDM solution.
> [!NOTE]
-> At the present time, conditional access policies are selectively enforced on users on iOS and Android devices. For more information, see the [Azure AD, Microsoft Intune and Windows - Using the cloud to modernize enterprise mobility!](https://techcommunity.microsoft.com/t5/azure-active-directory-identity/azure-ad-microsoft-intune-and-windows-10-8211-using-the-cloud-to/ba-p/244012) blog post.
+> At the present time, conditional access policies are selectively enforced on users on iOS and Android devices. For more information, see the [Microsoft Entra ID, Microsoft Intune and Windows - Using the cloud to modernize enterprise mobility!](https://techcommunity.microsoft.com/t5/azure-active-directory-identity/azure-ad-microsoft-intune-and-windows-10-8211-using-the-cloud-to/ba-p/244012) blog post.
### Cloud and on-premises apps conditional access control
-Conditional access control is a powerful policy evaluation engine built into Azure AD. It gives IT pros an easy way to create access rules beyond Office 365 that evaluate the context of a user's sign in to make real-time decisions about which applications they should be allowed to access.
+Conditional access control is a powerful policy evaluation engine built into Microsoft Entra ID. It gives IT pros an easy way to create access rules beyond Office 365 that evaluate the context of a user's sign in to make real-time decisions about which applications they should be allowed to access.
-IT pros can configure conditional access control policies for cloud SaaS applications secured by Azure AD and even on-premises applications. Access rules in Azure AD use the conditional access engine to check device health and compliance state reported by a compatible MDM solution like Intune in order to determine whether to allow access.
+IT pros can configure conditional access control policies for cloud SaaS applications secured by Microsoft Entra ID and even on-premises applications. Access rules in Microsoft Entra ID use the conditional access engine to check device health and compliance state reported by a compatible MDM solution like Intune in order to determine whether to allow access.
For more information about conditional access, see [Azure Conditional Access Preview for SaaS Apps.](/azure/active-directory/authentication/tutorial-enable-azure-mfa)
> [!NOTE]
-> Conditional access control is an Azure AD Premium feature that's also available with EMS. If you don't have an Azure AD Premium subscription, you can get a trial from the [Microsoft Azure](https://go.microsoft.com/fwlink/p/?LinkId=691617) site.
+> Conditional access control is a Microsoft Entra ID P1 or P2 feature that's also available with EMS. If you don't have a Microsoft Entra ID P1 or P2 subscription, you can get a trial from the [Microsoft Azure](https://go.microsoft.com/fwlink/p/?LinkId=691617) site.
For on-premises applications there are two options to enable conditional access control based on a device's compliance state:
-- For on-premises applications that are published through the Azure AD Application Proxy, you can configure conditional access control policies as you would for cloud applications. For more information, see [Using Azure AD Application Proxy to publish on-premises apps for remote users](/azure/active-directory/app-proxy/what-is-application-proxy).
-- Additionally, Azure AD Connect will sync device compliance information from Azure AD to on-premises AD. ADFS on Windows Server 2016 will support conditional access control based on a device's compliance state. IT pros will configure conditional access control policies in ADFS that use the device's compliance state reported by a compatible MDM solution to secure on-premises applications.
+- For on-premises applications that are published through the Microsoft Entra application proxy, you can configure conditional access control policies as you would for cloud applications. For more information, see [Using Microsoft Entra application proxy to publish on-premises apps for remote users](/azure/active-directory/app-proxy/what-is-application-proxy).
+- Additionally, Microsoft Entra Connect will sync device compliance information from Microsoft Entra ID to on-premises AD. ADFS on Windows Server 2016 will support conditional access control based on a device's compliance state. IT pros will configure conditional access control policies in ADFS that use the device's compliance state reported by a compatible MDM solution to secure on-premises applications.
:::image type="content" alt-text="figure 13." source="images/hva-fig12-conditionalaccess12.png":::
-The following process describes how Azure AD conditional access works:
+The following process describes how Microsoft Entra Conditional Access works:
-1. User has already enrolled with MDM through Workplace Access/Azure AD join, which registers device with Azure AD.
+1. User has already enrolled with MDM through Workplace Access/Azure AD join, which registers device with Microsoft Entra ID.
2. When the device boots or resumes from hibernate, a task "Tpm-HASCertRetr" is triggered to request in background a health attestation blob. Device sends TPM boot measurements to the Health Attestation Service.
3. Health Attestation Service validates device state and issues an encrypted blob to the device based on the health state with details on failed checks (if any).
4. User logs on and the MDM agent contacts the Intune/MDM server.
@@ -700,13 +700,13 @@ The following process describes how Azure AD conditional access works:
7. Intune/MDM server sends the health attestation blob to Health Attestation Service to be validated.
8. Health Attestation Service validates that the device that sent the health attestation blob is healthy, and returns this result to Intune/MDM server.
9. Intune/MDM server evaluates compliance based on the compliance and the queried inventory/health attestation state from device.
-10. Intune/MDM server updates compliance state against device object in Azure AD.
+10. Intune/MDM server updates compliance state against device object in Microsoft Entra ID.
11. User opens app, attempts to access a corporate managed asset.
-12. Access gated by compliance claim in Azure AD.
+12. Access gated by compliance claim in Microsoft Entra ID.
13. If the device is compliant and the user is authorized, an access token is generated.
14. User can access the corporate managed asset.
-For more information about Azure AD join, see [Azure AD & Windows: Better Together for Work or School](https://go.microsoft.com/fwlink/p/?LinkId=691619), a white paper.
+For more information about Microsoft Entra join, see [Microsoft Entra ID & Windows: Better Together for Work or School](https://go.microsoft.com/fwlink/p/?LinkId=691619), a white paper.
Conditional access control is a topic that many organizations and IT pros may not know and they should. The different attributes that describe a user, a device, compliance, and context of access are powerful when used with a conditional access engine. Conditional access control is an essential step that helps organizations secure their environment.
diff --git a/windows/security/operating-system-security/system-security/trusted-boot.md b/windows/security/operating-system-security/system-security/trusted-boot.md
index 364719eebb..431c65c17d 100644
--- a/windows/security/operating-system-security/system-security/trusted-boot.md
+++ b/windows/security/operating-system-security/system-security/trusted-boot.md
@@ -2,7 +2,7 @@
title: Secure Boot and Trusted Boot
description: Trusted Boot prevents corrupted components from loading during the boot-up process in Windows 11
ms.topic: conceptual
-ms.date: 09/21/2021
+ms.date: 10/30/2023
ms.reviewer: jsuther
appliesto:
- "✅ Windows 11"
diff --git a/windows/security/security-foundations/zero-trust-windows-device-health.md b/windows/security/security-foundations/zero-trust-windows-device-health.md
index 64696d3e5d..65cc2e9e7d 100644
--- a/windows/security/security-foundations/zero-trust-windows-device-health.md
+++ b/windows/security/security-foundations/zero-trust-windows-device-health.md
@@ -51,7 +51,7 @@ A summary of the steps involved in attestation and Zero Trust on the device side
3. The TPM is verified by using the keys/cryptographic material available on the chipset with an [Azure Certificate Service](/windows-server/identity/ad-ds/manage/component-updates/tpm-key-attestation).
-4. This information is then sent to the attestation service in the cloud to verify that the device is safe. Microsoft Endpoint Manger integrates with Microsoft Azure Attestation to review device health comprehensively and connect this information with Azure Active Directory conditional access. This integration is key for Zero Trust solutions that help bind trust to an untrusted device.
+4. This information is then sent to the attestation service in the cloud to verify that the device is safe. Microsoft Endpoint Manger integrates with Microsoft Azure Attestation to review device health comprehensively and connect this information with Microsoft Entra Conditional Access. This integration is key for Zero Trust solutions that help bind trust to an untrusted device.
5. The attestation service does the following tasks:
diff --git a/windows/security/threat-protection/security-policy-settings/dcom-machine-launch-restrictions-in-security-descriptor-definition-language-sddl-syntax.md b/windows/security/threat-protection/security-policy-settings/dcom-machine-launch-restrictions-in-security-descriptor-definition-language-sddl-syntax.md
index 81cfb68761..d4c07f3415 100644
--- a/windows/security/threat-protection/security-policy-settings/dcom-machine-launch-restrictions-in-security-descriptor-definition-language-sddl-syntax.md
+++ b/windows/security/threat-protection/security-policy-settings/dcom-machine-launch-restrictions-in-security-descriptor-definition-language-sddl-syntax.md
@@ -37,7 +37,7 @@ Access and Remote Access permissions to users and groups. We recommend that you
- Blank
- This value represents how the local security policy deletes the policy enforcement key. This value deletes the policy and then sets it to Not defined. The Blank value is set by using the ACL editor to empty the list, and then pressing OK.
+ This value represents how the local security policy deletes the policy enforcement key. This value deletes the policy and then sets it as Not defined. To set a blank value, select "Define this policy setting" and leave the Security descriptor empty, then select OK.
- *User-defined input* of the SDDL representation of the groups and privileges
diff --git a/windows/security/threat-protection/security-policy-settings/maximum-password-age.md b/windows/security/threat-protection/security-policy-settings/maximum-password-age.md
index 87337b86b8..1e3180694c 100644
--- a/windows/security/threat-protection/security-policy-settings/maximum-password-age.md
+++ b/windows/security/threat-protection/security-policy-settings/maximum-password-age.md
@@ -41,7 +41,7 @@ The **Maximum password age** policy setting determines the period of time (in da
Set **Maximum password age** to a value between 30 and 90 days, depending on your environment. This way, an attacker has a limited amount of time in which to compromise a user's password and have access to your network resources.
> [!NOTE]
-> The security baseline recommended by Microsoft doesn't contain the password-expiration policy, as it is less effective than modern mitigations. However, companies that didn't implement Azure AD Password Protection, multifactor authentication, or other modern mitigations of password-guessing attacks, should leave this policy in effect.
+> The security baseline recommended by Microsoft doesn't contain the password-expiration policy, as it is less effective than modern mitigations. However, companies that didn't implement Microsoft Entra Password Protection, multifactor authentication, or other modern mitigations of password-guessing attacks, should leave this policy in effect.
### Location
diff --git a/windows/security/threat-protection/security-policy-settings/network-security-allow-pku2u-authentication-requests-to-this-computer-to-use-online-identities.md b/windows/security/threat-protection/security-policy-settings/network-security-allow-pku2u-authentication-requests-to-this-computer-to-use-online-identities.md
index ce5adb5c59..abc5d527cd 100644
--- a/windows/security/threat-protection/security-policy-settings/network-security-allow-pku2u-authentication-requests-to-this-computer-to-use-online-identities.md
+++ b/windows/security/threat-protection/security-policy-settings/network-security-allow-pku2u-authentication-requests-to-this-computer-to-use-online-identities.md
@@ -41,7 +41,7 @@ This policy isn't configured by default on domain-joined devices. This disableme
- **Enabled**: This setting allows authentication to successfully complete between the two (or more) computers that have established a peer relationship by using online IDs. The PKU2U SSP obtains a local certificate and exchanges the policy between the peer devices. When validated on the peer computer, the certificate within the metadata is sent to the sign-in peer for validation. It associates the user's certificate to a security token, and then the sign-in process completes.
> [!NOTE]
- > PKU2U is disabled by default on Windows Server. If PKU2U is disabled, Remote Desktop connections from a hybrid Azure AD-joined server to an Azure AD-joined Windows 10 device or a Hybrid Azure AD-joined domain member Windows 10 device fail. To resolve this, enable PKU2U on the server and the client.
+ > PKU2U is disabled by default on Windows Server. If PKU2U is disabled, Remote Desktop connections from a Microsoft Entra hybrid joined server to a Microsoft Entra joined Windows 10 device or a Microsoft Entra hybrid joined domain member Windows 10 device fail. To resolve this, enable PKU2U on the server and the client.
- **Disabled**: This setting prevents online IDs from being used to authenticate the user to another computer in a peer-to-peer relationship.
@@ -49,7 +49,7 @@ This policy isn't configured by default on domain-joined devices. This disableme
### Best practices
-Within a domain, domain accounts should be used for authentication. Set this policy to **Disabled** or don't configure this policy to exclude online identities from being used to authenticate for on-premises only environments. Set this policy to **Enabled** for hybrid and Azure AD-joined environments.
+Within a domain, domain accounts should be used for authentication. Set this policy to **Disabled** or don't configure this policy to exclude online identities from being used to authenticate for on-premises only environments. Set this policy to **Enabled** for hybrid and Microsoft Entra joined environments.
### Location
@@ -75,7 +75,7 @@ This section describes how an attacker might exploit a feature or its configurat
### Vulnerability
-Enabling this policy setting allows a user’s account on one computer to be associated with an online identity, such as Microsoft account or an Azure AD account. That account can then sign in to a peer device (if the peer device is likewise configured) without the use of a Windows sign-in account (domain or local). This setup isn't only beneficial, but required for Azure AD-joined devices, where they're signed in with an online identity and are issued certificates by Azure AD. This policy may not be relevant for an *on-premises only* environment and might circumvent established security policies. However, it doesn't pose any threats in a hybrid environment where Azure AD is used as it relies on the user's online identity and Azure AD to authenticate.
+Enabling this policy setting allows a user’s account on one computer to be associated with an online identity, such as Microsoft account or a Microsoft Entra account. That account can then sign in to a peer device (if the peer device is likewise configured) without the use of a Windows sign-in account (domain or local). This setup isn't only beneficial, but required for Microsoft Entra joined devices, where they're signed in with an online identity and are issued certificates by Microsoft Entra ID. This policy may not be relevant for an *on-premises only* environment and might circumvent established security policies. However, it doesn't pose any threats in a hybrid environment where Microsoft Entra ID is used as it relies on the user's online identity and Microsoft Entra ID to authenticate.
### Countermeasure
@@ -85,7 +85,7 @@ Set this policy to *Disabled* or don't configure this security policy for *on-pr
If you don't set or you disable this policy, the PKU2U protocol won't be used to authenticate between peer devices, which forces users to follow domain-defined access control policies. This disablement is a valid configuration in *on-premises only* environments. Some roles/features (such as Failover Clustering) don't utilize a domain account for its PKU2U authentication and will cease to function properly when disabling this policy.
-If you enable this policy in a hybrid environment, you allow your users to authenticate by using certificates issued by Azure AD and their online identity between the corresponding devices. This configuration allows users to share resources between such devices. If this policy isn't enabled, remote connections to an Azure AD joined device won't work.
+If you enable this policy in a hybrid environment, you allow your users to authenticate by using certificates issued by Microsoft Entra ID and their online identity between the corresponding devices. This configuration allows users to share resources between such devices. If this policy isn't enabled, remote connections to a Microsoft Entra joined device won't work.
### Fix/Remediation
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/docfx.json b/windows/whats-new/docfx.json
index 036ef0bfa2..ec64e498bc 100644
--- a/windows/whats-new/docfx.json
+++ b/windows/whats-new/docfx.json
@@ -59,7 +59,10 @@
"jborsecnik",
"tiburd",
"garycentric",
- "beccarobins"
+ "beccarobins",
+ "Stacyrch140",
+ "v-stsavell",
+ "American-Dipper"
],
"searchScope": ["Windows 10"]
},
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.