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 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-deployment-journey.png b/windows/deployment/windows-autopatch/media/windows-autopatch-deployment-journey.png new file mode 100644 index 0000000000..1e898235fa Binary files /dev/null and b/windows/deployment/windows-autopatch/media/windows-autopatch-deployment-journey.png differ 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-edge.md b/windows/deployment/windows-autopatch/operate/windows-autopatch-edge.md index 03e04c49d8..5aadb310ef 100644 --- a/windows/deployment/windows-autopatch/operate/windows-autopatch-edge.md +++ b/windows/deployment/windows-autopatch/operate/windows-autopatch-edge.md @@ -1,7 +1,7 @@ --- title: Microsoft Edge description: This article explains how Microsoft Edge updates are managed in Windows Autopatch -ms.date: 05/30/2022 +ms.date: 09/15/2023 ms.prod: windows-client ms.technology: itpro-updates ms.topic: conceptual 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 e3b0793469..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 @@ -53,4 +53,4 @@ You can view the excluded devices in the **Not registered** tab to make it easie 1. Select **Windows Autopatch** in the left navigation menu. 1. Select **Devices**. 1. In the **Not registered** tab, select the device(s) you want to restore. -1. Once a device or multiple devices are selected, select **Device actions**. Then, select **Restore device**. +1. Once a device or multiple devices are selected, select **Device actions**. Then, select **Restore excluded device**. 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-overview.md b/windows/deployment/windows-autopatch/operate/windows-autopatch-groups-windows-quality-update-overview.md index 57b9aa5aad..34a3b93fab 100644 --- a/windows/deployment/windows-autopatch/operate/windows-autopatch-groups-windows-quality-update-overview.md +++ b/windows/deployment/windows-autopatch/operate/windows-autopatch-groups-windows-quality-update-overview.md @@ -1,7 +1,7 @@ --- title: Windows quality updates overview with Autopatch groups experience description: This article explains how Windows quality updates are managed with Autopatch groups -ms.date: 07/25/2023 +ms.date: 08/23/2023 ms.prod: windows-client ms.technology: itpro-updates ms.topic: conceptual @@ -24,17 +24,17 @@ To release updates to devices in a gradual manner, Windows Autopatch deploys a s | Policy | Description | | ----- | ----- | | [Deferrals](/windows/client-management/mdm/policy-csp-update#update-deferqualityupdatesperiodindays) | Deferral policies delay the time the update is offered to the device by a specific number of days. The "offer" date for Windows quality updates is equal to the number of days specified in the deferral policy after the second Tuesday of each month. | -| [Deadlines](/windows/client-management/mdm/policy-csp-update#update-autorestartdeadlineperiodindays) | Before the deadline, restarts can be scheduled by users or automatically scheduled outside of active hours. After the deadline passes, restarts will occur regardless of active hours and users won't be able to reschedule. The deadline for a specific device is set to be the specified number of days after the update is offered to the device. | +| [Deadlines](/windows/client-management/mdm/policy-csp-update#update-autorestartdeadlineperiodindays) | Before the deadline, users can schedule restarts or automatically scheduled outside of active hours. After the deadline passes, restarts will occur regardless of active hours and users won't be able to reschedule. The deadline for a specific device is set to be the specified number of days after the update is offered to the device. | | [Grace periods](/windows/client-management/mdm/policy-csp-update#update-configuredeadlinegraceperiod) | This policy specifies a minimum number of days after an update is downloaded until the device is automatically restarted. This policy overrides the deadline policy so that if a user comes back from vacation, it prevents the device from forcing a restart to complete the update as soon as it comes online. | -For devices in the [Default Autopatch group](../deploy/windows-autopatch-groups-overview.md#about-the-default-autopatch-group), Windows Autopatch configures these policies differently across deployment rings to gradually release the update. Devices in the Test ring receive changes first and devices in the Last ring receive changes last. For more information about the Test and Last deployment rings, see [About the Test and Last deployment rings in Autopatch groups](../deploy/windows-autopatch-groups-overview.md#about-the-test-and-last-deployment-rings). With Windows Autopatch groups you can also customize the [Default Deployment Group’s deployment ring composition](../deploy/windows-autopatch-groups-overview.md#default-deployment-ring-composition) to add and/or remove deployment rings and can customize the update deployment cadences for each deployment ring. To learn more about customizing Windows Quality updates deployment cadence, see [Customize Windows Update settings](../operate/windows-autopatch-groups-windows-update.md). +For devices in the [Default Autopatch group](../deploy/windows-autopatch-groups-overview.md#about-the-default-autopatch-group), Windows Autopatch configures these policies differently across deployment rings to gradually release the update. Devices in the Test ring receive changes first and devices in the Last ring receive changes last. For more information about the Test and Last deployment rings, see [About the Test and Last deployment rings in Autopatch groups](../deploy/windows-autopatch-groups-overview.md#about-the-test-and-last-deployment-rings). With Windows Autopatch groups, you can also customize the [Default Deployment Group’s deployment ring composition](../deploy/windows-autopatch-groups-overview.md#default-deployment-ring-composition) to add and/or remove deployment rings and can customize the update deployment cadences for each deployment ring. To learn more about customizing Windows Quality updates deployment cadence, see [Customize Windows Update settings](../operate/windows-autopatch-groups-windows-update.md). > [!IMPORTANT] > Deploying deferral, deadline, or grace period policies which conflict with Autopatch's policies will cause a device to be considered ineligible for management, it will still receive policies from Windows Autopatch that are not in conflict, but may not function as designed. These devices will be marked as ineligible in our device reporting and will not count towards our [service level objective](#service-level-objective). ## Service level objective -Windows Autopatch aims to keep at least 95% of eligible devices on the latest Windows quality update 21 days after release. Note that devices that have cadence type set to Schedule install won't be eligible for Windows quality update SLO. For more information about the Schedule Install cadence type, see [Deployment cadence types](../operate/windows-autopatch-groups-windows-update.md#deployment-cadence). +Windows Autopatch aims to keep at least 95% of eligible devices on the latest Windows quality update 21 days after release. Devices that have cadence type set to Schedule install aren't eligible for Windows quality update SLO. For more information about the Schedule Install cadence type, see [Deployment cadence types](../operate/windows-autopatch-groups-windows-update.md#deployment-cadence). > [!IMPORTANT] > Windows Autopatch supports registering [Windows 10 Long-Term Servicing Channel (LTSC)](/windows/whats-new/ltsc/) devices that are being currently serviced by the [Windows LTSC](/windows/release-health/release-information). The service only supports managing the [Windows quality updates](../operate/windows-autopatch-windows-quality-update-overview.md) workload for devices currently serviced by the LTSC. Windows Update for Business service and Windows Autopatch don't offer Windows feature updates for devices that are part of the LTSC. You must either use [LTSC media](https://www.microsoft.com/evalcenter/evaluate-windows-10-enterprise) or the [Configuration Manager Operating System Deployment capabilities to perform an in-place upgrade](/windows/deployment/deploy-windows-cm/upgrade-to-windows-10-with-configuration-manager) for Windows devices that are part of the LTSC. @@ -54,7 +54,7 @@ In the Release management blade, you can: For each [deployment ring](windows-autopatch-update-management.md#windows-autopatch-deployment-rings), the **Release schedule** tab contains: -- The status of the update. Releases will appear as **Active**. The update schedule is based on the values of the [Windows 10 Update Ring policies](/mem/intune/protect/windows-update-for-business-configure), which have been configured on your behalf. +- The status of the update. Releases appear as **Active**. The update schedule is based on the values of the [Windows 10 Update Ring policies](/mem/intune/protect/windows-update-for-business-configure), which have been configured on your behalf. - The date the update is available. - The target completion date of the update. - In the **Release schedule** tab, you can either [**Pause** and/or **Resume**](#pause-and-resume-a-release) a Windows quality update release. @@ -63,7 +63,7 @@ For each [deployment ring](windows-autopatch-update-management.md#windows-autopa Threat and vulnerability information about a new revision of Windows becomes available on the second Tuesday of each month. Windows Autopatch assesses that information shortly afterwards. If the service determines that it's critical to security, it may be expedited. The quality update is also evaluated on an ongoing basis throughout the release and Windows Autopatch may choose to expedite at any time during the release. -When running an expedited release, the regular goal of 95% of devices in 21 days no longer applies. Instead, Windows Autopatch greatly accelerates the release schedule of the release to update the environment more quickly. This approach requires an updated schedule for all devices outside of the Test ring since those devices are already getting the update quickly. +When expediting a release, the regular goal of 95% of devices in 21 days no longer applies. Instead, Windows Autopatch greatly accelerates the release schedule of the release to update the environment more quickly. This approach requires an updated schedule for all devices outside of the Test ring since those devices are already getting the update quickly. | Release type | Group | Deferral | Deadline | Grace period | | ----- | ----- | ----- | ----- | ----- | @@ -87,7 +87,7 @@ By default, the service expedites quality updates as needed. For those organizat Windows Autopatch schedules and deploys required Out of Band (OOB) updates released outside of the normal schedule. -For the deployment rings that have passed quality updates deferral date, the OOB release schedule will be expedited and deployed on the same day. For the deployment rings that have deferral upcoming, OOBs will be released as per the set deferral dates. +For the deployment rings that have passed quality updates deferral date, the OOB release schedule is expedited and deployed on the same day. For the deployment rings that have deferral upcoming, OOBs is released as per the set deferral dates. **To view deployed Out of Band quality updates:** @@ -114,19 +114,19 @@ If Windows Autopatch detects a [significant issue with a release](../operate/win 1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431). 1. Select **Devices** from the left navigation menu. 1. Under the **Windows Autopatch** section, select **Release management**. -1. In the **Release management** blade, got to the **Release schedule** tab and select **Windows quality updates**. -1. Select the Autopatch group that you want to pause or resume. Select either: **Pause** or **Resume**. Alternatively, you can select the **horizontal ellipses (...)** of the Autopatch group you want to pause or resume. Select, **Pause** or **Resume** from the dropdown menu. -1. Select a reason from the dropdown menu. -1. Optional. Enter details about why you're pausing or resuming the selected update. -1. If you're resuming an update, you can select one or more deployment rings. -1. Select **Okay**. +1. In the **Release management** blade, go to the **Release schedule** tab and select **Windows quality updates**. +1. Select the Autopatch group or deployment ring that you want to pause or resume. Select either: **Pause** or **Resume**. Alternatively, you can select the **horizontal ellipses (...)** of the Autopatch group or deployment ring you want to pause or resume. Select, **Pause** or **Resume** from the dropdown menu. +1. Optional. Enter the justification(s) about why you're pausing or resuming the selected update. +1. Optional. Select **This pause is related to Windows Update**. When you select this checkbox, you must provide information about how the pause is related to Windows Update. +1. If you're resuming an update, you can select one or more Autopatch groups or deployment rings. +1. Select **Pause or Resume deployment**. The three following statuses are associated with paused quality updates: | Status | Description | | ----- | ------ | -| Paused by Service | If the Windows Autopatch service has paused an update, the release will have the **Paused by Service** status. The Paused by Service only applies to rings that aren't Paused by the Tenant. | -| Paused by Tenant | If you've paused an update, the release will have the **Paused by Tenant** status. The Windows Autopatch service can't overwrite a tenant pause. You must select **Resume** to resume the update. | +| Paused by Service | If the Windows Autopatch service has paused an update, the release has the **Paused by Service** status. The Paused by Service only applies to rings that aren't Paused by the Tenant. | +| Paused by Tenant | If you've paused an update, the release has the **Paused by Tenant** status. The Windows Autopatch service can't overwrite a tenant pause. You must select **Resume** to resume the update. | ## Remediating Not ready and/or Not up to Date devices 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:
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:**
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:
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:**
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: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: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:
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-manage-driver-and-firmware-updates.md b/windows/deployment/windows-autopatch/operate/windows-autopatch-manage-driver-and-firmware-updates.md index e0298e93f1..041df4c91f 100644 --- a/windows/deployment/windows-autopatch/operate/windows-autopatch-manage-driver-and-firmware-updates.md +++ b/windows/deployment/windows-autopatch/operate/windows-autopatch-manage-driver-and-firmware-updates.md @@ -1,7 +1,7 @@ --- title: Manage driver and firmware updates description: This article explains how you can manage driver and firmware updates with Windows Autopatch -ms.date: 07/04/2023 +ms.date: 08/22/2023 ms.prod: windows-client ms.technology: itpro-updates ms.topic: how-to @@ -15,10 +15,7 @@ ms.collection: - tier1 --- -# Manage driver and firmware updates (public preview) - -> [!IMPORTANT] -> This feature is in **public preview**. The feature is being actively developed, and might not be complete. You can test and use these features in production environments and provide feedback. +# Manage driver and firmware updates You can manage and control your driver and firmware updates with Windows Autopatch. You can choose to receive driver and firmware updates automatically, or self-manage the deployment. @@ -32,7 +29,7 @@ Switching the toggle between Automatic and Self-managed modes creates driver pro | Modes | Description | | ----- | -----| | Automatic | We recommend using **Automatic** mode.Automatic mode (default) is recommended for organizations with standard Original Equipment Manufacturer (OEM) devices where no recent driver or hardware issues have occurred due to Windows Updates. Automatic mode ensures the most secure drivers are installed using Autopatch deployment ring rollout.
| -| Self-managed | When you use the the **Self-managed** mode for drivers and firmware, no drivers are installed in your environment without your explicit approval. You can still use Intune to choose specific drivers and deploy them on a ring-by-ring basis.Self-managed mode turns off Windows Autopatch’s automatic driver deployment. Instead, the Administrator controls the driver deployment.
The Administrator selects the individual driver within an Intune driver update profile. Then, Autopatch creates an Intune driver update profile per deployment ring. Drivers can vary between deployment rings.
The drivers listed for selection represent only the drivers needed for the targeted clients, which are the Autopatch rings. Therefore, the drivers offered may vary between rings depending on the variety of device hardware in an organization.
| +| Self-managed | When you use **Self-managed** mode, no drivers are installed in your environment without your explicit approval. You can still use Intune to choose specific drivers and deploy them on a ring-by-ring basis.Self-managed mode turns off Windows Autopatch’s automatic driver deployment. Instead, the Administrator controls the driver deployment.
The Administrator selects the individual driver within an Intune driver update profile. Then, Autopatch creates an Intune driver update profile per deployment ring. Drivers can vary between deployment rings.
The drivers listed for selection represent only the drivers needed for the targeted clients, which are the Autopatch rings. Therefore, the drivers offered may vary between rings depending on the variety of device hardware in an organization.
| ## Set driver and firmware updates to Automatic or Self-managed mode @@ -49,16 +46,16 @@ Switching the toggle between Automatic and Self-managed modes creates driver pro 1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431). 1. Navigate to **Devices** > **Driver updates for Windows 10 and later**. -1. Windows Autopatch creates four policies. The policy names begin with **Windows Autopatch – Driver Update Policy** and end with the name of the ring to which they're targeted in brackets. For example, **Windows Autopatch – Driver Update Policy [Test]**. +1. Windows Autopatch creates four policies. The policy names begin with **Windows Autopatch – Driver Update Policy** and end with the name of the deployment ring to which they're targeted in brackets. For example, **Windows Autopatch – Driver Update Policy [Test]**. The `CreateDriverUpdatePolicy` is created for the Test, First, Fast, and Broad deployment rings. The policy settings are defined in the following table: | Policy name | DisplayName | Description | Approval Type | DeploymentDeferralInDays | | ----- | ----- | ----- | ----- | ----- | -| `CreateDriverUpdatePolicy` | Windows Autopatch – Driver Update Policy [Test/First/Fast/Broad] | Driver Update Policy for device Test/First/Fast/Broad group | Automatic | `0` | - -> [!NOTE] -> In public preview, the DeploymentDeferralInDays setting is set to `0` for all deployment rings. +| `CreateDriverUpdatePolicy` | Windows Autopatch – Driver Update Policy [**Test**] | Driver Update Policy for device **Test** group | Automatic | `0` | +| `CreateDriverUpdatePolicy`| Windows Autopatch – Driver Update Policy [**First**] | Driver Update Policy for device **First** group | Automatic | `1` | +| `CreateDriverUpdatePolicy` |Windows Autopatch – Driver Update Policy [**Fast**] | Driver Update Policy for device **Fast** group | Automatic | `6` | +| `CreateDriverUpdatePolicy` | Windows Autopatch – Driver Update Policy [**Broad**] | Driver Update Policy for device **Broad** group | Automatic | `9` | ## Feedback and support diff --git a/windows/deployment/windows-autopatch/operate/windows-autopatch-teams.md b/windows/deployment/windows-autopatch/operate/windows-autopatch-teams.md index 5c0649bc8e..21a44e576c 100644 --- a/windows/deployment/windows-autopatch/operate/windows-autopatch-teams.md +++ b/windows/deployment/windows-autopatch/operate/windows-autopatch-teams.md @@ -1,7 +1,7 @@ --- title: Microsoft Teams description: This article explains how Microsoft Teams updates are managed in Windows Autopatch -ms.date: 05/30/2022 +ms.date: 09/15/2023 ms.prod: windows-client ms.technology: itpro-updates ms.topic: conceptual 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 new file mode 100644 index 0000000000..7fc5bce674 --- /dev/null +++ b/windows/deployment/windows-autopatch/overview/windows-autopatch-deployment-guide.md @@ -0,0 +1,337 @@ +--- +title: Windows Autopatch deployment guide +description: This guide explains how to successfully deploy Windows Autopatch in your environment +ms.date: 08/24/2023 +ms.prod: windows-client +ms.technology: itpro-updates +ms.topic: how-to +ms.localizationpriority: medium +author: tiaraquan +ms.author: tiaraquan +manager: dougeby +ms.reviewer: hathind +ms.collection: + - tier2 +--- + +# Windows Autopatch deployment guide + +As organizations move to support hybrid and remote workforces, and continue to adopt cloud-based endpoint management with services such as Intune, managing updates is critical. + +Windows Autopatch is a cloud service that automates Windows, Microsoft 365 Apps for enterprise, Microsoft Edge, and Microsoft Teams updates to improve security and productivity across your organization. + +A successful Windows Autopatch deployment starts with planning and determining your objectives. Use this deployment guide to plan your move or migration to Windows Autopatch. + +This guide: + +- Helps you plan your deployment and adopt Windows Autopatch +- Lists and describes some common objectives +- Provides a recommended deployment plan +- Provides migration considerations for Windows Update for Business (WUfB) and Microsoft Configuration Manager +- Lists some common general considerations when deploying Windows Autopatch +- Provides suggested business case benefits and communication guidance +- Gives additional guidance and how to join the Autopatch community + +## Determine your objectives + +This section details some common objectives when using Windows Autopatch. + +Once an organization is onboarded, Windows Autopatch automatically creates multiple progressive deployment rings and applies the latest updates according to Windows Autopatch recommended practices and your organization's custom configuration. While there are options to adjust configurations such as quality update cadence, the service provides you with a baseline to begin establishing your update objectives. + +Use Windows Autopatch to solve the following challenges: + +- Difficulty developing and defending update cadence and general best practices +- Increase visibility and improve issue reporting +- Achieving a consistent update success rate +- Standardize and optimize the configuration for devices, policies, tools and versions across their environment +- Transition to modern update management by configuring Intune and Windows Update for Business +- Make update processes more efficient and less reliant on IT admin resources +- Address vulnerabilities and Windows quality updates as soon as possible to improve security +- Assist with compliance to align with industry standards +- Invest more time on value-add IT projects rather than monthly updates +- Planning and managing Windows feature updates +- Transition to Windows 11 + +## Recommended deployment steps + +The following deployment steps can be used as a guide to help you to create your organization's specific deployment plan to adopt and deploy Windows Autopatch. + +:::image type="content" source="../media/windows-autopatch-deployment-journey.png" alt-text="Windows Autopatch deployment journey" lightbox="../media/windows-autopatch-deployment-journey.png"::: + +### Step one: Prepare + +[Review the prerequisites](../prepare/windows-autopatch-prerequisites.md) and [enroll your tenant](../prepare/windows-autopatch-enroll-tenant.md) into the Windows Autopatch service. At this stage, your devices aren't affected. You can enroll your tenant and review the service options before registering your devices. + +| Step | Description | +| ----- | ----- | +| **1A: Set up the service** |[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 afe28158bc..95f0ed85fc 100644 --- a/windows/deployment/windows-autopatch/prepare/windows-autopatch-enroll-tenant.md +++ b/windows/deployment/windows-autopatch/prepare/windows-autopatch-enroll-tenant.md @@ -1,7 +1,7 @@ --- title: Enroll your tenant description: This article details how to enroll your tenant -ms.date: 07/11/2022 +ms.date: 09/15/2023 ms.prod: windows-client ms.technology: itpro-updates ms.topic: how-to @@ -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.
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:
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-conflicting-configurations.md b/windows/deployment/windows-autopatch/references/windows-autopatch-conflicting-configurations.md new file mode 100644 index 0000000000..865f6c15c9 --- /dev/null +++ b/windows/deployment/windows-autopatch/references/windows-autopatch-conflicting-configurations.md @@ -0,0 +1,153 @@ +--- +title: Conflicting configurations +description: This article explains how to remediate conflicting configurations affecting the Windows Autopatch service. +ms.date: 09/05/2023 +ms.prod: windows-client +ms.technology: itpro-updates +ms.topic: conceptual +ms.localizationpriority: medium +author: tiaraquan +ms.author: tiaraquan +manager: dougeby +ms.reviewer: adnich +ms.collection: + - highpri + - tier1 +--- + +# Conflicting configurations (public preview) + +> [!IMPORTANT] +> This feature is in **public preview**. The feature is being actively developed and might not be complete. + +During Readiness checks, if there are devices with conflicting registry configurations, notifications are listed in the **Not ready** tab. The notifications include a list of alerts that explain why the device isn't ready for updates. Instructions are provided on how to resolve the issue(s). You can review any device marked as **Not ready** and remediate them to a **Ready** state. + +Windows Autopatch monitors conflicting configurations. You’re notified of the specific registry values that prevent Windows from updating properly. These registry keys should be removed to resolve the conflict. However, it’s possible that other services write back the registry keys. It’s recommended that you review common sources for conflicting configurations to ensure your devices continue to receive Windows Updates. + +The most common sources of conflicting configurations include: + +- Active Directory Group Policy (GPO) +- Configuration Manager Device client settings +- Windows Update for Business (WUfB) policies +- Manual registry updates +- Local Group Policy settings applied during imaging (LGPO) + +## Registry keys inspected by Autopatch + +```cmd +Location= HKLM:SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\DoNotConnectToWindowsUpdateInternetLocations Value=Any +Location= HKLM:SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\DisableWindowsUpdateAccess Value=Any +Location= HKLM:SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\WUServer String=Any +Location= HKLM:SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\UseWUServer Value=Any +Location= HKLM:SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\NoAutoUpdate Value=Any +``` + +## Resolving conflicts + +Windows Autopatch recommends removing the conflicting configurations. The following remediation examples can be used to remove conflicting settings and registry keys when targeted at Autopatch-managed clients. + +> [!IMPORTANT] +> **It’s recommended to only target devices with conflicting configuration alerts**. The following remediation examples can affect devices that aren’t managed by Windows Autopatch, be sure to target accordingly. + +### Intune Remediation + +Navigate to Intune Remediations and create a remediation using the following examples. It’s recommended to create a single remediation per value to understand if the value persists after removal. + +If you use either [**Detect**](#detect) and/or [**Remediate**](#remediate) actions, ensure to update the appropriate **Path** and **Value** called out in the Alert. For more information, see [Remediations](/mem/intune/fundamentals/remediations). + +#### Detect + +```powershell +if((Get-ItemProperty HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate).PSObject.Properties.Name -contains 'DoNotConnectToWindowsUpdateInternetLocations') { + Exit 1 +} else { + exit 0 +} +``` + +| Alert details | Description | +| ----- | ----- | +| Path | `HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate` | +| Value | `DoNotConnectToWindowsUpdateInternetLocations` | + +#### Remediate + +```powershell +if((Get-ItemProperty HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate).PSObject.Properties.Name -contains 'DoNotConnectToWindowsUpdateInternetLocations') { + Remove-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" -Name "DoNotConnectToWindowsUpdateInternetLocations" +} +``` + +| Alert details | Description | +| ----- | ----- | +| Path | `HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate` | +| Value | `DoNotConnectToWindowsUpdateInternetLocations` | + +### PowerShell + +Copy and paste the following PowerShell script into PowerShell or a PowerShell editor, and save it with a `.ps1` extension. For more information, see [Remove-ItemProperty (Microsoft.PowerShell.Management)](/powershell/module/microsoft.powershell.management/remove-itemproperty). + +```powershell +Remove-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" -Name "DoNotConnectToWindowsUpdateInternetLocations" +Remove-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" -Name "DisableWindowsUpdateAccess" +Remove-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" -Name "WUServer" +Remove-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" -Name "UseWUServer" +Remove-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" -Name "NoAutoUpdate" +``` + +### Batch file + +Copy and paste the following code into a text editor, and save it with a `.cmd` extension, and execute against affected devices. This command removes registry keys that affect the Windows Autopatch service. For more information, see [Using batch files: Scripting; Management Services](/previous-versions/windows/it-pro/windows-server-2003/cc758944(v=ws.10)?redirectedfrom=MSDN). + +```cmd +@echo off +echo Deleting registry keys... +reg delete "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v "DoNotConnectToWindowsUpdateInternetLocations" /f +reg delete "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v "DisableWindowsUpdateAccess" /f +reg delete "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v "WUServer" /f +reg delete "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v "UseWUServer" /f +reg delete "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v "NoAutoUpdate" /f +echo Registry keys deleted. +Pause +``` + +### Registry file + +Copy the following code to a Notepad file, save as a `.reg` extension, and execute against affected devices. This removes registry keys that affect the Windows Autopatch service. For more information, see [How to add, modify, or delete registry subkeys and values by using a .reg file](https://support.microsoft.com/topic/how-to-add-modify-or-delete-registry-subkeys-and-values-by-using-a-reg-file-9c7f37cf-a5e9-e1cd-c4fa-2a26218a1a23). + +```cmd +Windows Registry Editor Version 5.00 +[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate] +"DoNotConnectToWindowsUpdateInternetLocations"=- +"DisableWindowsUpdateAccess"=- +"WUServer"=- +[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU] +"UseWUServer"=- +"NoAutoUpdate"=- +``` + +## Common sources of conflicting configurations + +The following examples can be used to validate if the configuration is persistent from one of the following services. The list isn’t an exhaustive, and Admins should be aware that changes can affect devices not managed by Windows Autopatch and should plan accordingly. + +### Group Policy management + +Group Policy management is the most popular client configuration tool in most organizations. For this reason, it’s most often the source of conflicting configurations. Use Result Set of Policy (RSOP) on an affected client can quickly identify if configured policies conflict with Windows Autopatch. For more information, see Use Resultant Set of Policy to Manage Group Policy. + +1. Launch an Elevated Command Prompt and enter `RSOP`. +1. Navigate to **Computer Configuration** > **Policies** > **Administrative Templates** > **Windows Components** > **Windows Update** +1. If a Policy **doesn’t exist** in Windows Update, then it appears to not be Group Policy. +1. If a Policy **exists** in Windows Update is present, modify or limit the target of the conflicting policy to resolve the Alert. +1. If the **Policy name** is labeled **Local Group Policy**, these settings could have been applied during imaging or by Configuration Manager. + +### Configuration Manager + +Configuration Manager is a common enterprise management tool that, among many things, can help manage Windows Updates. For this reason, we see many environments misconfigured when moving to either a 100% cloud or co-managed workloads even when the workloads are configured correctly. The client settings are often missed. For more information, see [About client settings and software updates](/mem/configmgr/core/clients/deploy/about-client-settings#software-updates). + +1. Go the **Microsoft Endpoint Configuration Manager Console**. +1. Navigate to **Administration** > **Overview** > **Client Settings**. +1. Ensure **Software Updates** isn’t configured. If configured, it’s recommended to remove these settings to prevent conflicts with Windows Autopatch. + +## Third-party solutions + +Third-party solutions can include any other product that may write configurations for the devices in question, such as MDMs (Mobile Device Managers) or Policy Managers. 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 73fc735624..e800c3533c 100644 --- a/windows/deployment/windows-autopatch/whats-new/windows-autopatch-whats-new-2023.md +++ b/windows/deployment/windows-autopatch/whats-new/windows-autopatch-whats-new-2023.md @@ -1,7 +1,7 @@ --- title: What's new 2023 description: This article lists the 2023 feature releases and any corresponding Message center post numbers. -ms.date: 08/17/2023 +ms.date: 10/19/2023 ms.prod: windows-client ms.technology: itpro-updates ms.topic: whats-new @@ -21,15 +21,50 @@ This article lists new and updated feature releases, and service releases, with Minor corrections such as typos, style, or formatting issues aren't listed. +## October 2023 + +## October service release + +| Message center post number | Description | +| ----- | ----- | +| [MC680344](https://admin.microsoft.com/adminportal/home#/MessageCenter) | Planned Maintenance: Service Improvements | + +## September 2023 + +### September feature releases or updates + +| Article | Description | +| ----- | ----- | +| [Conflicting configurations](../references/windows-autopatch-conflicting-configurations.md) | New feature. This article explains how to remediate conflicting configurationsWindows 11 Enterprise|Determines whether Application Guard can use the clipboard functionality.|**Enabled.** This is effective only in managed mode. Turns on the clipboard functionality and lets you choose whether to additionally:
- Disable the clipboard functionality completely when Virtualization Security is enabled.
- Enable copying of certain content from Application Guard into Microsoft Edge.
- Enable copying of certain content from Microsoft Edge into Application Guard. **Important:** Allowing copied content to go from Microsoft Edge into Application Guard can cause potential security risks and isn't recommended.
**Disabled or not configured.** Completely turns off the clipboard functionality for Application Guard.| -|Configure Microsoft Defender Application Guard print settings|Windows 10 Enterprise, 1709 or higher
Windows 11 Enterprise|Determines whether Application Guard can use the print functionality.|**Enabled.** This is effective only in managed mode. Turns on the print functionality and lets you choose whether to additionally:
- Enable Application Guard to print into the XPS format.
- Enable Application Guard to print into the PDF format.
- Enable Application Guard to print to locally attached printers.
- Enable Application Guard to print from previously connected network printers. Employees can't search for other printers.
**Disabled or not configured.** Completely turns Off the print functionality for Application Guard.|
-|Allow Persistence|Windows 10 Enterprise, 1709 or higher
Windows 11 Enterprise|Determines whether data persists across different sessions in Microsoft Defender Application Guard.|**Enabled.** This is effective only in managed mode. Application Guard saves user-downloaded files and other items (such as, cookies, Favorites, and so on) for use in future Application Guard sessions.
**Disabled or not configured.** All user data within Application Guard is reset between sessions.
**NOTE**: If you later decide to stop supporting data persistence for your employees, you can use our Windows-provided utility to reset the container and to discard any personal data.
**To reset the container:**
1. Open a command-line program and navigate to `Windows/System32`.
2. Type `wdagtool.exe cleanup`. The container environment is reset, retaining only the employee-generated data.
3. Type `wdagtool.exe cleanup RESET_PERSISTENCE_LAYER`. The container environment is reset, including discarding all employee-generated data.|
-|Turn on Microsoft Defender Application Guard in Managed Mode|Windows 10 Enterprise, 1809 or higher
Windows 11 Enterprise|Determines whether to turn on Application Guard for Microsoft Edge and Microsoft Office.|**Enabled.** Turns on Application Guard for Microsoft Edge and/or Microsoft Office, honoring the network isolation settings, rendering untrusted content in the Application Guard container. Application Guard won't actually be turned on unless the required prerequisites and network isolation settings are already set on the device. Available options:
- Enable Microsoft Defender Application Guard only for Microsoft Edge
- Enable Microsoft Defender Application Guard only for Microsoft Office
- Enable Microsoft Defender Application Guard for both Microsoft Edge and Microsoft Office
**Disabled.** Turns off Application Guard, allowing all apps to run in Microsoft Edge and Microsoft Office.
**Note:** For Windows 10, if you have KB5014666 installed, and for Windows 11, if you have KB5014668 installed, you are no longer required to configure network isolation policy to enable Application Guard for Edge.|
-|Allow files to download to host operating system|Windows 10 Enterprise or Pro, 1803 or higher
Windows 11 Enterprise or Pro|Determines whether to save downloaded files to the host operating system from the Microsoft Defender Application Guard container.|**Enabled.** Allows users to save downloaded files from the Microsoft Defender Application Guard container to the host operating system. This action creates a share between the host and container that also allows for uploads from the host to the Application Guard container.
**Disabled or not configured.** Users aren't able to save downloaded files from Application Guard to the host operating system.| -|Allow hardware-accelerated rendering for Microsoft Defender Application Guard|Windows 10 Enterprise, 1803 or higher
Windows 11 Enterprise|Determines whether Microsoft Defender Application Guard renders graphics using hardware or software acceleration.|**Enabled.** This is effective only in managed mode. Microsoft Defender Application Guard uses Hyper-V to access supported, high-security rendering graphics hardware (GPUs). These GPUs improve rendering performance and battery life while using Microsoft Defender Application Guard, particularly for video playback and other graphics-intensive use cases. If this setting is enabled without connecting any high-security rendering graphics hardware, Microsoft Defender Application Guard will automatically revert to software-based (CPU) rendering. **Important:** Enabling this setting with potentially compromised graphics devices or drivers might pose a risk to the host device.
**Disabled or not configured.** Microsoft Defender Application Guard uses software-based (CPU) rendering and won't load any third-party graphics drivers or interact with any connected graphics hardware.|
-|Allow camera and microphone access in Microsoft Defender Application Guard|Windows 10 Enterprise, 1809 or higher
Windows 11 Enterprise|Determines whether to allow camera and microphone access inside Microsoft Defender Application Guard.|**Enabled.** This is effective only in managed mode. Applications inside Microsoft Defender Application Guard are able to access the camera and microphone on the user's device. **Important:** Enabling this policy with a potentially compromised container could bypass camera and microphone permissions and access the camera and microphone without the user's knowledge.
**Disabled or not configured.** Applications inside Microsoft Defender Application Guard are unable to access the camera and microphone on the user's device.| -|Allow Microsoft Defender Application Guard to use Root Certificate Authorities from a user's device|Windows 10 Enterprise or Pro, 1809 or higher
Windows 11 Enterprise or Pro|Determines whether Root Certificates are shared with Microsoft Defender Application Guard.|**Enabled.** Certificates matching the specified thumbprint are transferred into the container. Use a comma to separate multiple certificates.
**Disabled or not configured.** Certificates aren't shared with Microsoft Defender Application Guard.| -|Allow auditing events in Microsoft Defender Application Guard|Windows 10 Enterprise, 1809 or higher
Windows 11 Enterprise|This policy setting allows you to decide whether auditing events can be collected from Microsoft Defender Application Guard.|**Enabled.** This is effective only in managed mode. Application Guard inherits auditing policies from your device and logs system events from the Application Guard container to your host.
**Disabled or not configured.** Event logs aren't collected from your Application Guard container.| +|Configure Microsoft Defender Application Guard clipboard settings|Windows 10 Enterprise, 1709 or higher
Windows 10 Education, 1809 or higher
Windows 11 Enterprise and Education|Determines whether Application Guard can use the clipboard functionality.|**Enabled.** This is effective only in managed mode. Turns on the clipboard functionality and lets you choose whether to additionally:
- Disable the clipboard functionality completely when Virtualization Security is enabled.
- Enable copying of certain content from Application Guard into Microsoft Edge.
- Enable copying of certain content from Microsoft Edge into Application Guard. **Important:** Allowing copied content to go from Microsoft Edge into Application Guard can cause potential security risks and isn't recommended.
**Disabled or not configured.** Completely turns off the clipboard functionality for Application Guard.| +|Configure Microsoft Defender Application Guard print settings|Windows 10 Enterprise, 1709 or higher
Windows 10 Education, 1809 or higher
Windows 11 Enterprise and Education|Determines whether Application Guard can use the print functionality.|**Enabled.** This is effective only in managed mode. Turns on the print functionality and lets you choose whether to additionally:
- Enable Application Guard to print into the XPS format.
- Enable Application Guard to print into the PDF format.
- Enable Application Guard to print to locally attached printers.
- Enable Application Guard to print from previously connected network printers. Employees can't search for other printers.
**Disabled or not configured.** Completely turns Off the print functionality for Application Guard.|
+|Allow Persistence|Windows 10 Enterprise, 1709 or higher
Windows 10 Education, 1809 or higher
Windows 11 Enterprise and Education|Determines whether data persists across different sessions in Microsoft Defender Application Guard.|**Enabled.** This is effective only in managed mode. Application Guard saves user-downloaded files and other items (such as, cookies, Favorites, and so on) for use in future Application Guard sessions.
**Disabled or not configured.** All user data within Application Guard is reset between sessions.
**NOTE**: If you later decide to stop supporting data persistence for your employees, you can use our Windows-provided utility to reset the container and to discard any personal data.
**To reset the container:**
1. Open a command-line program and navigate to `Windows/System32`.
2. Type `wdagtool.exe cleanup`. The container environment is reset, retaining only the employee-generated data.
3. Type `wdagtool.exe cleanup RESET_PERSISTENCE_LAYER`. The container environment is reset, including discarding all employee-generated data.|
+|Turn on Microsoft Defender Application Guard in Managed Mode|Windows 10 Enterprise, 1709 or higher
Windows 10 Education, 1809 or higher
Windows 11 Enterprise and Education|Determines whether to turn on Application Guard for Microsoft Edge and Microsoft Office.|**Enabled.** Turns on Application Guard for Microsoft Edge and/or Microsoft Office, honoring the network isolation settings, rendering untrusted content in the Application Guard container. Application Guard won't actually be turned on unless the required prerequisites and network isolation settings are already set on the device. Available options:
- Enable Microsoft Defender Application Guard only for Microsoft Edge
- Enable Microsoft Defender Application Guard only for Microsoft Office
- Enable Microsoft Defender Application Guard for both Microsoft Edge and Microsoft Office
**Disabled.** Turns off Application Guard, allowing all apps to run in Microsoft Edge and Microsoft Office.
**Note:** For Windows 10, if you have KB5014666 installed, and for Windows 11, if you have KB5014668 installed, you are no longer required to configure network isolation policy to enable Application Guard for Edge.|
+|Allow files to download to host operating system|Windows 10 Enterprise or Pro, 1803 or higher
Windows 10 Education, 1809 or higher
Windows 11 Enterprise or Pro or Education|Determines whether to save downloaded files to the host operating system from the Microsoft Defender Application Guard container.|**Enabled.** Allows users to save downloaded files from the Microsoft Defender Application Guard container to the host operating system. This action creates a share between the host and container that also allows for uploads from the host to the Application Guard container.
**Disabled or not configured.** Users aren't able to save downloaded files from Application Guard to the host operating system.| +|Allow hardware-accelerated rendering for Microsoft Defender Application Guard|Windows 10 Enterprise, 1709 or higher
Windows 10 Education, 1809 or higher
Windows 11 Enterprise and Education|Determines whether Microsoft Defender Application Guard renders graphics using hardware or software acceleration.|**Enabled.** This is effective only in managed mode. Microsoft Defender Application Guard uses Hyper-V to access supported, high-security rendering graphics hardware (GPUs). These GPUs improve rendering performance and battery life while using Microsoft Defender Application Guard, particularly for video playback and other graphics-intensive use cases. If this setting is enabled without connecting any high-security rendering graphics hardware, Microsoft Defender Application Guard will automatically revert to software-based (CPU) rendering. **Important:** Enabling this setting with potentially compromised graphics devices or drivers might pose a risk to the host device.
**Disabled or not configured.** Microsoft Defender Application Guard uses software-based (CPU) rendering and won't load any third-party graphics drivers or interact with any connected graphics hardware.|
+|Allow camera and microphone access in Microsoft Defender Application Guard|Windows 10 Enterprise, 1709 or higher
Windows 10 Education, 1809 or higher
Windows 11 Enterprise and Education|Determines whether to allow camera and microphone access inside Microsoft Defender Application Guard.|**Enabled.** This is effective only in managed mode. Applications inside Microsoft Defender Application Guard are able to access the camera and microphone on the user's device. **Important:** Enabling this policy with a potentially compromised container could bypass camera and microphone permissions and access the camera and microphone without the user's knowledge.
**Disabled or not configured.** Applications inside Microsoft Defender Application Guard are unable to access the camera and microphone on the user's device.| +|Allow Microsoft Defender Application Guard to use Root Certificate Authorities from a user's device|Windows 10 Enterprise or Pro, 1809 or higher
Windows 10 Education, 1809 or higher
Windows 11 Enterprise or Pro|Determines whether Root Certificates are shared with Microsoft Defender Application Guard.|**Enabled.** Certificates matching the specified thumbprint are transferred into the container. Use a comma to separate multiple certificates.
**Disabled or not configured.** Certificates aren't shared with Microsoft Defender Application Guard.| +|Allow auditing events in Microsoft Defender Application Guard|Windows 10 Enterprise, 1709 or higher
Windows 10 Education, 1809 or higher
Windows 11 Enterprise and Education|This policy setting allows you to decide whether auditing events can be collected from Microsoft Defender Application Guard.|**Enabled.** This is effective only in managed mode. Application Guard inherits auditing policies from your device and logs system events from the Application Guard container to your host.
**Disabled or not configured.** Event logs aren't collected from your Application Guard container.|
## Application Guard support dialog settings
These settings are located at `Administrative Templates\Windows Components\Windows Security\Enterprise Customization`. If an error is encountered, you're presented with a dialog box. By default, this dialog box only contains the error information and a button for you to report it to Microsoft via the feedback hub. However, it's possible to provide additional information in the dialog box.
diff --git a/windows/security/application-security/application-isolation/microsoft-defender-application-guard/install-md-app-guard.md b/windows/security/application-security/application-isolation/microsoft-defender-application-guard/install-md-app-guard.md
index eeac8ba0d1..ac710efb7a 100644
--- a/windows/security/application-security/application-isolation/microsoft-defender-application-guard/install-md-app-guard.md
+++ b/windows/security/application-security/application-isolation/microsoft-defender-application-guard/install-md-app-guard.md
@@ -27,7 +27,8 @@ Standalone mode is applicable for:
- Windows 10 Enterprise edition, version 1709 and later
- Windows 10 Pro edition, version 1803 and later
-- Windows 11 and later
+- Windows 10 Education edition, version 1809 and later
+- Windows 11 Enterprise, Education, or Pro editions
## Enterprise-managed mode
@@ -36,7 +37,8 @@ You and your security department can define your corporate boundaries by explici
Enterprise-managed mode is applicable for:
- Windows 10 Enterprise edition, version 1709 and later
-- Windows 11 and later
+- Windows 10 Education edition, version 1809 and later
+- Windows 11 Enterprise or Education editions
The following diagram shows the flow between the host PC and the isolated container.
diff --git a/windows/security/application-security/application-isolation/microsoft-defender-application-guard/reqs-md-app-guard.md b/windows/security/application-security/application-isolation/microsoft-defender-application-guard/reqs-md-app-guard.md
index 190662392c..e27e886eea 100644
--- a/windows/security/application-security/application-isolation/microsoft-defender-application-guard/reqs-md-app-guard.md
+++ b/windows/security/application-security/application-isolation/microsoft-defender-application-guard/reqs-md-app-guard.md
@@ -34,6 +34,6 @@ Your environment must have the following hardware to run Microsoft Defender Appl
| Software | Description |
|--------|-----------|
-| Operating system | Windows 10 Enterprise edition, version 1809 or later
Windows 10 Professional edition, version 1809 or later
Windows 10 Professional for Workstations edition, version 1809 or later
Windows 10 Professional Education edition, version 1809 or later
Windows 10 Education edition, version 1809 or later
Windows 11 Education, Enterprise, and Professional editions |
+| Operating system | Windows 10 Enterprise or Education editions, version 1809 or later
Windows 10 Professional edition, version 1809 or later (only [standalone mode](/windows/security/application-security/application-isolation/microsoft-defender-application-guard/install-md-app-guard#standalone-mode) is supported)
Windows 11 Education or Enterprise editions
Windows 11 Professional edition (only [Standalone mode](/windows/security/application-security/application-isolation/microsoft-defender-application-guard/install-md-app-guard#standalone-mode) is supported) |
| Browser | Microsoft Edge |
| Management system
(only for managed devices)| [Microsoft Intune](/intune/)
**OR**
[Microsoft Configuration Manager](/configmgr/)
**OR**
[Group Policy](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc753298(v=ws.11))
**OR**
Your current, company-wide, non-Microsoft mobile device management (MDM) solution. For info about non-Microsoft MDM solutions, see the documentation that came with your product. |
diff --git a/windows/security/application-security/application-isolation/windows-sandbox/windows-sandbox-overview.md b/windows/security/application-security/application-isolation/windows-sandbox/windows-sandbox-overview.md
index 02bb837f09..928d31e27b 100644
--- a/windows/security/application-security/application-isolation/windows-sandbox/windows-sandbox-overview.md
+++ b/windows/security/application-security/application-isolation/windows-sandbox/windows-sandbox-overview.md
@@ -47,10 +47,11 @@ Windows Sandbox has the following properties:
2. Enable virtualization on the machine.
- If you're using a physical machine, make sure virtualization capabilities are enabled in the BIOS.
- - If you're using a virtual machine, run the following PowerShell command to enable nested virtualization:
+ - If you're using a virtual machine, you need to enable nested virtualization. If needed, also update the VM to support nested virtualization. Run the following PowerShell commands on the host:
```powershell
Set-VMProcessor -VMName Not configured: Device doesn't provision Windows Hello for Business for any user. Enabled: Device provisions Windows Hello for Business using keys or certificates for all users. Disabled: Device doesn't provision Windows Hello for Business for any user.|
-|Use a hardware security device|Computer| Not configured: Windows Hello for Business will be provisioned using TPM if available, and will be provisioned using software if TPM isn't available. Enabled: Windows Hello for Business will only be provisioned using TPM. This feature will provision Windows Hello for Business using TPM 1.2 unless the option to exclude them is explicitly set. Disabled: Windows Hello for Business will be provisioned using TPM if available, and will be provisioned using software if TPM isn't available.|
-|Use certificate for on-premises authentication|Computer or user| Not configured: Windows Hello for Business enrolls a key that is used for on-premises authentication. Enabled: Windows Hello for Business enrolls a sign-in certificate using ADFS that is used for on-premises authentication. Disabled: Windows Hello for Business enrolls a key that is used for on-premises authentication.|
-|Use PIN recovery|Computer| Added in Windows 10, version 1703 Not configured: Windows Hello for Business doesn't create or store a PIN recovery secret. PIN reset doesn't use the Azure-based PIN recovery service Enabled: Windows Hello for Business uses the Azure-based PIN recovery service for PIN reset Disabled: Windows Hello for Business doesn't create or store a PIN recovery secret. PIN reset doesn't use the Azure-based PIN recovery service. For more information about using the PIN recovery service for PIN reset see [Windows Hello for Business PIN Reset](hello-feature-pin-reset.md).|
-|Use biometrics|Computer| Not configured: Biometrics can be used as a gesture in place of a PIN Enabled: Biometrics can be used as a gesture in place of a PIN. Disabled: Only a PIN can be used as a gesture.|
+|Use Windows Hello for Business|Computer or user|- **Not configured**: Device doesn't provision Windows Hello for Business for any user. Not configured: Users must include a digit in their PIN. Enabled: Users must include a digit in their PIN. Disabled: Users can't use digits in their PIN.|
-|Require lowercase letters|Computer| Not configured: Users can't use lowercase letters in their PIN Enabled: Users must include at least one lowercase letter in their PIN. Disabled: Users can't use lowercase letters in their PIN.|
-|Maximum PIN length|Computer| Not configured: PIN length must be less than or equal to 127. Enabled: PIN length must be less than or equal to the number you specify. Disabled: PIN length must be less than or equal to 127.|
-|Minimum PIN length|Computer| Not configured: PIN length must be greater than or equal to 4. Enabled: PIN length must be greater than or equal to the number you specify. Disabled: PIN length must be greater than or equal to 4.|
-|Expiration|Computer| Not configured: PIN doesn't expire. Enabled: PIN can be set to expire after any number of days between 1 and 730, or PIN can be set to never expire by setting policy to 0. Disabled: PIN doesn't expire.|
-|History|Computer| Not configured: Previous PINs aren't stored. Enabled: Specify the number of previous PINs that can be associated to a user account that can't be reused. Disabled: Previous PINs aren't stored. Not configured: Windows allows, but doesn't require, special characters in the PIN. Enabled: Windows requires the user to include at least one special character in their PIN. Disabled: Windows doesn't allow the user to include special characters in their PIN.|
-|Require uppercase letters|Computer| Not configured: Users can't include an uppercase letter in their PIN. Enabled: Users must include at least one uppercase letter in their PIN. Disabled: Users can't include an uppercase letter in their PIN.|
+|Require digits|Computer|- **Not configured**: Users must include a digit in their PIN. True: Windows Hello for Business will be provisioned for all users on the device. False: Users won't be able to provision Windows Hello for Business. True: Windows Hello for Business will only be provisioned using TPM. False: Windows Hello for Business will be provisioned using TPM if available, and will be provisioned using software if TPM isn't available.|
-|ExcludeSecurityDevice TPM12|Device|False|Added in Windows 10, version 1703 True: TPM revision 1.2 modules will be disallowed from being used with Windows Hello for Business. False: TPM revision 1.2 modules will be allowed to be used with Windows Hello for Business.|
-|EnablePinRecovery|Device or use|False| Added in Windows 10, version 1703 True: Windows Hello for Business uses the Azure-based PIN recovery service for PIN reset. False: Windows Hello for Business doesn't create or store a PIN recovery secret. PIN reset doesn't use the Azure-based PIN recovery service. For more information about using the PIN recovery service for PIN reset see [Windows Hello for Business PIN Reset](hello-feature-pin-reset.md).|
+|UsePassportForWork|Device or user|True|- True: Windows Hello for Business will be provisioned for all users on the device. True: Biometrics can be used as a gesture in place of a PIN for domain sign-in. False: Only a PIN can be used as a gesture for domain sign-in.|
-| FacialFeaturesUser EnhancedAntiSpoofing|Device|Not configured| Not configured: users can choose whether to turn on enhanced anti-spoofing. True: Enhanced anti-spoofing is required on devices which support it. False: Users can't turn on enhanced anti-spoofing.|
+|UseBiometrics|Device |False|- True: Biometrics can be used as a gesture in place of a PIN for domain sign-in. 0: Digits are allowed. 1: At least one digit is required. 2: Digits aren't allowed.|
-|Lowercase letters |Device or user|2| 0: Lowercase letters are allowed. 1: At least one lowercase letter is required. 2: Lowercase letters aren't allowed.|
-|Special characters|Device or user|2| 0: Special characters are allowed. 1: At least one special character is required. 2: Special characters aren't allowed.|
-|Uppercase letters|Device or user|2| 0: Uppercase letters are allowed. 1: At least one uppercase letter is required. 2: Uppercase letters aren't allowed.|
-|Maximum PIN length |Device or user|127 | Maximum length that can be set is 127. Maximum length can't be less than minimum setting.|
-|Minimum PIN length|Device or user|6| Minimum length that can be set is 6. Minimum length can't be greater than maximum setting.|
-|Expiration |Device or user|0| Integer value specifies the period of time (in days) that a PIN can be used before the system requires the user to change it. The largest number you can configure for this policy setting is 730. The lowest number you can configure for this policy setting is 0. If this policy is set to 0, then the user's PIN will never expire.|
-|History|Device or user|0| Integer value that specifies the number of past PINs that can be associated to a user account that can't be reused. The largest number you can configure for this policy setting is 50. The lowest number you can configure for this policy setting is 0. If this policy is set to 0, then storage of previous PINs isn't required.|
+|Digits |Device or user|1 |- 0: Digits are allowed.
-Prevent changes to the BIOS settings|
+|**Hardware Rooted Trust Platform Secure Boot**|- Boot Integrity (Platform Secure Boot) must be supported. See the Windows Hardware Compatibility Program requirements under System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby - Hardware Security Test Interface (HSTI) must be implemented. See [Hardware Security Testability Specification](/windows-hardware/test/hlk/testref/hardware-security-testability-specification)|- Boot Integrity (Platform Secure Boot) from Power-On provides protections against physically present attackers, and defense-in-depth against malware. - HSTI provides security assurance for correctly secured silicon and platform|
+|**Firmware Update through Windows Update**|- Firmware must support field updates through Windows Update and UEFI encapsulation update|Helps ensure that firmware updates are fast, secure, and reliable.|
+|**Securing Boot Configuration and Management**|- Required BIOS capabilities: ability of OEM to add ISV, OEM, or Enterprise Certificate in Secure Boot DB at manufacturing time - Required configurations: Microsoft UEFI CA must be removed from Secure Boot DB. Support for 3rd-party UEFI modules is permitted but should use ISV-provided certificates or OEM certificate for the specific UEFI software|- Enterprises can choose to allow proprietary EFI drivers/applications to run - Removing Microsoft UEFI CA from Secure Boot DB provides full control to enterprises over software that runs before the operating system boots|
+|**VBS enablement of No-Execute (NX) protection for UEFI runtime services**|- VBS enables NX protection on UEFI runtime service code and data memory regions. UEFI runtime service code must support read-only page protections, and UEFI runtime service data must not be executable. UEFI runtime service must meet the following requirements: - Implement UEFI 2.6 `EFI_MEMORY_ATTRIBUTES_TABLE`. All UEFI runtime service memory (code and data) must be described by this table - PE sections must be page-aligned in memory (not required for in non-volatile storage). - The Memory Attributes Table needs to correctly mark code and data as `RO/NX` for configuration by the OS - All entries must include attributes `EFI_MEMORY_RO`, `EFI_MEMORY_XP`, or both. - No entries may be left with neither of the above attributes, indicating memory that is both executable and writable. Memory must be either readable and executable or writable and non-executable (**SEE IMPORTANT INFORMATION AFTER THIS TABLE**)|- Vulnerabilities in UEFI runtime, if any, are blocked from compromising VBS (such as in functions like *UpdateCapsule* and *SetVariable*) - Reduces the attack surface to VBS from system firmware.|
+|**Firmware support for SMM protection**|- The [Windows SMM Security Mitigations Table (WSMT) specification](https://download.microsoft.com/download/1/8/A/18A21244-EB67-4538-BAA2-1A54E0E490B6/WSMT.docx) contains details of an ACPI table that was created for use with Windows operating systems that support Windows virtualization-based features.|- Protects against potential vulnerabilities in UEFI runtime services, if any, will be blocked from compromising VBS (such as in functions like UpdateCapsule and SetVariable)
- Reduces the attack surface to VBS from system firmware
- Blocks additional security attacks against SMM|
+
+> [!IMPORTANT]
+>
+> Regarding **VBS enablement of NX protection for UEFI runtime services**:
+>
+> - It only applies to UEFI runtime service memory, and not UEFI boot service memory
+> - The protection is applied by VBS on OS page tables
+> - Don't use sections that are both writable and executable
+> - Don't attempt to directly modify executable system memory
+> - Don't use dynamic code
+
+## Restrict domain users to specific domain-joined devices
+
+Credential theft attacks allow the attacker to steal secrets from one device and use them from another device. If a user can sign on to multiple devices then any device could be used to steal credentials. How do you ensure that users only sign on with devices that have Credential Guard enabled? By deploying authentication policies that restrict them to specific domain-joined devices that have been configured with Credential Guard. For the domain controller to know what device a user is signing on from, Kerberos armoring must be used.
### Kerberos armoring
-Kerberos armoring is part of RFC 6113. When a device supports Kerberos armoring, its TGT is used to protect the user's proof of possession which can mitigate offline dictionary attacks. Kerberos armoring also provides the additional benefit of signed KDC errors this mitigates tampering which can result in things such as downgrade attacks.
+Kerberos armoring is part of RFC 6113. When a device supports Kerberos armoring, its TGT is used to protect the user's proof of possession which can mitigate offline dictionary attacks. Kerberos armoring also provides the additional benefit of signed KDC errors this mitigates tampering which can result in things such as downgrade attacks.
+
+To enable Kerberos armoring for restricting domain users to specific domain-joined devices:
-**To enable Kerberos armoring for restricting domain users to specific domain-joined devices**
- Users need to be in domains that are running Windows Server 2012 R2 or higher
- All the domain controllers in these domains must be configured to support Kerberos armoring. Set the **KDC support for claims, compound authentication, and Kerberos armoring** Group Policy setting to either **Supported** or **Always provide claims**.
-- All the devices with Windows Defender Credential Guard that the users will be restricted to must be configured to support Kerberos armoring. Enable the **Kerberos client support for claims, compound authentication and Kerberos armoring** Group Policy settings under **Computer Configuration** -> **Administrative Templates** -> **System** -> **Kerberos**.
+- All the devices with Credential Guard that the users will be restricted to must be configured to support Kerberos armoring. Enable the **Kerberos client support for claims, compound authentication and Kerberos armoring** Group Policy settings under **Computer Configuration** -> **Administrative Templates** -> **System** -> **Kerberos**.
-### Protecting domain-joined device secrets
+### Protect domain-joined device secrets
-Since domain-joined devices also use shared secrets for authentication, attackers can steal those secrets as well. By deploying device certificates with Windows Defender Credential Guard, the private key can be protected. Then authentication policies can require that users sign on to devices that authenticate using those certificates. This prevents shared secrets stolen from the device to be used with stolen user credentials to sign on as the user.
+Since domain-joined devices also use shared secrets for authentication, attackers can steal those secrets as well. By deploying device certificates with Credential Guard, the private key can be protected. Then authentication policies can require that users sign on to devices that authenticate using those certificates. This prevents shared secrets stolen from the device to be used with stolen user credentials to sign on as the user.
Domain-joined device certificate authentication has the following requirements:
+
- Devices' accounts are in Windows Server 2012 domain functional level or higher.
- All domain controllers in those domains have KDC certificates which satisfy strict KDC validation certificate requirements:
- KDC EKU present
- - DNS domain name matches the DNSName field of the SubjectAltName (SAN) extension
+ - DNS domain name matches the DNSName field of the SubjectAltName (SAN) extension
- Windows devices have the CA issuing the domain controller certificates in the enterprise store.
- A process is established to ensure the identity and trustworthiness of the device in a similar manner as you would establish the identity and trustworthiness of a user before issuing them a smartcard.
-#### Deploying domain-joined device certificates
+#### Deploy domain-joined device certificates
To guarantee that certificates with the required issuance policy are only installed on the devices these users must use, they must be deployed manually on each device. The same security procedures used for issuing smart cards to users should be applied to device certificates.
For example, let's say you wanted to use the High Assurance policy only on these devices. Using a Windows Server Enterprise certificate authority, you would create a new template.
-**Creating a new certificate template**
+**Create a new certificate template**
-1. From the Certificate Manager console, right-click **Certificate Templates**, and then click **Manage.**
-2. Right-click **Workstation Authentication**, and then click **Duplicate Template**.
-3. Right-click the new template, and then click **Properties**.
-4. On the **Extensions** tab, click **Application Policies**, and then click **Edit**.
-5. Click **Client Authentication**, and then click **Remove**.
-6. Add the ID-PKInit-KPClientAuth EKU. Click **Add**, click **New**, and then specify the following values:
+1. From the Certificate Manager console, right-click **Certificate Templates > Manage**
+1. Right-click **Workstation Authentication > Duplicate Template**
+1. Right-click the new template, and then select **Properties**
+1. On the **Extensions** tab, select **Application Policies > Edit**
+1. Select **Client Authentication**, and then select **Remove**
+1. Add the ID-PKInit-KPClientAuth EKU. Select **Add > New**, and then specify the following values:
- Name: Kerberos Client Auth
- Object Identifier: 1.3.6.1.5.2.3.4
-7. On the **Extensions** tab, click **Issuance Policies**, and then click **Edit**.
-8. Under **Issuance Policies**, click**High Assurance**.
-9. On the **Subject name** tab, clear the **DNS name** check box, and then select the **User Principal Name (UPN)** check box.
+1. On the **Extensions** tab, select **Issuance Policies > Edit**
+1. Under **Issuance Policies**, select **High Assurance**
+1. On the **Subject name** tab, clear the **DNS name** check box, and then select the **User Principal Name (UPN)** check box
-Then on the devices that are running Windows Defender Credential Guard, enroll the devices using the certificate you just created.
+Then on the devices that are running Credential Guard, enroll the devices using the certificate you just created.
-**Enrolling devices in a certificate**
+**Enroll devices in a certificate**
Run the following command:
+
```powershell
CertReq -EnrollCredGuardCert MachineAuthentication
```
@@ -88,7 +117,7 @@ From a Windows PowerShell command prompt, run the following command:
.\set-IssuancePolicyToGroupLink.ps1 -IssuancePolicyName:"
- **Enabled with UEFI lock**
- **Enabled without lock** |
+
+>[!IMPORTANT]
+> If you want to be able to turn off Credential Guard remotely, choose the option **Enabled without lock**.
+
+[!INCLUDE [intune-settings-catalog-2](../../../../includes/configure/intune-settings-catalog-2.md)]
+
+> [!TIP]
+> You can also configure Credential Guard by using an *account protection* profile in endpoint security. For more information, see [Account protection policy settings for endpoint security in Microsoft Intune](/mem/intune/protect/endpoint-security-account-protection-profile-settings).
+
+Alternatively, you can configure devices using a [custom policy][INT-1] with the [DeviceGuard Policy CSP][CSP-1].
+
+| Setting |
+|--------|
+| **Setting name**: Turn On Virtualization Based Security
**OMA-URI**: `./Device/Vendor/MSFT/Policy/Config/DeviceGuard/EnableVirtualizationBasedSecurity`
**Data type**: int
**Value**: `1`|
+| **Setting name**: Credential Guard Configuration
**OMA-URI**: `./Device/Vendor/MSFT/Policy/Config/DeviceGuard/LsaCfgFlags`
**Data type**: int
**Value**:
**Enabled with UEFI lock**: `1`
**Enabled without lock**: `2`|
+
+Once the policy is applied, restart the device.
+
+#### [:::image type="icon" source="../../images/icons/group-policy.svg" border="false"::: **Group policy**](#tab/gpo)
+
+### Configure Credential Guard with group policy
+
+[!INCLUDE [gpo-settings-1](../../../../includes/configure/gpo-settings-1.md)]
+
+| Group policy path | Group policy setting | Value |
+| - | - | - |
+| **Computer Configuration\Administrative Templates\System\Device Guard** |Turn On Virtualization Based Security | **Enabled** and select one of the options listed under the **Credential Guard Configuration** dropdown:
- **Enabled with UEFI lock**
- **Enabled without lock**|
+
+>[!IMPORTANT]
+> If you want to be able to turn off Credential Guard remotely, choose the option **Enabled without lock**.
+
+[!INCLUDE [gpo-settings-2](../../../../includes/configure/gpo-settings-2.md)]
+
+Once the policy is applied, restart the device.
+
+#### [:::image type="icon" source="../../images/icons/windows-os.svg" border="false"::: **Registry**](#tab/reg)
+
+### Configure Credential Guard with registry settings
+
+To configure devices using the registry, use the following settings:
+
+| Setting |
+|--|
+| **Key path**: `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard`
**Key name**: `EnableVirtualizationBasedSecurity`
**Type**: `REG_DWORD`
**Value**: `1` (to enable Virtualization Based Security)|
+| **Key path**: `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard`
**Key name**: `RequirePlatformSecurityFeatures`
**Type**: `REG_DWORD`
**Value**:
`1` (to use Secure Boot)
`3` (to use Secure Boot and DMA protection) |
+| **Key path**: `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa`
**Key name**: `LsaCfgFlags`
**Type**: `REG_DWORD`
**Value**:
`1` (to enable Credential Guard with UEFI lock)
`2` (to enable Credential Guard without lock)|
+
+Restart the device to apply the change.
+
+> [!TIP]
+> You can enable Credential Guard by setting the registry entries in the [*FirstLogonCommands*](/windows-hardware/customize/desktop/unattend/microsoft-windows-shell-setup-firstlogoncommands) unattend setting.
+
+---
+
+### Verify if Credential Guard is enabled
+
+Checking Task Manager if `LsaIso.exe` is running isn't a recommended method for determining whether Credential Guard is running. Instead, use one of the following methods:
+
+- System Information
+- PowerShell
+- Event Viewer
+
+#### System Information
+
+You can use *System Information* to determine whether Credential Guard is running on a device.
+
+1. Select **Start**, type `msinfo32.exe`, and then select **System Information**
+1. Select **System Summary**
+1. Confirm that **Credential Guard** is shown next to **Virtualization-based Security Services Running**
+
+#### PowerShell
+
+You can use PowerShell to determine whether Credential Guard is running on a device. From an elevated PowerShell session, use the following command:
+
+```powershell
+(Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning
+```
+
+The command generates the following output:
+
+- **0**: Credential Guard is disabled (not running)
+- **1**: Credential Guard is enabled (running)
+
+#### Event viewer
+
+Perform regular reviews of the devices that have Credential Guard enabled, using security audit policies or WMI queries.\
+Open the Event Viewer (`eventvwr.exe`) and go to `Windows Logs\System` and filter the event sources for *WinInit*:
+
+:::row:::
+ :::column span="1":::
+ **Event ID**
+ :::column-end:::
+ :::column span="3":::
+ **Description**
+ :::column-end:::
+:::row-end:::
+:::row:::
+ :::column span="1":::
+ 13 (Information)
+ :::column-end:::
+ :::column span="3":::
+ ```logging
+ Credential Guard (LsaIso.exe) was started and will protect LSA credentials.
+ ```
+ :::column-end:::
+:::row-end:::
+:::row:::
+ :::column span="1":::
+ `14` (Information)
+ :::column-end:::
+ :::column span="3":::
+ ```logging
+ Credential Guard (LsaIso.exe) configuration: [**0x0** | **0x1** | **0x2**], **0**
+ ```
+ - The first variable: **0x1** or **0x2** means that Credential Guard is configured to run. **0x0** means that it's not configured to run.
+ - The second variable: **0** means that it's configured to run in protect mode. **1** means that it's configured to run in test mode. This variable should always be **0**.
+ :::column-end:::
+:::row-end:::
+:::row:::
+ :::column span="1":::
+ `15` (Warning)
+ :::column-end:::
+ :::column span="3":::
+ ```logging
+ Credential Guard (LsaIso.exe) is configured but the secure kernel isn't running;
+ continuing without Credential Guard.
+ ```
+ :::column-end:::
+:::row-end:::
+:::row:::
+ :::column span="1":::
+ `16` (Warning)
+ :::column-end:::
+ :::column span="3":::
+ ```logging
+ Credential Guard (LsaIso.exe) failed to launch: [error code]
+ ```
+ :::column-end:::
+:::row-end:::
+:::row:::
+ :::column span="1":::
+ `17`
+ :::column-end:::
+ :::column span="3":::
+ ```logging
+ Error reading Credential Guard (LsaIso.exe) UEFI configuration: [error code]
+ ```
+ :::column-end:::
+:::row-end:::
+
+The following event indicates whether TPM is used for key protection. Path: `Applications and Services logs > Microsoft > Windows > Kernel-Boot`
+
+:::row:::
+ :::column span="1":::
+ **Event ID**
+ :::column-end:::
+ :::column span="3":::
+ **Description**
+ :::column-end:::
+:::row-end:::
+:::row:::
+ :::column span="1":::
+ 51 (Information)
+ :::column-end:::
+ :::column span="3":::
+ ```logging
+ VSM Master Encryption Key Provisioning. Using cached copy status: 0x0. Unsealing cached copy status: 0x1. New key generation status: 0x1. Sealing status: 0x1. TPM PCR mask: 0x0.
+ ```
+ :::column-end:::
+:::row-end:::
+
+If you're running with a TPM, the TPM PCR mask value is something other than 0.
+
+## Disable Credential Guard
+
+There are different options to disable Credential Guard. The option you choose depends on how Credential Guard is configured:
+
+- Credential Guard running in a virtual machine can be [disabled by the host](#disable-credential-guard-for-a-virtual-machine)
+- If Credential Guard is enabled **with UEFI Lock**, follow the procedure described in [disable Credential Guard with UEFI Lock](#disable-credential-guard-with-uefi-lock)
+- If Credential Guard is enabled **without UEFI Lock**, or as part of the automatic enablement in the Windows 11, version 22H2 update, use one of the following options to disable it:
+ - Microsoft Intune/MDM
+ - Group policy
+ - Registry
+
+[!INCLUDE [tab-intro](../../../../includes/configure/tab-intro.md)]
+
+#### [:::image type="icon" source="../../images/icons/intune.svg" border="false"::: **Intune/MDM**](#tab/intune)
+
+### Disable Credential Guard with Intune
+
+If Credential Guard is enabled via Intune and without UEFI Lock, disabling the same policy setting disables Credential Guard.
+
+[!INCLUDE [intune-settings-catalog-1](../../../../includes/configure/intune-settings-catalog-1.md)]
+
+| Category | Setting name | Value |
+|--|--|--|
+| Device Guard | Credential Guard | **Disabled** |
+
+[!INCLUDE [intune-settings-catalog-2](../../../../includes/configure/intune-settings-catalog-2.md)]
+
+Alternatively, you can configure devices using a [custom policy][INT-1] with the [DeviceGuard Policy CSP][CSP-1].
+
+| Setting |
+|--------|
+| **Setting name**: Credential Guard Configuration
**OMA-URI**: `./Device/Vendor/MSFT/Policy/Config/DeviceGuard/LsaCfgFlags`
**Data type**: int
**Value**: `0`|
+
+Once the policy is applied, restart the device.
+
+#### [:::image type="icon" source="../../images/icons/group-policy.svg" border="false"::: **Group policy**](#tab/gpo)
+
+### Disable Credential Guard with group policy
+
+If Credential Guard is enabled via Group Policy and without UEFI Lock, disabling the same group policy setting disables Credential Guard.
+
+[!INCLUDE [gpo-settings-1](../../../../includes/configure/gpo-settings-1.md)]
+
+| Group policy path | Group policy setting | Value |
+| - | - | - |
+| **Computer Configuration\Administrative Templates\System\Device Guard** |Turn On Virtualization Based Security | **Disabled** |
+
+[!INCLUDE [gpo-settings-2](../../../../includes/configure/gpo-settings-2.md)]
+
+Once the policy is applied, restart the device.
+
+#### [:::image type="icon" source="../../images/icons/windows-os.svg" border="false"::: **Registry**](#tab/reg)
+
+### Disable Credential Guard with registry settings
+
+If Credential Guard is enabled without UEFI Lock and without Group Policy, it's sufficient to edit the registry keys to disable it.
+
+| Setting |
+|-|
+| **Key path**: `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa`
**Key name**: `LsaCfgFlags`
**Type**: `REG_DWORD`
**Value**: `0`|
+| **Key path**: `HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard`
**Key name**: `LsaCfgFlags`
**Type**: `REG_DWORD`
**Value**: `0`|
+
+> [!NOTE]
+> Deleting these registry settings may not disable Credential Guard. They must be set to a value of 0.
+
+Restart the device to apply the change.
+
+---
+
+For information on disabling Virtualization-based Security (VBS), see [disable Virtualization-based Security](#disable-virtualization-based-security).
+
+### Disable Credential Guard with UEFI lock
+
+If Credential Guard is enabled with UEFI lock, follow this procedure since the settings are persisted in EFI (firmware) variables.
+
+> [!NOTE]
+> This scenario requires physical presence at the machine to press a function key to accept the change.
+
+1. Follow the steps in [Disable Credential Guard](#disable-credential-guard)
+1. Delete the Credential Guard EFI variables by using bcdedit. From an elevated command prompt, type the following commands:
+
+ ```cmd
+ mountvol X: /s
+ copy %WINDIR%\System32\SecConfig.efi X:\EFI\Microsoft\Boot\SecConfig.efi /Y
+ bcdedit /create {0cb3b571-2f2e-4343-a879-d86a476d7215} /d "DebugTool" /application osloader
+ bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} path "\EFI\Microsoft\Boot\SecConfig.efi"
+ bcdedit /set {bootmgr} bootsequence {0cb3b571-2f2e-4343-a879-d86a476d7215}
+ bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO
+ bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} device partition=X:
+ mountvol X: /d
+ ```
+
+1. Restart the device. Before the OS boots, a prompt appears notifying that UEFI was modified, and asking for confirmation. The prompt must be confirmed for the changes to persist.
+
+### Disable Credential Guard for a virtual machine
+
+From the host, you can disable Credential Guard for a virtual machine with the following command:
+
+```powershell
+Set-VMSecurity -VMName
**OMA-URI**: `./Device/Vendor/MSFT/Policy/Config/DeviceGuard/EnableVirtualizationBasedSecurity`
**Data type**: int
**Value**: `0`|
+
+Once the policy is applied, restart the device.
+
+#### [:::image type="icon" source="../../images/icons/group-policy.svg" border="false"::: **Group policy**](#tab/gpo)
+
+### Disable VBS with group policy
+
+Configure the policy used to enable VBS to **Disabled**.
+
+[!INCLUDE [gpo-settings-1](../../../../includes/configure/gpo-settings-1.md)]
+
+| Group policy path | Group policy setting | Value |
+| - | - | - |
+| **Computer Configuration\Administrative Templates\System\Device Guard\Turn on Virtualization Based Security** |Turn On Virtualization Based Security | **Disabled** |
+
+[!INCLUDE [gpo-settings-2](../../../../includes/configure/gpo-settings-2.md)]
+
+Once the policy is applied, restart the device
+
+#### [:::image type="icon" source="../../images/icons/windows-os.svg" border="false"::: **Registry**](#tab/reg)
+
+### Disable VBS with registry settings
+
+Delete the following registry keys:
+
+| Setting |
+|--|
+| Key path: `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard`
Key name: `EnableVirtualizationBasedSecurity` |
+| Key path: `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard`
Key name: `RequirePlatformSecurityFeatures`|
+
+> [!IMPORTANT]
+> If you manually remove the registry settings, make sure to delete them all, otherwise the device might go into BitLocker recovery.
+
+Restart the device to apply the change.
+
+---
+
+If Credential Guard is enabled with UEFI Lock, the EFI variables stored in firmware must be cleared using the command `bcdedit.exe`. From an elevated command prompt, run the following commands:
+
+```cmd
+bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO,DISABLE-VBS
+bcdedit /set vsmlaunchtype off
+```
+
+## Next steps
+
+- Review the advice and sample code for making your environment more secure and robust with Credential Guard in the [Additional mitigations](additional-mitigations.md) article
+- Review [considerations and known issues when using Credential Guard](considerations-known-issues.md)
+
+
+
+[CSP-1]: /windows/client-management/mdm/policy-csp-deviceguard#enablevirtualizationbasedsecurity
+[INT-1]: /mem/intune/configuration/settings-catalog
diff --git a/windows/security/identity-protection/credential-guard/considerations-known-issues.md b/windows/security/identity-protection/credential-guard/considerations-known-issues.md
new file mode 100644
index 0000000000..dbf52336f8
--- /dev/null
+++ b/windows/security/identity-protection/credential-guard/considerations-known-issues.md
@@ -0,0 +1,222 @@
+---
+ms.date: 08/31/2023
+title: Considerations and known issues when using Credential Guard
+description: Considerations, recommendations and known issues when using Credential Guard.
+ms.topic: troubleshooting
+---
+
+# Considerations and known issues when using Credential Guard
+
+It's recommended that in addition to deploying Credential Guard, organizations move away from passwords to other authentication methods, such as Windows Hello for Business, FIDO 2 security keys or smart cards.
+
+## Wi-fi and VPN considerations
+
+When you enable Credential Guard, you can no longer use NTLM classic authentication for single sign-on. You'll be forced to enter your credentials to use these protocols and can't save the credentials for future use.
+
+If you're using WiFi and VPN endpoints that are based on MS-CHAPv2, they're subject to similar attacks as for NTLMv1.
+
+For WiFi and VPN connections, it's recommended to move from MSCHAPv2-based connections (such as PEAP-MSCHAPv2 and EAP-MSCHAPv2), to certificate-based authentication (such as PEAP-TLS or EAP-TLS).
+
+## Kerberos considerations
+
+When you enable Credential Guard, you can no longer use Kerberos unconstrained delegation or DES encryption. Unconstrained delegation could allow attackers to extract Kerberos keys from the isolated LSA process.\
+Use constrained or resource-based Kerberos delegation instead.
+
+## Third party Security Support Providers considerations
+
+Some third party Security Support Providers (SSPs and APs) might not be compatible with Credential Guard because it doesn't allow third-party SSPs to ask for password hashes from LSA. However, SSPs and APs still get notified of the password when a user logs on and/or changes their password. Any use of undocumented APIs within custom SSPs and APs aren't supported.\
+It's recommended that custom implementations of SSPs/APs are tested with Credential Guard. SSPs and APs that depend on any undocumented or unsupported behaviors fail. For example, using the KerbQuerySupplementalCredentialsMessage API isn't supported. Replacing the NTLM or Kerberos SSPs with custom SSPs and APs.
+
+For more information, see [Restrictions around Registering and Installing a Security Package](/windows/win32/secauthn/restrictions-around-registering-and-installing-a-security-package).
+
+## Upgrade considerations
+
+As the depth and breadth of protections provided by Credential Guard are increased, new releases of Windows with Credential Guard running may affect scenarios that were working in the past. For example, Credential Guard may block the use of a particular type of credential or a particular component to prevent malware from taking advantage of vulnerabilities.
+
+Test scenarios required for operations in an organization before upgrading a device using Credential Guard.
+
+## Saved Windows credentials considerations
+
+*Credential Manager* allows you to store three types of credentials:
+
+- Windows credentials
+- Certificate-based credentials
+- Generic credentials
+
+Domain credentials that are stored in *Credential Manager* are protected with Credential Guard.
+
+Generic credentials, such as user names and passwords that you use to sign in websites, aren't protected since the applications require your clear-text password. If the application doesn't need a copy of the password, they can save domain credentials as Windows credentials that are protected. Windows credentials are used to connect to other computers on a network.
+
+The following considerations apply to the Credential Guard protections for Credential Manager:
+
+- Windows credentials saved by the Remote Desktop client can't be sent to a remote host. Attempts to use saved Windows credentials fail, displaying the error message *Logon attempt failed*
+- Applications that extract Windows credentials fail
+- When credentials are backed up from a PC that has Credential Guard enabled, the Windows credentials can't be restored. If you need to back up your credentials, you must do so before you enable Credential Guard
+
+## TPM clearing considerations
+
+Virtualization-based Security (VBS) uses the TPM to protect its key. When the TPM is cleared, the TPM protected key used to encrypt VBS secrets is lost.
+
+>[!WARNING]
+> Clearing the TPM results in loss of protected data for all features that use VBS to protect data.
+>
+> When a TPM is cleared, **all** features that use VBS to protect data can no longer decrypt their protected data.
+
+As a result, Credential Guard can no longer decrypt protected data. VBS creates a new TPM protected key for Credential Guard. Credential Guard uses the new key to protect new data. However, the previously protected data is lost forever.
+
+>[!NOTE]
+> Credential Guard obtains the key during initialization. The data loss will only impact persistent data and occur after the next system startup.
+
+### Windows credentials saved to Credential Manager
+
+Since Credential Manager can't decrypt saved Windows Credentials, they're deleted. Applications should prompt for credentials that were previously saved. If saved again, then Windows credentials are protected Credential Guard.
+
+### Domain-joined device's automatically provisioned public key
+
+Active Directory domain-joined devices automatically provision a bound public key, for more information about automatic public key provisioning, see [Domain-joined Device Public Key Authentication](/windows-server/security/kerberos/domain-joined-device-public-key-authentication).
+
+Since Credential Guard can't decrypt the protected private key, Windows uses the domain-joined computer's password for authentication to the domain. Unless other policies are deployed, there shouldn't be a loss of functionality. If a device is configured to only use public key, then it can't authenticate with password until that policy is disabled. For more information on Configuring devices to only use public key, see [Domain-joined Device Public Key Authentication](/windows-server/security/kerberos/domain-joined-device-public-key-authentication).
+
+Also if any access control checks including authentication policies require devices to have either the `KEY TRUST IDENTITY (S-1-18-4)` or `FRESH PUBLIC KEY IDENTITY (S-1-18-3)` well-known SIDs, then those access checks fail. For more information about authentication policies, see [Authentication Policies and Authentication Policy Silos](/windows-server/security/credentials-protection-and-management/authentication-policies-and-authentication-policy-silos). For more information about well-known SIDs, see [[MS-DTYP] Section 2.4.2.4 Well-known SID Structures](/openspecs/windows_protocols/ms-dtyp/81d92bba-d22b-4a8c-908a-554ab29148ab).
+
+### Breaking DPAPI on domain-joined devices
+
+On domain-joined devices, DPAPI can recover user keys using a domain controller from the user's domain. If a domain-joined device has no connectivity to a domain controller, then recovery isn't possible.
+
+>[!IMPORTANT]
+> Best practice when clearing a TPM on a domain-joined device is to be on a network with connectivity to domain controllers. This ensures DPAPI functions and the user does not experience strange behavior.
+
+Auto VPN configuration is protected with user DPAPI. User may not be able to use VPN to connect to domain controllers since the VPN configurations are lost.
+If you must clear the TPM on a domain-joined device without connectivity to domain controllers, then you should consider the following.
+
+Domain user sign-in on a domain-joined device after clearing a TPM for as long as there's no connectivity to a domain controller:
+
+|Credential Type | Behavior
+|---|---|---|
+| Certificate (smart card or Windows Hello for Business) | All data protected with user DPAPI is unusable and user DPAPI doesn't work at all. |
+| Password | If the user signed in with a certificate or password prior to clearing the TPM, then they can sign-in with password and user DPAPI is unaffected. |
+
+Once the device has connectivity to the domain controllers, DPAPI recovers the user's key and data protected prior to clearing the TPM can be decrypted.
+
+#### Impact of DPAPI failures on Windows Information Protection
+
+When data protected with user DPAPI is unusable, then the user loses access to all work data protected by Windows Information Protection. The impact includes: Outlook is unable to start and work protected documents can't be opened. If DPAPI is working, then newly created work data is protected and can be accessed.
+
+**Workaround:** Users can resolve the problem by connecting their device to the domain and rebooting or using their Encrypting File System Data Recovery Agent certificate. For more information about Encrypting File System Data Recovery Agent certificate, see [Create and verify an Encrypting File System (EFS) Data Recovery Agent (DRA) certificate](/windows/threat-protection/windows-information-protection/create-and-verify-an-efs-dra-certificate).
+
+## Known issues
+
+Credential Guard blocks certain authentication capabilities. Applications that require such capabilities won't function when Credential Guard is enabled.
+
+This article describes known issues when Credential Guard is enabled.
+
+### Single sign-on for Network services breaks after upgrading to Windows 11, version 22H2
+
+Devices that use 802.1x wireless or wired network, RDP, or VPN connections that rely on insecure protocols with password-based authentication are unable to use SSO to sign in and are forced to manually re-authenticate in every new Windows session when Credential Guard is running.
+
+#### Affected devices
+
+Any device with Credential Guard enabled may encounter the issue. As part of the Windows 11, version 22H2 update, eligible devices that didn't disable Credential Guard, have it enabled by default. This affected all devices on Enterprise (E3 and E5) and Education licenses, as well as some Pro licenses, as long as they met the [minimum hardware requirements](index.md#hardware-and-software-requirements).
+
+All Windows Pro devices that previously ran Credential Guard on an eligible license and later downgraded to Pro, and which still meet the [minimum hardware requirements](index.md#hardware-and-software-requirements), will receive default enablement.
+
+> [!TIP]
+> To determine if a Windows Pro device receives default enablement when upgraded to **Windows 11, version 22H2**, check if the registry key `IsolatedCredentialsRootSecret` is present in `Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0`.
+> If it's present, the device enables Credential Guard after the update.
+>
+> You can Credential Guard can be disabled after upgrade by following the [disablement instructions](configure.md#disable-credential-guard).
+
+#### Cause of the issue
+
+Applications and services are affected by the issue when they rely on insecure protocols that use password-based authentication. Such protocols are considered insecure because they can lead to password disclosure on the client or the server, and Credential Guard blocks them. Affected protocols include:
+
+- Kerberos unconstrained delegation (both SSO and supplied credentials are blocked)
+- Kerberos when PKINIT uses RSA encryption instead of Diffie-Hellman (both SSO and supplied credentials are blocked)
+- MS-CHAP (only SSO is blocked)
+- WDigest (only SSO is blocked)
+- NTLM v1 (only SSO is blocked)
+
+> [!NOTE]
+> Since only SSO is blocked for MS-CHAP, WDigest, and NTLM v1, these protocols can still be used by prompting the user to supply credentials.
+
+#### How to confirm the issue
+
+MS-CHAP and NTLMv1 are relevant to the SSO breakage after the Windows 11, version 22H2 update. To confirm if Credential Guard is blocking MS-CHAP or NTLMv1, open the Event Viewer (`eventvwr.exe`) and go to `Application and Services Logs\Microsoft\Windows\NTLM\Operational`. Check the following logs:
+
+:::row:::
+ :::column span="1":::
+ **Event ID (type)**
+ :::column-end:::
+ :::column span="3":::
+ **Description**
+ :::column-end:::
+:::row-end:::
+:::row:::
+ :::column span="1":::
+ 4013 (Warning)
+ :::column-end:::
+ :::column span="3":::
+ ```logging
+
-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 04b493aa73..e289afe305 100644
--- a/windows/security/identity-protection/hello-for-business/hello-faq.yml
+++ b/windows/security/identity-protection/hello-for-business/hello-faq.yml
@@ -36,7 +36,7 @@ sections:
- question: What's a container?
answer: |
In the context of Windows Hello for Business, a container is a logical grouping of *key material* or data. Windows Hello uses a single container that holds user key material for personal accounts, including key material associated with the user's Microsoft account or with other consumer identity providers, and credentials associated with a workplace or school account.
- The container holds enterprise credentials only on devices that have been registered with an organization; it contains key material for the enterprise IDP, such as on-premises Active Directory or Azure AD.
+ The container holds enterprise credentials only on devices that have been registered with an organization; it contains key material for the enterprise IDP, such as on-premises Active Directory or Microsoft Entra ID.
> [!NOTE]
> There are no physical containers on disk, in the registry, or elsewhere. Containers are logical units used to group related items. The keys, certificates, and credentials that Windows Hello stores, are protected without the creation of actual containers or folders.
@@ -46,7 +46,7 @@ sections:
Containers can contain several types of key material:
- An authentication key, which is always an asymmetric public-private key pair. This key pair is generated during registration. It must be unlocked each time it's accessed, by using either the user's PIN or a biometric gesture. The authentication key exists until the user resets the PIN, at which time a new key will be generated. When the new key is generated, all the key material that the old key previously protected must be decrypted and re-encrypted using the new key.
- - The IDP key. These keys can be either symmetric or asymmetric, depending on which IDP you use. A single container may contain zero or more IDP keys, with some restrictions (for example, the enterprise container can contain zero or one IDP key). IDP keys are stored in the container. For certificate-based Windows Hello for Work, when the container is unlocked, applications that require access to the IDP key or key pair can request access. IDP keys are used to sign or encrypt authentication requests or tokens sent from this device to the IDP. IDP keys are typically long-lived but could have a shorter lifetime than the authentication key. Microsoft accounts, Active Directory accounts, and Azure AD accounts all require the use of asymmetric key pairs. The device generates public and private keys, registers the public key with the IDP (which stores it for later verification), and securely stores the private key. For enterprises, the IDP keys can be generated in two ways:
+ - The IDP key. These keys can be either symmetric or asymmetric, depending on which IDP you use. A single container may contain zero or more IDP keys, with some restrictions (for example, the enterprise container can contain zero or one IDP key). IDP keys are stored in the container. For certificate-based Windows Hello for Work, when the container is unlocked, applications that require access to the IDP key or key pair can request access. IDP keys are used to sign or encrypt authentication requests or tokens sent from this device to the IDP. IDP keys are typically long-lived but could have a shorter lifetime than the authentication key. Microsoft accounts, Active Directory accounts, and Microsoft Entra accounts all require the use of asymmetric key pairs. The device generates public and private keys, registers the public key with the IDP (which stores it for later verification), and securely stores the private key. For enterprises, the IDP keys can be generated in two ways:
- The IDP key pair can be associated with an enterprise Certificate Authority (CA) through the Windows Network Device Enrollment Service (NDES). In this case, Windows Hello requests a new certificate with the same key as the certificate from the existing PKI. This option lets organizations that have an existing PKI continue to use it where appropriate. Given that many applications, such as VPN solutions, require the use of certificates, when you deploy Windows Hello in this mode, it allows a faster transition away from user passwords while still preserving certificate-based functionality. This option also allows the enterprise to store additional certificates in the protected container.
- The IDP can generate the IDP key pair directly, which allows quick, lower-overhead deployment of Windows Hello in environments that don't have or need a PKI.
- question: How are keys protected?
@@ -54,7 +54,7 @@ sections:
Anytime key material is generated, it must be protected against attack. The most robust way to do this is through specialized hardware. There's a long history of using hardware security modules (HSMs) to generate, store, and process keys for security-critical applications. Smart cards are a special type of HSM, as are devices that are compliant with the Trusted Computing Group TPM standard. Wherever possible, the Windows Hello for Business implementation takes advantage of onboard TPM hardware to generate and protect keys. Administrators can choose to allow key operations in software, but it's recommended the use of TPM hardware. The TPM protects against a variety of known and potential attacks, including PIN brute-force attacks. The TPM provides an additional layer of protection after an account lockout, too. When the TPM has locked the key material, the user will have to reset the PIN (which means the user will have to use MFA to reauthenticate to the IDP before the IDP allows re-registration). Resetting the PIN means that all keys and certificates encrypted with the old key material will be removed.
- question: How does PIN caching work with Windows Hello for Business?
answer: |
- Windows Hello for Business provides a PIN caching user experience by using a ticketing system. Rather than caching a PIN, processes cache a ticket they can use to request private key operations. Azure AD and Active Directory sign-in keys are cached under lock. This means the keys remain available for use without prompting, as long as the user is interactively signed-in. Microsoft Account sign-in keys are transactional keys, which means the user is always prompted when accessing the key.
+ Windows Hello for Business provides a PIN caching user experience by using a ticketing system. Rather than caching a PIN, processes cache a ticket they can use to request private key operations. Microsoft Entra ID and Active Directory sign-in keys are cached under lock. This means the keys remain available for use without prompting, as long as the user is interactively signed-in. Microsoft Account sign-in keys are transactional keys, which means the user is always prompted when accessing the key.
Beginning with Windows 10, version 1709, Windows Hello for Business used as a smart card (smart card emulation that is enabled by default) provides the same user experience of default smart card PIN caching. Each process requesting a private key operation will prompt the user for the PIN on first use. Subsequent private key operations won't prompt the user for the PIN.
@@ -70,9 +70,9 @@ sections:
Since Windows Hello biometrics data is stored in encrypted format, no user, or any process other than Windows Hello has access to it.
- question: What's the difference between non-destructive and destructive PIN reset?
answer: |
- Windows Hello for Business has two types of PIN reset: non-destructive and destructive. Organizations running Windows 10 version 1903 and later and Azure Active Directory can take advantage of the Microsoft PIN Reset service. Once on-boarded to a tenant and deployed to computers, users who have forgotten their PINs can authenticate to Azure, provide a second factor of authentication, and reset their PIN without reprovisioning a new Windows Hello for Business enrollment. This flow is a non-destructive PIN reset because the user doesn't delete the current credential and obtain a new one. For more information, see [PIN Reset](hello-feature-pin-reset.md).
+ Windows Hello for Business has two types of PIN reset: non-destructive and destructive. Organizations running Windows 10 version 1903 and later and Microsoft Entra ID can take advantage of the Microsoft PIN Reset service. Once on-boarded to a tenant and deployed to computers, users who have forgotten their PINs can authenticate to Azure, provide a second factor of authentication, and reset their PIN without reprovisioning a new Windows Hello for Business enrollment. This flow is a non-destructive PIN reset because the user doesn't delete the current credential and obtain a new one. For more information, see [PIN Reset](hello-feature-pin-reset.md).
- Organizations that have the on-premises deployment of Windows Hello for Business, or those not using Windows 10 version 1903 and later can use destructive PIN reset. With destructive PIN reset, users that have forgotten their PIN can authenticate by using their password and then performing a second factor of authentication to reprovision their Windows Hello for Business credential. Reprovisioning deletes the old credential and requests a new credential and certificate. On-premises deployments need network connectivity to their domain controllers, Active Directory Federation Services, and their issuing certificate authority to perform a destructive PIN reset. For hybrid Azure Active Directory joined devices, destructive PIN reset is only supported with the certificate trust model and the latest updates to Active Directory Federation Services.
+ Organizations that have the on-premises deployment of Windows Hello for Business, or those not using Windows 10 version 1903 and later can use destructive PIN reset. With destructive PIN reset, users that have forgotten their PIN can authenticate by using their password and then performing a second factor of authentication to reprovision their Windows Hello for Business credential. Reprovisioning deletes the old credential and requests a new credential and certificate. On-premises deployments need network connectivity to their domain controllers, Active Directory Federation Services, and their issuing certificate authority to perform a destructive PIN reset. For Microsoft Entra hybrid joined devices, destructive PIN reset is only supported with the certificate trust model and the latest updates to Active Directory Federation Services.
- question: When is Windows Hello biometrics database file created? How is a user enrolled into Windows Hello face or fingerprint authentication?
answer: |
Windows Hello biometrics template database file is created on the device only when a user is enrolled into Windows Hello biometrics-based authentication. Your workplace or IT administrator may have turned certain authentication functionality, however, it is always your choice if you want to use Windows Hello or an alternative method, like a PIN. Users can check their current enrollment into Windows Hello biometrics by going to sign-in options on their device. Go to **Start > Settings > Accounts > Sign-in** options. If you don't see Windows Hello in Sign-in options, then it may not be available for your device or blocked by admin via policy. Admins can request users to enroll into Windows Hello during Autopilot or during the initial setup of the device. Admins can disallow users to enroll into biometrics via Windows Hello for Business policy configurations. However, when allowed via policy configurations, enrollment into Windows Hello biometrics is always optional for users.
@@ -123,7 +123,7 @@ sections:
No. The movement away from passwords is accomplished by gradually reducing the use of the password. In situations where you can't authenticate by using biometrics, you need a fallback mechanism that isn't a password. The PIN is the fallback mechanism. Disabling or hiding the PIN credential provider will disable the use of biometrics.
- question: What is Event ID 300?
answer: |
- This event is created when Windows Hello for Business is successfully created and registered with Azure Active Directory (Azure AD). Applications or services can trigger actions on this event. For example, a certificate provisioning service can listen to this event and trigger a certificate request. This is a normal condition and no further action is required.
+ This event is created when Windows Hello for Business is successfully created and registered with Microsoft Entra ID. Applications or services can trigger actions on this event. For example, a certificate provisioning service can listen to this event and trigger a certificate request. This is a normal condition and no further action is required.
- question: What happens when an unauthorized user gains possession of a device enrolled in Windows Hello for Business?
answer: |
The unauthorized user won't be able to utilize any biometric options and will have the only option to enter a PIN.
@@ -142,12 +142,12 @@ sections:
- question: How many users can enroll for Windows Hello for Business on a single Windows device?
answer: |
The maximum number of supported enrollments on a single device is 10. This lets 10 users each enroll their face and up to 10 fingerprints. For devices with more than 10 users, or for users that sign-in to many devices (for example, a support technician), it's recommended the use of FIDO2 security keys.
- - question: I have extended Active Directory to Azure Active Directory. Can I use the on-premises deployment model?
+ - question: I have extended Active Directory to Microsoft Entra ID. Can I use the on-premises deployment model?
answer: |
No. If your organization is using Microsoft cloud services, then you must use a hybrid deployment model. On-premises deployments are exclusive to organizations who need more time before moving to the cloud and exclusively use Active Directory.
- - question: What attributes are synchronized by Azure AD Connect with Windows Hello for Business?
+ - question: What attributes are synchronized by Microsoft Entra Connect with Windows Hello for Business?
answer: |
- Review [Azure AD Connect sync: Attributes synchronized to Azure Active Directory](/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized) for a list of attributes that sync based on scenarios. The base scenarios that include Windows Hello for Business are the [Windows 10](/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized#windows-10) scenario and the [Device writeback](/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized#device-writeback) scenario. Your environment may include other attributes.
+ Review [Microsoft Entra Connect Sync: Attributes synchronized to Microsoft Entra ID](/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized) for a list of attributes that sync based on scenarios. The base scenarios that include Windows Hello for Business are the [Windows 10](/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized#windows-10) scenario and the [Device writeback](/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized#device-writeback) scenario. Your environment may include other attributes.
- question: Can I use third-party MFA providers with Windows Hello for Business?
answer: |
Yes, if you're using federated hybrid deployment, you can use any third-party that provides an AD FS MFA adapter. A list of third-party MFA adapters can be found [here](/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs#microsoft-and-third-party-additional-authentication-methods).
@@ -170,21 +170,21 @@ sections:
- question: Can I wear a mask to enroll or unlock using Windows Hello face authentication?
answer: |
Wearing a mask to enroll is a security concern because other users wearing a similar mask may be able to unlock your device. The product group is aware of this behavior and is investigating this article further. Remove a mask if you're wearing one when you enroll or unlock with Windows Hello face authentication. If your working environment doesn't allow you to remove a mask temporarily, consider un-enrolling from face authentication and only using PIN or fingerprint.
- - question: How does Windows Hello for Business work with Azure AD registered devices?
+ - question: How does Windows Hello for Business work with Microsoft Entra registered devices?
answer: |
- A user will be prompted to set up a Windows Hello for Business key on an Azure AD registered devices if the feature is enabled by policy. If the user has an existing Windows Hello container, the Windows Hello for Business key will be enrolled in that container and will be protected using existing gestures.
+ A user will be prompted to set up a Windows Hello for Business key on a Microsoft Entra registered devices if the feature is enabled by policy. If the user has an existing Windows Hello container, the Windows Hello for Business key will be enrolled in that container and will be protected using existing gestures.
- If a user has signed into their Azure AD registered device with Windows Hello, their Windows Hello for Business key will be used to authenticate the user's work identity when they try to use Azure AD resources. The Windows Hello for Business key meets Azure AD multifactor authentication (MFA) requirements and reduces the number of MFA prompts users will see when accessing resources.
+ If a user has signed into their Microsoft Entra registered device with Windows Hello, their Windows Hello for Business key will be used to authenticate the user's work identity when they try to use Microsoft Entra resources. The Windows Hello for Business key meets Microsoft Entra multifactor authentication (MFA) requirements and reduces the number of MFA prompts users will see when accessing resources.
- It's possible to Azure AD register a domain joined device. If the domain joined device has a convenience PIN, sign in with the convenience PIN will no longer work. This configuration isn't supported by Windows Hello for Business.
+ It's possible to Microsoft Entra register a domain joined device. If the domain joined device has a convenience PIN, sign in with the convenience PIN will no longer work. This configuration isn't supported by Windows Hello for Business.
- For more information, please read [Azure AD registered devices](/azure/active-directory/devices/concept-azure-ad-register).
+ For more information, please read [Microsoft Entra registered devices](/azure/active-directory/devices/concept-azure-ad-register).
- question: Does Windows Hello for Business work with non-Windows operating systems?
answer: |
Windows Hello for Business is a feature of the Windows platform. At this time, Microsoft isn't developing clients for other platforms. However, Microsoft is open to third-parties who are interested in moving these platforms away from passwords. Interested third-parties can get more information by emailing [whfbfeedback@microsoft.com](mailto:whfbfeedback@microsoft.com?subject=collaboration).
- - question: Does Windows Hello for Business work with Azure Active Directory Domain Services (Azure AD DS) clients?
+ - question: Does Windows Hello for Business work with Microsoft Entra Domain Services clients?
answer: |
- No, Azure AD DS is a separately managed environment in Azure, and hybrid device registration with cloud Azure AD isn't available for it via Azure AD Connect. Hence, Windows Hello for Business doesn't work with Azure AD DS.
+ No, Microsoft Entra Domain Services is a separately managed environment in Azure, and hybrid device registration with cloud Microsoft Entra ID isn't available for it via Microsoft Entra Connect. Hence, Windows Hello for Business doesn't work with Microsoft Entra Domain Services.
- question: Is Windows Hello for Business considered multifactor authentication?
answer: |
Windows Hello for Business is two-factor authentication based on the observed authentication factors of: *something you have*, *something you know*, and *something that's part of you*. Windows Hello for Business incorporates two of these factors: something you have (the user's private key protected by the device's security module) and something you know (your PIN). With the proper hardware, you can enhance the user experience by introducing biometrics. By using biometrics, you can replace the "something you know" authentication factor with the "something that is part of you" factor, with the assurances that users can fall back to the "something you know factor".
@@ -200,9 +200,9 @@ sections:
- question: What is convenience PIN?
answer: |
*Convenience PIN* provides a simpler way to sign in to Windows than passwords, but it still uses a password for authentication. When the correct convenience PIN is provided to Windows, the password information is loaded from its cache and authenticates the user. Organizations using convenience PINs should move to **Windows Hello for Business**. New Windows deployments should deploy Windows Hello for Business and not convenience PINs.
- - question: Can I use a convenience PIN with Azure Active Directory?
+ - question: Can I use a convenience PIN with Microsoft Entra ID?
answer: |
- No. While it's possible to set a convenience PIN on Azure AD joined and hybrid Azure AD joined devices, convenience PIN isn't supported for Azure AD user accounts (including synchronized identities). Convenience PIN is only supported for on-premises Active Directory users and local account users.
+ No. While it's possible to set a convenience PIN on Microsoft Entra joined and Microsoft Entra hybrid joined devices, convenience PIN isn't supported for Microsoft Entra user accounts (including synchronized identities). Convenience PIN is only supported for on-premises Active Directory users and local account users.
- question: What about virtual smart cards?
answer: |
Windows Hello for Business is the modern, two-factor authentication for Windows. Microsoft will deprecate virtual smart cards in the near future. Customers using virtual smart cards are strongly encouraged to move to Windows Hello for Business. Microsoft will publish the deprecation date to ensure customers have adequate lead time to move to Windows Hello for Business. We recommend that new Windows deployments use Windows Hello for Business.
@@ -231,7 +231,7 @@ sections:
questions:
- question: What is Windows Hello for Business cloud Kerberos trust?
answer: |
- Windows Hello for Business *cloud Kerberos trust* is a *trust model* that enables Windows Hello for Business deployment using the infrastructure introduced for supporting [security key sign-in on Hybrid Azure AD-joined devices and on-premises resource access on Azure AD Joined devices](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises). Cloud Kerberos trust is the preferred deployment model if you do not need to support certificate authentication scenarios. For more information, see [cloud Kerberos trust deployment](/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust).
+ Windows Hello for Business *cloud Kerberos trust* is a *trust model* that enables Windows Hello for Business deployment using the infrastructure introduced for supporting [security key sign-in on Microsoft Entra hybrid joined devices and on-premises resource access on Microsoft Entra joined devices](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises). Cloud Kerberos trust is the preferred deployment model if you do not need to support certificate authentication scenarios. For more information, see [cloud Kerberos trust deployment](/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust).
- question: Does Windows Hello for Business cloud Kerberos trust work in my on-premises environment?
answer: |
This feature doesn't work in a pure on-premises AD domain services environment.
@@ -254,7 +254,7 @@ sections:
questions:
- question: Why does authentication fail immediately after provisioning hybrid key trust?
answer: |
- In a hybrid deployment, a user's public key must sync from Azure AD to AD before it can be used to authenticate against a domain controller. This sync is handled by Azure AD Connect and will occur during a normal sync cycle.
+ In a hybrid deployment, a user's public key must sync from Microsoft Entra ID to Active Directory before it can be used to authenticate against a domain controller. This sync is handled by Microsoft Entra Connect and will occur during a normal sync cycle.
- question: Can I use Windows Hello for Business key trust and RDP?
answer: |
- Remote Desktop Protocol (RDP) doesn't currently support using key-based authentication and self-signed certificates as supplied credentials. However, you can deploy certificates in the key trust model to enable RDP. For more information, see [Deploying certificates to key trust users to enable RDP](hello-deployment-rdp-certs.md). In addition, Windows Hello for Business key trust can be also used with RDP with [Windows Defender Remote Credential Guard](../remote-credential-guard.md) without deploying certificates.
+ 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 9f0e8d48ae..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":::
@@ -68,7 +70,9 @@ To register the applications, follow these steps:
:::row-end:::
:::row:::
:::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
+ 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 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":::
@@ -78,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":::
@@ -111,10 +115,10 @@ Alternatively, you can configure devices using a [custom policy][INT-1] with the
| OMA-URI |Data type| Value|
|-|-|-|
-| `./Vendor/MSFT/Policy/PassportForWork/`*TenantId*`/Policies/EnablePinRecovery`| Boolean | Tue |
+| `./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
@@ -122,11 +126,12 @@ GET https://graph.microsoft.com/v1.0/organization?$select=id
#### [:::image type="icon" source="../../images/icons/group-policy.svg"::: **GPO**](#tab/gpo)
-[!INCLUDE [gpo-settings-1](../../../../includes/configure/gpo-settings-1.md)] **Computer Configuration > Administrative Templates > Windows Components > Windows Hello for Business**:
+[!INCLUDE [gpo-settings-1](../../../../includes/configure/gpo-settings-1.md)]
+[!INCLUDE [gpo-settings-1](../../../../includes/configure/gpo-settings-1.md)]
-| Group policy setting | Value |
-| - | - |
-| **Use PIN Recovery** | **Enabled** |
+| Group policy path | Group policy setting | Value |
+| - | - | - |
+|**Computer Configuration > Administrative Templates > Windows Components > Windows Hello for Business**| Use PIN Recovery | Enabled |
[!INCLUDE [gpo-settings-2](../../../../includes/configure/gpo-settings-2.md)]
@@ -174,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)]
@@ -196,14 +203,14 @@ Alternatively, you can configure devices using a [custom policy][INT-1] with the
|
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 219e82d35c..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
@@ -2,106 +2,116 @@
title: How Windows Hello for Business works - Provisioning
description: Explore the provisioning flows for Windows Hello for Business, from within a variety of environments.
ms.date: 2/15/2022
-ms.topic: article
+ms.topic: overview
---
# Windows Hello for Business Provisioning
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 b1338f11e5..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
@@ -2,7 +2,7 @@
title: How Windows Hello for Business works - technology and terms
description: Explore technology and terms associated with Windows Hello for Business. Learn how Windows Hello for Business works.
ms.date: 10/08/2018
-ms.topic: article
+ms.topic: glossary
---
# Technology and terms
@@ -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 93bfd6d56a..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
@@ -2,11 +2,11 @@
title: How Windows Hello for Business works
description: Learn how Windows Hello for Business works, and how it can help your users authenticate to services.
ms.date: 05/05/2018
-ms.topic: article
+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 bcd910f606..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: article
+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 d1059a1570..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 hybrid 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,
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 | 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-adfs.md b/windows/security/identity-protection/hello-for-business/hello-key-trust-adfs.md
index be437d043f..cf93d23831 100644
--- a/windows/security/identity-protection/hello-for-business/hello-key-trust-adfs.md
+++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-adfs.md
@@ -1,5 +1,5 @@
---
-ms.date: 12/12/2022
+ms.date: 09/07/2023
title: Prepare and deploy Active Directory Federation Services in an on-premises key trust
description: Learn how to configure Active Directory Federation Services to support the Windows Hello for Business key trust model.
appliesto:
diff --git a/windows/security/identity-protection/hello-for-business/hello-key-trust-policy-settings.md b/windows/security/identity-protection/hello-for-business/hello-key-trust-policy-settings.md
index 3fd25ec607..ed52f1c594 100644
--- a/windows/security/identity-protection/hello-for-business/hello-key-trust-policy-settings.md
+++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-policy-settings.md
@@ -1,5 +1,5 @@
---
-ms.date: 12/12/2022
+ms.date: 09/07/2023
title: Configure Windows Hello for Business Policy settings in an on-premises key trust
description: Configure Windows Hello for Business Policy settings for Windows Hello for Business in an on-premises key trust scenario
appliesto:
@@ -20,7 +20,7 @@ If you configure the Group Policy for computers, all users that sign-in to those
The Group Policy setting determines whether users are allowed, and prompted, to enroll for Windows Hello for Business. It can be configured for computers or users.
-If you configure the Group Policy for computers, all users that sign-in to those computers will be allowed and prompted to enroll for Windows Hello for Business. If you configure the Group Policy for users, only those users will be allowed and prompted to enroll for Windows Hello for Business .
+If you configure the Group Policy for computers, all users that sign-in to those computers will be allowed and prompted to enroll for Windows Hello for Business. If you configure the Group Policy for users, only those users will be allowed and prompted to enroll for Windows Hello for Business.
## Create the GPO
@@ -105,4 +105,4 @@ Before you continue with the deployment, validate your deployment progress by re
## Add users to the Windows Hello for Business Users group
-Users must receive the Windows Hello for Business group policy settings and have the proper permission to enroll for the Windows Hello for Business Authentication certificate. You can provide users with these settings and permissions by adding the group used synchronize users to the *Windows Hello for Business Users* group. Users and groups that are not members of this group will not attempt to enroll for Windows Hello for Business.
\ No newline at end of file
+Users must receive the Windows Hello for Business group policy settings and have the proper permission to enroll for the Windows Hello for Business Authentication certificate. You can provide users with these settings and permissions by adding the group used synchronize users to the *Windows Hello for Business Users* group. Users and groups that are not members of this group will not attempt to enroll for Windows Hello for Business.
diff --git a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-ad-prereq.md b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-ad-prereq.md
index 19fe709d3f..2537513f37 100644
--- a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-ad-prereq.md
+++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-ad-prereq.md
@@ -1,7 +1,7 @@
---
title: Validate Active Directory prerequisites in an on-premises key trust
description: Validate Active Directory prerequisites when deploying Windows Hello for Business in a key trust model.
-ms.date: 12/12/2022
+ms.date: 09/07/2023
appliesto:
- ✅ Windows 11
- ✅ Windows 10
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 4d089851ff..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,7 +1,7 @@
---
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.
-ms.date: 12/12/2022
+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
- ✅ Windows 10
@@ -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-key-trust-validate-pki.md b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-pki.md
index e2f7510aac..ab932d9a99 100644
--- a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-pki.md
+++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-pki.md
@@ -1,7 +1,7 @@
---
title: Configure and validate the Public Key Infrastructure in an on-premises key trust model
description: Configure and validate the Public Key Infrastructure when deploying Windows Hello for Business in a key trust model.
-ms.date: 12/12/2022
+ms.date: 09/07/2023
appliesto:
- ✅ Windows 11
- ✅ Windows 10
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 576ffdb0a4..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
@@ -4,8 +4,8 @@ description: Learn how to create a Group Policy or mobile device management (MDM
ms.collection:
- highpri
- tier1
-ms.date: 2/15/2022
-ms.topic: article
+ms.date: 9/25/2023
+ms.topic: reference
---
# Manage Windows Hello for Business in your organization
@@ -13,37 +13,37 @@ ms.topic: article
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.
## Group Policy settings for Windows Hello for Business
-The following table lists the Group Policy settings that you can configure for Windows Hello use in your organization. These policy settings are available in **User configuration** and **Computer Configuration** under **Policies > Administrative Templates > Windows Components > Windows Hello for Business**.
+The following table lists the Group Policy settings that you can configure for Windows Hello use in your organization. These policy settings are available in **User configuration** and **Computer Configuration** under **Policies** > **Administrative Templates** > **Windows Components** > **Windows Hello for Business**.
> [!NOTE]
> The location of the PIN complexity section of the Group Policy is: **Computer Configuration > Administrative Templates > System > PIN Complexity**.
|Policy|Scope|Options|
|--- |--- |--- |
-|Use Windows Hello for Business|Computer or user|
- **Enabled**: Device provisions Windows Hello for Business using keys or certificates for all users.
- **Disabled**: Device doesn't provision Windows Hello for Business for any user.|
+|Use a hardware security device|Computer|- **Not configured**: Windows Hello for Business will be provisioned using TPM if available, and will be provisioned using software if TPM isn't available.
- **Enabled**: Windows Hello for Business will only be provisioned using TPM. This feature will provision Windows Hello for Business using TPM 1.2 unless the option to exclude them is explicitly set.
- **Disabled**: Windows Hello for Business will be provisioned using TPM if available, and will be provisioned using software if TPM isn't available.|
+|Use certificate for on-premises authentication|Computer or user|- **Not configured**: Windows Hello for Business enrolls a key that is used for on-premises authentication.
- **Enabled**: Windows Hello for Business enrolls a sign-in certificate using ADFS that is used for on-premises authentication.
- **Disabled**: Windows Hello for Business enrolls a key that is used for on-premises authentication.|
+|Use PIN recovery|Computer|- Added in Windows 10, version 1703
- **Not configured**: Windows Hello for Business doesn't create or store a PIN recovery secret. PIN reset doesn't use the Azure-based PIN recovery service
- **Enabled**: Windows Hello for Business uses the Azure-based PIN recovery service for PIN reset
- **Disabled**: Windows Hello for Business doesn't create or store a PIN recovery secret. PIN reset doesn't use the Azure-based PIN recovery service.
- For more information about using the PIN recovery service for PIN reset see [Windows Hello for Business PIN Reset](hello-feature-pin-reset.md).|
+|Use biometrics|Computer|- **Not configured**: Biometrics can be used as a gesture in place of a PIN
- **Enabled**: Biometrics can be used as a gesture in place of a PIN.
- **Disabled**: Only a PIN can be used as a gesture.|
### PIN Complexity
|Policy|Scope|Options|
|--- |--- |--- |
-|Require digits|Computer|
- **Enabled**: Users must include a digit in their PIN.
- **Disabled**: Users can't use digits in their PIN.|
+|Require lowercase letters|Computer|- **Not configured**: Users can't use lowercase letters in their PIN
- **Enabled**: Users must include at least one lowercase letter in their PIN.
- **Disabled**: Users can't use lowercase letters in their PIN.|
+|Maximum PIN length|Computer|- **Not configured**: PIN length must be less than or equal to 127.
- **Enabled**: PIN length must be less than or equal to the number you specify.
- **Disabled**: PIN length must be less than or equal to 127.|
+|Minimum PIN length|Computer|- **Not configured**: PIN length must be greater than or equal to 4.
- **Enabled**: PIN length must be greater than or equal to the number you specify.
- **Disabled**: PIN length must be greater than or equal to 4.|
+|Expiration|Computer|- **Not configured**: PIN doesn't expire.
- **Enabled**: PIN can be set to expire after any number of days between 1 and 730, or PIN can be set to never expire by setting policy to 0.
- **Disabled**: PIN doesn't expire.|
+|History|Computer|- **Not configured**: Previous PINs aren't stored.
- **Enabled**: Specify the number of previous PINs that can be associated to a user account that can't be reused.
- **Disabled**: Previous PINs aren't stored.
**Note** Current PIN is included in PIN history.
+|Require special characters|Computer|- **Not configured**: Windows allows, but doesn't require, special characters in the PIN.
- **Enabled**: Windows requires the user to include at least one special character in their PIN.
- **Disabled**: Windows doesn't allow the user to include special characters in their PIN.|
+|Require uppercase letters|Computer|- **Not configured**: Users can't include an uppercase letter in their PIN.
- **Enabled**: Users must include at least one uppercase letter in their PIN.
- **Disabled**: Users can't include an uppercase letter in their PIN.|
### Phone Sign-in
@@ -56,34 +56,34 @@ The following table lists the Group Policy settings that you can configure for W
The following table lists the MDM policy settings that you can configure for Windows Hello for Business use in your workplace. These MDM policy settings use the [PassportForWork configuration service provider (CSP)](/windows/client-management/mdm/passportforwork-csp).
>[!IMPORTANT]
->Starting in Windows 10, version 1607, all devices only have one PIN associated with Windows Hello for Business. This means that any PIN on a device will be subject to the policies specified in the PassportForWork CSP. The values specified take precedence over any complexity rules set via Exchange ActiveSync (EAS) or the DeviceLock CSP.
+>All devices only have one PIN associated with Windows Hello for Business. This means that any PIN on a device will be subject to the policies specified in the PassportForWork CSP. The values specified take precedence over any complexity rules set via Exchange ActiveSync (EAS) or the DeviceLock CSP.
|Policy|Scope|Default|Options|
|--- |--- |--- |--- |
-|UsePassportForWork|Device or user|True|
- False: Users won't be able to provision Windows Hello for Business.
**Note:** If Windows Hello for Business is enabled, and then the policy is changed to False, users who previously set up Windows Hello for Business can continue to use it, but won't be able to set up Windows Hello for Business on other devices|
+|RequireSecurityDevice|Device or user|False|- True: Windows Hello for Business will only be provisioned using TPM.
- False: Windows Hello for Business will be provisioned using TPM if available, and will be provisioned using software if TPM isn't available.|
+|ExcludeSecurityDevice
- TPM12|Device|False|Added in Windows 10, version 1703
- True: TPM revision 1.2 modules will be disallowed from being used with Windows Hello for Business.
- False: TPM revision 1.2 modules will be allowed to be used with Windows Hello for Business.|
+|EnablePinRecovery|Device or use|False|- Added in Windows 10, version 1703
- True: Windows Hello for Business uses the Azure-based PIN recovery service for PIN reset.
- False: Windows Hello for Business doesn't create or store a PIN recovery secret. PIN reset doesn't use the Azure-based PIN recovery service. For more information about using the PIN recovery service for PIN reset see [Windows Hello for Business PIN Reset](hello-feature-pin-reset.md).|
### Biometrics
|Policy|Scope|Default|Options|
|--- |--- |--- |--- |
-|UseBiometrics|Device |False|
- False: Only a PIN can be used as a gesture for domain sign-in.|
+|- FacialFeaturesUser
- EnhancedAntiSpoofing|Device|Not configured|- Not configured: users can choose whether to turn on enhanced anti-spoofing.
- True: Enhanced anti-spoofing is required on devices which support it.
- False: Users can't turn on enhanced anti-spoofing.|
### PINComplexity
|Policy|Scope|Default|Options|
|--- |--- |--- |--- |
-|Digits |Device or user|1 |
- 1: At least one digit is required.
- 2: Digits aren't allowed.|
+|Lowercase letters |Device or user|2|- 0: Lowercase letters are allowed.
- 1: At least one lowercase letter is required.
- 2: Lowercase letters aren't allowed.|
+|Special characters|Device or user|2|- 0: Special characters are allowed.
- 1: At least one special character is required.
- 2: Special characters aren't allowed.|
+|Uppercase letters|Device or user|2|- 0: Uppercase letters are allowed.
- 1: At least one uppercase letter is required.
- 2: Uppercase letters aren't allowed.|
+|Maximum PIN length |Device or user|127 |- Maximum length that can be set is 127. Maximum length can't be less than minimum setting.|
+|Minimum PIN length|Device or user|6|- Minimum length that can be set is 6. Minimum length can't be greater than maximum setting.|
+|Expiration |Device or user|0|- Integer value specifies the period of time (in days) that a PIN can be used before the system requires the user to change it. The largest number you can configure for this policy setting is 730. The lowest number you can configure for this policy setting is 0. If this policy is set to 0, then the user's PIN will never expire.|
+|History|Device or user|0|- Integer value that specifies the number of past PINs that can be associated to a user account that can't be reused. The largest number you can configure for this policy setting is 50. The lowest number you can configure for this policy setting is 0. If this policy is set to 0, then storage of previous PINs isn't required.|
### Remote
@@ -92,42 +92,15 @@ The following table lists the MDM policy settings that you can configure for Win
|UseRemotePassport|Device or user|False|Not currently supported.|
>[!NOTE]
-> In Windows 10, version 1709 and later, if policy is not configured to explicitly require letters or special characters, users can optionally set an alphanumeric PIN. Prior to version 1709 the user is required to set a numeric PIN.
+> If a policy isn't explicitly configured to require letters or special characters, users can optionally set an alphanumeric PIN.
## Policy conflicts from multiple policy sources
-Windows Hello for Business is designed to be managed by Group Policy or MDM but not a combination of both. If policies are set from both sources it can result in a mixed result of what is actually enforced for a user or device.
+Windows Hello for Business is designed to be managed by group policy or MDM, but not a combination of both. Avoid mixing group policy and MDM policy settings for Windows Hello for Business. If you mix group policy and MDM policy settings, the MDM settings are ignored until all group policy settings are cleared.
-Policies for Windows Hello for Business are enforced using the following hierarchy: User Group Policy > Computer Group Policy > User MDM > Device MDM > Device Lock policy.
+> [!IMPORTANT]
+> The [*MDMWinsOverGP*](/windows/client-management/mdm/policy-csp-controlpolicyconflict#mdmwinsovergp) policy setting doesn't apply to Windows Hello for Business. MDMWinsOverGP only applies to policies in the *Policy CSP*, while the Windows Hello for Business policies are in the *PassportForWork CSP*.
-Feature enablement policy and certificate trust policy are grouped together and enforced from the same source (either GP or MDM), based on the rule above. The Use Passport for Work policy is used to determine the winning policy source.
+## Policy precedence
-All PIN complexity policies are grouped separately from feature enablement and are enforced from a single policy source. Use a hardware security device and RequireSecurityDevice enforcement are also grouped together with PIN complexity policy. Conflict resolution for other Windows Hello for Business policies are enforced on a per policy basis.
-
->[!NOTE]
-> Windows Hello for Business policy conflict resolution logic does not respect the ControlPolicyConflict/MDMWinsOverGP policy in the Policy CSP.
->
->Examples
->
->The following are configured using computer Group Policy:
->
->- Use Windows Hello for Business - Enabled
->- User certificate for on-premises authentication - Enabled
->
->The following are configured using device MDM Policy:
->
->- UsePassportForWork - Disabled
->- UseCertificateForOnPremAuth - Disabled
->- MinimumPINLength - 8
->- Digits - 1
->- LowercaseLetters - 1
->- SpecialCharacters - 1
->
->Enforced policy set:
->
->- Use Windows Hello for Business - Enabled
->- Use certificate for on-premises authentication - Enabled
->- MinimumPINLength - 8
->- Digits - 1
->- LowercaseLetters - 1
->- SpecialCharacters - 1
\ No newline at end of file
+Windows Hello for Business *user policies* take precedence over *computer policies*. If a user policy is set, the corresponded computer policy is ignored. If a user policy is not set, the computer policy is used.
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 3363f0ae55..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
@@ -2,11 +2,11 @@
title: Planning a Windows Hello for Business Deployment
description: Learn about the role of each component within Windows Hello for Business and how certain deployment decisions affect other aspects of your infrastructure.
ms.date: 09/16/2020
-ms.topic: article
+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,44 +81,44 @@ 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.
> [!NOTE]
-> RDP does not support authentication with Windows Hello for Business key trust deployments as a supplied credential. RDP is only supported with certificate trust deployments as a supplied credential at this time. Windows Hello for Business key trust can be used with [Windows Defender Remote Credential Guard](../remote-credential-guard.md).
+> RDP does not support authentication with Windows Hello for Business key trust deployments as a supplied credential. RDP is only supported with certificate trust deployments as a supplied credential at this time. Windows Hello for Business key trust can be used with [Remote Credential Guard](../remote-credential-guard.md).
#### 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 fc9083049d..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
@@ -2,7 +2,7 @@
title: Prepare people to use Windows Hello
description: When you set a policy to require Windows Hello for Business in the workplace, you will want to prepare people in your organization.
ms.date: 08/19/2018
-ms.topic: article
+ms.topic: end-user-help
---
# Prepare people to use Windows Hello
@@ -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/hello-videos.md b/windows/security/identity-protection/hello-for-business/hello-videos.md
index 0963b04163..24b362c125 100644
--- a/windows/security/identity-protection/hello-for-business/hello-videos.md
+++ b/windows/security/identity-protection/hello-for-business/hello-videos.md
@@ -1,8 +1,8 @@
---
title: Windows Hello for Business Videos
description: View several informative videos describing features and experiences in Windows Hello for Business in Windows 10 and Windows 11.
-ms.date: 03/09/2023
-ms.topic: article
+ms.date: 09/07/2023
+ms.topic: get-started
---
# Windows Hello for Business Videos
## Overview of Windows Hello for Business and Features
diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless/aduc-account-scril.png b/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/aduc-account-scril.png
similarity index 100%
rename from windows/security/identity-protection/hello-for-business/images/passwordless/aduc-account-scril.png
rename to windows/security/identity-protection/hello-for-business/images/passwordless-strategy/aduc-account-scril.png
diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless/exclude-credential-providers-properties.png b/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/exclude-credential-providers-properties.png
similarity index 100%
rename from windows/security/identity-protection/hello-for-business/images/passwordless/exclude-credential-providers-properties.png
rename to windows/security/identity-protection/hello-for-business/images/passwordless-strategy/exclude-credential-providers-properties.png
diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless/four-steps-passwordless-strategy.png b/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/four-steps-passwordless-strategy.png
similarity index 100%
rename from windows/security/identity-protection/hello-for-business/images/passwordless/four-steps-passwordless-strategy.png
rename to windows/security/identity-protection/hello-for-business/images/passwordless-strategy/four-steps-passwordless-strategy.png
diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless/gpmc-exclude-credential-providers.png b/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/gpmc-exclude-credential-providers.png
similarity index 100%
rename from windows/security/identity-protection/hello-for-business/images/passwordless/gpmc-exclude-credential-providers.png
rename to windows/security/identity-protection/hello-for-business/images/passwordless-strategy/gpmc-exclude-credential-providers.png
diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless/gpmc-require-smart-card-policy.png b/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/gpmc-require-smart-card-policy.png
similarity index 100%
rename from windows/security/identity-protection/hello-for-business/images/passwordless/gpmc-require-smart-card-policy.png
rename to windows/security/identity-protection/hello-for-business/images/passwordless-strategy/gpmc-require-smart-card-policy.png
diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless/gpmc-security-options.png b/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/gpmc-security-options.png
similarity index 100%
rename from windows/security/identity-protection/hello-for-business/images/passwordless/gpmc-security-options.png
rename to windows/security/identity-protection/hello-for-business/images/passwordless-strategy/gpmc-security-options.png
diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless/require-whfb-smart-card-policy.png b/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/require-whfb-smart-card-policy.png
similarity index 100%
rename from windows/security/identity-protection/hello-for-business/images/passwordless/require-whfb-smart-card-policy.png
rename to windows/security/identity-protection/hello-for-business/images/passwordless-strategy/require-whfb-smart-card-policy.png
diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless/server-2012-adac-user-scril.png b/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/server-2012-adac-user-scril.png
similarity index 100%
rename from windows/security/identity-protection/hello-for-business/images/passwordless/server-2012-adac-user-scril.png
rename to windows/security/identity-protection/hello-for-business/images/passwordless-strategy/server-2012-adac-user-scril.png
diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless/server-2016-adac-domain-scril.png b/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/server-2016-adac-domain-scril.png
similarity index 100%
rename from windows/security/identity-protection/hello-for-business/images/passwordless/server-2016-adac-domain-scril.png
rename to windows/security/identity-protection/hello-for-business/images/passwordless-strategy/server-2016-adac-domain-scril.png
diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless/server-2016-adac-user-scril.png b/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/server-2016-adac-user-scril.png
similarity index 100%
rename from windows/security/identity-protection/hello-for-business/images/passwordless/server-2016-adac-user-scril.png
rename to windows/security/identity-protection/hello-for-business/images/passwordless-strategy/server-2016-adac-user-scril.png
diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless/edge-on.png b/windows/security/identity-protection/hello-for-business/images/passwordless/edge-on.png
new file mode 100644
index 0000000000..06a13b6f1a
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/passwordless/edge-on.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless/key-credential-provider.svg b/windows/security/identity-protection/hello-for-business/images/passwordless/key-credential-provider.svg
new file mode 100644
index 0000000000..dd8c09b2dd
--- /dev/null
+++ b/windows/security/identity-protection/hello-for-business/images/passwordless/key-credential-provider.svg
@@ -0,0 +1,11 @@
+
diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless/lock-screen-off.png b/windows/security/identity-protection/hello-for-business/images/passwordless/lock-screen-off.png
new file mode 100644
index 0000000000..ccfade47d9
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/passwordless/lock-screen-off.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless/lock-screen-on.png b/windows/security/identity-protection/hello-for-business/images/passwordless/lock-screen-on.png
new file mode 100644
index 0000000000..abb9b6456d
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/passwordless/lock-screen-on.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless/uac-off.png b/windows/security/identity-protection/hello-for-business/images/passwordless/uac-off.png
new file mode 100644
index 0000000000..8913baa8ce
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/passwordless/uac-off.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless/uac-on.png b/windows/security/identity-protection/hello-for-business/images/passwordless/uac-on.png
new file mode 100644
index 0000000000..b0d03a6299
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/passwordless/uac-on.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/pinreset/pin-reset.gif b/windows/security/identity-protection/hello-for-business/images/pinreset/pin-reset.gif
index 2ef07cd63c..d8aba4d740 100644
Binary files a/windows/security/identity-protection/hello-for-business/images/pinreset/pin-reset.gif and b/windows/security/identity-protection/hello-for-business/images/pinreset/pin-reset.gif differ
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 84acf6b19c..953074993d 100644
--- a/windows/security/identity-protection/hello-for-business/index.md
+++ b/windows/security/identity-protection/hello-for-business/index.md
@@ -4,7 +4,7 @@ description: Learn how Windows Hello for Business replaces passwords with strong
ms.collection:
- highpri
- tier1
-ms.topic: conceptual
+ms.topic: overview
ms.date: 04/24/2023
---
# Windows Hello for Business Overview
@@ -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,9 +89,9 @@ 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 [Windows Defender Remote Credential Guard](../remote-credential-guard.md).
+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).
## Learn more
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 9dafd8be5b..a66a69f90c 100644
--- a/windows/security/identity-protection/hello-for-business/passwordless-strategy.md
+++ b/windows/security/identity-protection/hello-for-business/passwordless-strategy.md
@@ -13,11 +13,11 @@ This article describes Windows' password-less strategy and how Windows Hello for
Over the past few years, Microsoft has continued their commitment to enabling a world without passwords.
-:::image type="content" source="images/passwordless/four-steps-passwordless-strategy.png" alt-text="Diagram of stair-step strategy with four steps.":::
+:::image type="content" source="images/passwordless-strategy/four-steps-passwordless-strategy.png" alt-text="Diagram of stair-step strategy with four steps.":::
### 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.
@@ -224,17 +224,17 @@ Windows provides two ways to prevent your users from using passwords. You can us
You can use Group Policy to deploy an interactive logon security policy setting to the computer. This policy setting is found under **Computer Configuration > Policies > Windows Settings > Local Policy > Security Options**. The name of the policy setting depends on the version of the operating systems you use to configure Group Policy.
-:::image type="content" source="images/passwordless/gpmc-security-options.png" alt-text="The Group Policy Management Editor displaying the location of the Security Options node.":::
+:::image type="content" source="images/passwordless-strategy/gpmc-security-options.png" alt-text="The Group Policy Management Editor displaying the location of the Security Options node.":::
**Windows Server 2016 and earlier**
The policy name for these operating systems is **Interactive logon: Require smart card**.
-:::image type="content" source="images/passwordless/gpmc-require-smart-card-policy.png" alt-text="The Group Policy Management Editor displaying the location of the policy 'Interactive logon: Require smart card'.":::
+:::image type="content" source="images/passwordless-strategy/gpmc-require-smart-card-policy.png" alt-text="The Group Policy Management Editor displaying the location of the policy 'Interactive logon: Require smart card'.":::
**Windows 10, version 1703 or later using Remote Server Administrator Tools**
The policy name for these operating systems is **Interactive logon: Require Windows Hello for Business or smart card**.
-:::image type="content" source="images/passwordless/require-whfb-smart-card-policy.png" alt-text="Highlighting the security policy 'Interactive logon: Require Windows Hello for Business or smart card'.":::
+:::image type="content" source="images/passwordless-strategy/require-whfb-smart-card-policy.png" alt-text="Highlighting the security policy 'Interactive logon: Require Windows Hello for Business or smart card'.":::
When you enable this security policy setting, Windows prevents users from signing in or unlocking with a password. The password credential provider remains visible to the user. If a user tries to use a password, Windows informs the user they must use Windows Hello for Business or a smart card.
@@ -242,11 +242,11 @@ When you enable this security policy setting, Windows prevents users from signin
You can use Group Policy to deploy an administrative template policy setting to the computer. This policy setting is found under **Computer Configuration > Policies > Administrative Templates > System > Logon**:
-:::image type="content" source="images/passwordless/gpmc-exclude-credential-providers.png" alt-text="The Group Policy Management Editor displaying the location of 'Logon' node and the policy setting 'Exclude credential providers'.":::
+:::image type="content" source="images/passwordless-strategy/gpmc-exclude-credential-providers.png" alt-text="The Group Policy Management Editor displaying the location of 'Logon' node and the policy setting 'Exclude credential providers'.":::
The name of the policy setting is **Exclude credential providers**. The value to enter in the policy to hide the password credential provider is `{60b78e88-ead8-445c-9cfd-0b87f74ea6cd}`.
-:::image type="content" source="images/passwordless/exclude-credential-providers-properties.png" alt-text="Properties of the policy setting 'Exclude credential providers'.":::
+:::image type="content" source="images/passwordless-strategy/exclude-credential-providers-properties.png" alt-text="Properties of the policy setting 'Exclude credential providers'.":::
Excluding the password credential provider hides the password credential provider from Windows and any application that attempts to load it. This configuration prevents the user from entering a password using the credential provider. However, this change doesn't prevent applications from creating their own password collection dialogs and prompting the user for a password using custom dialogs.
@@ -296,7 +296,7 @@ The account options on a user account include the option **Smart card is require
The following image shows the SCRIL setting for a user in Active Directory Users and Computers:
-:::image type="content" source="images/passwordless/aduc-account-scril.png" alt-text="Example user properties in Active Directory that shows the SCRIL setting on Account options.":::
+:::image type="content" source="images/passwordless-strategy/aduc-account-scril.png" alt-text="Example user properties in Active Directory that shows the SCRIL setting on Account options.":::
When you configure a user account for SCRIL, Active Directory changes the affected user's password to a random 128 bits of data. Additionally, domain controllers hosting the user account don't allow the user to sign-in interactively with a password. Users will no longer need to change their password when it expires, because passwords for SCRIL users don't expire. The users are effectively password-less because:
@@ -307,7 +307,7 @@ When you configure a user account for SCRIL, Active Directory changes the affect
The following image shows the SCRIL setting for a user in Active Directory Administrative Center on Windows Server 2012:
-:::image type="content" source="images/passwordless/server-2012-adac-user-scril.png" alt-text="Example user properties in Windows Server 2012 Active Directory Administrative Center that shows the SCRIL setting.":::
+:::image type="content" source="images/passwordless-strategy/server-2012-adac-user-scril.png" alt-text="Example user properties in Windows Server 2012 Active Directory Administrative Center that shows the SCRIL setting.":::
> [!NOTE]
> Although a SCRIL user's password never expires in early domains, you can toggle the SCRIL configuration on a user account to generate a new random 128 bit password. Use the following process to toggle this configuration:
@@ -317,11 +317,11 @@ The following image shows the SCRIL setting for a user in Active Directory Admin
> 1. Enable the setting.
> 1. Save changes again.
>
-> When you upgrade the domain to Windows Server 2016 domain forest functional level or later, the domain controller automatically does this action for you.
+> When you upgrade the domain functional level to Windows Server 2016 or later, the domain controller automatically does this action for you.
The following image shows the SCRIL setting for a user in Active Directory Administrative Center on Windows Server 2016:
-:::image type="content" source="images/passwordless/server-2016-adac-user-scril.png" alt-text="Example user properties in Windows Server 2016 Active Directory Administrative Center that shows the SCRIL setting.":::
+:::image type="content" source="images/passwordless-strategy/server-2016-adac-user-scril.png" alt-text="Example user properties in Windows Server 2016 Active Directory Administrative Center that shows the SCRIL setting.":::
> [!TIP]
> Windows Hello for Business was formerly known as Microsoft Passport.
@@ -332,8 +332,7 @@ Domains configured for Windows Server 2016 or later domain functional level can
In this configuration, passwords for SCRIL-configured users expire based on Active Directory password policy settings. When the SCRIL user authenticates from a domain controller, the domain controller recognizes the password has expired, and automatically generates a new random 128-bit password for the user as part of the authentication. This feature is great because your users don't experience any change password notifications or any authentication outages.
-:::image type="content" source="images/passwordless/server-2016-adac-domain-scril.png" alt-text="The Active Directory Administrative Center on Windows Server 2016 showing the domain setting for SCRIL.":::
+:::image type="content" source="images/passwordless-strategy/server-2016-adac-domain-scril.png" alt-text="The Active Directory Administrative Center on Windows Server 2016 showing the domain setting for SCRIL.":::
> [!NOTE]
> Some components within Windows 10, such as Data Protection APIs and NTLM authentication, still need artifacts of a user possessing a password. This configuration provides interoperability by reducing the usage surface while Microsoft continues to close the gaps to remove the password completely.
-
diff --git a/windows/security/identity-protection/hello-for-business/toc.yml b/windows/security/identity-protection/hello-for-business/toc.yml
index ad2fc7674a..ee0f2774a8 100644
--- a/windows/security/identity-protection/hello-for-business/toc.yml
+++ b/windows/security/identity-protection/hello-for-business/toc.yml
@@ -4,8 +4,6 @@ items:
- name: Concepts
expanded: true
items:
- - name: Passwordless strategy
- href: passwordless-strategy.md
- name: Why a PIN is better than a password
href: hello-why-pin-is-better-than-password.md
- name: Windows Hello biometrics in the enterprise
@@ -43,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
@@ -60,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
@@ -112,6 +110,8 @@ items:
items:
- name: PIN reset
href: hello-feature-pin-reset.md
+ - name: Windows Hello Enhanced Security Sign-in (ESS) 🔗
+ href: /windows-hardware/design/device-experiences/windows-hello-enhanced-sign-in-security
- name: Dual enrollment
href: hello-feature-dual-enrollment.md
- name: Dynamic Lock
diff --git a/windows/security/identity-protection/hello-for-business/webauthn-apis.md b/windows/security/identity-protection/hello-for-business/webauthn-apis.md
index 7646115753..1eb2da9944 100644
--- a/windows/security/identity-protection/hello-for-business/webauthn-apis.md
+++ b/windows/security/identity-protection/hello-for-business/webauthn-apis.md
@@ -2,7 +2,7 @@
title: WebAuthn APIs
description: Learn how to use WebAuthn APIs to enable passwordless authentication for your sites and apps.
ms.date: 07/27/2023
-ms.topic: article
+ms.topic: how-to
---
# WebAuthn APIs for passwordless authentication on Windows
diff --git a/windows/security/identity-protection/images/rdp-to-a-server-without-windows-defender-remote-credential-guard.png b/windows/security/identity-protection/images/rdp-to-a-server-without-windows-defender-remote-credential-guard.png
deleted file mode 100644
index f7767ac5f0..0000000000
Binary files a/windows/security/identity-protection/images/rdp-to-a-server-without-windows-defender-remote-credential-guard.png and /dev/null differ
diff --git a/windows/security/identity-protection/images/remote-credential-guard-gp.png b/windows/security/identity-protection/images/remote-credential-guard-gp.png
deleted file mode 100644
index f7db3ee411..0000000000
Binary files a/windows/security/identity-protection/images/remote-credential-guard-gp.png and /dev/null differ
diff --git a/windows/security/identity-protection/images/remote-credential-guard.gif b/windows/security/identity-protection/images/remote-credential-guard.gif
new file mode 100644
index 0000000000..effe8a4bc2
Binary files /dev/null and b/windows/security/identity-protection/images/remote-credential-guard.gif differ
diff --git a/windows/security/identity-protection/images/windows-defender-remote-credential-guard-with-remote-admin-mode.png b/windows/security/identity-protection/images/windows-defender-remote-credential-guard-with-remote-admin-mode.png
deleted file mode 100644
index 56021d820e..0000000000
Binary files a/windows/security/identity-protection/images/windows-defender-remote-credential-guard-with-remote-admin-mode.png and /dev/null differ
diff --git a/windows/security/identity-protection/passkeys/images/delete-passkey.png b/windows/security/identity-protection/passkeys/images/delete-passkey.png
new file mode 100644
index 0000000000..1363d8db62
Binary files /dev/null and b/windows/security/identity-protection/passkeys/images/delete-passkey.png differ
diff --git a/windows/security/identity-protection/passkeys/images/device-save-qr.png b/windows/security/identity-protection/passkeys/images/device-save-qr.png
new file mode 100644
index 0000000000..e551a1e528
Binary files /dev/null and b/windows/security/identity-protection/passkeys/images/device-save-qr.png differ
diff --git a/windows/security/identity-protection/passkeys/images/device-save.png b/windows/security/identity-protection/passkeys/images/device-save.png
new file mode 100644
index 0000000000..240b3a9695
Binary files /dev/null and b/windows/security/identity-protection/passkeys/images/device-save.png differ
diff --git a/windows/security/identity-protection/passkeys/images/device-use.png b/windows/security/identity-protection/passkeys/images/device-use.png
new file mode 100644
index 0000000000..5aa3daea3d
Binary files /dev/null and b/windows/security/identity-protection/passkeys/images/device-use.png differ
diff --git a/windows/security/identity-protection/passkeys/images/hello-save-confirm.png b/windows/security/identity-protection/passkeys/images/hello-save-confirm.png
new file mode 100644
index 0000000000..b9fdda9002
Binary files /dev/null and b/windows/security/identity-protection/passkeys/images/hello-save-confirm.png differ
diff --git a/windows/security/identity-protection/passkeys/images/hello-save.png b/windows/security/identity-protection/passkeys/images/hello-save.png
new file mode 100644
index 0000000000..785a45596b
Binary files /dev/null and b/windows/security/identity-protection/passkeys/images/hello-save.png differ
diff --git a/windows/security/identity-protection/passkeys/images/hello-use-confirm.png b/windows/security/identity-protection/passkeys/images/hello-use-confirm.png
new file mode 100644
index 0000000000..4139c708c3
Binary files /dev/null and b/windows/security/identity-protection/passkeys/images/hello-use-confirm.png differ
diff --git a/windows/security/identity-protection/passkeys/images/hello-use.png b/windows/security/identity-protection/passkeys/images/hello-use.png
new file mode 100644
index 0000000000..df46054877
Binary files /dev/null and b/windows/security/identity-protection/passkeys/images/hello-use.png differ
diff --git a/windows/security/identity-protection/passkeys/images/laptop.svg b/windows/security/identity-protection/passkeys/images/laptop.svg
new file mode 100644
index 0000000000..2440c97fd5
--- /dev/null
+++ b/windows/security/identity-protection/passkeys/images/laptop.svg
@@ -0,0 +1,3 @@
+
\ No newline at end of file
diff --git a/windows/security/identity-protection/passkeys/images/linked-device-connect.png b/windows/security/identity-protection/passkeys/images/linked-device-connect.png
new file mode 100644
index 0000000000..34cb085968
Binary files /dev/null and b/windows/security/identity-protection/passkeys/images/linked-device-connect.png differ
diff --git a/windows/security/identity-protection/passkeys/images/linked-device-save.png b/windows/security/identity-protection/passkeys/images/linked-device-save.png
new file mode 100644
index 0000000000..48bd40f658
Binary files /dev/null and b/windows/security/identity-protection/passkeys/images/linked-device-save.png differ
diff --git a/windows/security/identity-protection/passkeys/images/linked-device-use.png b/windows/security/identity-protection/passkeys/images/linked-device-use.png
new file mode 100644
index 0000000000..5aeacdae7a
Binary files /dev/null and b/windows/security/identity-protection/passkeys/images/linked-device-use.png differ
diff --git a/windows/security/identity-protection/passkeys/images/phone.svg b/windows/security/identity-protection/passkeys/images/phone.svg
new file mode 100644
index 0000000000..acb1dce81f
--- /dev/null
+++ b/windows/security/identity-protection/passkeys/images/phone.svg
@@ -0,0 +1,3 @@
+
\ No newline at end of file
diff --git a/windows/security/identity-protection/passkeys/images/qr-code.svg b/windows/security/identity-protection/passkeys/images/qr-code.svg
new file mode 100644
index 0000000000..d84c521351
--- /dev/null
+++ b/windows/security/identity-protection/passkeys/images/qr-code.svg
@@ -0,0 +1,3 @@
+
\ No newline at end of file
diff --git a/windows/security/identity-protection/passkeys/images/save-passkey.png b/windows/security/identity-protection/passkeys/images/save-passkey.png
new file mode 100644
index 0000000000..9dd3799a14
Binary files /dev/null and b/windows/security/identity-protection/passkeys/images/save-passkey.png differ
diff --git a/windows/security/identity-protection/passkeys/images/security-key-save.png b/windows/security/identity-protection/passkeys/images/security-key-save.png
new file mode 100644
index 0000000000..a17554e17c
Binary files /dev/null and b/windows/security/identity-protection/passkeys/images/security-key-save.png differ
diff --git a/windows/security/identity-protection/passkeys/images/security-key-setup.png b/windows/security/identity-protection/passkeys/images/security-key-setup.png
new file mode 100644
index 0000000000..192d63cc74
Binary files /dev/null and b/windows/security/identity-protection/passkeys/images/security-key-setup.png differ
diff --git a/windows/security/identity-protection/passkeys/images/security-key-use.png b/windows/security/identity-protection/passkeys/images/security-key-use.png
new file mode 100644
index 0000000000..1513aa359e
Binary files /dev/null and b/windows/security/identity-protection/passkeys/images/security-key-use.png differ
diff --git a/windows/security/identity-protection/passkeys/images/usb.svg b/windows/security/identity-protection/passkeys/images/usb.svg
new file mode 100644
index 0000000000..18027400c1
--- /dev/null
+++ b/windows/security/identity-protection/passkeys/images/usb.svg
@@ -0,0 +1,3 @@
+
\ No newline at end of file
diff --git a/windows/security/identity-protection/passkeys/images/use-passkey.png b/windows/security/identity-protection/passkeys/images/use-passkey.png
new file mode 100644
index 0000000000..1ff07346ea
Binary files /dev/null and b/windows/security/identity-protection/passkeys/images/use-passkey.png differ
diff --git a/windows/security/identity-protection/passkeys/images/website.png b/windows/security/identity-protection/passkeys/images/website.png
new file mode 100644
index 0000000000..d344d8dbde
Binary files /dev/null and b/windows/security/identity-protection/passkeys/images/website.png differ
diff --git a/windows/security/identity-protection/passkeys/index.md b/windows/security/identity-protection/passkeys/index.md
new file mode 100644
index 0000000000..40d33d3ed3
--- /dev/null
+++ b/windows/security/identity-protection/passkeys/index.md
@@ -0,0 +1,329 @@
+---
+title: Support for passkeys in Windows
+description: Learn about passkeys and how to use them on Windows devices.
+ms.collection:
+- highpri
+- tier1
+ms.topic: article
+ms.date: 09/27/2023
+appliesto:
+- ✅ Windows 11
+- ✅ Windows 10
+---
+
+# Support for passkeys in Windows
+
+Passkeys provide a more secure and convenient method to logging into websites and applications compared to passwords. Unlike passwords, which users must remember and type, passkeys are stored as secrets on a device and can use a device's unlock mechanism (such as biometrics or a PIN). Passkeys can be used without the need for other sign-in challenges, making the authentication process faster, secure, and more convenient.
+
+You can use passkeys with any applications or websites that support them, to create and sign in with Windows Hello. Once a passkey is created and stored with Windows Hello, you can use your device's biometrics or PIN to sign in. Alternatively, you can use a companion device (phone or tablet) to sign in.
+
+> [!NOTE]
+> Starting in Windows 11, version 22H2 with [KB5030310][KB-1], Windows provides a native experience for passkey management. However, passkeys can be used in all supported versions of Windows clients.
+
+This article describes how to create and use passkeys on Windows devices.
+
+## How passkeys work
+
+Microsoft has long been a founding member of the FIDO Alliance and has helped to define and use passkeys natively within a platform authenticator like Windows Hello. Passkeys utilize the FIDO industry security standard, which is adopted by all major platforms. Leading technology companies like Microsoft are backing passkeys as part of the FIDO Alliance, and numerous websites and apps are integrating support for passkeys.
+
+The FIDO protocols rely on standard public/private key cryptography techniques to offer more secure authentication. When a user registers with an online service, their client device generates a new key pair. The private key is stored securely on the user's device, while the public key is registered with the service. To authenticate, the client device must prove that it possesses the private key by signing a challenge. The private keys can only be used after they're unlocked by the user using the Windows Hello unlock factor (biometrics or PIN).
+
+FIDO protocols prioritize user privacy, as they're designed to prevent online services from sharing information or tracking users across different services. Additionally, any biometric information used in the authentication process remains on the user's device and isn't transmitted across the network or to the service.
+
+### Passkeys compared to passwords
+
+Passkeys have several advantages over passwords, including their ease of use and intuitive nature. Unlike passwords, passkeys are easy to create, don't need to be remembered, and don't need to be safeguarded. Additionally, passkeys are unique to each website or application, preventing their reuse. They're highly secure because they're only stored on the user's devices, with the service only storing public keys. Passkeys are designed to prevent attackers to guess or obtain them, which helps to make them resistant to phishing attempts where the attacker may try to trick the user into revealing the private key. Passkeys are enforced by the browsers or operating systems to only be used for the appropriate service, rather than relying on human verification. Finally, passkeys provide cross-device and cross-platform authentication, meaning that a passkey from one device can be used to sign in on another device.
+
+[!INCLUDE [passkey](../../../../includes/licensing/passkeys.md)]
+
+## User experiences
+
+### Create a passkey
+
+Follow these steps to create a passkey from a Windows device:
+
+:::row:::
+ :::column span="4":::
+
+ 1. Open a website or app that supports passkeys
+
+ :::column-end:::
+:::row-end:::
+:::row:::
+ :::column span="4":::
+
+ 2. Create a passkey from your account settings
+
+ :::column-end:::
+:::row-end:::
+:::row:::
+ :::column span="4":::
+ 3. Choose where to save the passkey. By default, Windows offers to save the passkey locally if you're using Windows Hello or Windows Hello for Business. If you select the option **Use another device**, you can choose to save the passkey in one of the following locations:
+ :::column-end:::
+:::row-end:::
+:::row:::
+ :::column span="3":::
+
+- **This Windows device**: the passkey is saved locally on your Windows device, and protected by Windows Hello (biometrics and PIN)
+- **iPhone, iPad or Android device**: the passkey is saved on a phone or tablet, protected by the device's biometrics, if offered by the device. This option requires you to scan a QR code with your phone or tablet, which must be in proximity of the Windows device
+- **Linked device**: the passkey is saved on a phone or tablet, protected by the device's biometrics, if offered by the device. This option requires the linked device to be in proximity of the Windows device, and it's only supported for Android devices
+- **Security key**: the passkey is saved to a FIDO2 security key, protected by the key's unlock mechanism (for example, biometrics or PIN)
+
+ :::column-end:::
+ :::column span="1":::
+ :::image type="content" source="images/save-passkey.png" alt-text="Screenshot showing a dialog box prompting the user to pick a location to store the passkey." lightbox="images/save-passkey.png" border="false":::
+ :::column-end:::
+:::row-end:::
+:::row:::
+ :::column span="4":::
+ 4. Select **Next**
+ :::column-end:::
+:::row-end:::
+
+Pick one of the following options to learn how to save a passkey, based on where you want to store it.
+
+#### [:::image type="icon" source="images/laptop.svg" border="false"::: **Windows device**](#tab/windows)
+
+:::row:::
+ :::column span="3":::
+
+ 5. Select a Windows Hello verification method and proceed with the verification, then select **OK**
+
+ :::column-end:::
+ :::column span="1":::
+ :::image type="content" source="images/hello-save.png" alt-text="Screenshot showing the Windows Hello face verification method." lightbox="images/hello-save.png" border="false":::
+ :::column-end:::
+:::row-end:::
+:::row:::
+ :::column span="3":::
+
+ 6. The passkey is saved to your Windows device. To confirm select **OK**
+
+ :::column-end:::
+ :::column span="1":::
+ :::image type="content" source="images/hello-save-confirm.png" alt-text="Screenshot confirming that the passkey is saved to the Windows device" lightbox="images/hello-save-confirm.png" border="false":::
+ :::column-end:::
+:::row-end:::
+
+#### [:::image type="icon" source="images/qr-code.svg" border="false"::: **New phone or tablet**](#tab/mobile)
+
+:::row:::
+ :::column span="3":::
+
+ 5. Scan the QR code with your phone or tablet. Wait for the connection to the device to be established and follow the instructions to save the passkey
+
+ :::column-end:::
+ :::column span="1":::
+ :::image type="content" source="images/device-save-qr.png" alt-text="Screenshot showing the QR code asking the user to scan on the device." lightbox="images/device-save-qr.png" border="false":::
+ :::column-end:::
+:::row-end:::
+:::row:::
+ :::column span="3":::
+
+ 6. Once the passkey is saved to your phone or tablet, select **OK**
+
+ :::column-end:::
+ :::column span="1":::
+ :::image type="content" source="images/device-save.png" alt-text="Screenshot confirming that the passkey is saved to the device." lightbox="images/device-save.png" border="false":::
+ :::column-end:::
+:::row-end:::
+
+#### [:::image type="icon" source="images/phone.svg" border="false"::: **Linked phone or tablet**](#tab/linked)
+
+:::row:::
+ :::column span="3":::
+
+ 5. Once the connection to the linked device is established, follow the instructions on the device to save the passkey
+
+ :::column-end:::
+ :::column span="1":::
+ :::image type="content" source="images/linked-device-connect.png" alt-text="Screenshot showing the passkey save dialog connecting to a linked device." lightbox="images/linked-device-connect.png" border="false":::
+ :::column-end:::
+:::row-end:::
+:::row:::
+ :::column span="3":::
+
+ 6. Once the passkey is saved to your linked device, select **OK**
+
+ :::column-end:::
+ :::column span="1":::
+ :::image type="content" source="images/linked-device-save.png" alt-text="Screenshot confirming that the passkey is saved to the linked device." lightbox="images/linked-device-save.png" border="false":::
+ :::column-end:::
+:::row-end:::
+
+#### [:::image type="icon" source="images/usb.svg" border="false"::: **Security key**](#tab/key)
+
+:::row:::
+ :::column span="3":::
+
+ 5. Select **OK** to confirm that you want to set up a security key, and unlock the security key using the key's unlock mechanism
+
+ :::column-end:::
+ :::column span="1":::
+ :::image type="content" source="images/security-key-setup.png" alt-text="Screenshot showing a prompt to use a security key to store the passkey." lightbox="images/security-key-setup.png" border="false":::
+ :::column-end:::
+:::row-end:::
+:::row:::
+ :::column span="3":::
+
+ 6. Once the passkey is saved to the security key, select **OK**
+
+ :::column-end:::
+ :::column span="1":::
+ :::image type="content" source="images/security-key-save.png" alt-text="Screenshot confirming that the passkey is saved to the security key." lightbox="images/security-key-save.png" border="false":::
+ :::column-end:::
+:::row-end:::
+
+---
+
+### Use a passkey
+
+Follow these steps to use a passkey:
+
+:::row:::
+ :::column span="3":::
+ 1. Open a website or app that supports passkeys
+ :::column-end:::
+ :::column span="1":::
+ :::column-end:::
+:::row-end:::
+:::row:::
+ :::column span="3":::
+ 2. Select **Sign in with a passkey**, or a similar option
+ :::column-end:::
+ :::column span="1":::
+ :::image type="content" source="images/website.png" alt-text="Screenshot of a website offering the passkey sign in option." lightbox="images/website.png" border="false":::
+ :::column-end:::
+:::row-end:::
+:::row:::
+ :::column span="3":::
+ 3. If a passkey is stored locally and protected by Windows Hello, you're prompted to use Windows Hello to sign in. If you select the option **Use another device**, you can choose one of the following options:
+ :::column-end:::
+:::row-end:::
+:::row:::
+ :::column span="3":::
+- **This Windows device**: use this option to use a passkey that is stored locally on your Windows device, and protected by Windows Hello
+- **iPhone, iPad or Android device**: use this option if you want to sign in with a passkey stored on a phone or tablet. This option requires you to scan a QR code with your phone or tablet, which must be in proximity of the Windows device
+- **Linked device**: use this option if you want to sign in with a passkey stored on a device that is in proximity of the Windows device. This option is only supported for Android devices
+- **Security key**: use this option if you want to sign in with a passkey stored on a FIDO2 security key
+ :::column-end:::
+ :::column span="1":::
+ :::image type="content" source="images/use-passkey.png" alt-text="Screenshot of the passkey dialog prompting the user to pick where the passkey is stored." lightbox="images/use-passkey.png" border="false":::
+ :::column-end:::
+:::row-end:::
+
+Pick one of the following options to learn how to use a passkey, based on where you saved it.
+
+#### [:::image type="icon" source="images/laptop.svg" border="false"::: **Windows device**](#tab/windows)
+
+:::row:::
+ :::column span="3":::
+
+ 4. Select a Windows Hello unlock option
+
+ :::column-end:::
+ :::column span="1":::
+ :::image type="content" source="images/hello-use.png" alt-text="Screenshot showing the Windows Hello prompt for a verification method." lightbox="images/hello-use.png" border="false":::
+ :::column-end:::
+:::row-end:::
+:::row:::
+ :::column span="3":::
+
+ 5. Select **OK** to continue signing in
+
+ :::column-end:::
+ :::column span="1":::
+ :::column-end:::
+:::row-end:::
+
+#### [:::image type="icon" source="images/qr-code.svg" border="false"::: **Phone or tablet**](#tab/mobile)
+
+:::row:::
+ :::column span="3":::
+
+ 4. Scan the QR code with your phone or tablet where you saved the passkey. Once the connection to the device is established, follow the instructions to use the passkey
+
+ :::column-end:::
+ :::column span="1":::
+ :::image type="content" source="images/device-use.png" alt-text="Screenshot showing the QR code to scan from your phone or tablet." lightbox="images/device-use.png" border="false":::
+ :::column-end:::
+:::row-end:::
+:::row:::
+ :::column span="4":::
+
+ 5. You're signed in to the website or app
+
+ :::column-end:::
+:::row-end:::
+
+#### [:::image type="icon" source="images/phone.svg" border="false"::: **Linked phone or tablet**](#tab/linked)
+
+:::row:::
+ :::column span="3":::
+
+ 4. Once the connection to the linked device is established, follow the instructions on the device to use the passkey
+
+ :::column-end:::
+ :::column span="1":::
+ :::image type="content" source="images/linked-device-use.png" alt-text="Screenshot showing that the linked device is connected to Windows." lightbox="images/linked-device-use.png" border="false":::
+ :::column-end:::
+:::row-end:::
+:::row:::
+ :::column span="3":::
+
+ 5. You're signed in to the website or app
+
+ :::column-end:::
+ :::column span="1":::
+ :::column-end:::
+:::row-end:::
+
+#### [:::image type="icon" source="images/usb.svg" border="false"::: **Security key**](#tab/key)
+
+:::row:::
+ :::column span="3":::
+
+ 4. Unlock the security key using the key's unlock mechanism
+
+ :::column-end:::
+ :::column span="1":::
+ :::image type="content" source="images/security-key-use.png" alt-text="Screenshot showing a prompt asking the user to unlock the security key." lightbox="images/security-key-use.png" border="false":::
+ :::column-end:::
+:::row-end:::
+:::row:::
+ :::column span="3":::
+
+ 5. You're signed in to the website or app
+
+ :::column-end:::
+ :::column span="1":::
+ :::column-end:::
+:::row-end:::
+
+---
+
+### Manage passkeys
+
+Starting in Windows 11, version 22H2 with [KB5030310][KB-1], you can use the Settings app to view and manage passkeys saved for apps or websites. Go to **Settings > Accounts > Passkeys**, or use the following shortcut:
+
+> [!div class="nextstepaction"]
+>
+> [Manage passkeys][MSS-1]
+
+- A list of saved passkeys is displayed and you can filter them by name
+- To delete a passkey, select **... > Delete passkey** next to the passkey name
+
+:::image type="content" source="images/delete-passkey.png" alt-text="Screenshot of the Settings app showing the delete option for a passkey." lightbox="images/delete-passkey.png" border="false":::
+
+> [!NOTE]
+> Some passkeys for *login.microsoft.com* can't be deleted, as they're used with Microsoft Entra ID and/or Microsoft Account for signing in to the device and Microsoft services.
+
+## :::image type="icon" source="../../images/icons/feedback.svg" border="false"::: Provide feedback
+
+To provide feedback for passkeys, open [**Feedback Hub**][FHUB] and use the category **Security and Privacy > Passkey**.
+
+
+
+[FHUB]: feedback-hub:?tabid=2&newFeedback=true
+[KB-1]: https://support.microsoft.com/kb/5030310
+[MSS-1]: ms-settings:savedpasskeys
diff --git a/windows/security/identity-protection/passwordless-experience/images/edge-on.png b/windows/security/identity-protection/passwordless-experience/images/edge-on.png
new file mode 100644
index 0000000000..06a13b6f1a
Binary files /dev/null and b/windows/security/identity-protection/passwordless-experience/images/edge-on.png differ
diff --git a/windows/security/identity-protection/passwordless-experience/images/key-credential-provider.svg b/windows/security/identity-protection/passwordless-experience/images/key-credential-provider.svg
new file mode 100644
index 0000000000..dd8c09b2dd
--- /dev/null
+++ b/windows/security/identity-protection/passwordless-experience/images/key-credential-provider.svg
@@ -0,0 +1,11 @@
+
diff --git a/windows/security/identity-protection/passwordless-experience/images/lock-screen-off.png b/windows/security/identity-protection/passwordless-experience/images/lock-screen-off.png
new file mode 100644
index 0000000000..ccfade47d9
Binary files /dev/null and b/windows/security/identity-protection/passwordless-experience/images/lock-screen-off.png differ
diff --git a/windows/security/identity-protection/passwordless-experience/images/lock-screen-on.png b/windows/security/identity-protection/passwordless-experience/images/lock-screen-on.png
new file mode 100644
index 0000000000..abb9b6456d
Binary files /dev/null and b/windows/security/identity-protection/passwordless-experience/images/lock-screen-on.png differ
diff --git a/windows/security/identity-protection/passwordless-experience/images/uac-off.png b/windows/security/identity-protection/passwordless-experience/images/uac-off.png
new file mode 100644
index 0000000000..8913baa8ce
Binary files /dev/null and b/windows/security/identity-protection/passwordless-experience/images/uac-off.png differ
diff --git a/windows/security/identity-protection/passwordless-experience/images/uac-on.png b/windows/security/identity-protection/passwordless-experience/images/uac-on.png
new file mode 100644
index 0000000000..b0d03a6299
Binary files /dev/null and b/windows/security/identity-protection/passwordless-experience/images/uac-on.png differ
diff --git a/windows/security/identity-protection/passwordless-experience/index.md b/windows/security/identity-protection/passwordless-experience/index.md
new file mode 100644
index 0000000000..7ea73c4603
--- /dev/null
+++ b/windows/security/identity-protection/passwordless-experience/index.md
@@ -0,0 +1,143 @@
+---
+title: Windows passwordless experience
+description: Learn how Windows passwordless experience enables your organization to move away from passwords.
+ms.collection:
+ - highpri
+ - tier1
+ms.date: 09/27/2023
+ms.topic: how-to
+appliesto:
+ - ✅ Windows 11
+---
+
+# Windows passwordless experience
+
+Starting in Windows 11, version 22H2 with [KB5030310][KB-1], *Windows passwordless experience* is a security policy that promotes a user experience without passwords on Microsoft Entra joined devices.\
+When the policy is enabled, certain Windows authentication scenarios don't offer users the option to use a password, helping organizations and preparing users to gradually move away from passwords.
+
+With Windows passwordless experience, users who sign in with Windows Hello or a FIDO2 security key:
+
+- Can't use the password credential provider on the Windows lock screen
+- Aren't prompted to use a password during in-session authentications (for example, UAC elevation, password manager in the browser, etc.)
+- Don't have the option *Accounts > Change password* in the Settings app
+
+ >[!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 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.
+
+>[!TIP]
+> Windows Hello for Business users can achieve passwordless sign-in from the first sign-in using the Web sign-in feature. For more information about Web sign-in, see [Web sign-in for Windows devices](../web-sign-in/index.md).
+
+## System requirements
+
+Windows passwordless experience has the following requirements:
+
+- Windows 11, version 22H2 with [KB5030310][KB-1] or later
+- Microsoft Entra joined
+- Windows Hello for Business credentials enrolled for the user, or a FIDO2 security key
+- MDM-managed: Microsoft Intune or other MDM solution
+
+>[!NOTE]
+>Microsoft Entra hybrid joined devices and Active Directory domain joined devices are currently out of scope.
+
+[!INCLUDE [windows-passwordless-experience](../../../../includes/licensing/windows-passwordless-experience.md)]
+
+## Enable Windows passwordless experience with Intune
+
+[!INCLUDE [intune-settings-catalog-1](../../../../includes/configure/intune-settings-catalog-1.md)]
+
+| Category | Setting name | Value |
+|--|--|--|
+| **Authentication** | Enable Passwordless Experience | Enabled |
+
+[!INCLUDE [intune-settings-catalog-2](../../../../includes/configure/intune-settings-catalog-2.md)]
+
+Alternatively, you can configure devices using a [custom policy][INT-2] with the [Policy CSP][CSP-1].
+
+| Setting |
+|--------|
+| - **OMA-URI:** `./Device/Vendor/MSFT/Policy/Config/Authentication/EnablePasswordlessExperience`
- **Data type:** int
- **Value:** `1`|
+
+## User experiences
+
+### Lock screen experience
+
+:::row:::
+ :::column span="3":::
+ **Passwordless experience turned off**: users can sign in using a password, as indicated by the presence of the password credential provider :::image type="icon" source="images/key-credential-provider.svg" border="false"::: in the Windows lock screen.
+ :::column-end:::
+ :::column span="1":::
+ :::image type="content" source="images/lock-screen-off.png" lightbox="images/lock-screen-off.png" alt-text="Screenshot of the Windows lock screen showing the fingerprint, PIN and password credential providers.":::
+ :::column-end:::
+:::row-end:::
+:::row:::
+ :::column span="3":::
+ **Passwordless experience turned on**: the password credential provider :::image type="icon" source="images/key-credential-provider.svg" border="false"::: is missing for the last user who signed in with strong credentials. A user can either sign in using a strong credential or opt to use the *Other user* option to sign in with a password.
+ :::column-end:::
+ :::column span="1":::
+ :::image type="content" source="images/lock-screen-on.png" lightbox="images/lock-screen-on.png" alt-text="Screenshot of the Windows lock screen showing the fingerprint and PIN credential providers only. The password credential provider is missing.":::
+ :::column-end:::
+:::row-end:::
+
+### In-session authentication experiences
+
+When Windows passwordless experience is enabled, users can't use the password credential provider for in-session authentication scenarios. In-session authentication scenarios include:
+
+- Password Manager in a web browser
+- Connecting to file shares or intranet sites
+- User Account Control (UAC) elevation, except if a local user account is used for elevation
+
+>[!NOTE]
+> RDP sign in defaults to the credential provider used during sign-in. However, a user can select the option *Use a different account* to sign in with a password.
+>
+> *Run as different user* is not impacted by Windows passwordless experience.
+
+Example of UAC elevation experience:
+
+:::row:::
+ :::column span="3":::
+ **Passwordless experience turned off**: UAC elevation allows the user to authenticate using a password.
+ :::column-end:::
+ :::column span="1":::
+ :::image type="content" source="images/uac-off.png" lightbox="images/uac-off.png" alt-text="Screenshot of the UAC prompt showing username and password fields.":::
+ :::column-end:::
+:::row-end:::
+:::row:::
+ :::column span="3":::
+ **Passwordless experience turned on**: UAC elevation doesn't allow the user to use the password credential provider for the currently logged on user. The user can authenticate using Windows Hello, a FIDO2 security key or a local user account, if available.
+ :::column-end:::
+ :::column span="1":::
+ :::image type="content" source="images/uac-on.png" lightbox="images/uac-on.png" alt-text="Screenshot of the UAC prompt showing fingerprint and PIN options only.":::
+ :::column-end:::
+:::row-end:::
+
+## Recommendations
+
+Here's a list of recommendations to consider before enabling Windows passwordless experience:
+
+- 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 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]
+
+## Known issues
+
+There's a known issue affecting the in-session authentication experience when using FIDO2 security keys, where security keys aren't always an available option. The product group is aware of this behavior and plans to improve this in the future.
+
+### :::image type="icon" source="../../images/icons/feedback.svg" border="false"::: Provide feedback
+
+To provide feedback for Windows passwordless experience, open [**Feedback Hub**][FHUB] and use the category **Security and Privacy > Passwordless experience**.
+
+
+
+[CSP-1]: /windows/client-management/mdm/policy-csp-authentication#enablepasswordlessexperience
+[FHUB]: feedback-hub://?tabid=2&newFeedback=true&feedbackType=1
+[INT-2]: /mem/intune/configuration/custom-settings-windows-10
+[KB-1]: https://support.microsoft.com/kb/5030310
+[SERV-1]: /windows-server/identity/laps/laps-overview
diff --git a/windows/security/identity-protection/remote-credential-guard.md b/windows/security/identity-protection/remote-credential-guard.md
index 41748c9408..5c99653fe4 100644
--- a/windows/security/identity-protection/remote-credential-guard.md
+++ b/windows/security/identity-protection/remote-credential-guard.md
@@ -1,11 +1,11 @@
---
-title: Protect Remote Desktop credentials with Windows Defender Remote Credential Guard
-description: Windows Defender Remote Credential Guard helps to secure your Remote Desktop credentials by never sending them to the target device.
+title: Remote Credential Guard
+description: Learn how Remote Credential Guard helps to secure Remote Desktop credentials by never sending them to the target device.
ms.collection:
- highpri
-- tier2
-ms.topic: article
-ms.date: 01/12/2018
+- tier1
+ms.topic: how-to
+ms.date: 09/06/2023
appliesto:
- ✅ Windows 11
- ✅ Windows 10
@@ -13,96 +13,112 @@ appliesto:
- ✅ Windows Server 2019
- ✅ Windows Server 2016
---
-# Protect Remote Desktop credentials with Windows Defender Remote Credential Guard
-Introduced in Windows 10, version 1607, Windows Defender Remote Credential Guard helps you protect your credentials over a Remote Desktop connection by redirecting Kerberos requests back to the device that's requesting the connection. It also provides single sign-on experiences for Remote Desktop sessions.
+# Remote Credential Guard
-Administrator credentials are highly privileged and must be protected. By using Windows Defender Remote Credential Guard to connect during Remote Desktop sessions, if the target device is compromised, your credentials are not exposed because both credential and credential derivatives are never passed over the network to the target device.
+## Overview
+
+Remote Credential Guard helps protecting credentials over a Remote Desktop (RDP) connection by redirecting Kerberos requests back to the device that's requesting the connection. If the target device is compromised, the credentials aren't exposed because both credential and credential derivatives are never passed over the network to the target device. Remote Credential Guard also provides single sign-on experiences for Remote Desktop sessions.
+
+This article describes how to configure and use Remote Credential Guard.
> [!IMPORTANT]
> For information on Remote Desktop connection scenarios involving helpdesk support, see [Remote Desktop connections and helpdesk support scenarios](#remote-desktop-connections-and-helpdesk-support-scenarios) in this article.
-## Comparing Windows Defender Remote Credential Guard with other Remote Desktop connection options
+## Compare Remote Credential Guard with other connection options
-The following diagram helps you to understand how a standard Remote Desktop session to a server without Windows Defender Remote Credential Guard works:
+Using a Remote Desktop session without Remote Credential Guard has the following security implications:
-
+- Credentials are sent to and stored on the remote host
+- Credentials aren't protected from attackers on the remote host
+- Attacker can use credentials after disconnection
-The following diagram helps you to understand how Windows Defender Remote Credential Guard works, what it helps to protect against, and compares it with the [Restricted Admin mode](https://social.technet.microsoft.com/wiki/contents/articles/32905.how-to-enable-restricted-admin-mode-for-remote-desktop.aspx) option:
+The security benefits of Remote Credential Guard include:
-
+- Credentials aren't sent to the remote host
+- During the remote session you can connect to other systems using SSO
+- An attacker can act on behalf of the user only when the session is ongoing
-As illustrated, Windows Defender Remote Credential Guard blocks NTLM (allowing only Kerberos), prevents Pass-the-Hash (PtH) attacks, and also prevents use of credentials after disconnection.
+The security benefits of [Restricted Admin mode][TECH-1] include:
+
+- Credentials aren't sent to the remote host
+- The Remote Desktop session connects to other resources as the remote host's identity
+- An attacker can't act on behalf of the user and any attack is local to the server
Use the following table to compare different Remote Desktop connection security options:
-| Feature | Remote Desktop | Windows Defender Remote Credential Guard | Restricted Admin mode |
+| Feature | Remote Desktop | Remote Credential Guard | Restricted Admin mode |
|--|--|--|--|
-| **Protection benefits** | Credentials on the server are not protected from Pass-the-Hash attacks. | User credentials remain on the client. An attacker can act on behalf of the user *only* when the session is ongoing | User logs on to the server as local administrator, so an attacker cannot act on behalf of the "domain user". Any attack is local to the server |
-| **Version support** | The remote computer can run any Windows operating system | Both the client and the remote computer must be running **at least Windows 10, version 1607, or Windows Server 2016**. | The remote computer must be running **at least patched Windows 7 or patched Windows Server 2008 R2**.
For more information about patches (software updates) related to Restricted Admin mode, see [Microsoft Security Advisory 2871997](/security-updates/SecurityAdvisories/2016/2871997). |
-| **Helps prevent** | N/A |
|
|
-| **Credentials supported from the remote desktop client device** |
|
|
-| **Access** | **Users allowed**, that is, members of Remote Desktop Users group of remote host. | **Users allowed**, that is, members of Remote Desktop Users of remote host. | **Administrators only**, that is, only members of Administrators group of remote host. |
-| **Network identity** | Remote Desktop session **connects to other resources as signed-in user**. | Remote Desktop session **connects to other resources as signed-in user**. | Remote Desktop session **connects to other resources as remote host's identity**. |
-| **Multi-hop** | From the remote desktop, **you can connect through Remote Desktop to another computer** | From the remote desktop, you **can connect through Remote Desktop to another computer**. | Not allowed for user as the session is running as a local host account |
-| **Supported authentication** | Any negotiable protocol. | Kerberos only. | Any negotiable protocol |
-
-For further technical information, see [Remote Desktop Protocol](/windows/win32/termserv/remote-desktop-protocol)
-and [How Kerberos works](/previous-versions/windows/it-pro/windows-2000-server/cc961963(v=technet.10)).
-
-## Remote Desktop connections and helpdesk support scenarios
-
-For helpdesk support scenarios in which personnel require administrative access to provide remote assistance to computer users via Remote Desktop sessions, Microsoft recommends that Windows Defender Remote Credential Guard should not be used in that context. This is because if an RDP session is initiated to a compromised client that an attacker already controls, the attacker could use that open channel to create sessions on the user's behalf (without compromising credentials) to access any of the user's resources for a limited time (a few hours) after the session disconnects.
-
-Therefore, we recommend instead that you use the Restricted Admin mode option. For helpdesk support scenarios, RDP connections should only be initiated using the /RestrictedAdmin switch. This helps ensure that credentials and other user resources are not exposed to compromised remote hosts. For more information, see [Mitigating Pass-the-Hash and Other Credential Theft v2](https://download.microsoft.com/download/7/7/A/77ABC5BD-8320-41AF-863C-6ECFB10CB4B9/Mitigating-Pass-the-Hash-Attacks-and-Other-Credential-Theft-Version-2.pdf).
-
-To further harden security, we also recommend that you implement Local Administrator Password Solution (LAPS), a Group Policy client-side extension (CSE) introduced in Windows 8.1 that automates local administrator password management. LAPS mitigates the risk of lateral escalation and other cyberattacks facilitated when customers use the same administrative local account and password combination on all their computers. You can download and install LAPS [here](https://www.microsoft.com/download/details.aspx?id=46899).
-
-For further information on LAPS, see [Microsoft Security Advisory 3062591](https://technet.microsoft.com/library/security/3062591.aspx).
-
-[!INCLUDE [windows-defender-remote-credential-guard](../../../includes/licensing/windows-defender-remote-credential-guard.md)]
+| Single sign-on (SSO) to other systems as signed in user | ✅ | ✅ | ❌ |
+| Multi-hop RDP | ✅ | ✅ | ❌ |
+| Prevent use of user's identity during connection | ❌ | ❌ | ✅ |
+| Prevent use of credentials after disconnection | ❌ | ✅ | ✅ |
+| Prevent Pass-the-Hash (PtH) | ❌ | ✅ | ✅ |
+| Supported authentication | Any negotiable protocol | Kerberos only | Any negotiable protocol |
+| Credentials supported from the remote desktop client device | - Signed on credentials
- Supplied credentials
- Saved credentials | - Signed on credentials
- Supplied credentials
| - Signed on credentials
- Supplied credentials
- Saved credentials |
+| RDP access granted with | Membership of **Remote Desktop Users** group on remote host | Membership of **Remote Desktop Users** group on remote host | Membership of **Administrators** group on remote host |
## Remote Credential Guard requirements
-To use Windows Defender Remote Credential Guard, the Remote Desktop client and remote host must meet the following requirements:
+To use Remote Credential Guard, the remote host and the client must meet the following requirements.
-The Remote Desktop client device:
+The remote host:
-- Must be running at least Windows 10, version 1703 to be able to supply credentials, which is sent to the remote device. This allows users to run as different users without having to send credentials to the remote machine
-- Must be running at least Windows 10, version 1607 or Windows Server 2016 to use the user's signed-in credentials. This requires the user's account be able to sign in to both the client device and the remote host
-- Must be running the Remote Desktop Classic Windows application. The Remote Desktop Universal Windows Platform application doesn't support Windows Defender Remote Credential Guard
-- Must use Kerberos authentication to connect to the remote host. If the client cannot connect to a domain controller, then RDP attempts to fall back to NTLM. Windows Defender Remote Credential Guard does not allow NTLM fallback because this would expose credentials to risk
+- Must allow the user to access via Remote Desktop connections
+- Must allow delegation of nonexportable credentials to the client device
-The Remote Desktop remote host:
+The client device:
-- Must be running at least Windows 10, version 1607 or Windows Server 2016.
-- Must allow Restricted Admin connections.
-- Must allow the client's domain user to access Remote Desktop connections.
-- Must allow delegation of non-exportable credentials.
+- Must be running the Remote Desktop Windows application. The Remote Desktop Universal Windows Platform (UWP) application doesn't support Remote Credential Guard
+- Must use Kerberos authentication to connect to the remote host. If the client can't connect to a domain controller, then RDP attempts to fall back to NTLM. Remote Credential Guard does not allow NTLM fallback because this would expose credentials to risk
-There are no hardware requirements for Windows Defender Remote Credential Guard.
+[!INCLUDE [remote-credential-guard](../../../includes/licensing/remote-credential-guard.md)]
-> [!NOTE]
-> Remote Desktop client devices running earlier versions, at minimum Windows 10 version 1607, only support signed-in credentials, so the client device must also be joined to an Active Directory domain. Both Remote Desktop client and server must either be joined to the same domain, or the Remote Desktop server can be joined to a domain that has a trust relationship to the client device's domain.
->
-> GPO [Remote host allows delegation of non-exportable credentials](/windows/client-management/mdm/policy-csp-credentialsdelegation) should be enabled for delegation of non-exportable credentials.
+## Enable delegation of nonexportable credentials on the remote hosts
-- For Windows Defender Remote Credential Guard to be supported, the user must authenticate to the remote host using Kerberos authentication.
-- The remote host must be running at least Windows 10 version 1607, or Windows Server 2016.
-- The Remote Desktop classic Windows app is required. The Remote Desktop Universal Windows Platform app doesn't support Windows Defender Remote Credential Guard.
+This policy is required on the remote hosts to support Remote Credential Guard and Restricted Admin mode. It allows the remote host to delegate nonexportable credentials to the client device.\
+If you disable or don't configure this setting, Restricted Admin and Remote Credential Guard mode aren't supported. User will always need to pass their credentials to the host, exposing users to the risk of credential theft from attackers on the remote host.
-## Enable Windows Defender Remote Credential Guard
+To enable delegation of nonexportable credentials on the remote hosts, you can use:
-You must enable Restricted Admin or Windows Defender Remote Credential Guard on the remote host by using the Registry.
+- Microsoft Intune/MDM
+- Group policy
+- Registry
-1. Open Registry Editor on the remote host
-1. Enable Restricted Admin and Windows Defender Remote Credential Guard:
+[!INCLUDE [tab-intro](../../../includes/configure/tab-intro.md)]
- - Go to `HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa`
- - Add a new DWORD value named **DisableRestrictedAdmin**
- - To turn on Restricted Admin and Windows Defender Remote Credential Guard, set the value of this registry setting to 0
+#### [:::image type="icon" source="../images/icons/intune.svg" border="false"::: **Intune/MDM**](#tab/intune)
-1. Close Registry Editor
+[!INCLUDE [intune-settings-catalog-1](../../../includes/configure/intune-settings-catalog-1.md)]
+
+| Category | Setting name | Value |
+|--|--|--|
+| **Administrative Templates > System > Credentials Delegation** | Remote host allows delegation of nonexportable credentials | Enabled |
+
+[!INCLUDE [intune-settings-catalog-2](../../../includes/configure/intune-settings-catalog-2.md)]
+
+Alternatively, you can configure devices using a [custom policy][INT-3] with the [Policy CSP][CSP-1].
+
+| Setting |
+|--------|
+| - **OMA-URI:** `./Device/Vendor/MSFT/Policy/Config/CredentialsDelegation/RemoteHostAllowsDelegationOfNonExportableCredentials`
- **Data type:** string
- **Value:** `
- **Key name:** `DisableRestrictedAdmin`
- **Type:** `REG_DWORD`
- **Value:** `0`|
You can add this by running the following command from an elevated command prompt:
@@ -110,44 +126,103 @@ You can add this by running the following command from an elevated command promp
reg.exe add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v DisableRestrictedAdmin /d 0 /t REG_DWORD
```
-## Using Windows Defender Remote Credential Guard
+---
-Beginning with Windows 10 version 1703, you can enable Windows Defender Remote Credential Guard on the client device either by using Group Policy or by using a parameter with the Remote Desktop Connection.
+## Configure delegation of credentials on the clients
-### Turn on Windows Defender Remote Credential Guard by using Group Policy
+To enable Remote Credential Guard on the clients, you can configure a policy that prevents the delegation of credentials to the remote hosts.
-1. From the Group Policy Management Console, go to **Computer Configuration** -> **Administrative Templates** -> **System** -> **Credentials Delegation**
-1. Double-click **Restrict delegation of credentials to remote servers**
- 
-1. Under **Use the following restricted mode**:
- - If you want to require either [Restricted Admin mode](https://social.technet.microsoft.com/wiki/contents/articles/32905.remote-desktop-services-enable-restricted-admin-mode.aspx) or Windows Defender Remote Credential Guard, choose **Restrict Credential Delegation**. In this configuration, Windows Defender Remote Credential Guard is preferred, but it will use Restricted Admin mode (if supported) when Windows Defender Remote Credential Guard cannot be used
+> [!TIP]
+> If you don't want to configure your clients to enforce Remote Credential Guard, you can use the following command to use Remote Credential Guard for a specific RDP session:
+> ```cmd
+> mstsc.exe /remoteGuard
+> ```
- > [!NOTE]
- > Neither Windows Defender Remote Credential Guard nor Restricted Admin mode will send credentials in clear text to the Remote Desktop server.
- > When **Restrict Credential Delegation** is enabled, the /restrictedAdmin switch will be ignored. Windows will enforce the policy configuration instead and will use Windows Defender Remote Credential Guard.
+The policy can have different values, depending on the level of security you want to enforce:
- - If you want to require Windows Defender Remote Credential Guard, choose **Require Remote Credential Guard**. With this setting, a Remote Desktop connection will succeed only if the remote computer meets the [requirements](#remote-credential-guard-requirements) listed earlier in this topic.
- - If you want to require Restricted Admin mode, choose **Require Restricted Admin**. For information about Restricted Admin mode, see the table in [Comparing Windows Defender Remote Credential Guard with other Remote Desktop connection options](#comparing-windows-defender-remote-credential-guard-with-other-remote-desktop-connection-options), earlier in this topic.
-
-1. Click **OK**
-1. Close the Group Policy Management Console
-1. From a command prompt, run **gpupdate.exe /force** to ensure that the Group Policy object is applied
-
-### Use Windows Defender Remote Credential Guard with a parameter to Remote Desktop Connection
-
-If you don't use Group Policy in your organization, or if not all your remote hosts support Remote Credential Guard, you can add the remoteGuard parameter when you start Remote Desktop Connection to turn on Windows Defender Remote Credential Guard for that connection.
-
-```cmd
-mstsc.exe /remoteGuard
-```
+- **Disabled**: *Restricted Admin* and *Remote Credential Guard* mode aren't enforced and the Remote Desktop Client can delegate credentials to remote devices
+- **Require Restricted Admin**: the Remote Desktop Client must use Restricted Admin to connect to remote hosts
+- **Require Remote Credential Guard**: Remote Desktop Client must use Remote Credential Guard to connect to remote hosts
+- **Restrict credential delegation**: Remote Desktop Client must use Restricted Admin or Remote Credential Guard to connect to remote hosts. In this configuration, Remote Credential Guard is preferred, but it uses Restricted Admin mode (if supported) when Remote Credential Guard can't be used
> [!NOTE]
-> The user must be authorized to connect to the remote server using Remote Desktop Protocol, for example by being a member of the Remote Desktop Users local group on the remote computer.
+> When *Restrict Credential Delegation* is enabled, the `/restrictedAdmin` switch will be ignored. Windows enforces the policy configuration instead and uses Remote Credential Guard.
-## Considerations when using Windows Defender Remote Credential Guard
+To configure your clients, you can use:
-- Windows Defender Remote Credential Guard does not 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
-- Windows Defender Remote Credential Guard can be used only when connecting to a device that is joined to a Windows Server Active Directory domain, including AD domain-joined servers that run as Azure virtual machines (VMs). Windows Defender Remote Credential Guard cannot be used when connecting to remote devices joined to Azure Active Directory
-- Remote Desktop Credential Guard only works with the RDP protocol
+- Microsoft Intune/MDM
+- Group policy
+
+[!INCLUDE [tab-intro](../../../includes/configure/tab-intro.md)]
+
+#### [:::image type="icon" source="../images/icons/intune.svg" border="false"::: **Intune/MDM**](#tab/intune)
+
+[!INCLUDE [intune-settings-catalog-1](../../../includes/configure/intune-settings-catalog-1.md)]
+
+| Category | Setting name | Value |
+|--|--|--|
+| **Administrative Templates > System > Credentials Delegation** | Restrict delegation of credentials to remote servers | Select **Enabled** and in the dropdown, select one of the options:
- **Restrict Credential Delegation**
- **Require Remote Credential Guard**|
+
+[!INCLUDE [intune-settings-catalog-2](../../../includes/configure/intune-settings-catalog-2.md)]
+
+Alternatively, you can configure devices using a [custom policy][INT-3] with the [Policy CSP][CSP-2].
+
+| Setting |
+|--|
+|- **OMA-URI:** `./Device/Vendor/MSFT/Policy/Config/ADMX_CredSsp/RestrictedRemoteAdministration`
- **Data type:** string
- **Value:** `
Possible values for `RestrictedRemoteAdministrationDrop` are:
- `0`: Disabled
- `1`: Require Restricted Admin
- `2`: Require Remote Credential Guard
- `3`: Restrict credential delegation |
+
+#### [:::image type="icon" source="../images/icons/group-policy.svg" border="false"::: **Group policy**](#tab/gpo)
+
+[!INCLUDE [gpo-settings-1](../../../includes/configure/gpo-settings-1.md)]
+
+| Group policy path | Group policy setting | Value |
+| - | - | - |
+| **Computer Configuration\Administrative Templates\System\Credentials Delegation** | Restrict delegation of credentials to remote servers| **Enabled** and in the dropdown, select one of the options:
- **Restrict Credential Delegation**
- **Require Remote Credential Guard**|
+
+[!INCLUDE [gpo-settings-2](../../../includes/configure/gpo-settings-2.md)]
+
+#### [:::image type="icon" source="../images/icons/windows-os.svg" border="false"::: **Registry**](#tab/reg)
+
+Not documented.
+
+---
+
+## Use Remote Credential Guard
+
+Once a client receives the policy, you can connect to the remote host using Remote Credential Guard by opening the Remote Desktop Client (`mstsc.exe`). The user is automatically authenticated to the remote host:
+
+:::image type="content" source="images/remote-credential-guard.gif" alt-text="Animation showing a client connecting to a remote server using Remote Credential Guard with SSO.":::
+
+> [!NOTE]
+> The user must be authorized to connect to the remote server using the Remote Desktop protocol, for example by being a member of the Remote Desktop Users local group on the remote host.
+
+## Remote Desktop connections and helpdesk support scenarios
+
+For helpdesk support scenarios in which personnel require administrative access via Remote Desktop sessions, it isn't recommended the use of Remote Credential Guard. If an RDP session is initiated to an already compromised client, the attacker could use that open channel to create sessions on the user's behalf. The attacker can access any of the user's resources for a limited time after the session disconnects.
+
+We recommend using Restricted Admin mode option instead. For helpdesk support scenarios, RDP connections should only be initiated using the `/RestrictedAdmin` switch. This helps to ensure that credentials and other user resources aren't exposed to compromised remote hosts. For more information, see [Mitigating Pass-the-Hash and Other Credential Theft v2][PTH-1].
+
+To further harden security, we also recommend that you implement Windows Local Administrator Password Solution (LAPS), which automates local administrator password management. LAPS mitigates the risk of lateral escalation and other cyberattacks facilitated when customers use the same administrative local account and password combination on all their computers.
+
+For more information about LAPS, see [What is Windows LAPS][LEARN-1].
+
+## Additional considerations
+
+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 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
+- Remote Credential Guard is only supported for direct connections to the target machines and not for the ones via Remote Desktop Connection Broker and Remote Desktop Gateway
+
+
+
+[CSP-1]: /windows/client-management/mdm/policy-csp-credentialsdelegation
+[CSP-2]: /windows/client-management/mdm/policy-csp-admx-credssp
+[INT-3]: /mem/intune/configuration/settings-catalog
+[LEARN-1]: /windows-server/identity/laps/laps-overview
+[TECH-1]: https://social.technet.microsoft.com/wiki/contents/articles/32905.how-to-enable-restricted-admin-mode-for-remote-desktop.aspx
+[PTH-1]: https://download.microsoft.com/download/7/7/A/77ABC5BD-8320-41AF-863C-6ECFB10CB4B9/Mitigating-Pass-the-Hash-Attacks-and-Other-Credential-Theft-Version-2.pdf
diff --git a/windows/security/identity-protection/smart-cards/smart-card-and-remote-desktop-services.md b/windows/security/identity-protection/smart-cards/smart-card-and-remote-desktop-services.md
index 5443446244..35ace33d60 100644
--- a/windows/security/identity-protection/smart-cards/smart-card-and-remote-desktop-services.md
+++ b/windows/security/identity-protection/smart-cards/smart-card-and-remote-desktop-services.md
@@ -2,7 +2,7 @@
ms.date: 09/24/2021
title: Smart Card and Remote Desktop Services
description: This topic for the IT professional describes the behavior of Remote Desktop Services when you implement smart card sign-in.
-ms.topic: article
+ms.topic: conceptual
ms.reviewer: ardenw
---
# Smart Card and Remote Desktop Services
diff --git a/windows/security/identity-protection/smart-cards/smart-card-architecture.md b/windows/security/identity-protection/smart-cards/smart-card-architecture.md
index d305de2eae..f66eedf547 100644
--- a/windows/security/identity-protection/smart-cards/smart-card-architecture.md
+++ b/windows/security/identity-protection/smart-cards/smart-card-architecture.md
@@ -2,7 +2,7 @@
title: Smart Card Architecture
description: This topic for the IT professional describes the system architecture that supports smart cards in the Windows operating system.
ms.reviewer: ardenw
-ms.topic: article
+ms.topic: reference-architecture
ms.date: 09/24/2021
---
diff --git a/windows/security/identity-protection/smart-cards/smart-card-certificate-propagation-service.md b/windows/security/identity-protection/smart-cards/smart-card-certificate-propagation-service.md
index f44786fcb1..62737034ae 100644
--- a/windows/security/identity-protection/smart-cards/smart-card-certificate-propagation-service.md
+++ b/windows/security/identity-protection/smart-cards/smart-card-certificate-propagation-service.md
@@ -2,7 +2,7 @@
title: Certificate Propagation Service
description: This topic for the IT professional describes the certificate propagation service (CertPropSvc), which is used in smart card implementation.
ms.reviewer: ardenw
-ms.topic: article
+ms.topic: concept-article
ms.date: 08/24/2021
---
diff --git a/windows/security/identity-protection/smart-cards/smart-card-certificate-requirements-and-enumeration.md b/windows/security/identity-protection/smart-cards/smart-card-certificate-requirements-and-enumeration.md
index ac153d8216..9931e52d1f 100644
--- a/windows/security/identity-protection/smart-cards/smart-card-certificate-requirements-and-enumeration.md
+++ b/windows/security/identity-protection/smart-cards/smart-card-certificate-requirements-and-enumeration.md
@@ -2,7 +2,7 @@
title: Certificate Requirements and Enumeration
description: This topic for the IT professional and smart card developers describes how certificates are managed and used for smart card sign-in.
ms.reviewer: ardenw
-ms.topic: article
+ms.topic: concept-article
ms.date: 09/24/2021
---
@@ -175,7 +175,7 @@ The smart card certificate has specific format requirements when it is used with
| **Component** | **Requirements for Windows 8.1, Windows 8, Windows 7, Windows Vista, Windows 10, and Windows 11** | **Requirements for Windows XP** |
|--------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| CRL distribution point location | Not required | The location must be specified, online, and available, for example:
\[1\]CRL Distribution Point
Distribution Point Name:
Full Name:
URL=`
\[1\]CRL Distribution Point
Distribution Point Name:
Full Name:
URL=`
**Note** If an EKU is present, it must contain the smart card sign-in EKU. Certificates with no EKU can be used for sign-in. | - Client Authentication (1.3.6.1.5.5.7.3.2)
The client authentication object identifier is required only if a certificate is used for SSL authentication.
- Smart Card Sign-in (1.3.6.1.4.1.311.20.2.2) |
@@ -310,4 +310,4 @@ For more information about this option for the command-line tool, see [-SCRoots]
## See also
-[How Smart Card Sign-in Works in Windows](smart-card-how-smart-card-sign-in-works-in-windows.md)
\ No newline at end of file
+[How Smart Card Sign-in Works in Windows](smart-card-how-smart-card-sign-in-works-in-windows.md)
diff --git a/windows/security/identity-protection/smart-cards/smart-card-debugging-information.md b/windows/security/identity-protection/smart-cards/smart-card-debugging-information.md
index afd45f5a5f..8193759010 100644
--- a/windows/security/identity-protection/smart-cards/smart-card-debugging-information.md
+++ b/windows/security/identity-protection/smart-cards/smart-card-debugging-information.md
@@ -5,7 +5,7 @@ ms.reviewer: ardenw
ms.collection:
- highpri
- tier2
-ms.topic: article
+ms.topic: troubleshooting
ms.date: 09/24/2021
---
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 e2ef4a9160..f3f0e7de99 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
@@ -2,7 +2,7 @@
title: Smart Card Group Policy and Registry Settings
description: Discover the Group Policy, registry key, local security policy, and credential delegation policy settings that are available for configuring smart cards.
ms.reviewer: ardenw
-ms.topic: article
+ms.topic: reference
ms.date: 11/02/2021
---
diff --git a/windows/security/identity-protection/smart-cards/smart-card-how-smart-card-sign-in-works-in-windows.md b/windows/security/identity-protection/smart-cards/smart-card-how-smart-card-sign-in-works-in-windows.md
index 5d498cb152..5ad7eb1205 100644
--- a/windows/security/identity-protection/smart-cards/smart-card-how-smart-card-sign-in-works-in-windows.md
+++ b/windows/security/identity-protection/smart-cards/smart-card-how-smart-card-sign-in-works-in-windows.md
@@ -2,7 +2,7 @@
title: How Smart Card Sign-in Works in Windows
description: This topic for IT professional provides links to resources about the implementation of smart card technologies in the Windows operating system.
ms.reviewer: ardenw
-ms.topic: article
+ms.topic: overview
ms.date: 09/24/2021
---
diff --git a/windows/security/identity-protection/smart-cards/smart-card-removal-policy-service.md b/windows/security/identity-protection/smart-cards/smart-card-removal-policy-service.md
index 8250828ff6..4b9fd9a3fd 100644
--- a/windows/security/identity-protection/smart-cards/smart-card-removal-policy-service.md
+++ b/windows/security/identity-protection/smart-cards/smart-card-removal-policy-service.md
@@ -2,7 +2,7 @@
title: Smart Card Removal Policy Service
description: This topic for the IT professional describes the role of the removal policy service (ScPolicySvc) in smart card implementation.
ms.reviewer: ardenw
-ms.topic: article
+ms.topic: concept-article
ms.date: 09/24/2021
---
diff --git a/windows/security/identity-protection/smart-cards/smart-card-smart-cards-for-windows-service.md b/windows/security/identity-protection/smart-cards/smart-card-smart-cards-for-windows-service.md
index e3a98718be..2604d84270 100644
--- a/windows/security/identity-protection/smart-cards/smart-card-smart-cards-for-windows-service.md
+++ b/windows/security/identity-protection/smart-cards/smart-card-smart-cards-for-windows-service.md
@@ -2,7 +2,7 @@
title: Smart Cards for Windows Service
description: This topic for the IT professional and smart card developers describes how the Smart Cards for Windows service manages readers and application interactions.
ms.reviewer: ardenw
-ms.topic: article
+ms.topic: concept-article
ms.date: 09/24/2021
---
diff --git a/windows/security/identity-protection/smart-cards/smart-card-tools-and-settings.md b/windows/security/identity-protection/smart-cards/smart-card-tools-and-settings.md
index 4de4acbfc6..f18465fff3 100644
--- a/windows/security/identity-protection/smart-cards/smart-card-tools-and-settings.md
+++ b/windows/security/identity-protection/smart-cards/smart-card-tools-and-settings.md
@@ -2,7 +2,7 @@
title: Smart Card Tools and Settings
description: This topic for the IT professional and smart card developer links to information about smart card debugging, settings, and events.
ms.reviewer: ardenw
-ms.topic: article
+ms.topic: conceptual
ms.date: 09/24/2021
---
diff --git a/windows/security/identity-protection/smart-cards/smart-card-windows-smart-card-technical-reference.md b/windows/security/identity-protection/smart-cards/smart-card-windows-smart-card-technical-reference.md
index 07d20ddf30..a7e5247fcc 100644
--- a/windows/security/identity-protection/smart-cards/smart-card-windows-smart-card-technical-reference.md
+++ b/windows/security/identity-protection/smart-cards/smart-card-windows-smart-card-technical-reference.md
@@ -2,7 +2,7 @@
title: Smart Card Technical Reference
description: Learn about the Windows smart card infrastructure for physical smart cards, and how smart card-related components work in Windows.
ms.reviewer: ardenw
-ms.topic: article
+ms.topic: reference
ms.date: 09/24/2021
---
diff --git a/windows/security/identity-protection/toc.yml b/windows/security/identity-protection/toc.yml
index d8e6726e39..5762bfaf81 100644
--- a/windows/security/identity-protection/toc.yml
+++ b/windows/security/identity-protection/toc.yml
@@ -3,16 +3,18 @@ items:
href: index.md
- name: Passwordless sign-in
items:
- - name: Windows Hello for Business 🔗
- href: hello-for-business/index.md
+ - name: Passwordless strategy
+ href: hello-for-business/passwordless-strategy.md
+ - name: Windows Hello for Business
+ href: hello-for-business/toc.yml
- name: Windows presence sensing
href: https://support.microsoft.com/windows/wake-your-windows-11-pc-when-you-approach-82285c93-440c-4e15-9081-c9e38c1290bb
- - name: Windows Hello for Business Enhanced Security Sign-in (ESS) 🔗
- href: /windows-hardware/design/device-experiences/windows-hello-enhanced-sign-in-security
- - name: FIDO 2 security key 🔗
+ - name: FIDO2 security key 🔗
href: /azure/active-directory/authentication/howto-authentication-passwordless-security-key
- - name: Federated sign-in 🔗
- href: /education/windows/federated-sign-in
+ - name: Windows passwordless experience
+ href: passwordless-experience/index.md
+ - name: Passkeys
+ href: passkeys/index.md
- name: Smart Cards
href: smart-cards/toc.yml
- name: Virtual smart cards
@@ -20,6 +22,10 @@ items:
displayName: VSC
- name: Enterprise Certificate Pinning
href: enterprise-certificate-pinning.md
+ - name: Web sign-in
+ href: web-sign-in/index.md
+ - name: Federated sign-in 🔗
+ href: /education/windows/federated-sign-in
- name: Advanced credential protection
items:
- name: Windows LAPS (Local Administrator Password Solution) 🔗
@@ -33,11 +39,11 @@ items:
- name: Access Control
href: access-control/access-control.md
displayName: ACL/SACL
- - name: Windows Defender Credential Guard
+ - name: Credential Guard
href: credential-guard/toc.yml
- - name: Windows Defender Remote Credential Guard
+ - name: Remote Credential Guard
href: remote-credential-guard.md
- - name: LSA Protection
+ - name: LSA Protection 🔗
href: /windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection
- name: Local Accounts
href: access-control/local-accounts.md
diff --git a/windows/security/identity-protection/web-sign-in/images/lock-screen.png b/windows/security/identity-protection/web-sign-in/images/lock-screen.png
new file mode 100644
index 0000000000..dfe0a0687e
Binary files /dev/null and b/windows/security/identity-protection/web-sign-in/images/lock-screen.png differ
diff --git a/windows/security/identity-protection/web-sign-in/images/web-sign-in-authenticator.gif b/windows/security/identity-protection/web-sign-in/images/web-sign-in-authenticator.gif
new file mode 100644
index 0000000000..499f39dbb5
Binary files /dev/null and b/windows/security/identity-protection/web-sign-in/images/web-sign-in-authenticator.gif differ
diff --git a/windows/security/identity-protection/web-sign-in/images/web-sign-in-authenticator.png b/windows/security/identity-protection/web-sign-in/images/web-sign-in-authenticator.png
new file mode 100644
index 0000000000..be213d4500
Binary files /dev/null and b/windows/security/identity-protection/web-sign-in/images/web-sign-in-authenticator.png differ
diff --git a/windows/security/identity-protection/web-sign-in/images/web-sign-in-credential-provider.svg b/windows/security/identity-protection/web-sign-in/images/web-sign-in-credential-provider.svg
new file mode 100644
index 0000000000..1afb38e115
--- /dev/null
+++ b/windows/security/identity-protection/web-sign-in/images/web-sign-in-credential-provider.svg
@@ -0,0 +1,4 @@
+
diff --git a/windows/security/identity-protection/web-sign-in/images/web-sign-in-federated-auth.gif b/windows/security/identity-protection/web-sign-in/images/web-sign-in-federated-auth.gif
new file mode 100644
index 0000000000..403c7fb609
Binary files /dev/null and b/windows/security/identity-protection/web-sign-in/images/web-sign-in-federated-auth.gif differ
diff --git a/windows/security/identity-protection/web-sign-in/images/web-sign-in-federated-auth.png b/windows/security/identity-protection/web-sign-in/images/web-sign-in-federated-auth.png
new file mode 100644
index 0000000000..f22395fbd7
Binary files /dev/null and b/windows/security/identity-protection/web-sign-in/images/web-sign-in-federated-auth.png differ
diff --git a/windows/security/identity-protection/web-sign-in/images/web-sign-in-pin-reset.gif b/windows/security/identity-protection/web-sign-in/images/web-sign-in-pin-reset.gif
new file mode 100644
index 0000000000..9ae9f3c92f
Binary files /dev/null and b/windows/security/identity-protection/web-sign-in/images/web-sign-in-pin-reset.gif differ
diff --git a/windows/security/identity-protection/web-sign-in/images/web-sign-in-pin-reset.png b/windows/security/identity-protection/web-sign-in/images/web-sign-in-pin-reset.png
new file mode 100644
index 0000000000..e3b341d814
Binary files /dev/null and b/windows/security/identity-protection/web-sign-in/images/web-sign-in-pin-reset.png differ
diff --git a/windows/security/identity-protection/web-sign-in/images/web-sign-in-preferred-tenant.png b/windows/security/identity-protection/web-sign-in/images/web-sign-in-preferred-tenant.png
new file mode 100644
index 0000000000..01d91be145
Binary files /dev/null and b/windows/security/identity-protection/web-sign-in/images/web-sign-in-preferred-tenant.png differ
diff --git a/windows/security/identity-protection/web-sign-in/images/web-sign-in-tap.gif b/windows/security/identity-protection/web-sign-in/images/web-sign-in-tap.gif
new file mode 100644
index 0000000000..b677b87480
Binary files /dev/null and b/windows/security/identity-protection/web-sign-in/images/web-sign-in-tap.gif differ
diff --git a/windows/security/identity-protection/web-sign-in/images/web-sign-in-tap.png b/windows/security/identity-protection/web-sign-in/images/web-sign-in-tap.png
new file mode 100644
index 0000000000..18c20dd4fd
Binary files /dev/null and b/windows/security/identity-protection/web-sign-in/images/web-sign-in-tap.png differ
diff --git a/windows/security/identity-protection/web-sign-in/index.md b/windows/security/identity-protection/web-sign-in/index.md
new file mode 100644
index 0000000000..edd4b03647
--- /dev/null
+++ b/windows/security/identity-protection/web-sign-in/index.md
@@ -0,0 +1,172 @@
+---
+title: Web sign-in for Windows
+description: Learn how Web sign-in in Windows works, key scenarios, and how to configure it.
+ms.date: 09/27/2023
+ms.topic: how-to
+appliesto:
+ - ✅ Windows 11
+ms.collection:
+ - highpri
+ - tier1
+---
+
+# Web sign-in for Windows
+
+Starting in Windows 11, version 22H2 with [KB5030310][KB-1], you can enable a web-based sign-in experience on Microsoft Entra joined devices, unlocking new sign-in options and capabilities.
+This feature is called *Web sign-in*.
+
+Web sign-in is a *credential provider*, and it was 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 are expanded.\
+For example, you can sign in with the Microsoft Authenticator app or with a SAML-P federated identity.
+
+This article describes how to configure Web sign-in and the supported key scenarios.
+
+## System requirements
+
+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 have Internet connectivity, as the authentication is done over the Internet
+
+[!INCLUDE [federated-sign-in](../../../../includes/licensing/web-sign-in.md)]
+
+## Configure web sign-in
+
+To use web sign-in, your devices must be configured with different policies. Review the following instructions to configure your devices using either Microsoft Intune or a provisioning package (PPKG).
+
+#### [:::image type="icon" source="../../images/icons/intune.svg"::: **Intune**](#tab/intune)
+
+[!INCLUDE [intune-settings-catalog-1](../../../../includes/configure/intune-settings-catalog-1.md)]
+
+| Category | Setting name | Value |
+|--|--|--|
+| Authentication | Enable Web Sign In | Enabled |
+| Authentication | Configure Web Sign In Allowed Urls | This setting is optional, and it contains a list of domains required for sign in, for example:
- `idp.example.com`
- `example.com` |
+| Authentication | Configure Webcam Access Domain Names | This setting is optional, and it should be configured if you need to use the webcam during the sign-in process. Specify the list of domains that are allowed to use the webcam during the sign-in process, for example: `example.com` |
+
+[!INCLUDE [intune-settings-catalog-2](../../../../includes/configure/intune-settings-catalog-2.md)]
+
+Alternatively, you can configure devices using a [custom policy][INT-1] with the following settings:
+
+| OMA-URI | More information |
+|-|-|
+| `./Vendor/MSFT/Policy/Config/Authentication/EnableWebSignIn`| [EnableWebSignIn](/windows/client-management/mdm/policy-csp-authentication#enablewebsignin) |
+| `./Vendor/MSFT/Policy/Config/Authentication/ConfigureWebSignInAllowedUrls`|[ConfigureWebSignInAllowedUrls](/windows/client-management/mdm/policy-csp-authentication#configurewebsigninallowedurls)|
+| `./Vendor/MSFT/Policy/Config/Authentication/ConfigureWebCamAccessDomainNames`|[ConfigureWebcamAccessDomainNames](/windows/client-management/mdm/policy-csp-authentication#configurewebcamaccessdomainnames)|
+
+#### [:::image type="icon" source="../../images/icons/provisioning-package.svg"::: **PPKG**](#tab/ppkg)
+
+[!INCLUDE [provisioning-package-1](../../../../includes/configure/provisioning-package-1.md)]
+
+| Path | Setting name | Value |
+|--|--|--|
+| `Policies/Authentication` | `EnableWebSignIn` | Enabled |
+| `Policies/Authentication` | `ConfigureWebSignInAllowedUrls` | This setting is optional, and it contains a semicolon-separated list of domains required for sign in, for example: `idp.example.com;example.com` |
+| `Policies/Authentication` | `ConfigureWebCamAccessDomainNames` | This setting is optional, and it should be configured if you need to use the webcam during the sign-in process. Specify the list of domains that are allowed to use the webcam during the sign-in process, separated by a semicolon. For example: `example.com` |
+
+[!INCLUDE [provisioning-package-2](../../../../includes/configure/provisioning-package-2.md)]
+
+---
+
+## User experiences
+
+Once the devices are configured, a new sign-in experience becomes available, as indicated by the presence of the Web sign-in credential provider :::image type="icon" source="images/web-sign-in-credential-provider.svg" border="false"::: in the Windows lock screen.
+
+:::image type="content" source="images/lock-screen.png" border="false" lightbox="images/lock-screen.png" alt-text="Screenshot of the Windows lock screen showing the Web sign-in credential provider.":::
+
+Here's a list of key scenarios supported by Web sign-in, and a brief animation showing the user experience. Select the thumbnail to start the animation.
+
+### Passwordless sign-in
+:::row:::
+ :::column span="3":::
+ Users can sign in to Windows passwordless, even before enrolling in Windows Hello for Business. For example, by using the Microsoft Authenticator app as a sign-in method.
+ :::column-end:::
+ :::column span="1":::
+ :::image type="content" source="images/web-sign-in-authenticator.png" border="false" lightbox="images/web-sign-in-authenticator.gif" alt-text="Animation of the Web sign-in experience with Microsoft Authenticator.":::
+ :::column-end:::
+:::row-end:::
+
+> [!TIP]
+> When used in conjuction with *Windows Hello for Business passwordless*, you can hide the password credential provider from the lock screen as well as in-session authentication scenarios. This enables a truly passwordless Windows experience.
+
+To learn more:
+- [Enable passwordless sign-in with Microsoft Authenticator][AAD-1]
+- [Passwordless authentication options for Microsoft Entra ID][AAD-2]
+- [Windows passwordless experience](../passwordless-experience/index.md)
+
+### Windows Hello for Business PIN reset
+
+:::row:::
+ :::column span="3":::
+ The Windows Hello PIN reset flow is seamless and more robust than in previous versions.
+ :::column-end:::
+ :::column span="1":::
+ :::image type="content" source="images/web-sign-in-pin-reset.png" border="false" lightbox="images/web-sign-in-pin-reset.gif" alt-text="Animation of the PIN reset in experience.":::
+ :::column-end:::
+:::row-end:::
+
+For more information, see [PIN reset](../hello-for-business/hello-feature-pin-reset.md).
+
+### Temporary Access Pass (TAP)
+
+:::row:::
+ :::column span="3":::
+ A Temporary Access Pass (TAP) is a time-limited passcode granted by an administrator to a user. Users can sign in with a TAP using the Web sign-in credential provider. For example:
+
+ - to onboard Windows Hello for Business or a FIDO2 security key
+ - if lost or forgotten FIDO2 security key and unknown password
+
+ :::column-end:::
+ :::column span="1":::
+ :::image type="content" source="images/web-sign-in-tap.png" border="false" lightbox="images/web-sign-in-tap.gif" alt-text="Animation of the TAP sign in experience.":::
+ :::column-end:::
+:::row-end:::
+
+For more information, see [Use a Temporary Access Pass][AAD-3].
+
+### Sign in with a federated identity
+
+:::row:::
+ :::column span="3":::
+ 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.":::
+ :::column-end:::
+:::row-end:::
+
+> [!TIP]
+> To improve the user experience for federated identities:
+>
+> - 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].
+
+## Important considerations
+
+Here's a list of important considerations to keep in mind when configuring or using Web sign-in:
+
+- Cached credentials aren't supported with Web sign-in. If the device is offline, the user can't use the Web sign-in credential provider to sign in
+- After sign out, the user isn't displayed in the user selection list
+- Once enabled, the Web sign-in credential provider is the default credential provider for new users signing in to the device. To change the default credential provider, you can use the [DefaultCredentialProvider][WIN-2] ADMX-backed policy
+- The user can exit the Web sign-in flow by pressing Ctrl+Alt+Delete to get back to the Windows lock screen
+
+### Known issues
+
+- If you attempt to sign in while the device is offline, you get the following message: *It doesn't look that you're connected to the Internet. Check your connection and try again*. Selecting the *Back to sign-in* option doesn't bring you back to the lock screen. As a workaround, you can press Ctrl+Alt+Delete to get back to the lock screen.
+
+### :::image type="icon" source="../../images/icons/feedback.svg" border="false"::: Provide feedback
+
+To provide feedback for web sign-in, open [**Feedback Hub**][FHUB] and use the category **Security and Privacy > Passwordless experience**.
+
+
+
+[AAD-1]: /azure/active-directory/authentication/howto-authentication-passwordless-phone
+[AAD-2]: /azure/active-directory/authentication/concept-authentication-passwordless
+[AAD-3]: /azure/active-directory/authentication/howto-authentication-temporary-access-pass
+[FHUB]: feedback-hub://?tabid=2&newFeedback=true&feedbackType=1
+[INT-1]: /mem/intune/configuration/custom-settings-windows-10
+[KB-1]: https://support.microsoft.com/kb/5030310
+[WIN-1]: /windows/client-management/mdm/policy-csp-authentication#preferredaadtenantdomainname
+[WIN-2]: /windows/client-management/mdm/policy-csp-admx-credentialproviders#defaultcredentialprovider
diff --git a/windows/security/images/icons/feedback.svg b/windows/security/images/icons/feedback.svg
new file mode 100644
index 0000000000..2ecd143695
--- /dev/null
+++ b/windows/security/images/icons/feedback.svg
@@ -0,0 +1,3 @@
+
diff --git a/windows/security/images/icons/key.svg b/windows/security/images/icons/key.svg
new file mode 100644
index 0000000000..c9df33c18f
--- /dev/null
+++ b/windows/security/images/icons/key.svg
@@ -0,0 +1,3 @@
+
\ No newline at end of file
diff --git a/windows/security/images/icons/provisioning-package.svg b/windows/security/images/icons/provisioning-package.svg
new file mode 100644
index 0000000000..dbbad7d780
--- /dev/null
+++ b/windows/security/images/icons/provisioning-package.svg
@@ -0,0 +1,3 @@
+
\ No newline at end of file
diff --git a/windows/security/includes/sections/application.md b/windows/security/includes/sections/application.md
index 34f9e6a785..8b6b510ef4 100644
--- a/windows/security/includes/sections/application.md
+++ b/windows/security/includes/sections/application.md
@@ -1,7 +1,7 @@
---
author: paolomatarazzo
ms.author: paoloma
-ms.date: 08/02/2023
+ms.date: 09/18/2023
ms.topic: include
---
@@ -10,17 +10,17 @@ ms.topic: include
| Feature name | Description |
|:---|:---|
| **[Smart App Control](/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control)** | Smart App Control prevents users from running malicious applications on Windows devices by blocking untrusted or unsigned applications. Smart App Control goes beyond previous built-in browser protections, by adding another layer of security that is woven directly into the core of the OS at the process level. Using AI, our new Smart App Control only allows processes to run that are predicted to be safe based on existing and new intelligence processed daily. Smart App Control builds on top of the same cloud-based AI used in Windows Defender Application Control (WDAC) to predict the safety of an application, so people can be confident they're using safe and reliable applications on their new Windows 11 devices, or Windows 11 devices that have been reset. |
-| **[AppLocker](/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-overview)** | |
| **[Windows Defender Application Control (WDAC)](/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control)** | Your organization is only as secure as the applications that run on your devices. With application control, apps must earn trust to run, in contrast to an application trust model where all code is assumed trustworthy. By helping prevent unwanted or malicious code from running, application control is an important part of an effective security strategy. Many organizations cite application control as one of the most effective means for addressing the threat of executable file-based malware.
Windows 10 and above include Windows Defender Application Control (WDAC) and AppLocker. WDAC is the next generation app control solution for Windows and provides powerful control over what runs in your environment. Customers who were using AppLocker on previous versions of Windows can continue to use the feature as they consider whether to switch to WDAC for the stronger protection. |
+| **[AppLocker](/windows/security/application-security/application-control/windows-defender-application-control/applocker/applocker-overview)** | |
| **[User Account Control (UAC)](/windows/security/application-security/application-control/user-account-control/)** | User Account Control (UAC) helps prevent malware from damaging a device. With UAC, apps and tasks always run in the security context of a non-administrator account, unless an administrator authorizes administrator-level access to the system. UAC can block the automatic installation of unauthorized apps and prevents inadvertent changes to system settings. Enabling UAC helps to prevent malware from altering device settings and potentially gaining access to networks and sensitive data. UAC can also block the automatic installation of unauthorized apps and prevent inadvertent changes to system settings. |
-| **[Microsoft vulnerable driver blocklist](/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-driver-block-rules)** | The Windows kernel is the most privileged software and is therefore a compelling target for malware authors. Since Windows has strict requirements for code running in the kernel, cybercriminals commonly exploit vulnerabilities in kernel drivers to get access. Microsoft works with the ecosystem partners to constantly identify and respond to potentially vulnerable kernel drivers.
Prior to Windows 11, version 22H2, the operating system enforced a block policy when HVCI is enabled to prevent vulnerable versions of drivers from running. Starting in Windows 11, version 22H2, the block policy is enabled by default for all new Windows devices, and users can opt-in to enforce the policy from the Windows Security app. |
+| **[Microsoft vulnerable driver blocklist](/windows/security/application-security/application-control/windows-defender-application-control/design/microsoft-recommended-driver-block-rules)** | The Windows kernel is the most privileged software and is therefore a compelling target for malware authors. Since Windows has strict requirements for code running in the kernel, cybercriminals commonly exploit vulnerabilities in kernel drivers to get access. Microsoft works with the ecosystem partners to constantly identify and respond to potentially vulnerable kernel drivers.
Prior to Windows 11, version 22H2, the operating system enforced a block policy when HVCI is enabled to prevent vulnerable versions of drivers from running. Starting in Windows 11, version 22H2, the block policy is enabled by default for all new Windows devices, and users can opt-in to enforce the policy from the Windows Security app. |
## Application isolation
| Feature name | Description |
|:---|:---|
-| **[Microsoft Defender Application Guard (MDAG) for Edge standalone mode](/windows/security/threat-protection/microsoft-defender-application-guard/md-app-guard-overview)** | Standalone mode allows Windows users to use hardware-isolated browsing sessions without any administrator or management policy configuration. In this mode, user must manually start Microsoft Edge in Application Guard from Edge menu for browsing untrusted sites. |
-| **[Microsoft Defender Application Guard (MDAG) for Edge enterprise mode and enterprise management](/windows/security/threat-protection/microsoft-defender-application-guard/configure-md-app-guard)** | Microsoft Defender Application Guard protects users' desktop while they browse the Internet using Microsoft Edge browser. Application Guard in enterprise mode automatically redirects untrusted website navigation in an anonymous and isolated Hyper-V based container, which is separate from the host operating system. With Enterprise mode, you can define your corporate boundaries by explicitly adding trusted domains and can customizing the Application Guard experience to meet and enforce your organization needs on Windows devices. |
+| **[Microsoft Defender Application Guard (MDAG) for Edge standalone mode](/windows/security/application-security/application-isolation/microsoft-defender-application-guard/md-app-guard-overview)** | Standalone mode allows Windows users to use hardware-isolated browsing sessions without any administrator or management policy configuration. In this mode, user must manually start Microsoft Edge in Application Guard from Edge menu for browsing untrusted sites. |
+| **[Microsoft Defender Application Guard (MDAG) for Edge enterprise mode and enterprise management](/windows/security/application-security/application-isolation/microsoft-defender-application-guard/configure-md-app-guard)** | Microsoft Defender Application Guard protects users' desktop while they browse the Internet using Microsoft Edge browser. Application Guard in enterprise mode automatically redirects untrusted website navigation in an anonymous and isolated Hyper-V based container, which is separate from the host operating system. With Enterprise mode, you can define your corporate boundaries by explicitly adding trusted domains and can customizing the Application Guard experience to meet and enforce your organization needs on Windows devices. |
| **Microsoft Defender Application Guard (MDAG) public APIs** | Enable applications using them to be isolated Hyper-V based container, which is separate from the host operating system. |
| **[Microsoft Defender Application Guard (MDAG) for Microsoft Office](https://support.microsoft.com/office/application-guard-for-office-9e0fb9c2-ffad-43bf-8ba3-78f785fdba46)** | Application Guard protects Office files including Word, PowerPoint, and Excel. Application icons have a small shield if Application Guard has been enabled and they are under protection. |
| **[Microsoft Defender Application Guard (MDAG) configure via MDM](/windows/client-management/mdm/windowsdefenderapplicationguard-csp)** | The WindowsDefenderApplicationGuard configuration service provider (CSP) is used by the enterprise to configure the settings in Microsoft Defender Application Guard. |
diff --git a/windows/security/includes/sections/cloud-services.md b/windows/security/includes/sections/cloud-services.md
index 07fc5b88b5..efde3a725d 100644
--- a/windows/security/includes/sections/cloud-services.md
+++ b/windows/security/includes/sections/cloud-services.md
@@ -1,7 +1,7 @@
---
author: paolomatarazzo
ms.author: paoloma
-ms.date: 08/02/2023
+ms.date: 09/18/2023
ms.topic: include
---
@@ -9,10 +9,10 @@ ms.topic: include
| Feature name | Description |
|:---|:---|
-| **[Azure AD join, Active Directory domain join, and Hybrid Azure AD join with single sign-on (SSO)](/azure/active-directory/devices/concept-azure-ad-join)** | Microsoft Azure Active Directory 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/threat-protection/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. |
+| **[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. |
| **[Universal Print](/universal-print/)** | Unlike traditional print solutions that rely on Windows print servers, Universal Print is a Microsoft hosted cloud subscription service that supports a zero-trust security model by enabling network isolation of printers, including the Universal Print connector software, from the rest of the organization's resources. |
| **[Windows Autopatch](/windows/deployment/windows-autopatch/)** | With the Autopatch service, IT teams can delegate management of updates to Windows 10/11, Microsoft Edge, and Microsoft 365 apps to Microsoft. Under the hood, Autopatch takes over configuration of the policies and deployment service of Windows Update for Business. What the customer gets are endpoints that are up to date, thanks to dynamically generated rings for progressive deployment that will pause and/or roll back updates (where possible) when issues arise.
The goal is to provide peace of mind to IT pros, encourage rapid adoption of updates, and to reduce bandwidth required to deploy them successfully, thereby closing gaps in protection that may have been open to exploitation by malicious actors. |
-| **[Windows Autopilot](/windows/deployment/windows-autopilot)** | Windows Autopilot simplifies the way devices get deployed, reset, and repurposed, with an experience that is zero touch for IT. |
+| **[Windows Autopilot](/autopilot/)** | Windows Autopilot simplifies the way devices get deployed, reset, and repurposed, with an experience that is zero touch for IT. |
diff --git a/windows/security/includes/sections/hardware.md b/windows/security/includes/sections/hardware.md
index 11a4f97b60..fa6c065293 100644
--- a/windows/security/includes/sections/hardware.md
+++ b/windows/security/includes/sections/hardware.md
@@ -1,7 +1,7 @@
---
author: paolomatarazzo
ms.author: paoloma
-ms.date: 08/02/2023
+ms.date: 09/18/2023
ms.topic: include
---
@@ -20,7 +20,7 @@ ms.topic: include
| **[Virtualization-based security (VBS)](/windows-hardware/design/device-experiences/oem-vbs)** | In addition to a modern hardware root-of-trust, there are numerous other capabilities in the latest chips that harden the operating system against threats, such as by protecting the boot process, safeguarding the integrity of memory, isolating security sensitive compute logic, and more. Two examples include Virtualization-based security (VBS) and Hypervisor-protected code integrity (HVCI). Virtualization-based security (VBS), also known as core isolation, is a critical building block in a secure system. VBS uses hardware virtualization features to host a secure kernel separated from the operating system. This means that even if the operating system is compromised, the secure kernel remains protected.
Starting with Windows 10, all new devices are required to ship with firmware support for VBS and HCVI enabled by default in the BIOS. Customers can then enable the OS support in Windows.
With new installs of Windows 11, OS support for VBS and HVCI is turned on by default for all devices that meet prerequisites. |
| **[Hypervisor-protected Code Integrity (HVCI)](/windows/security/hardware-security/enable-virtualization-based-protection-of-code-integrity)** | Hypervisor-protected code integrity (HVCI), also called memory integrity, uses VBS to run Kernel Mode Code Integrity (KMCI) inside the secure VBS environment instead of the main Windows kernel. This helps to prevent attacks that attempt to modify kernel mode code, such as drivers. The KMCI role is to check that all kernel code is properly signed and hasn't been tampered with before it is allowed to run. HVCI helps to ensure that only validated code can be executed in kernel-mode.
Starting with Windows 10, all new devices are required to ship with firmware support for VBS and HCVI enabled by default in the BIOS. Customers can then enable the OS support in Windows.
With new installs of Windows 11, OS support for VBS and HVCI is turned on by default for all devices that meet prerequisites. |
| **[Hardware-enforced stack protection](https://techcommunity.microsoft.com/t5/windows-os-platform-blog/understanding-hardware-enforced-stack-protection/ba-p/1247815)** | Hardware-enforced stack protection integrates software and hardware for a modern defense against cyberthreats such as memory corruption and zero-day exploits. Based on Control-flow Enforcement Technology (CET) from Intel and AMD Shadow Stacks, hardware-enforced stack protection is designed to protect against exploit techniques that try to hijack return addresses on the stack. |
-| **[Kernel Direct Memory Access (DMA) protection](/windows/security/information-protection/kernel-dma-protection-for-thunderbolt)** | Kernel DMA Protection protects against external peripherals from gaining unauthorized access to memory. Physical threats such as drive-by Direct Memory Access (DMA) attacks typically happen quickly while the system owner isn't present. PCIe hot plug devices such as Thunderbolt, USB4, and CFexpress allow users to attach new classes of external peripherals, including graphics cards or other PCI devices, to their PCs with the plug-and-play ease of USB. Because PCI hot plug ports are external and easily accessible, devices are susceptible to drive-by DMA attacks. |
+| **[Kernel Direct Memory Access (DMA) protection](/windows/security/hardware-security/kernel-dma-protection-for-thunderbolt)** | Kernel DMA Protection protects against external peripherals from gaining unauthorized access to memory. Physical threats such as drive-by Direct Memory Access (DMA) attacks typically happen quickly while the system owner isn't present. PCIe hot plug devices such as Thunderbolt, USB4, and CFexpress allow users to attach new classes of external peripherals, including graphics cards or other PCI devices, to their PCs with the plug-and-play ease of USB. Because PCI hot plug ports are external and easily accessible, devices are susceptible to drive-by DMA attacks. |
## Secured-core PC
diff --git a/windows/security/includes/sections/identity.md b/windows/security/includes/sections/identity.md
index 891ad65444..5a643de599 100644
--- a/windows/security/includes/sections/identity.md
+++ b/windows/security/includes/sections/identity.md
@@ -1,7 +1,7 @@
---
author: paolomatarazzo
ms.author: paoloma
-ms.date: 08/02/2023
+ms.date: 09/18/2023
ms.topic: include
---
@@ -9,20 +9,23 @@ ms.topic: include
| Feature name | Description |
|:---|:---|
-| **[Windows Hello for Business](/windows/security/identity-protection/hello-for-business)** | Windows 11 devices can protect user identities by removing the need to use passwords from day one. It's easy to get started with the method that's right for your organization. A password may only need to be used once during the provisioning process, after which people use a PIN, face, or fingerprint to unlock credentials and sign into the device.
Windows Hello for Business replaces the username and password by combining a security key or certificate with a PIN or biometrics data, and then mapping the credentials to a user account during setup. There are multiple ways to deploy Windows Hello for Business, depending on your organization's needs. Organizations that rely on certificates typically use on-premises public key infrastructure (PKI) to support authentication through Certificate Trust. Organizations using key trust deployment require root-of-trust provided by certificates on domain controllers. |
-| **[Windows presence sensing](https://support.microsoft.com/windows/wake-your-windows-11-pc-when-you-approach-82285c93-440c-4e15-9081-c9e38c1290bb)** | Windows presence sensing provides another layer of data security protection for hybrid workers. Windows 11 devices can intelligently adapt to your presence to help you stay secure and productive, whether you're working at home, the office, or a public environment. Windows presence sensing combines presence detection sensors with Windows Hello facial recognition to automatically lock your device when you leave, and then unlock your device and sign you in using Windows Hello facial recognition when you return. Requires OEM supporting hardware. |
+| **[Windows Hello for Business](/windows/security/identity-protection/hello-for-business/)** | Windows 11 devices can protect user identities by removing the need to use passwords from day one. It's easy to get started with the method that's right for your organization. A password may only need to be used once during the provisioning process, after which people use a PIN, face, or fingerprint to unlock credentials and sign into the device.
Windows Hello for Business replaces the username and password by combining a security key or certificate with a PIN or biometrics data, and then mapping the credentials to a user account during setup. There are multiple ways to deploy Windows Hello for Business, depending on your organization's needs. Organizations that rely on certificates typically use on-premises public key infrastructure (PKI) to support authentication through Certificate Trust. Organizations using key trust deployment require root-of-trust provided by certificates on domain controllers. |
+| **[Windows presence sensing](https://support.microsoft.com/windows/managing-presence-sensing-settings-in-windows-11-82285c93-440c-4e15-9081-c9e38c1290bb)** | Windows presence sensing provides another layer of data security protection for hybrid workers. Windows 11 devices can intelligently adapt to your presence to help you stay secure and productive, whether you're working at home, the office, or a public environment. Windows presence sensing combines presence detection sensors with Windows Hello facial recognition to automatically lock your device when you leave, and then unlock your device and sign you in using Windows Hello facial recognition when you return. Requires OEM supporting hardware. |
| **[Windows Hello for Business Enhanced Security Sign-in (ESS)](/windows-hardware/design/device-experiences/windows-hello-enhanced-sign-in-security)** | Windows Hello biometrics also supports enhanced sign-in security, which uses specialized hardware and software components to raise the security bar even higher for biometric sign in.
Enhanced sign-in security biometrics uses VBS and the TPM to isolate user authentication processes and data and secure the pathway by which the information is communicated. These specialized components protect against a class of attacks that include biometric sample injection, replay, tampering, and more.
For example, fingerprint readers must implement Secure Device Connection Protocol, which uses key negotiation and a Microsoft-issued certificate to protect and securely store user authentication data. For facial recognition, components such as the Secure Devices (SDEV) table and process isolation with trustlets help prevent additional class of attacks. |
-| **[Fast Identity Online (FIDO2) security key](/azure/active-directory/authentication/howto-authentication-passwordless-security-key)** | Fast Identity Online (FIDO) defined CTAP and WebAuthN specifications are becoming the open standard for providing strong authentication that is non-phishable, user-friendly, and privacy-respecting with implementations from major platform providers and relying parties. FIDO standards and certifications are becoming recognized as the leading standard for creating secure authentication solutions across enterprises, governments, and consumer markets.
Windows 11 can use external FIDO2 security keys for authentication alongside or in addition to Windows Hello which is also a FIDO2 certified passwordless solution. Windows 11 can be used as a FIDO authenticator for many popular identity management services. |
-| **[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 passwordless experience](/windows/security/identity-protection/passwordless-experience)** | Windows passwordless experience is a security policy that aims to create a more user-friendly experience for Microsoft Entra joined devices by eliminating the need for passwords in certain authentication scenarios. By enabling this policy, users will not be given the option to use a password in these scenarios, which helps organizations transition away from passwords over time. |
+| **[Passkeys](/windows/security/identity-protection/passkeys)** | Passkeys provide a more secure and convenient method to logging into websites and applications compared to passwords. Unlike passwords, which users must remember and type, passkeys are stored as secrets on a device and can use a device's unlock mechanism (such as biometrics or a PIN). Passkeys can be used without the need for other sign in challenges, making the authentication process faster, secure, and more convenient. |
+| **[FIDO2 security key](/azure/active-directory/authentication/howto-authentication-passwordless-security-key)** | Fast Identity Online (FIDO) defined CTAP and WebAuthN specifications are becoming the open standard for providing strong authentication that is non-phishable, user-friendly, and privacy-respecting with implementations from major platform providers and relying parties. FIDO standards and certifications are becoming recognized as the leading standard for creating secure authentication solutions across enterprises, governments, and consumer markets.
Windows 11 can use external FIDO2 security keys for authentication alongside or in addition to Windows Hello which is also a FIDO2 certified passwordless solution. Windows 11 can be used as a FIDO authenticator for many popular identity management services. |
| **[Smart Cards for Windows Service](/windows/security/identity-protection/smart-cards/smart-card-smart-cards-for-windows-service)** | Organizations also have the option of using smart cards, an authentication method that pre-dates biometric sign in. Smart cards are tamper-resistant, portable storage devices that can enhance Windows security when authenticating clients, signing code, securing e-mail, and signing in with Windows domain accounts. Smart cards can only be used to sign into domain accounts, not local accounts. When a password is used to sign into a domain account, Windows uses the Kerberos version 5 (v5) protocol for authentication. If you use a smart card, the operating system uses Kerberos v5 authentication with X.509 v3 certificates. |
## Advanced credential protection
| Feature name | Description |
|:---|:---|
-| **[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 Azure Active Directory-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. |
+| **[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 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/threat-protection/microsoft-defender-smartscreen/phishing-protection-microsoft-defender-smartscreen)** | 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. |
+| **[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. |
-| **[Windows Defender Credential Guard](/windows/security/identity-protection/credential-guard/credential-guard)** | Enabled by default in Windows 11 Enterprise, Windows Credential Guard uses hardware-backed, Virtualization-based security (VBS) to protect against credential theft. With Windows Credential Guard, the Local Security Authority (LSA) stores and protects secrets in an isolated environment that isn't accessible to the rest of the operating system. LSA uses remote procedure calls to communicate with the isolated LSA process.
By protecting the LSA process with Virtualization-based security, Windows Credential Guard shields systems from credential theft attack techniques like pass-the-hash or pass-the-ticket. It also helps prevent malware from accessing system secrets even if the process is running with admin privileges. |
-| **[Windows Defender Remote Credential Guard](/windows/security/identity-protection/remote-credential-guard)** | Window Defender Remote Credential Guard helps you protect your credentials over a Remote Desktop connection by redirecting the Kerberos requests back to the device that is requesting the connection. It also provides single sign-on experiences for Remote Desktop sessions.
Administrator credentials are highly privileged and must be protected. When you use Windows Defender Remote Credential Guard to connect during Remote Desktop sessions, your credential and credential derivatives are never passed over the network to the target device. If the target device is compromised, your credentials aren't exposed. |
+| **[Credential Guard](/windows/security/identity-protection/credential-guard/)** | Enabled by default in Windows 11 Enterprise, Credential Guard uses hardware-backed, Virtualization-based security (VBS) to protect against credential theft. With Credential Guard, the Local Security Authority (LSA) stores and protects secrets in an isolated environment that isn't accessible to the rest of the operating system. LSA uses remote procedure calls to communicate with the isolated LSA process.
By protecting the LSA process with Virtualization-based security, Credential Guard shields systems from credential theft attack techniques like pass-the-hash or pass-the-ticket. It also helps prevent malware from accessing system secrets even if the process is running with admin privileges. |
+| **[Remote Credential Guard](/windows/security/identity-protection/remote-credential-guard)** | Remote Credential Guard helps you protect your credentials over a Remote Desktop connection by redirecting the Kerberos requests back to the device that is requesting the connection. It also provides single sign-on experiences for Remote Desktop sessions.
Administrator credentials are highly privileged and must be protected. When you use Remote Credential Guard to connect during Remote Desktop sessions, your credential and credential derivatives are never passed over the network to the target device. If the target device is compromised, your credentials aren't exposed. |
diff --git a/windows/security/includes/sections/operating-system-security.md b/windows/security/includes/sections/operating-system-security.md
index 3a748fac25..4a4ee4acf2 100644
--- a/windows/security/includes/sections/operating-system-security.md
+++ b/windows/security/includes/sections/operating-system-security.md
@@ -1,7 +1,7 @@
---
author: paolomatarazzo
ms.author: paoloma
-ms.date: 08/02/2023
+ms.date: 09/18/2023
ms.topic: include
---
@@ -9,10 +9,11 @@ ms.topic: include
| Feature name | Description |
|:---|:---|
-| **[Secure Boot and Trusted Boot](/windows/security/trusted-boot)** | Secure Boot and Trusted Boot help to prevent malware and corrupted components from loading when a device starts.
Secure Boot starts with initial boot-up protection, and then Trusted Boot picks up the process. Together, Secure Boot and Trusted Boot help to ensure the system boots up safely and securely. |
+| **[Secure Boot and Trusted Boot](/windows/security/operating-system-security/system-security/trusted-boot)** | Secure Boot and Trusted Boot help to prevent malware and corrupted components from loading when a device starts.
Secure Boot starts with initial boot-up protection, and then Trusted Boot picks up the process. Together, Secure Boot and Trusted Boot help to ensure the system boots up safely and securely. |
| **[Measured boot](/windows/compatibility/measured-boot)** | Measured Boot measures all important code and configuration settings during the boot of Windows. This includes: the firmware, boot manager, hypervisor, kernel, secure kernel and operating system. Measured Boot stores the measurements in the TPM on the machine, and makes them available in a log that can be tested remotely to verify the boot state of the client.
The Measured Boot feature provides antimalware software with a trusted (resistant to spoofing and tampering) log of all boot components that started before it. The antimalware software can use the log to determine whether components that ran before it are trustworthy, or if they are infected with malware. The antimalware software on the local machine can send the log to a remote server for evaluation. The remote server may initiate remediation actions, either by interacting with software on the client, or through out-of-band mechanisms, as appropriate. |
-| **[Device health attestation service](/windows/security/threat-protection/protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices)** | The Windows device health attestation process supports a zero-trust paradigm that shifts the focus from static, network-based perimeters, to users, assets, and resources. The attestation process confirms the device, firmware, and boot process are in a good state and have not been tampered with before they can access corporate resources. The determinations are made with data stored in the TPM, which provides a secure root of trust. The information is sent to an attestation service, such as Azure Attestation, to verify the device is in a trusted state. Then, an MDM tool like Microsoft Intune reviews device health and connects this information with Azure Active Directory for conditional access. |
+| **[Device health attestation service](/windows/security/operating-system-security/system-security/protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices)** | The Windows device health attestation process supports a zero-trust paradigm that shifts the focus from static, network-based perimeters, to users, assets, and resources. The attestation process confirms the device, firmware, and boot process are in a good state and have not been tampered with before they can access corporate resources. The determinations are made with data stored in the TPM, which provides a secure root of trust. The information is sent to an attestation service, such as Azure Attestation, to verify the device is in a trusted state. Then, an MDM tool like Microsoft Intune reviews device health and connects this information with Microsoft Entra ID for conditional access. |
| **[Windows security policy settings and auditing](/windows/security/threat-protection/security-policy-settings/security-policy-settings)** | Microsoft provides a robust set of security settings policies that IT administrators can use to protect Windows devices and other resources in their organization. |
+| **[Assigned Access (kiosk mode)](/windows/configuration/kiosk-methods)** | Some desktop devices in an enterprise serve a special purpose. For example, a PC in the lobby that customers use to see your product catalog. Or, a PC displaying visual content as a digital sign. Windows client offers two different locked-down experiences for public or specialized use: A single-app kiosk that runs a single Universal Windows Platform (UWP) app in full screen above the lock screen, or A multi-app kiosk that runs one or more apps from the desktop.
Kiosk configurations are based on Assigned Access, a feature in Windows that allows an administrator to manage the user's experience by limiting the application entry points exposed to the user. |
## Virus and threat protection
@@ -24,20 +25,21 @@ ms.topic: include
| **[Tamper protection settings for MDE](/microsoft-365/security/defender-endpoint/prevent-changes-to-security-settings-with-tamper-protection)** | Tamper protection is a capability in Microsoft Defender for Endpoint that helps protect certain security settings, such as virus and threat protection, from being disabled or changed. During some kinds of cyber attacks, bad actors try to disable security features on devices. Disabling security features provides bad actors with easier access to your data, the ability to install malware, and the ability to exploit your data, identity, and devices. Tamper protection helps guard against these types of activities. |
| **[Controlled folder access](/microsoft-365/security/defender-endpoint/controlled-folders)** | You can protect your valuable information in specific folders by managing app access to specific folders. Only trusted apps can access protected folders, which are specified when controlled folder access is configured. Commonly used folders, such as those used for documents, pictures, downloads, are typically included in the list of controlled folders. Controlled folder access works with a list of trusted apps. Apps that are included in the list of trusted software work as expected. Apps that are not included in the trusted list are prevented from making any changes to files inside protected folders.
Controlled folder access helps to protect user's valuable data from malicious apps and threats, such as ransomware. |
| **[Exploit protection](/microsoft-365/security/defender-endpoint/exploit-protection)** | Exploit protection automatically applies several exploit mitigation techniques to operating system processes and apps. Exploit protection works best with Microsoft Defender for Endpoint, which gives organizations detailed reporting into exploit protection events and blocks as part of typical alert investigation scenarios. You can enable exploit protection on an individual device, and then use MDM or group policy to distribute the configuration file to multiple devices. When a mitigation is encountered on the device, a notification will be displayed from the Action Center. You can customize the notification with your company details and contact information. You can also enable the rules individually to customize which techniques the feature monitors. |
-| **[Microsoft Defender SmartScreen](/windows/security/threat-protection/microsoft-defender-smartscreen/microsoft-defender-smartscreen-overview)** | Microsoft Defender SmartScreen protects against phishing, malware websites and applications, and the downloading of potentially malicious files. For enhanced phishing protection, SmartScreen also alerts people when they are entering their credentials into a potentially risky location. IT can customize which notifications appear via MDM or group policy. The protection runs in audit mode by default, giving IT admins full control to make decisions around policy creation and enforcement. |
+| **[Microsoft Defender SmartScreen](/windows/security/operating-system-security/virus-and-threat-protection/microsoft-defender-smartscreen/)** | Microsoft Defender SmartScreen protects against phishing, malware websites and applications, and the downloading of potentially malicious files. For enhanced phishing protection, SmartScreen also alerts people when they are entering their credentials into a potentially risky location. IT can customize which notifications appear via MDM or group policy. The protection runs in audit mode by default, giving IT admins full control to make decisions around policy creation and enforcement. |
| **[Microsoft Defender for Endpoint](/microsoft-365/security/defender-endpoint)** | Microsoft Defender for Endpoint is an enterprise endpoint detection and response solution that helps security teams to detect, investigate, and respond to advanced threats. Organizations can use the rich event data and attack insights Defender for Endpoint provides to investigate incidents. Defender for Endpoint brings together the following elements to provide a more complete picture of security incidents: endpoint behavioral sensors, cloud security analytics, threat intelligence and rich response capabilities. |
## Network security
| Feature name | Description |
|:---|:---|
-| **[Transport layer security (TLS)](/windows-server/security/tls/tls-ssl-schannel-ssp-overview)** | Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a network. TLS 1.3 is the latest version of the protocol and is enabled by default in Windows 11. This version eliminates obsolete cryptographic algorithms, enhances security over older versions, and aims to encrypt as much of the TLS handshake as possible. The handshake is more performant with one fewer round trip per connection on average, and supports only five strong cipher suites which provide perfect forward secrecy and less operational risk. |
+| **[Transport Layer Security (TLS)](/windows-server/security/tls/tls-ssl-schannel-ssp-overview)** | Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a network. TLS 1.3 is the latest version of the protocol and is enabled by default in Windows 11. This version eliminates obsolete cryptographic algorithms, enhances security over older versions, and aims to encrypt as much of the TLS handshake as possible. The handshake is more performant with one fewer round trip per connection on average, and supports only five strong cipher suites which provide perfect forward secrecy and less operational risk. |
+| **[Domain Name System (DNS) security](/windows-server/networking/dns/doh-client-support)** | Starting in Windows 11, the Windows DNS client supports DNS over HTTPS (DoH), an encrypted DNS protocol. This allows administrators to ensure their devices protect DNS queries from on-path attackers, whether they are passive observers logging browsing behavior or active attackers trying to redirect clients to malicious sites.
In a zero-trust model where there is no trust placed in a network boundary, having a secure connection to a trusted name resolver is required. |
| **Bluetooth pairing and connection protection** | The number of Bluetooth devices connected to Windows continues to increase. Windows supports all standard Bluetooth pairing protocols, including classic and LE Secure connections, secure simple pairing, and classic and LE legacy pairing. Windows also implements host based LE privacy. Windows updates help users stay current with OS and driver security features in accordance with the Bluetooth Special Interest Group (SIG), Standard Vulnerability Reports, as well as issues beyond those required by the Bluetooth core industry standards. Microsoft strongly recommends that users ensure their firmware and/ or software of their Bluetooth accessories are kept up to date. |
| **[WiFi Security](https://support.microsoft.com/windows/faster-and-more-secure-wi-fi-in-windows-26177a28-38ed-1a8e-7eca-66f24dc63f09)** | Wi-Fi Protected Access (WPA) is a security certification programs designed to secure wireless networks. WPA3 is the latest version of the certification and provides a more secure and reliable connection method as compared to WPA2 and older security protocols. Windows supports three WPA3 modes: WPA3 personal with the Hash-to-Element (H2E) protocol, WPA3 Enterprise, and WPA3 Enterprise 192-bit Suite B.
Windows 11 also supports WFA defined WPA3 Enterprise that includes enhanced Server Cert validation and TLS 1.3 for authentication using EAP-TLS Authentication. |
| **Opportunistic Wireless Encryption (OWE)** | Opportunistic Wireless Encryption (OWE) is a technology that allows wireless devices to establish encrypted connections to public Wi-Fi hotspots. |
-| **[Windows Firewall](/windows/security/threat-protection/windows-firewall/windows-firewall-with-advanced-security)** | Windows Firewall with Advanced Securityprovides host-based, two-way network traffic filtering, blocking unauthorized traffic flowing into or out of the local device based on the types of networks to which the device is connected. Windows Firewall reduces the attack surface of a device with rules to restrict or allow traffic by many properties such as IP addresses, ports, or program paths. Reducing the attack surface of a device increases manageability and decreases the likelihood of a successful attack.
With its integration with Internet Protocol Security (IPsec), Windows Firewall provides a simple way to enforce authenticated, end-to-end network communications. It provides scalable, tiered access to trusted network resources, helping to enforce integrity of the data, and optionally helping to protect the confidentiality of the data. Windows Firewall is a host-based firewall that is included with the operating system, there is no additional hardware or software required. Windows Firewall is also designed to complement existing non-Microsoft network security solutions through a documented application programming interface (API). |
-| **[Virtual private network (VPN)](/windows/security/identity-protection/vpn/vpn-guide)** | The Windows VPN client platform includes built in VPN protocols, configuration support, a common VPN user interface, and programming support for custom VPN protocols. VPN apps are available in the Microsoft Store for both enterprise and consumer VPNs, including apps for the most popular enterprise VPN gateways.
In Windows 11, the most commonly used VPN controls are integrated right into the Quick Actions pane. From the Quick Actions pane, users can see the status of their VPN, start and stop the VPN tunnels, and access the Settings app for more controls. |
-| **[Always On VPN (device tunnel)](/windows-server/remote/remote-access/vpn/always-on-vpn/)** | With Always On VPN, you can create a dedicated VPN profile for the device. Unlike User Tunnel, which only connects after a user logs on to the device, Device Tunnel allows the VPN to establish connectivity before a user sign-in. Both Device Tunnel and User Tunnel operate independently with their VPN profiles, can be connected at the same time, and can use different authentication methods and other VPN configuration settings as appropriate. |
+| **[Windows Firewall](/windows/security/operating-system-security/network-security/windows-firewall/windows-firewall-with-advanced-security)** | Windows Firewall with Advanced Securityprovides host-based, two-way network traffic filtering, blocking unauthorized traffic flowing into or out of the local device based on the types of networks to which the device is connected. Windows Firewall reduces the attack surface of a device with rules to restrict or allow traffic by many properties such as IP addresses, ports, or program paths. Reducing the attack surface of a device increases manageability and decreases the likelihood of a successful attack.
With its integration with Internet Protocol Security (IPsec), Windows Firewall provides a simple way to enforce authenticated, end-to-end network communications. It provides scalable, tiered access to trusted network resources, helping to enforce integrity of the data, and optionally helping to protect the confidentiality of the data. Windows Firewall is a host-based firewall that is included with the operating system, there is no additional hardware or software required. Windows Firewall is also designed to complement existing non-Microsoft network security solutions through a documented application programming interface (API). |
+| **[Virtual private network (VPN)](/windows/security/operating-system-security/network-security/vpn/vpn-guide)** | The Windows VPN client platform includes built in VPN protocols, configuration support, a common VPN user interface, and programming support for custom VPN protocols. VPN apps are available in the Microsoft Store for both enterprise and consumer VPNs, including apps for the most popular enterprise VPN gateways.
In Windows 11, the most commonly used VPN controls are integrated right into the Quick Actions pane. From the Quick Actions pane, users can see the status of their VPN, start and stop the VPN tunnels, and access the Settings app for more controls. |
+| **[Always On VPN (device tunnel)](/Windows-server/remote/remote-access/overview-always-on-vpn)** | With Always On VPN, you can create a dedicated VPN profile for the device. Unlike User Tunnel, which only connects after a user logs on to the device, Device Tunnel allows the VPN to establish connectivity before a user sign-in. Both Device Tunnel and User Tunnel operate independently with their VPN profiles, can be connected at the same time, and can use different authentication methods and other VPN configuration settings as appropriate. |
| **[Direct Access](/windows-server/remote/remote-access/directaccess/directaccess)** | DirectAccess allows connectivity for remote users to organization network resources without the need for traditional Virtual Private Network (VPN) connections.
With DirectAccess connections, remote devices are always connected to the organization and there's no need for remote users to start and stop connections. |
| **[Server Message Block (SMB) file service](/windows-server/storage/file-server/file-server-smb-overview)** | SMB Encryption provides end-to-end encryption of SMB data and protects data from eavesdropping occurrences on internal networks. In Windows 11, the SMB protocol has significant security updates, including AES-256 bits encryption, accelerated SMB signing, Remote Directory Memory Access (RDMA) network encryption, and SMB over QUIC for untrusted networks. Windows 11 introduces AES-256-GCM and AES-256-CCM cryptographic suites for SMB 3.1.1 encryption. Windows administrators can mandate the use of more advanced security or continue to use the more compatible, and still-safe, AES-128 encryption. |
| **[Server Message Block Direct (SMB Direct)](/windows-server/storage/file-server/smb-direct)** | SMB Direct (SMB over remote direct memory access) is a storage protocol that enables direct memory-to-memory data transfers between device and storage, with minimal CPU usage, while using standard RDMA-capable network adapters.
SMB Direct supports encryption, and now you can operate with the same safety as traditional TCP and the performance of RDMA. Previously, enabling SMB encryption disabled direct data placement, making RDMA as slow as TCP. Now data is encrypted before placement, leading to relatively minor performance degradation while adding AES-128 and AES-256 protected packet privacy. |
@@ -46,8 +48,8 @@ ms.topic: include
| Feature name | Description |
|:---|:---|
-| **[BitLocker management](/windows/security/information-protection/bitlocker/bitlocker-management-for-enterprises)** | The BitLocker CSP allows an MDM solution, like Microsoft Intune, to manage the BitLocker encryption features on Windows devices. This includes OS volumes, fixed drives and removeable storage, and recovery key management into Azure AD. |
-| **[BitLocker enablement](/windows/security/information-protection/bitlocker/bitlocker-overview)** | BitLocker Drive Encryption is a data protection feature that integrates with the operating system and addresses the threats of data theft or exposure from lost, stolen, or inappropriately decommissioned computers. BitLocker uses AES algorithm in XTS or CBC mode of operation with 128-bit or 256-bit key length to encrypt data on the volume. Cloud storage on Microsoft OneDrive or Azure can be used to save recovery key content. BitLocker can be managed by any MDM solution such as Microsoft Intune, using a configuration service provider (CSP).
BitLocker provides encryption for the OS, fixed data, and removable data drives leveraging technologies like hardware security test interface (HSTI), Modern Standby, UEFI Secure Boot and TPM. |
-| **[Encrypted hard drive](/windows/security/information-protection/encrypted-hard-drive)** | Encrypted hard drives are a class of hard drives that are self-encrypted at the hardware level and allow for full disk hardware encryption while being transparent to the device user. These drives combine the security and management benefits provided by BitLocker Drive Encryption with the power of self-encrypting drives.
By offloading the cryptographic operations to hardware, encrypted hard drives increase BitLocker performance and reduce CPU usage and power consumption. Because encrypted hard drives encrypt data quickly, BitLocker deployment can be expanded across enterprise devices with little to no impact on productivity. |
-| **[Personal data encryption (PDE)](/windows/security/information-protection/personal-data-encryption/overview-pde)** | Personal data encryption (PDE) works with BitLocker and Windows Hello for Business to further protect user documents and other files, including when the device is turned on and locked. Files are encrypted automatically and seamlessly to give users more security without interrupting their workflow.
Windows Hello for Business is used to protect the container which houses the encryption keys used by PDE. When the user signs in, the container gets authenticated to release the keys in the container to decrypt user content. |
-| **[Email Encryption (S/MIME)](/windows/security/identity-protection/configure-s-mime)** | Email encryption enables users to encrypt outgoing email messages and attachments, so only intended recipients with a digital ID (certificate) can read them. Users can digitally sign a message, which verifies the identity of the sender and confirms the message has not been tampered with. The encrypted messages can be sent by a user to other users within their organization or external contacts if they have proper encryption certificates. |
+| **[BitLocker management](/windows/security/operating-system-security/data-protection/bitlocker/bitlocker-management-for-enterprises)** | The BitLocker CSP allows an MDM solution, like Microsoft Intune, to manage the BitLocker encryption features on Windows devices. This includes OS volumes, fixed drives and removeable storage, and recovery key management into Microsoft Entra ID. |
+| **[BitLocker enablement](/windows/security/operating-system-security/data-protection/bitlocker/)** | BitLocker Drive Encryption is a data protection feature that integrates with the operating system and addresses the threats of data theft or exposure from lost, stolen, or inappropriately decommissioned computers. BitLocker uses AES algorithm in XTS or CBC mode of operation with 128-bit or 256-bit key length to encrypt data on the volume. Cloud storage on Microsoft OneDrive or Azure can be used to save recovery key content. BitLocker can be managed by any MDM solution such as Microsoft Intune, using a configuration service provider (CSP).
BitLocker provides encryption for the OS, fixed data, and removable data drives leveraging technologies like hardware security test interface (HSTI), Modern Standby, UEFI Secure Boot and TPM. |
+| **[Encrypted hard drive](/windows/security/operating-system-security/data-protection/encrypted-hard-drive)** | Encrypted hard drives are a class of hard drives that are self-encrypted at the hardware level and allow for full disk hardware encryption while being transparent to the device user. These drives combine the security and management benefits provided by BitLocker Drive Encryption with the power of self-encrypting drives.
By offloading the cryptographic operations to hardware, encrypted hard drives increase BitLocker performance and reduce CPU usage and power consumption. Because encrypted hard drives encrypt data quickly, BitLocker deployment can be expanded across enterprise devices with little to no impact on productivity. |
+| **[Personal data encryption (PDE)](/windows/security/operating-system-security/data-protection/personal-data-encryption/)** | Personal data encryption (PDE) works with BitLocker and Windows Hello for Business to further protect user documents and other files, including when the device is turned on and locked. Files are encrypted automatically and seamlessly to give users more security without interrupting their workflow.
Windows Hello for Business is used to protect the container which houses the encryption keys used by PDE. When the user signs in, the container gets authenticated to release the keys in the container to decrypt user content. |
+| **[Email Encryption (S/MIME)](/windows/security/operating-system-security/data-protection/configure-s-mime)** | Email encryption enables users to encrypt outgoing email messages and attachments, so only intended recipients with a digital ID (certificate) can read them. Users can digitally sign a message, which verifies the identity of the sender and confirms the message has not been tampered with. The encrypted messages can be sent by a user to other users within their organization or external contacts if they have proper encryption certificates. |
diff --git a/windows/security/includes/sections/security-foundations.md b/windows/security/includes/sections/security-foundations.md
index 61eb75d6e8..7a85af0543 100644
--- a/windows/security/includes/sections/security-foundations.md
+++ b/windows/security/includes/sections/security-foundations.md
@@ -1,7 +1,7 @@
---
author: paolomatarazzo
ms.author: paoloma
-ms.date: 08/02/2023
+ms.date: 09/18/2023
ms.topic: include
---
@@ -11,14 +11,14 @@ ms.topic: include
|:---|:---|
| **[Microsoft Security Development Lifecycle (SDL)](/windows/security/security-foundations/msft-security-dev-lifecycle)** | The Microsoft Security Development Lifecycle (SDL) introduces security best practices, tools, and processes throughout all phases of engineering and development. |
| **[OneFuzz service](https://www.microsoft.com/security/blog/2020/09/15/microsoft-onefuzz-framework-open-source-developer-tool-fix-bugs/)** | A range of tools and techniques - such as threat modeling, static analysis, fuzz testing, and code quality checks - enable continued security value to be embedded into Windows by every engineer on the team from day one. Through the SDL practices, Microsoft engineers are continuously provided with actionable and up-to-date methods to improve development workflows and overall product security before the code has been released. |
-| **[Microsoft Windows Insider Preview bounty program](https://www.microsoft.com/msrc/bounty-windows-insider-preview)** | As part of our secure development process, the Microsoft Windows Insider Preview bounty program invites eligible researchers across the globe to find and submit vulnerabilities that reproduce in the latest Windows Insider Preview (WIP) Dev Channel. The goal of the Windows Insider Preview bounty program is to uncover significant vulnerabilities that have a direct and demonstrable impact on the security of customers using the latest version of Windows.
Through this collaboration with researchers across the globe, our teams identify critical vulnerabilities that were not previously found during development and quickly fix the issues before releasing the final Windows. |
+| **[Microsoft Windows Insider Preview bounty program](https://www.microsoft.com/msrc/bounty-windows-insider-preview)** | As part of our secure development process, the Microsoft Windows Insider Preview bounty program invites eligible researchers across the globe to find and submit vulnerabilities that reproduce in the latest Windows Insider Preview (WIP) Dev Channel. The goal of the Windows Insider Preview bounty program is to uncover significant vulnerabilities that have a direct and demonstrable impact on the security of customers using the latest version of Windows.
Through this collaboration with researchers across the globe, our teams identify critical vulnerabilities that were not previously found during development and quicky fix the issues before releasing the final Windows. |
## Certification
| Feature name | Description |
|:---|:---|
-| **[Common Criteria certifications](/windows/security/threat-protection/windows-platform-common-criteria)** | Common Criteria (CC) is an international standard currently maintained by national governments who participate in the Common Criteria Recognition Arrangement. CC defines a common taxonomy for security functional requirements, security assurance requirements, and an evaluation methodology used to ensure products undergoing evaluation satisfy the functional and assurance requirements. Microsoft ensures that products incorporate the features and functions required by relevant Common Criteria Protection Profiles and completes Common Criteria certifications of Microsoft Windows products. |
-| **[Federal Information Processing Standard (FIPS) 140 validation](/windows/security/threat-protection/fips-140-validation)** | The Federal Information Processing Standard (FIPS) Publication 140 is a U.S. government standard that defines the minimum security requirements for cryptographic modules in IT products. Microsoft maintains an active commitment to meeting the requirements of the FIPS 140 standard, having validated cryptographic modules against FIPS 140-2 since it was first established in 2001. Multiple Microsoft products, including Windows 11, Windows 10, Windows Server, and many cloud services, use these cryptographic modules. |
+| **[Common Criteria certifications](/windows/security/security-foundations/certification/windows-platform-common-criteria)** | Common Criteria (CC) is an international standard currently maintained by national governments who participate in the Common Criteria Recognition Arrangement. CC defines a common taxonomy for security functional requirements, security assurance requirements, and an evaluation methodology used to ensure products undergoing evaluation satisfy the functional and assurance requirements. Microsoft ensures that products incorporate the features and functions required by relevant Common Criteria Protection Profiles and completes Common Criteria certifications of Microsoft Windows products. |
+| **[Federal Information Processing Standard (FIPS) 140 validation](/windows/security/security-foundations/certification/fips-140-validation)** | The Federal Information Processing Standard (FIPS) Publication 140 is a U.S. government standard that defines the minimum security requirements for cryptographic modules in IT products. Microsoft maintains an active commitment to meeting the requirements of the FIPS 140 standard, having validated cryptographic modules against FIPS 140-2 since it was first established in 2001. Multiple Microsoft products, including Windows 11, Windows 10, Windows Server, and many cloud services, use these cryptographic modules. |
## Secure supply chain
@@ -26,4 +26,4 @@ ms.topic: include
|:---|:---|
| **Software Bill of Materials (SBOM)** | SBOMs are leveraged to provide the transparency and provenance of the content as it moves through various stages of the Windows supply chain. This enables trust between each supply chain segment, ensures that tampering has not taken place during ingestion and along the way, and provides a provable chain of custody for the product that we ship to customers. |
| **[Azure Code Signing](/windows/security/application-security/application-control/windows-defender-application-control/deployment/use-code-signing-for-better-control-and-protection)** | Windows Defender Application Control (WDAC) enables customers to define policies for controlling what is allowed to run on their devices. WDAC policies can be remotely applied to devices using an MDM solution like Microsoft Intune.
To simplify WDAC enablement, organizations can take advantage of Azure Code Signing, a secure and fully managed service for signing WDAC policies and apps.
Azure Code Signing minimizes the complexity of code signing with a turnkey service backed by a Microsoft managed certificate authority, eliminating the need to procure and self-manage any signing certificates. The service is managed just as any other Azure resource and integrates easily with the leading development and CI/CD toolsets. |
-| **[Windows application software development kit (SDK)](https://developer.microsoft.com/windows/downloads/windows-sdk/)** | Developers have an opportunity to design highly secure applications that benefit from the latest Windows safeguards. The Windows App SDK provides a unified set of APIs and tools for developing secure desktop apps for Windows. To help create apps that are up-to-date and protected, the SDK follows the same security standards, protocols, and compliance as the core Windows operating system. |
+| **[Windows application software development kit (SDK)](https://developer.microsoft.com/windows/downloads/windows-sdk/)** | Developers have an opportunity to design highly secure applications that benefit from the latest Windows safeguards. The Windows App SDK provides a unified set of APIs and tools for developing secure desktop apps for Windows. To help create apps that are up-to-date and protected, the SDK follows the same security standards, protocols, and compliance as the core Windows operating system. |
diff --git a/windows/security/index.yml b/windows/security/index.yml
index fcb82babda..40983d837f 100644
--- a/windows/security/index.yml
+++ b/windows/security/index.yml
@@ -7,13 +7,14 @@ brand: windows
metadata:
ms.topic: hub-page
ms.prod: windows-client
+ ms.technology: itpro-security
ms.collection:
- highpri
- tier1
author: paolomatarazzo
ms.author: paoloma
manager: aaroncz
- ms.date: 08/11/2023
+ ms.date: 09/18/2023
highlightedContent:
items:
@@ -72,14 +73,14 @@ productDirectory:
links:
- url: /windows/security/identity-protection/hello-for-business
text: Windows Hello for Business
- - url: /windows/security/identity-protection/credential-guard/credential-guard
- text: Windows Defender Credential Guard
- - url: /windows-server/identity/laps/laps-overview
- text: Windows LAPS (Local Administrator Password Solution)
+ - url: /windows/security/identity-protection/passwordless-experience
+ text: Windows passwordless experience
+ - url: /windows/security/identity-protection/web-sign-in
+ text: Web sign-in for Windows
+ - url: /windows/security/identity-protection/passkeys
+ text: Support for passkeys in Windows
- url: /windows/security/operating-system-security/virus-and-threat-protection/microsoft-defender-smartscreen/enhanced-phishing-protection
text: Enhanced phishing protection with SmartScreen
- - url: /education/windows/federated-sign-in
- text: Federated sign-in (EDU)
- url: /windows/security/identity-protection
text: Learn more about identity protection >
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 a87668dc0e..92105b512d 100644
--- a/windows/security/introduction.md
+++ b/windows/security/introduction.md
@@ -1,7 +1,7 @@
---
title: Introduction to Windows security
description: System security book.
-ms.date: 08/01/2023
+ms.date: 09/01/2023
ms.topic: tutorial
ms.author: paoloma
content_well_notification:
@@ -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 enable 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
@@ -45,11 +45,11 @@ In Windows 11, [Microsoft Defender Application Guard](/windows-hardware/design/d
### Secured identities
-Passwords have been an important part of digital security for a long time, and they're also a top target for cybercriminals. Windows 11 provides powerful protection against credential theft with chip-level hardware security. Credentials are protected by layers of hardware and software security such as [TPM 2.0](information-protection/tpm/trusted-platform-module-overview.md), [VBS](/windows-hardware/design/device-experiences/oem-vbs), and/or [Windows Defender Credential Guard](identity-protection/credential-guard/credential-guard.md), making it harder for attackers to steal credentials from a device. With [Windows Hello for Business](identity-protection/hello-for-business/index.md), users can quickly sign in with face, fingerprint, or PIN for passwordless protection. Windows 11 also supports [FIDO2 security keys](/azure/active-directory/authentication/howto-authentication-passwordless-security-key) for passwordless authentication.
+Passwords have been an important part of digital security for a long time, and they're also a top target for cybercriminals. Windows 11 provides powerful protection against credential theft with chip-level hardware security. Credentials are protected by layers of hardware and software security such as [TPM 2.0](information-protection/tpm/trusted-platform-module-overview.md), [VBS](/windows-hardware/design/device-experiences/oem-vbs), and/or [Credential Guard](identity-protection/credential-guard/index.md), making it harder for attackers to steal credentials from a device. With [Windows Hello for Business](identity-protection/hello-for-business/index.md), users can quickly sign in with face, fingerprint, or PIN for passwordless protection. Windows 11 also supports [FIDO2 security keys](/azure/active-directory/authentication/howto-authentication-passwordless-security-key) for passwordless authentication.
### 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/bitlocker/index.md b/windows/security/operating-system-security/data-protection/bitlocker/index.md
index 2464ef0104..3faff60393 100644
--- a/windows/security/operating-system-security/data-protection/bitlocker/index.md
+++ b/windows/security/operating-system-security/data-protection/bitlocker/index.md
@@ -13,7 +13,7 @@ ms.date: 08/03/2023
Bitlocker is a Windows disk encryption feature, designed to protect data by providing encryption for entire volumes.\
BitLocker addresses the threats of data theft or exposure from lost, stolen, or inappropriately decommissioned devices.
-BitLocker provides maximum protection when used with a Trusted Platform Module (TPM). A TPM is a hardware component installed in many devices ant it works with BitLocker to help protect user data and to ensure that a computer hasn't been tampered with while the system is offline.
+BitLocker provides maximum protection when used with a Trusted Platform Module (TPM). A TPM is a hardware component installed in many devices and it works with BitLocker to help protect user data and to ensure that a computer hasn't been tampered with while the system is offline.
On devices that don't have a TPM, BitLocker can still be used to encrypt the Windows operating system drive. However, this implementation requires the user to insert a USB startup key to start the device or resume from hibernation. An operating system volume password can be used to protect the operating system volume on a computer without TPM. Both options don't provide the pre-startup system integrity verification offered by BitLocker with a TPM.
diff --git a/windows/security/operating-system-security/data-protection/personal-data-encryption/configure-pde-in-intune.md b/windows/security/operating-system-security/data-protection/personal-data-encryption/configure-pde-in-intune.md
deleted file mode 100644
index fe2fb5b3e9..0000000000
--- a/windows/security/operating-system-security/data-protection/personal-data-encryption/configure-pde-in-intune.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-title: Configure Personal Data Encryption (PDE) in Intune
-description: Configuring and enabling Personal Data Encryption (PDE) required and recommended policies in Intune
-ms.topic: how-to
-ms.date: 03/13/2023
----
-
-
-
-
-# Configure Personal Data Encryption (PDE) policies in Intune
-
-The various required and recommended policies needed for Personal Data Encryption (PDE) can be configured in Intune. The following links for both required and recommended policies contain step by step instructions on how to configure these policies in Intune.
-
-## Required prerequisites
-
-1. [Enable Personal Data Encryption (PDE)](intune-enable-pde.md)
-1. [Disable Winlogon automatic restart sign-on (ARSO)](intune-disable-arso.md)
-
-## Security hardening recommendations
-
-1. [Disable kernel-mode crash dumps and live dumps](intune-disable-memory-dumps.md)
-1. [Disable Windows Error Reporting (WER)/user-mode crash dumps](intune-disable-wer.md)
-1. [Disable hibernation](intune-disable-hibernation.md)
-1. [Disable allowing users to select when a password is required when resuming from connected standby](intune-disable-password-connected-standby.md)
-
-## See also
-
-- [Personal Data Encryption (PDE)](index.md)
-- [Personal Data Encryption (PDE) FAQ](faq-pde.yml)
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
new file mode 100644
index 0000000000..dc6e715410
--- /dev/null
+++ b/windows/security/operating-system-security/data-protection/personal-data-encryption/configure.md
@@ -0,0 +1,141 @@
+---
+title: PDE settings and configuration
+description: Learn about the available options to configure Personal Data Encryption (PDE) and how to configure them via Microsoft Intune or Configuration Service Providers (CSP).
+ms.topic: how-to
+ms.date: 08/11/2023
+---
+
+# PDE settings and configuration
+
+This article describes the Personal Data Encryption (PDE) settings and how to configure them via Microsoft Intune or Configuration Service Providers (CSP).
+
+> [!NOTE]
+> PDE can be configured using MDM policies. The content to be protected by PDE can be specified using [PDE APIs](/uwp/api/windows.security.dataprotection.userdataprotectionmanager). There is no user interface in Windows to either enable PDE or protect content using PDE.
+>
+> The PDE APIs can be used to create custom applications and scripts to specify which content to protect and at what level to protect the content. Additionally, the PDE APIs can't be used to protect content until the PDE policy has been enabled.
+
+## PDE settings
+
+The following table lists the required settings to enable PDE.
+
+| Setting name | Description |
+|-|-|
+|Enable Personal Data Encryption|PDE isn't enabled by default. Before PDE can be used, you must enable it.|
+|Sign-in and lock last interactive user automatically after a restart| Winlogon automatic restart sign-on (ARSO) isn't supported for use with PDE. To use PDE, ARSO must be disabled.|
+
+## PDE hardening recommendations
+
+The following table lists the recommended settings to improve PDE's security.
+
+| Setting name | Description |
+|-|-|
+|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 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
+
+[!INCLUDE [intune-settings-catalog-1](../../../../../includes/configure/intune-settings-catalog-1.md)]
+
+| Category | Setting name | Value |
+|--|--|--|
+|**PDE**|Enable Personal Data Encryption (User)|Enable Personal Data Encryption|
+|**Administrative Templates > Windows Components > Windows Logon Options**|Sign-in and lock last interactive user automatically after a restart|Disabled|
+|**Memory Dump**|Allow Live Dump|Block|
+|**Memory Dump**|Allow Crash Dump|Block|
+|**Administrative Templates > Windows Components > Windows Error Reporting** | Disable Windows Error Reporting | Enabled|
+|**Power**|Allow Hibernate|Block|
+|**Administrative Templates > System > Logon** | Allow users to select when a password is required when resuming from connected standby | Disabled|
+
+[!INCLUDE [intune-settings-catalog-2](../../../../../includes/configure/intune-settings-catalog-2.md)]
+
+> [!TIP]
+> Use the following Graph call to automatically create the settings catalog policy in your tenant without assignments nor scope tags.
+>
+> When using this call, authenticate to your tenant in the Graph Explorer window. If it's the first time using Graph Explorer, you may need to authorize the application to access your tenant or to modify the existing permissions. This graph call requires *DeviceManagementConfiguration.ReadWrite.All* permissions.
+
+```msgraph-interactive
+POST https://graph.microsoft.com/beta/deviceManagement/configurationPolicies
+Content-Type: application/json
+
+{ "id": "00-0000-0000-0000-000000000000", "name": "_MSLearn_PDE", "description": "", "platforms": "windows10", "technologies": "mdm", "roleScopeTagIds": [ "0" ], "settings": [ { "@odata.type": "#microsoft.graph.deviceManagementConfigurationSetting", "settingInstance": { "@odata.type": "#microsoft.graph.deviceManagementConfigurationChoiceSettingInstance", "settingDefinitionId": "device_vendor_msft_policy_config_admx_credentialproviders_allowdomaindelaylock", "choiceSettingValue": { "@odata.type": "#microsoft.graph.deviceManagementConfigurationChoiceSettingValue", "value": "device_vendor_msft_policy_config_admx_credentialproviders_allowdomaindelaylock_0", "children": [] } } }, { "@odata.type": "#microsoft.graph.deviceManagementConfigurationSetting", "settingInstance": { "@odata.type": "#microsoft.graph.deviceManagementConfigurationChoiceSettingInstance", "settingDefinitionId": "device_vendor_msft_policy_config_errorreporting_disablewindowserrorreporting", "choiceSettingValue": { "@odata.type": "#microsoft.graph.deviceManagementConfigurationChoiceSettingValue", "value": "device_vendor_msft_policy_config_errorreporting_disablewindowserrorreporting_1", "children": [] } } }, { "@odata.type": "#microsoft.graph.deviceManagementConfigurationSetting", "settingInstance": { "@odata.type": "#microsoft.graph.deviceManagementConfigurationChoiceSettingInstance", "settingDefinitionId": "device_vendor_msft_policy_config_windowslogon_allowautomaticrestartsignon", "choiceSettingValue": { "@odata.type": "#microsoft.graph.deviceManagementConfigurationChoiceSettingValue", "value": "device_vendor_msft_policy_config_windowslogon_allowautomaticrestartsignon_0", "children": [] } } }, { "@odata.type": "#microsoft.graph.deviceManagementConfigurationSetting", "settingInstance": { "@odata.type": "#microsoft.graph.deviceManagementConfigurationChoiceSettingInstance", "settingDefinitionId": "device_vendor_msft_policy_config_memorydump_allowcrashdump", "choiceSettingValue": { "@odata.type": "#microsoft.graph.deviceManagementConfigurationChoiceSettingValue", "value": "device_vendor_msft_policy_config_memorydump_allowcrashdump_0", "children": [] } } }, { "@odata.type": "#microsoft.graph.deviceManagementConfigurationSetting", "settingInstance": { "@odata.type": "#microsoft.graph.deviceManagementConfigurationChoiceSettingInstance", "settingDefinitionId": "device_vendor_msft_policy_config_memorydump_allowlivedump", "choiceSettingValue": { "@odata.type": "#microsoft.graph.deviceManagementConfigurationChoiceSettingValue", "value": "device_vendor_msft_policy_config_memorydump_allowlivedump_0", "children": [] } } }, { "@odata.type": "#microsoft.graph.deviceManagementConfigurationSetting", "settingInstance": { "@odata.type": "#microsoft.graph.deviceManagementConfigurationChoiceSettingInstance", "settingDefinitionId": "user_vendor_msft_pde_enablepersonaldataencryption", "choiceSettingValue": { "@odata.type": "#microsoft.graph.deviceManagementConfigurationChoiceSettingValue", "value": "user_vendor_msft_pde_enablepersonaldataencryption_1", "children": [] } } }, { "@odata.type": "#microsoft.graph.deviceManagementConfigurationSetting", "settingInstance": { "@odata.type": "#microsoft.graph.deviceManagementConfigurationChoiceSettingInstance", "settingDefinitionId": "device_vendor_msft_policy_config_power_allowhibernate", "choiceSettingValue": { "@odata.type": "#microsoft.graph.deviceManagementConfigurationChoiceSettingValue", "value": "device_vendor_msft_policy_config_power_allowhibernate_0", "children": [] } } } ] }
+```
+
+## Configure PDE with CSP
+
+Alternatively, you can configure devices using the [Policy CSP][CSP-1] and [PDE CSP][CSP-2].
+
+|OMA-URI|Format|Value|
+|-|-|-|
+|`./User/Vendor/MSFT/PDE/EnablePersonalDataEncryption`|int|`1`|
+|`./Device/Vendor/MSFT/Policy/Config/WindowsLogon/AllowAutomaticRestartSignOn`|string|`
If the domain controllers require smart card EKU either:
Otherwise:
|
+| 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:
If the domain controllers require smart card EKU either:
Otherwise:
|
## 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 \
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/virus-and-threat-protection/microsoft-defender-smartscreen/enhanced-phishing-protection.md b/windows/security/operating-system-security/virus-and-threat-protection/microsoft-defender-smartscreen/enhanced-phishing-protection.md
index a16db47b99..38961897cb 100644
--- a/windows/security/operating-system-security/virus-and-threat-protection/microsoft-defender-smartscreen/enhanced-phishing-protection.md
+++ b/windows/security/operating-system-security/virus-and-threat-protection/microsoft-defender-smartscreen/enhanced-phishing-protection.md
@@ -1,7 +1,7 @@
---
title: Enhanced Phishing Protection in Microsoft Defender SmartScreen
description: Learn how Enhanced Phishing Protection for Microsoft Defender SmartScreen helps protect Microsoft school or work passwords against phishing and unsafe usage on sites and apps.
-ms.date: 08/11/2023
+ms.date: 09/25/2023
ms.topic: conceptual
appliesto:
- ✅ Windows 11, version 22H2
@@ -13,9 +13,10 @@ Starting in Windows 11, version 22H2, Enhanced Phishing Protection in Microsoft
If a user signs into Windows using a password, Enhanced Phishing Protection works alongside Windows security protections, and helps protect typed work or school password used to sign into Windows 11 in these ways:
-- If users type their work or school password on any Chromium browser, into a site deemed malicious by Microsoft Defender SmartScreen, Enhanced Phishing Protection alerts them. It also alerts them to change their password so attackers can't gain access to their account.
+- If users type or paste their work or school password on any browser, into a site deemed malicious by Microsoft Defender SmartScreen, Enhanced Phishing Protection alerts them. It also alerts them to change their password so attackers can't gain access to their account.
- Reusing work or school passwords makes it easy for attackers who compromise a user's password to gain access to their other accounts. Enhanced Phishing Protection can warn users if they reuse their work or school Microsoft account password on sites and apps and alert them to change their password.
- Since it's unsafe to store plaintext passwords in text editors, Enhanced Phishing Protection can warn users if they store their work or school password in Notepad, Word, or any Microsoft 365 Office app, and recommends they delete their password from the file.
+- If users type their work or school password into a website or app that SmartScreen finds suspicious, Enhanced Phishing Protection can automatically collect information from that website or app to help identify security threats. For example, the content displayed, sounds played, and application memory.
> [!NOTE]
> When a user signs-in to a device using a Windows Hello for Business PIN or biometric, Enhanced Phishing Protection does not alert the user or send events to Microsoft Defender for Endpoint.
@@ -68,10 +69,11 @@ Enhanced Phishing Protection can be configured using the [WebThreatDefense CSP][
| Setting | OMA-URI | Data type |
|-------------------------|---------------------------------------------------------------------------|-----------|
-| **ServiceEnabled** | `./Device/Vendor/MSFT/Policy/Config/WebThreatDefense/ServiceEnabled` | Integer |
+| **AutomaticDataCollection** | `./Device/Vendor/MSFT/Policy/Config/WebThreatDefense/AutomaticDataCollection` | Integer |
| **NotifyMalicious** | `./Device/Vendor/MSFT/Policy/Config/WebThreatDefense/NotifyMalicious` | Integer |
| **NotifyPasswordReuse** | `./Device/Vendor/MSFT/Policy/Config/WebThreatDefense/NotifyPasswordReuse` | Integer |
| **NotifyUnsafeApp** | `./Device/Vendor/MSFT/Policy/Config/WebThreatDefense/NotifyUnsafeApp` | Integer |
+| **ServiceEnabled** | `./Device/Vendor/MSFT/Policy/Config/WebThreatDefense/ServiceEnabled` | Integer |
---
@@ -80,7 +82,6 @@ Enhanced Phishing Protection can be configured using the [WebThreatDefense CSP][
By default, Enhanced Phishing Protection is deployed in audit mode, preventing notifications to the users for any protection scenarios. In audit mode, Enhanced Phishing Protection captures unsafe password entry events and sends diagnostic data through Microsoft Defender. Users aren't warned if they enter their work or school password into a phishing site, if they reuse their password, or if they unsafely store their password in applications. Because of this possibility, it's recommended that you configure Enhanced Phishing Protection to warn users during all protection scenarios.
To better help you protect your organization, we recommend turning on and using these specific Microsoft Defender SmartScreen settings.
-
#### [:::image type="icon" source="images/icons/intune.svg"::: **Intune**](#tab/intune)
|Settings catalog element|Recommendation|
@@ -108,15 +109,19 @@ To better help you protect your organization, we recommend turning on and using
|NotifyPasswordReuse|**1**: Turns on Enhanced Phishing Protection notifications when users reuse their work or school password and encourages them to change their password.|
|NotifyUnsafeApp|**1**: Turns on Enhanced Phishing Protection notifications when users type their work or school passwords in Notepad and Microsoft 365 Office Apps.|
+
---
## Related articles
-- [SmartScreen Frequently Asked Questions](https://fb.smartscreen.microsoft.com/smartscreenfaq.aspx)
+- [SmartScreen frequently asked questions](https://fb.smartscreen.microsoft.com/smartscreenfaq.aspx)
- [WebThreatDefense CSP][WIN-1]
- [Threat protection](index.md)
[WIN-1]: /windows/client-management/mdm/policy-csp-webthreatdefense
+
[MEM-2]: /mem/intune/configuration/settings-catalog
+
+
diff --git a/windows/security/security-foundations/certification/fips-140-validation.md b/windows/security/security-foundations/certification/fips-140-validation.md
index d34c1295ff..1cb3c7c91f 100644
--- a/windows/security/security-foundations/certification/fips-140-validation.md
+++ b/windows/security/security-foundations/certification/fips-140-validation.md
@@ -2,14 +2,14 @@
title: Federal Information Processing Standard (FIPS) 140 Validation
description: Learn how Microsoft products and cryptographic modules follow the U.S. Federal government standard FIPS 140.
ms.prod: windows-client
-ms.date: 11/03/2022
+ms.date: 08/18/2023
manager: aaroncz
ms.author: paoloma
author: paolomatarazzo
ms.collection:
- highpri
- tier3
-ms.topic: article
+ms.topic: reference
ms.localizationpriority: medium
ms.reviewer:
ms.technology: itpro-security
diff --git a/windows/security/security-foundations/certification/windows-platform-common-criteria.md b/windows/security/security-foundations/certification/windows-platform-common-criteria.md
index c79a189b61..0f426874c2 100644
--- a/windows/security/security-foundations/certification/windows-platform-common-criteria.md
+++ b/windows/security/security-foundations/certification/windows-platform-common-criteria.md
@@ -5,7 +5,7 @@ ms.prod: windows-client
ms.author: sushmanemali
author: s4sush
manager: aaroncz
-ms.topic: article
+ms.topic: reference
ms.localizationpriority: medium
ms.date: 11/4/2022
ms.reviewer: paoloma
@@ -278,10 +278,6 @@ Certified against the Protection Profile for General Purpose Operating Systems.
### Windows Server 2003 Certificate Server
- [Security Target](https://www.commoncriteriaportal.org/files/epfiles/st_vid9507-st.pdf)
-- [Administrator's Guide](https://www.microsoft.com/downloads/en/details.aspx?familyid=445093d8-45e2-4cf6-884c-8802c1e6cb2d)
-- [Configuration Guide](https://www.microsoft.com/downloads/en/details.aspx?familyid=46abc8b5-11be-4e3d-85c2-63226c3688d2)
-- [User's Guide](https://www.microsoft.com/downloads/en/details.aspx?familyid=74f66d84-2654-48d0-b9b5-b383d383425e)
-- [Evaluation Technical Report](https://www.microsoft.com/downloads/details.aspx?familyid=a594e77f-dcbb-4787-9d68-e4689e60a314)
- [Validation Report](https://www.commoncriteriaportal.org/files/epfiles/st_vid9507-vr.pdf)
### Windows Rights Management Services
diff --git a/windows/security/security-foundations/index.md b/windows/security/security-foundations/index.md
index 52c893e6cb..0f47d591b2 100644
--- a/windows/security/security-foundations/index.md
+++ b/windows/security/security-foundations/index.md
@@ -1,7 +1,7 @@
---
title: Windows security foundations
description: Get an overview of security foundations, including the security development lifecycle, common criteria, and the bug bounty program.
-ms.topic: conceptual
+ms.topic: overview
ms.date: 06/15/2023
author: paolomatarazzo
ms.author: paoloma
diff --git a/windows/security/security-foundations/msft-security-dev-lifecycle.md b/windows/security/security-foundations/msft-security-dev-lifecycle.md
index 4f96b191e4..99fc260eb9 100644
--- a/windows/security/security-foundations/msft-security-dev-lifecycle.md
+++ b/windows/security/security-foundations/msft-security-dev-lifecycle.md
@@ -4,13 +4,13 @@ description: Download the Microsoft Security Development Lifecycle white paper t
author: paolomatarazzo
ms.author: paoloma
manager: aaroncz
-ms.topic: article
+ms.topic: conceptual
ms.date: 07/31/2023
---
# Microsoft Security Development Lifecycle
-The Security Development Lifecycle (SDL) is a security assurance process that is focused on software development. As a Microsoft-wide initiative and a mandatory policy since 2004, the SDL has played a critical role in embedding security and privacy in software and culture at Microsoft.
+The Security Development Lifecycle (SDL) is a security assurance process that is focused on software development. As a Microsoft-wide initiative and a mandatory policy since 2004, the SDL has played a critical role in embedding security and privacy in software and culture at Microsoft.
[:::image type="content" source="images/simplified-sdl.png" alt-text="Simplified secure development lifecycle":::](https://www.microsoft.com/en-us/securityengineering/sdl)
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/security/threat-protection/security-policy-settings/security-options.md b/windows/security/threat-protection/security-policy-settings/security-options.md
index a53ae544d8..39d6b0489e 100644
--- a/windows/security/threat-protection/security-policy-settings/security-options.md
+++ b/windows/security/threat-protection/security-policy-settings/security-options.md
@@ -108,7 +108,7 @@ For info about setting security policies, see [Configure security policy setting
| [Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers](network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers.md)| Describes the best practices, location, values, management aspects, and security considerations for the **Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers** security policy setting. |
| [Recovery console: Allow automatic administrative logon](recovery-console-allow-automatic-administrative-logon.md)| Describes the best practices, location, values, policy management, and security considerations for the **Recovery console: Allow automatic administrative logon** security policy setting. |
| [Recovery console: Allow floppy copy and access to all drives and folders](recovery-console-allow-floppy-copy-and-access-to-all-drives-and-folders.md)| Describes the best practices, location, values, policy management, and security considerations for the **Recovery console: Allow floppy copy and access to all drives and folders** security policy setting. |
-| [Shutdown: Allow system to be shut down without having to lg on](shutdown-allow-system-to-be-shut-down-without-having-to-log-on.md)| Describes the best practices, location, values, policy management, and security considerations for the **Shutdown: Allow system to be shut down without having to log on** security policy setting. |
+| [Shutdown: Allow system to be shut down without having to log on](shutdown-allow-system-to-be-shut-down-without-having-to-log-on.md)| Describes the best practices, location, values, policy management, and security considerations for the **Shutdown: Allow system to be shut down without having to log on** security policy setting. |
| [Shutdown: Clear virtual memory pagefile](shutdown-clear-virtual-memory-pagefile.md)| Describes the best practices, location, values, policy management, and security considerations for the **Shutdown: Clear virtual memory pagefile** security policy setting.|
| [System cryptography: Force strong key protection for user keys stored on the computer](system-cryptography-force-strong-key-protection-for-user-keys-stored-on-the-computer.md)| Describes the best practices, location, values, policy management, and security considerations for the **System cryptography: Force strong key protection for user keys stored on the computer** security policy setting. |
| [System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing](system-cryptography-use-fips-compliant-algorithms-for-encryption-hashing-and-signing.md)| This security policy reference topic for the IT professional describes the best practices, location, values, policy management, and security considerations for this policy setting. |
diff --git a/windows/whats-new/TOC.yml b/windows/whats-new/TOC.yml
index 2e144448b8..2bd556b46f 100644
--- a/windows/whats-new/TOC.yml
+++ b/windows/whats-new/TOC.yml
@@ -11,7 +11,7 @@
href: windows-11-plan.md
- name: Prepare for Windows 11
href: windows-11-prepare.md
- - name: Windows 11 temporary enterprise feature control
+ - name: Windows 11 enterprise feature control
href: temporary-enterprise-feature-control.md
- name: What's new in Windows 11, version 22H2
href: whats-new-windows-11-version-22h2.md
diff --git a/windows/whats-new/deprecated-features-resources.md b/windows/whats-new/deprecated-features-resources.md
index 3943ef84fc..6b07079c0f 100644
--- a/windows/whats-new/deprecated-features-resources.md
+++ b/windows/whats-new/deprecated-features-resources.md
@@ -1,7 +1,7 @@
---
title: Resources for deprecated features in the Windows client
description: Resources and details for deprecated features in the Windows client.
-ms.date: 08/01/2023
+ms.date: 10/09/2023
ms.prod: windows-client
ms.technology: itpro-fundamentals
ms.localizationpriority: medium
@@ -21,6 +21,10 @@ appliesto:
This article provides additional resources about [deprecated features for Windows client](deprecated-features.md) that may be needed by IT professionals. The following information is provided to help IT professionals plan for the removal of deprecated features:
+## VBScript
+
+VBScript will be available as a [feature on demand](/windows-hardware/manufacture/desktop/features-on-demand-v2--capabilities) before being retired in future Windows releases. Initially, the VBScript feature on demand will be preinstalled to allow for uninterrupted use while you prepare for the retirement of VBScript.
+
## TLS versions 1.0 and 1.1 disablement resources
Over the past several years, internet standards and regulatory bodies have [deprecated or disallowed](https://www.ietf.org/rfc/rfc8996.html) TLS versions 1.0 and 1.1 due to various security issues. Starting in Windows 11 Insider Preview builds for September 2023 and continuing in future Windows OS releases, TLS 1.0 and 1.1 are disabled by default. This change increases the security posture of Windows customers and encourages modern protocol adoption. For organizations that need to use these versions, there's an option to re-enable TLS 1.0 or TLS 1.1.
@@ -69,11 +73,11 @@ Re-enabling TLS 1.0 or TLS 1.1 on machines should only be done as a last resort,
The [Microsoft Support Diagnostic Tool (MSDT)](/windows-server/administration/windows-commands/msdt) gathers diagnostic data for analysis by support professionals. MSDT is the engine used to run legacy Windows built-in troubleshooters. There are currently 28 built-in troubleshooters for MSDT. Half of the built-in troubleshooters have already been [redirected](#redirected-msdt-troubleshooters) to the Get Help platform, while the other half will be [retired](#retired-msdt-troubleshooters).
-If you're using MSDT to run [custom troubleshooting packages](/previous-versions/windows/desktop/wintt/package-schema), it will be available as a [Feature on Demand](/windows-hardware/manufacture/desktop/features-on-demand-v2--capabilities) before the tool is fully retired in 2025. This change will allow you to continue to use MSDT to run custom troubleshooting packages while transitioning to a new platform. [Contact Microsoft support](https://support.microsoft.com/contactus) for Windows if you require additional assistance.
+If you're using MSDT to run [custom troubleshooting packages](/previous-versions/windows/desktop/wintt/package-schema), it will be available as a [feature on demand](/windows-hardware/manufacture/desktop/features-on-demand-v2--capabilities) before the tool is fully retired in 2025. This change allows you to continue to use MSDT to run custom troubleshooting packages while transitioning to a new platform. [Contact Microsoft support](https://support.microsoft.com/contactus) for Windows if you require more assistance.
### Redirected MSDT troubleshooters
-The following troubleshooters will automatically be redirected when you access them from **Start** > **Settings** > **System** > **Troubleshoot**:
+The following troubleshooters are automatically redirected when you access them from **Start** > **Settings** > **System** > **Troubleshoot**:
- Background Intelligent Transfer Service (BITS)
- Bluetooth
diff --git a/windows/whats-new/deprecated-features.md b/windows/whats-new/deprecated-features.md
index 5d0649468d..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 developing in Windows 10 and Windows 11.
-ms.date: 08/01/2023
+description: Review the list of features that Microsoft is no longer actively developing in Windows 10 and Windows 11.
+ms.date: 10/18/2023
ms.prod: windows-client
ms.technology: itpro-fundamentals
ms.localizationpriority: medium
@@ -36,6 +36,10 @@ 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 |
| TLS 1.0 and 1.1 | Over the past several years, internet standards and regulatory bodies have [deprecated or disallowed](https://www.ietf.org/rfc/rfc8996.html) TLS versions 1.0 and 1.1 due to various security issues. Starting in Windows 11 Insider Preview builds for September 2023 and continuing in future Windows OS releases, TLS 1.0 and 1.1 will be disabled by default. This change increases the security posture of Windows customers and encourages modern protocol adoption. For organizations that need to use these versions, there's an option to re-enable TLS 1.0 or TLS 1.1. For more information, see [Resources for deprecated features](deprecated-features-resources.md). | August 1, 2023|
| Cortana in Windows | Cortana in Windows as a standalone app is deprecated. This change only impacts Cortana in Windows, and your productivity assistant, Cortana, will continue to be available in Outlook mobile, Teams mobile, Microsoft Teams display, and Microsoft Teams rooms. | June 2023 |
| Microsoft Support Diagnostic Tool (MSDT) | [MSDT](/windows-server/administration/windows-commands/msdt) is deprecated and will be removed in a future release of Windows. MSDT is used to gather diagnostic data for analysis by support professionals. For more information, see [Resources for deprecated features](deprecated-features-resources.md) | January 2023 |
@@ -49,6 +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 |
| 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 |
@@ -59,7 +64,6 @@ The features in this article are no longer being actively developed, and might b
| Print 3D app | 3D Builder is the recommended 3D printing app. To 3D print objects on new Windows devices, customers must first install 3D Builder from the Store.| 1903 |
|Companion device dynamic lock APIS|The companion device framework (CDF) APIs enable wearables and other devices to unlock a PC. In Windows 10, version 1709, we introduced [Dynamic Lock](/windows/security/identity-protection/hello-for-business/hello-feature-dynamic-lock), including an inbox method using Bluetooth to detect whether a user is present and lock or unlock the PC. Because of this reason, and because non-Microsoft partners didn't adopt the CDF method, we're no longer developing CDF Dynamic Lock APIs.| 1809 |
|OneSync service|The OneSync service synchronizes data for the Mail, Calendar, and People apps. We've added a sync engine to the Outlook app that provides the same synchronization.| 1809 |
-|Snipping Tool|The Snipping Tool is an application included in Windows 10 that is used to capture screenshots, either the full screen or a smaller, custom "snip" of the screen. In Windows 10, version 1809, we're [introducing a new universal app, Snip & Sketch](https://blogs.windows.com/windowsexperience/2018/05/03/announcing-windows-10-insider-preview-build-17661/#8xbvP8vMO0lF20AM.97). It provides the same screen snipping abilities plus other features. You can launch Snip & Sketch directly and start a snip from there, or just press WIN + Shift + S. Snip & Sketch can also be launched from the "Screen snip" button in the Action Center. We're no longer developing the Snipping Tool as a separate app but are instead consolidating its functionality into Snip & Sketch.| 1809 |
|[Software Restriction Policies](/windows-server/identity/software-restriction-policies/software-restriction-policies) in Group Policy|Instead of using the Software Restriction Policies through Group Policy, you can use [AppLocker](/windows/security/threat-protection/applocker/applocker-overview) or [Windows Defender Application Control](/windows/security/threat-protection/windows-defender-application-control) to control which apps users can access and what code can run in the kernel.| 1803 |
|[Offline symbol packages](/windows-hardware/drivers/debugger/debugger-download-symbols) (Debug symbol MSIs)|We're no longer making the symbol packages available as a downloadable MSI. Instead, the [Microsoft Symbol Server is moving to be an Azure-based symbol store](/archive/blogs/windbg/update-on-microsofts-symbol-server). If you need the Windows symbols, connect to the Microsoft Symbol Server to cache your symbols locally or use a manifest file with SymChk.exe on a computer with internet access.| 1803 |
|Windows Help Viewer (WinHlp32.exe)|All Windows help information is [available online](https://support.microsoft.com/products/windows?os=windows-10). The Windows Help Viewer is no longer supported in Windows 10. For more information, see [Error opening Help in Windows-based programs: "Feature not included" or "Help not supported"](https://support.microsoft.com/topic/error-opening-help-in-windows-based-programs-feature-not-included-or-help-not-supported-3c841463-d67c-6062-0ee7-1a149da3973b).| 1803 |
@@ -89,3 +93,4 @@ The features in this article are no longer being actively developed, and might b
|`wusa.exe /uninstall /kb:####### /quiet`|The `wusa` tool usage to quietly uninstall an update has been deprecated. The uninstall command with `/quiet` switch fails with event ID 8 in the Setup event log. Uninstalling updates quietly could be a security risk because malicious software could quietly uninstall an update in the background without user intervention.|1507
Applies to Windows Server 2016 and Windows Server 2019.|
+
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/ltsc/whats-new-windows-10-2019.md b/windows/whats-new/ltsc/whats-new-windows-10-2019.md
index b2c710d264..99cf0f87aa 100644
--- a/windows/whats-new/ltsc/whats-new-windows-10-2019.md
+++ b/windows/whats-new/ltsc/whats-new-windows-10-2019.md
@@ -208,14 +208,14 @@ Windows Hello for Business now supports FIDO 2.0 authentication for Azure AD Joi
For more information, see: [Windows Hello and FIDO2 Security Keys enable secure and easy authentication for shared devices](https://blogs.windows.com/business/2018/04/17/windows-hello-fido2-security-keys/#OdKBg3pwJQcEKCbJ.97)
-#### Windows Defender Credential Guard
+#### Credential Guard
-Windows Defender Credential Guard is a security service in Windows 10 built to protect Active Directory (AD) domain credentials so that they can't be stolen or misused by malware on a user's machine. It's designed to protect against well-known threats such as Pass-the-Hash and credential harvesting.
+Credential Guard is a security service in Windows 10 built to protect Active Directory (AD) domain credentials so that they can't be stolen or misused by malware on a user's machine. It's designed to protect against well-known threats such as Pass-the-Hash and credential harvesting.
-Windows Defender Credential Guard has always been an optional feature, but Windows 10 in S mode turns on this functionality by default when the machine has been Azure Active Directory-joined. This feature provides an added level of security when connecting to domain resources not normally present on devices running Windows 10 in S mode.
+Credential Guard has always been an optional feature, but Windows 10 in S mode turns on this functionality by default when the machine has been Azure Active Directory-joined. This feature provides an added level of security when connecting to domain resources not normally present on devices running Windows 10 in S mode.
> [!NOTE]
-> Windows Defender Credential Guard is available only to S mode devices or Enterprise and Education Editions.
+> Credential Guard is available only to S mode devices or Enterprise and Education Editions.
For more information, see [Credential Guard Security Considerations](/windows/security/identity-protection/credential-guard/credential-guard-requirements#security-considerations).
diff --git a/windows/whats-new/ltsc/whats-new-windows-10-2021.md b/windows/whats-new/ltsc/whats-new-windows-10-2021.md
index 48b3e3b651..c07ad692ea 100644
--- a/windows/whats-new/ltsc/whats-new-windows-10-2021.md
+++ b/windows/whats-new/ltsc/whats-new-windows-10-2021.md
@@ -74,7 +74,7 @@ Windows Defender Firewall also now supports [Windows Subsystem for Linux (WSL)](
### Virus and threat protection
-[Attack surface area reduction](/windows/security/threat-protection/windows-defender-atp/overview-attack-surface-reduction) - IT admins can configure devices with advanced web protection that enables them to define allowlists and blocklists for specific URL's and IP addresses.
+[Attack surface area reduction](/windows/security/threat-protection/windows-defender-atp/overview-attack-surface-reduction) - IT admins can configure devices with advanced web protection that enables them to define allowlists and blocklists for specific URLs and IP addresses.
[Next generation protection](/microsoft-365/security/defender-endpoint/microsoft-defender-antivirus-in-windows-10) - Controls have been extended to protection from ransomware, credential misuse, and attacks that are transmitted through removable storage.
- Integrity enforcement capabilities - Enable remote runtime attestation of Windows 10 platform.
- [Tamper-proofing](/microsoft-365/security/defender-endpoint/prevent-changes-to-security-settings-with-tamper-protection) capabilities - Uses virtualization-based security to isolate critical Microsoft Defender for Endpoint security capabilities away from the OS and attackers.
@@ -149,9 +149,9 @@ Windows Hello enhancements include:
### Credential protection
-#### Windows Defender Credential Guard
+#### Credential Guard
-[Windows Defender Credential Guard](/windows/security/identity-protection/credential-guard/credential-guard) is now available for ARM64 devices, for extra protection against credential theft for enterprises deploying ARM64 devices in their organizations, such as Surface Pro X.
+[Credential Guard](/windows/security/identity-protection/credential-guard/credential-guard) is now available for ARM64 devices, for extra protection against credential theft for enterprises deploying ARM64 devices in their organizations, such as Surface Pro X.
### Privacy controls
diff --git a/windows/whats-new/temporary-enterprise-feature-control.md b/windows/whats-new/temporary-enterprise-feature-control.md
index b20be1c0ab..65ebf38755 100644
--- a/windows/whats-new/temporary-enterprise-feature-control.md
+++ b/windows/whats-new/temporary-enterprise-feature-control.md
@@ -1,6 +1,6 @@
---
-title: Temporary enterprise feature control in Windows 11
-description: Learn about the Windows 11 features behind temporary enterprise feature control.
+title: Enterprise feature control in Windows 11
+description: Learn about the Windows 11 features behind temporary enterprise feature control and permanent feature control.
ms.prod: windows-client
ms.technology: itpro-fundamentals
ms.author: mstewart
@@ -8,7 +8,7 @@ author: mestew
manager: aaroncz
ms.localizationpriority: medium
ms.topic: reference
-ms.date: 05/19/2023
+ms.date: 09/26/2023
ms.collection:
- highpri
- tier2
@@ -16,21 +16,20 @@ appliesto:
- ✅ Windows 11, version 22H2 and later
---
-# Temporary enterprise feature control in Windows 11
+# Enterprise feature control in Windows 11
-New features and enhancements are introduced through the monthly cumulative update to provide continuous innovation for Windows 11. To give organizations time to plan and prepare, some of these new features are temporarily turned off by default. Features that are turned off by default are listed in the KB article for the monthly cumulative update. Typically, a feature is selected to be off by default because it either impacts the user experience or IT administrators significantly.
+New features and enhancements are introduced through the monthly cumulative update to provide continuous innovation for Windows 11. To give organizations time to plan and prepare, some of these new features might be:
+
+- Temporarily turned off by default using [temporary enterprise feature control](#temporary-enterprise-feature-control)
+- Controlled by a policy that allows for [permanent enterprise feature control](#permanent-enterprise-feature-control)
+
+Features that are turned off by default are listed in the KB article for the monthly cumulative update. Typically, a feature is selected to be off by default because it either impacts the user experience or IT administrators significantly. For example, a feature might be turned off by default if it requires a change in user behavior or if it requires IT administrators to take action before the feature can be used.
+
+## Temporary enterprise feature control
Features behind temporary enterprise control are automatically disabled for devices that have their Windows updates managed by policies.
-## Windows 11 features behind temporary enterprise feature control
-
-The following features are behind temporary enterprise control in Windows 11:
-
-| Feature | KB article where the feature was introduced | Feature update that ends temporary control |
-|---|---|---|
-| Touch-optimized taskbar for 2-in-1 devices | [February 28, 2023 - KB5022913](https://support.microsoft.com/topic/february-28-2023-kb5022913-os-build-22621-1344-preview-3e38c0d9-924d-4f3f-b0b6-3bd49b2657b9) | 2023 annual feature update |
-
-## Enable features behind temporary enterprise feature control
+### Enable features behind temporary enterprise feature control
Features that are behind temporary enterprise control will be enabled when one of the following conditions is met:
@@ -38,7 +37,7 @@ Features that are behind temporary enterprise control will be enabled when one o
- The device receives a policy that enables features behind temporary enterprise control
- When the policy is enabled, all features on the device behind temporary control are turned on when the device next restarts.
-## Policy settings for temporary enterprise feature control
+### Policy settings for temporary enterprise feature control
You can use a policy to enable features that are behind temporary enterprise feature control. When this policy is enabled, all features that were disabled behind temporary enterprise feature control are turned on when the device next reboots. The following polices apply to Windows 11, version 22H2 with [KB5022845](https://support.microsoft.com/en-us/topic/february-14-2023-kb5022845-os-build-22621-1265-90a807f4-d2e8-486e-8a43-d09e66319f38) and later:
@@ -46,3 +45,33 @@ You can use a policy to enable features that are behind temporary enterprise fea
- **CSP**: ./Device/Vendor/MSFT/Policy/Config/Update/[AllowTemporaryEnterpriseFeatureControl](/windows/client-management/mdm/policy-csp-update?toc=/windows/deployment/toc.json&bc=/windows/deployment/breadcrumb/toc.json#allowtemporaryenterprisefeaturecontrol)
- In the Intune [settings catalog](/mem/intune/configuration/settings-catalog), this setting is named **Allow Temporary Enterprise Feature Control** under the **Windows Update for Business** category.
+
+### Windows 11 features behind temporary enterprise feature control
+
+The following features are behind temporary enterprise control in Windows 11:
+
+| Feature | KB article where the feature was introduced | Feature update that ends temporary control | Notes |
+|---|---|---|---|
+| Touch-optimized taskbar for 2-in-1 devices | [February 28, 2023 - KB5022913](https://support.microsoft.com/topic/february-28-2023-kb5022913-os-build-22621-1344-preview-3e38c0d9-924d-4f3f-b0b6-3bd49b2657b9) | 2023 annual feature update | |
+| Selecting **Uninstall** for a Win32 app from the right-click menu uses the **Installed Apps** page in **Settings** rather than **Programs and Features** under the **Control Panel** | [September 2023 - KB5030310](https://support.microsoft.com/kb/5030310) | 2023 annual feature update | |
+| Windows Spotlight provides a minimized experience, opportunities to learn more about each image, and allows users to preview images at full screen.| [September 2023 - KB5030310](https://support.microsoft.com/kb/5030310) | 2023 annual feature update | This feature also has a permanent control: **CSP**: ./User/Vendor/MSFT/Policy/Config/Experience/[AllowWindowsSpotlight](/windows/client-management/mdm/policy-csp-experience#allowwindowsspotlight) **Group Policy**: User Configuration\Administrative Templates\Windows Components\Cloud Content\\**Turn off all Windows spotlight features**|
+| Copilot in Windows | [September 2023 - KB5030310](https://support.microsoft.com/kb/5030310) | 2023 annual feature update | This feature has a permanent control. For more information, see the [Windows 11 features with permanent enterprise feature control](#windows-11-features-with-permanent-enterprise-feature-control) section. |
+| Dev Home | [September 2023 - KB5030310](https://support.microsoft.com/kb/5030310) | 2023 annual feature update | `Get-AppxPackage -Name Microsoft.Windows.DevHome` |
+|Dev Drive | [September 2023 - KB5030310](https://support.microsoft.com/kb/5030310) | 2023 annual feature update | This feature has multiple permanent controls. For more information, see the [Windows 11 features with permanent enterprise feature control](#windows-11-features-with-permanent-enterprise-feature-control) section |
+
+## Permanent enterprise feature control
+
+New features and enhancements used to be introduced only in feature updates. However, with continuous innovation for Windows 11, new features are introduced more frequently through the monthly cumulative update. Some new features can be controlled through policies that enable you to configure them for your organization. When a feature can be controlled by a policy, it has permanent enterprise feature control.
+
+### Windows 11 features with permanent enterprise feature control
+
+The following features introduced through the monthly cumulative updates allow permanent enterprise feature control:
+
+| Feature | KB article where the feature was introduced | Feature enabled by default | CSP and Group Policy |
+|---|---|---|---|
+| Configure search on the taskbar | [February 28, 2023 - KB5022913](https://support.microsoft.com/topic/february-28-2023-kb5022913-os-build-22621-1344-preview-3e38c0d9-924d-4f3f-b0b6-3bd49b2657b9)| Yes | **CSP**: ./Device/Vendor/MSFT/Policy/Config/Search/[ConfigureSearchOnTaskbarMode](/windows/client-management/mdm/policy-csp-search#configuresearchontaskbarmode) **Group Policy**: Computer Configuration\Administrative Templates\Windows Components\Search\\**Configures search on the taskbar**|
+| The **Recommended** section of the **Start Menu** displays personalized website recommendations |[September 2023 - KB5030310](https://support.microsoft.com/kb/5030310)| No |**CSP**: ./Device/Vendor/MSFT/Policy/Config/Start/[HideRecoPersonalizedSites](/windows/client-management/mdm/policy-csp-start) **Group Policy**: Computer Configuration\Administrative Templates\Start Menu and Taskbar\\**Remove Personalized Website Recommendations from the Recommended section in the Start Menu**|
+| **Recommended** section added to File Explorer Home for users signed into Windows with an Azure AD account. | [September 2023 - KB5030310](https://support.microsoft.com/kb/5030310) | Yes | **CSP**:./Device/Vendor/MSFT/Policy/Config/FileExplorer/[DisableGraphRecentItems](/windows/client-management/mdm/policy-csp-fileexplorer#disablegraphrecentitems) **Group Policy**: Computer Configuration\Administrative Templates\Windows Components\File Explorer\\**Turn off files from Office.com in Quick Access View** **Note**: This control disables additional items beyond the **Recommended** items. Review the policy before implementing this control. |
+| Transfer files to another PC using WiFi direct|[September 2023 - KB5030310](https://support.microsoft.com/kb/5030310)|Yes|**CSP**: ./Device/Vendor/MSFT/Policy/Config/Wifi/[AllowWiFiDirect](/windows/client-management/mdm/policy-csp-wifi#allowwifidirect)|
+| Copilot in Windows | [September 2023 - KB5030310](https://support.microsoft.com/kb/5030310) | Yes |**CSP**: ./User/Vendor/MSFT/WindowsAI/[TurnOffWindowsCopilot](/windows/client-management/mdm/policy-csp-windowsai#turnoffwindowscopilot) **Group Policy**: User Configuration\Administrative Templates\Windows Components\Windows Copilot\\**Turn off Windows Copilot**|
+|Dev Drive | [September 2023 - KB5030310](https://support.microsoft.com/kb/5030310) | Yes |**CSPs**: - ./Device/Vendor/MSFT/Policy/Config/FileSystem/[EnableDevDrive](/windows/client-management/mdm/policy-csp-filesystem#enableeeverive) - ./Device/Vendor/MSFT/Policy/Config/FileSystem/[DevDriveAttachPolicy](/windows/client-management/mdm/policy-csp-filesystem#devdriveattachpolicy) **Group Policies**: - Computer Configuration\Administrative Templates\System\FileSystem\\**Enable dev drive** - Computer Configuration\Administrative Templates\System\FileSystem\\**Dev drive filter attach policy**|
diff --git a/windows/whats-new/whats-new-windows-10-version-1709.md b/windows/whats-new/whats-new-windows-10-version-1709.md
index 55b211215b..4f608c1dd6 100644
--- a/windows/whats-new/whats-new-windows-10-version-1709.md
+++ b/windows/whats-new/whats-new-windows-10-version-1709.md
@@ -80,7 +80,7 @@ The AssignedAccess CSP has been expanded to make it easy for administrators to c
## Security
>[!NOTE]
->Windows security features have been rebranded as Windows Defender security features, including Windows Defender Device Guard, Windows Defender Credential Guard, and Windows Defender Firewall.
+>Windows security features have been rebranded as Windows Defender security features, including Windows Defender Device Guard, Credential Guard, and Windows Defender Firewall.
**Windows security baselines** have been updated for Windows 10. A [security baseline](/windows/device-security/windows-security-baselines) is a group of Microsoft-recommended configuration settings and explains their security impact. For more information, and to download the Policy Analyzer tool, see [Microsoft Security Compliance Toolkit 1.0](/windows/device-security/security-compliance-toolkit-10).
diff --git a/windows/whats-new/whats-new-windows-10-version-1809.md b/windows/whats-new/whats-new-windows-10-version-1809.md
index b617d899f5..ad971e7d6a 100644
--- a/windows/whats-new/whats-new-windows-10-version-1809.md
+++ b/windows/whats-new/whats-new-windows-10-version-1809.md
@@ -141,11 +141,11 @@ You can add specific rules for a WSL process in Windows Defender Firewall, just
We introduced new group policies and Modern Device Management settings to manage Microsoft Edge. The new policies include enabling and disabling full-screen mode, printing, favorites bar, and saving history; preventing certificate error overrides; configuring the Home button and startup options; setting the New Tab page and Home button URL, and managing extensions. Learn more about the [new Microsoft Edge policies](/microsoft-edge/deploy/change-history-for-microsoft-edge).
-### Windows Defender Credential Guard is supported by default on 10S devices that are Azure Active Directory-joined
+### Credential Guard is supported by default on 10S devices that are Azure Active Directory-joined
-Windows Defender Credential Guard is a security service in Windows 10 built to protect Active Directory (AD) domain credentials so that they can't be stolen or misused by malware on a user's machine. It's designed to protect against well-known threats such as Pass-the-Hash and credential harvesting.
+Credential Guard is a security service in Windows 10 built to protect Active Directory (AD) domain credentials so that they can't be stolen or misused by malware on a user's machine. It's designed to protect against well-known threats such as Pass-the-Hash and credential harvesting.
-Windows Defender Credential Guard has always been an optional feature, but Windows 10-S turns on this functionality by default when the machine has been Azure Active Directory-joined. This functionality provides an added level of security when connecting to domain resources not normally present on 10-S devices. Windows Defender Credential Guard is available only to S-Mode devices or Enterprise and Education Editions.
+Credential Guard has always been an optional feature, but Windows 10-S turns on this functionality by default when the machine has been Azure Active Directory-joined. This functionality provides an added level of security when connecting to domain resources not normally present on 10-S devices. Credential Guard is available only to S-Mode devices or Enterprise and Education Editions.
### Windows 10 Pro S Mode requires a network connection
diff --git a/windows/whats-new/whats-new-windows-10-version-1909.md b/windows/whats-new/whats-new-windows-10-version-1909.md
index c0202f98fe..d40de13c9d 100644
--- a/windows/whats-new/whats-new-windows-10-version-1909.md
+++ b/windows/whats-new/whats-new-windows-10-version-1909.md
@@ -41,9 +41,9 @@ If you're using Windows Update for Business, you'll receive the Windows 10, vers
## Security
-### Windows Defender Credential Guard
+### Credential Guard
-[Windows Defender Credential Guard](/windows/security/identity-protection/credential-guard/credential-guard) is now available for ARM64 devices, for extra protection against credential theft for enterprises deploying ARM64 devices in their organizations, such as Surface Pro X.
+[Credential Guard](/windows/security/identity-protection/credential-guard/credential-guard) is now available for ARM64 devices, for extra protection against credential theft for enterprises deploying ARM64 devices in their organizations, such as Surface Pro X.
### Microsoft BitLocker
diff --git a/windows/whats-new/whats-new-windows-10-version-20H2.md b/windows/whats-new/whats-new-windows-10-version-20H2.md
index 37a10475d2..a433405b4e 100644
--- a/windows/whats-new/whats-new-windows-10-version-20H2.md
+++ b/windows/whats-new/whats-new-windows-10-version-20H2.md
@@ -25,7 +25,7 @@ This article lists new and updated features and content that is of interest to I
As with previous fall releases, Windows 10, version 20H2 is a scoped set of features for select performance improvements, enterprise features, and quality enhancements. As an [H2-targeted release](/lifecycle/faq/windows), 20H2 is serviced for 30 months from the release date for devices running Windows 10 Enterprise or Windows 10 Education editions.
-To download and install Windows 10, version 20H2, use Windows Update (**Settings > Update & Security > Windows Update**). For more information, including a video, see [How to get the Windows 10 October 2020 Update](https://community.windows.com/videos/how-to-get-the-windows-10-october-2020-update/7c7_mWN0wi8).
+To download and install Windows 10, version 20H2, use Windows Update (**Settings > Update & Security > Windows Update**).
## Microsoft Edge
diff --git a/windows/whats-new/whats-new-windows-11-version-22H2.md b/windows/whats-new/whats-new-windows-11-version-22H2.md
index 4e91dc9a19..b09c1ab588 100644
--- a/windows/whats-new/whats-new-windows-11-version-22H2.md
+++ b/windows/whats-new/whats-new-windows-11-version-22H2.md
@@ -50,9 +50,9 @@ For more information, see [Smart App Control](/windows/security/threat-protectio
## Credential Guard
-Compatible Windows 11 Enterprise version 22H2 devices will have **Windows Defender Credential Guard** turned on by default. This changes the default state of the feature in Windows, though system administrators can still modify this enablement state.
+Compatible Windows 11 Enterprise version 22H2 devices will have **Credential Guard** turned on by default. This changes the default state of the feature in Windows, though system administrators can still modify this enablement state.
-For more information, see [Manage Windows Defender Credential Guard](/windows/security/identity-protection/credential-guard/credential-guard-manage).
+For more information, see [Manage Credential Guard](/windows/security/identity-protection/credential-guard/credential-guard-manage).
## Malicious and vulnerable driver blocking
diff --git a/windows/whats-new/windows-11-overview.md b/windows/whats-new/windows-11-overview.md
index 90928f5742..2bab9205d6 100644
--- a/windows/whats-new/windows-11-overview.md
+++ b/windows/whats-new/windows-11-overview.md
@@ -152,7 +152,7 @@ For more information on the security features you can configure, manage, and enf
- Your Windows 10 apps will also work on Windows 11. **[App Assure](https://www.microsoft.com/fasttrack/microsoft-365/app-assure)** is also available if there are some issues.
- You can continue to use **MSIX packages** for your UWP, Win32, WPF, and WinForm desktop application files. Continue to use **Windows Package Manager** to install Windows apps. You can create **Azure virtual desktops** that run Windows 11. Use **Azure Virtual desktop with MSIX app attach** to virtualize desktops and apps. For more information on these features, see [Overview of apps on Windows client devices](/windows/application-management/apps-in-windows-10).
+ You can continue to use **MSIX packages** for your UWP, Win32, WPF, and WinForm desktop application files. Continue to use **Windows Package Manager** to install Windows apps. You can create **Azure virtual desktops** that run Windows 11. Use **Azure Virtual desktop with MSIX app attach** to virtualize desktops and apps. For more information on these features, see [Overview of apps on Windows client devices](/windows/application-management/overview-windows-apps).
In the **Settings** app > **Apps**, users can manage some of the app settings. For example, they can get apps anywhere, but let the user know if there's a comparable app in the Microsoft Store. They can also choose which apps start when they sign in.
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.
diff --git a/windows/whats-new/windows-licensing.md b/windows/whats-new/windows-licensing.md
index 3a56385d67..d6f384c4f5 100644
--- a/windows/whats-new/windows-licensing.md
+++ b/windows/whats-new/windows-licensing.md
@@ -7,7 +7,7 @@ ms.author: paoloma
manager: aaroncz
ms.collection:
- tier2
-ms.topic: conceptual
+ms.topic: overview
ms.date: 05/04/2023
appliesto:
- ✅ Windows 11
@@ -67,7 +67,7 @@ The following table describes the unique Windows Enterprise edition features:
| OS-based feature | Description |
|-|-|
-|**[Windows Defender Credential Guard][WIN-1]**|Protects against user credential harvesting and pass-the-hash attacks or pass the token attacks.|
+|**[Credential Guard][WIN-1]**|Protects against user credential harvesting and pass-the-hash attacks or pass the token attacks.|
|**[Managed Microsoft Defender Application Guard (MDAG) for Microsoft Edge][WIN-11]**| Isolates enterprise-defined untrusted sites with virtualization-based security from Windows, protecting your organization while users browse the Internet.|
|**[Modern BitLocker Management][WIN-2]** | Allows you to eliminate on-premises tools to monitor and support BitLocker recovery scenarios. |
|**[Personal Data Encryption][WIN-3]**|Encrypts individual's content using Windows Hello for Business to link the encryption keys to user credentials.|
@@ -135,13 +135,13 @@ In most cases, the Windows Pro edition comes pre-installed on a business-class d
- A developer that is developing applications that must be tested and certified on Pro, as that is how it will be delivered to customers
- A Windows Pro device that was pre-configured for a specific purpose and is certified on Pro only
-In these cases, you want the PC to be configured, secured, monitored, and updated with the enterprise management and security tools that come with the Windows Enterprise user subscription. Your Windows Enterprise E3 subscriptions does not block these scenarios.
+In these cases, you want the PC to be configured, secured, monitored, and updated with the enterprise management and security tools that come with the Windows Enterprise user subscription. Your Windows Enterprise E3 subscription doesn't block these scenarios.
The following table lists the Windows 11 Enterprise features and their Windows edition requirements:
| OS-based feature |Windows Pro|Windows Enterprise|
|-|-|-|
-|**[Windows Defender Credential Guard][WIN-1]**|❌|Yes|
+|**[Credential Guard][WIN-1]**|❌|Yes|
|**[Microsoft Defender Application Guard (MDAG) for Microsoft Edge][WIN-11]**|Yes|Yes|
|**[Modern BitLocker Management][WIN-2]**|Yes|Yes|
|**[Personal data encryption (PDE)][WIN-3]**|❌|Yes|