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 7964c96198..af6c28cb74 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 @@ -137,7 +137,7 @@ Before you can remotely reset PINs, you must register two applications in your A Before you can remotely reset PINs, your devices must be configured to enable PIN Recovery. Follow the instructions below to configure your devices using either Microsoft Intune, Group Policy Objects (GPO), or Configuration Service Providers (CSP). -#### [✅ **Intune**](#tab/intune) +#### [:::image type="icon" source="../../images/icons/intune.svg"::: **Intune**](#tab/intune) You can configure Windows devices to use the **Microsoft PIN Reset Service** using Microsoft Intune. @@ -166,7 +166,7 @@ You can configure Windows devices to use the **Microsoft PIN Reset Service** usi > 1. Sign in to the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com). > 1. Select **Endpoint security** > **Account protection** > **Create Policy**. -#### [✅ **GPO**](#tab/gpo) +#### [:::image type="icon" source="../../images/icons/group-policy.svg"::: **GPO**](#tab/gpo) You can configure Windows devices to use the **Microsoft PIN Reset Service** using a Group Policy Object (GPO). @@ -175,7 +175,7 @@ You can configure Windows devices to use the **Microsoft PIN Reset Service** usi 1. Enable the **Use PIN Recovery** policy setting located under **Computer Configuration > Administrative Templates > Windows Components > Windows Hello for Business**. 1. Close the Group Policy Management Editor to save the Group Policy object. -#### [✅ **CSP**](#tab/csp) +#### [:::image type="icon" source="../../images/icons/windows-os.svg"::: **CSP**](#tab/CSP) You can configure Windows devices to use the **Microsoft PIN Reset Service** using the [PassportForWork CSP](/windows/client-management/mdm/passportforwork-csp). 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 9386370d64..bee8c29bee 100644 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md @@ -1,5 +1,5 @@ --- -title: Hybrid cloud Kerberos trust Deployment (Windows Hello for Business) +title: Hybrid cloud Kerberos trust deployment (Windows Hello for Business) description: Learn the information you need to successfully deploy Windows Hello for Business in a hybrid cloud Kerberos trust scenario. ms.prod: windows-client author: paolomatarazzo @@ -9,83 +9,93 @@ ms.reviewer: prsriva ms.collection: M365-identity-device-management ms.topic: article localizationpriority: medium -ms.date: 2/15/2022 +ms.date: 11/1/2022 appliesto: - ✅ Windows 10, version 21H2 and later - ✅ Windows 11 - ✅ Hybrid deployment - - ✅ Cloud Kerberos trust + - ✅ Hybrid cloud Kerberos trust --- -# Hybrid Cloud Kerberos Trust Deployment +# Hybrid cloud Kerberos trust deployment -Windows Hello for Business replaces username and password Windows sign-in with strong authentication using an asymmetric key pair. The following deployment guide provides the information needed to successfully deploy Windows Hello for Business in a hybrid cloud Kerberos trust scenario. +Windows Hello for Business replaces password Windows sign-in with strong authentication, using an asymmetric key pair. This deployment guide provides the information to successfully deploy Windows Hello for Business in a hybrid cloud Kerberos trust scenario. -## Introduction to Cloud Kerberos Trust +## Introduction to cloud Kerberos trust -The goal of the Windows Hello for Business cloud Kerberos trust is to bring the simplified deployment experience of [on-premises SSO with passwordless security keys](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises) to Windows Hello for Business. This deployment model can be used for new Windows Hello for Business deployments or existing deployments can move to this model using policy controls. +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.\ +This deployment model can be used for new or existing Windows Hello for Business deployments. -Windows Hello for Business cloud Kerberos trust uses Azure Active Directory (AD) Kerberos to address pain points of the key trust deployment model: +*Windows Hello for Business cloud Kerberos trust* leverages **Azure AD Kerberos**, which enables a simpler deployment when compared to the *key trust model*: -- Windows Hello for Business cloud Kerberos trust provides a simpler deployment experience because it doesn't require the deployment of public key infrastructure (PKI) or changes to existing PKI -- Cloud Kerberos trust doesn't require syncing of public keys between Azure AD and on-premises domain controllers (DCs) for users to access on-premises resources and applications. This change means there isn't a delay between the user provisioning and being able to authenticate -- Deploying Windows Hello for Business cloud Kerberos trust enables you to also deploy passwordless security keys with minimal extra setup +- 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. This means that there isn't delay between the user's WHFB 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 recommended instead of key trust if you meet the prerequisites to deploy cloud Kerberos trust. Cloud Kerberos trust is the preferred deployment model if you do not need to support certificate authentication scenarios. +> 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 Active Directory Kerberos and Cloud Kerberos Trust Authentication +## Azure AD 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 PKI for DC certificates, and requires end-user certificates for certificate trust. Single sign-on (SSO) to on-premises resources from Azure AD-joined devices requires more PKI configuration to publish a certificate revocation list (CRL) to a public endpoint. Cloud Kerberos trust uses Azure AD Kerberos that doesn't require any of the above PKI to get the user a TGT. +*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.\ +Single sign-on (SSO) to on-premises resources from *Azure AD-joined devices* requires to publish a certificate revocation list (CRL) to a public endpoint. -With Azure AD Kerberos, Azure AD can issue TGTs for one or more of your AD domains. Windows can request a TGT from Azure AD when authenticating with Windows Hello for Business and use the returned TGT for logon or to access traditional AD-based resources. Kerberos service tickets and authorization continue to be controlled by your on-premises AD DCs. +*Cloud Kerberos trust* uses *Azure AD Kerberos*, which doesn't require any of the above PKI to get the user a TGT. -When you enable Azure AD Kerberos in a domain, an Azure AD Kerberos Server object is created in your on-premises AD. This object will appear as a Read Only Domain Controller (RODC) object but isn't associated with any physical servers. This resource is only used by Azure Active Directory to generate TGTs for your Active Directory Domain. The same rules and restrictions used for RODCs apply to the Azure AD Kerberos Server object. +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 logon or to access traditional AD-based resources. Kerberos service tickets and authorization continue to be controlled the on-premises Domain Controllers. -More details on how Azure AD Kerberos enables access to on-premises resources are available in our documentation on [enabling passwordless security key sign-in to on-premises resources](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises). There's more information on how Azure AD Kerberos works with Windows Hello for Business cloud Kerberos trust in the [Windows Hello for Business authentication technical deep dive](hello-how-it-works-authentication.md#hybrid-azure-ad-join-authentication-using-azure-ad-kerberos-cloud-kerberos-trust). +When *Azure AD Kerberos* is enabled in an Active Directory domain, an *Azure AD Kerberos server object* is created in the domain. This object: -If you're using the hybrid cloud Kerberos trust deployment model, you _must_ ensure that you have adequate (one or more, depending on your authentication load) Windows Server 2016 or later read-write domain controllers in each Active Directory site where users will be authenticating for Windows Hello for Business. +- 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. The same rules and restrictions used for RODCs apply to the Azure AD Kerberos Server object + +:::image type="content" source="images/azuread-kerberos-object.png" alt-text="Active Directory Users and Computers console, showing the computer object represnenting the Azure AD Kerberos server "::: + +For more details 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 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-azure-ad-kerberos-cloud-kerberos-trust). + +> [!IMPORTANT] +> When implementing the *hybrid 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] ## Prerequisites | 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. | -| Patched Windows 10, version 21H2 or patched 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. | -| Fully patched Windows Server 2016 or later Domain Controllers | Domain controllers should be fully patched to support updates needed for Azure AD Kerberos. If you're using Windows Server 2016, [KB3534307](https://support.microsoft.com/en-us/topic/january-23-2020-kb4534307-os-build-14393-3474-b181594e-2c6a-14ea-e75b-678efea9d27e) must be installed. If you're using Server 2019, [KB4534321](https://support.microsoft.com/en-us/topic/january-23-2020-kb4534321-os-build-17763-1012-023e84c3-f9aa-3b55-8aff-d512911c459f) must be installed. | +| 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. | +| 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).| | 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 +### Unsupported scenarios The following scenarios aren't supported using Windows Hello for Business cloud Kerberos trust: - 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) -- Scenarios that require a certificate for authentication - 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 > [!NOTE] > The default security policy for AD does not grant permission to sign high privilege accounts on to on-premises resources with cloud Kerberos trust or FIDO2 security keys. -> +> > To unblock the accounts, use Active Directory Users and Computers to modify the msDS-NeverRevealGroup property of the Azure AD Kerberos Computer object (CN=AzureADKerberos,OU=Domain Controllers,\). -## Deployment Instructions +## Deployment steps -Deploying Windows Hello for Business cloud Kerberos trust consists of two steps: +Deploying *Windows Hello for Business cloud Kerberos trust* consists of two steps: -1. Set up Azure AD Kerberos in your hybrid environment. -1. Configure Windows Hello for Business policy and deploy it to devices. +1. Set up *Azure AD 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. -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](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises#install-the-azure-ad-kerberos-powershell-module) 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 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. -### Configure Windows Hello for Business Policy +### 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 *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). #### [:::image type="icon" source="../../images/icons/intune.svg"::: **Intune**](#tab/intune) @@ -93,72 +103,46 @@ Windows Hello for Business can be enabled using device enrollment or device conf The cloud Kerberos trust policy needs to be configured using a custom template and is configured separately from enabling Windows Hello from Business. -### Create a user Group that will be targeted for Windows Hello for Business - -If you have an existing group you want to target with Windows Hello for Business cloud Kerberos trust policy, you can skip this step. - -1. Sign in to the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com/) -1. Browse to **Groups** and select **New group** -1. Configure the following group settings: - 1. Group type: **Security** - 1. Group name: *WHFB cloud Kerberos trust users* or a group name of your choosing - 1. Membership type: **Assigned** -1. Select **Members** and add users that you want to target with Windows Hello for Business cloud Kerberos trust - -You can also create a group through the Azure portal instead of using the Microsoft Endpoint Manager admin center - ### Enable Windows Hello for Business If you already enabled Windows Hello for Business for a target set of users or devices, you can skip below to configuring the cloud Kerberos trust policy. Otherwise, follow the instructions at [Integrate Windows Hello for Business with Microsoft Intune](/mem/intune/protect/windows-hello) to create a Windows Hello for Business device enrollment policy. -You can also follow these steps to create a device configuration policy instead of a device enrollment policy: +You can also follow these steps to create a device configuration policy instead of using the device enrollment policy: -1. Sign in to the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com/). -1. Browse to Devices > Windows > Configuration Profiles > Create profile. -1. For Platform, select Windows 10 and later. -1. For Profile Type, select **Templates** and select the **Identity Protection** Template. -1. Name the profile with a familiar name. For example, "Windows Hello for Business". -1. In **Configurations settings**, set the **Configure Windows Hello for Business** option to **Enable**. -1. After setting Configure Windows Hello for Business to Enable, multiple policy options become available. These policies are optional to configure. More information on these policies is available in our documentation on managing [Windows Hello for Business in your organization](hello-manage-in-organization.md#mdm-policy-settings-for-windows-hello-for-business). We recommend setting **Use a Trusted Platform Module (TPM)** to **Enable**. +1. Sign in to the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com/) +1. Select **Devices** > **Windows** > **Configuration Profiles** > **Create profile** +1. For Platform, select **Windows 10 and later** +1. For Profile Type, select **Templates** and select the **Identity Protection** Template +1. Name the profile with a familiar name. For example, "Windows Hello for Business" +1. In **Configurations settings**, set the **Configure Windows Hello for Business** option to **Enable** +1. After setting Configure Windows Hello for Business to Enable, multiple policy options become available. These policies are optional to configure. More information on these policies is available in our documentation on managing [Windows Hello for Business in your organization](hello-manage-in-organization.md#mdm-policy-settings-for-windows-hello-for-business). We recommend setting **Use a Trusted Platform Module (TPM)** to **Enable** [![Intune custom device configuration policy creation](./images/hello-intune-enable.png)](./images/hello-intune-enable-large.png#lightbox) -1. Select Next to move to **Assignments**. -1. Under Included groups, select **Add groups**. -1. Select the user group you would like to use Windows Hello for Business cloud Kerberos trust. This group may be *WHFB cloud Kerberos trust users* or a group of your choosing. -1. Select Next to move to the Applicability Rules. -1. Select Next again to move to the **Review + create** tab and select the option to create the policy. +Assign the policy to a security group that contains as members the devices or users that you want to configure. Windows Hello for Business settings are also available in the settings catalog. For more information, see [Use the settings catalog to configure settings on Windows and macOS devices - preview](/mem/intune/configuration/settings-catalog). -### Configure Cloud Kerberos Trust policy +### Configure cloud Kerberos trust policy -To configure the cloud Kerberos trust policy, follow the steps below: +To configure the *cloud Kerberos trust* policy, follow the steps below: -1. Sign in to the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com/). -1. Browse to Devices > Windows > Configuration Profiles > Create profile. -1. For Platform, select Windows 10 and later. -1. For Profile Type, select **Templates** and select the **Custom** Template. -1. Name the profile with a familiar name. For example, "Windows Hello for Business cloud Kerberos trust". +1. Sign in to the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com/) +1. Select **Devices** > **Windows** > **Configuration Profiles** > **Create profile** +1. For Profile Type, select **Templates** and select the **Custom** Template +1. Name the profile with a familiar name. For example, "Windows Hello for Business cloud Kerberos trust" 1. In Configuration Settings, add a new configuration with the following settings: - + | Setting | |--------| | | - - >[!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](/azure/active-directory/fundamentals/active-directory-how-to-find-tenant) for instructions on looking up your tenant ID. - - [![Intune custom-device configuration policy creation](./images/hello-cloud-trust-intune.png)](./images/hello-cloud-trust-intune-large.png#lightbox) - -1. Select Next to navigate to **Assignments**. -1. Under Included groups, select **Add groups**. -1. Select the user group you would like to use Windows Hello for Business cloud Kerberos trust. This group may be *WHFB cloud Kerberos trust users* or a group of your choosing. -1. Select Next to move to the Applicability Rules. -1. Select Next again to move to the **Review + create** tab and select the option to create the policy. -> [!Important] -> If the Use certificate for on-premises authentication policy is enabled, we will enforce certificate trust instead of cloud Kerberos trust on the client. Please make sure that any machines that you want to use Windows Hello for Business cloud Kerberos trust have this policy not configured or disabled. + >[!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. + + [![Intune custom-device configuration policy creation](./images/hello-cloud-trust-intune.png)](./images/hello-cloud-trust-intune-large.png#lightbox) + +Assign the policy to a security group that contains as members the devices or users that you want to configure. #### [:::image type="icon" source="../../images/icons/group-policy.svg"::: **GPO**](#tab/gpo) @@ -171,98 +155,97 @@ You can configure the Enable Windows Hello for Business Group Policy setting for cloud Kerberos trust requires setting a dedicated policy for it to be enabled. This policy is only available as a computer configuration. > [!NOTE] -> If you deployed Windows Hello for Business configuration using both Group Policy and Microsoft Intune, Group Policy settings will take precedence and Intune settings will be ignored. For more information about deploying Windows Hello for Business configuration using Microsoft Intune, see [Windows device settings to enable Windows Hello for Business in Intune](/mem/intune/protect/identity-protection-windows-settings) and [PassportForWork CSP](/windows/client-management/mdm/passportforwork-csp). For more information about policy conflicts, see [Policy conflicts from multiple policy sources](hello-manage-in-organization.md#policy-conflicts-from-multiple-policy-sources) +> If you deployed Windows Hello for Business configuration using both Group Policy and Microsoft Intune, Group Policy settings will take precedence and Intune settings will be ignored. For more information about deploying Windows Hello for Business configuration using Microsoft Intune, see [Windows device settings to enable Windows Hello for Business in Intune][MEM-1] and [PassportForWork CSP][WIN-1]. For more information about policy conflicts, see [Policy conflicts from multiple policy sources](hello-manage-in-organization.md#policy-conflicts-from-multiple-policy-sources) -#### Update Group Policy Objects +#### Update administrative templates -You may need to update your Group Policy definitions to be able to configure the cloud Kerberos trust policy. You can copy the ADMX and ADML files from a Windows 10 21H2 or Windows 11 device that supports cloud Kerberos trust to their respective language folder on your Group Policy management server. Windows Hello for Business settings are in the Passport.admx and Passport.adml files. +You may need to update your Group Policy definitions to be able to configure the cloud Kerberos trust policy. You can copy the ADMX and ADML files from a **Windows 10 21H2** or **Windows 11** device that supports cloud Kerberos trust to their respective language folder on your Group Policy management server. Windows Hello for Business settings are in the *Passport.admx* and *Passport.adml* files. -You can also create a Group Policy Central Store and copy them their respective language folder. For more information, see [How to create and manage the Central Store for Group Policy Administrative Templates in Windows](/troubleshoot/windows-client/group-policy/create-and-manage-central-store). +You can also create a Group Policy Central Store and copy them their respective language folder. For more information, see [How to create and manage the Central Store for Group Policy Administrative Templates in Windows][TS-1]. -#### Create the Windows Hello for Business Group Policy object +#### Create the Windows Hello for Business group policy object -Sign-in a domain controller or management workstations with *Domain Admin* equivalent credentials. +You can configure Windows devices to enable *Windows Hello for Business cloud Kerberos trust* using a Group Policy Object (GPO). -1. Start the **Group Policy Management Console** (gpmc.msc). -1. Expand the domain and select the **Group Policy Object** node in the navigation pane. -1. Right-click **Group Policy object** and select **New**. -1. Type *Enable Windows Hello for Business* in the name box and click **OK**. -1. In the content pane, right-click the **Enable Windows Hello for Business** Group Policy object and click **Edit**. -1. In the navigation pane, expand **Policies** under **Device Configuration**. -1. Expand **Administrative Templates > Windows Component**, and select **Windows Hello for Business**. -1. In the content pane, double-click **Use Windows Hello for Business**. Click **Enable** and click **OK**. -1. In the content pane, double-click **Use cloud Kerberos trust for on-premises authentication**. Click **Enable** and click **OK**. -1. *Optional but recommended*: In the content pane, double-click **Use a hardware security device**. Click **Enable** and click **OK**. +1. Using the Group Policy Management Console (GPMC), scope a domain-based Group Policy to computer objects in Active Directory +1. Edit the Group Policy object from Step 1 +1. Expand **Computer Configuration > Administrative Templates > Windows Components > Windows Hello for Business** +1. Select **Use Windows Hello for Business** > **Enable** > **OK** +1. Select **Use cloud Kerberos trust for on-premises authentication** > **Enable** > **OK** +1. *Optional, but recommended*: select **Use a hardware security device** > **Enable** > **OK** -This group policy should be targeted at the computer group that you've created for that you want to use Windows Hello for Business. - -> [!Important] +> [!IMPORTANT] > If the Use certificate for on-premises authentication policy is enabled, we will enforce certificate trust instead of cloud Kerberos trust on the client. Please make sure that any machines that you want to use Windows Hello for Business cloud Kerberos trust have this policy not configured or disabled. --- -## Provisioning +> [!IMPORTANT] +> If the *Use certificate for on-premises authentication* policy is enabled, *certificate trust* will take precedence over *cloud Kerberos trust*. Ensure that the machines that you want to enable *cloud Kerberos trust* have this policy *not configured* or *disabled*. -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. +## Provision Windows Hello for Business -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**](/azure/active-directory/devices/troubleshoot-device-dsregcmd) command from a console. +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. - ![cloud Kerberos trust prerequisite check in the user device registration log](./images/cloud-trust-prereq-check.png) +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**][AZ-4] command from a console. + + ![Cloud Kerberos trust prerequisite check in the user device registration log](./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 is not being enforced by policy or if the device is Azure AD joined. -This prerequisite check isn't done for provisioning 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. +> [!NOTE] +> This prerequisite check isn't done for provisioning 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. ### PIN Setup -When Windows Hello for Business provisioning begins, the user will see a full screen page with the title **Setup a PIN** and button with the same name. The user clicks **Setup a PIN**. +This is the process that occurs after a user signs in, to enroll in Windows Hello for Business: -![Setup a PIN Provisioning.](images/setupapin.png) +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 -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. - -![MFA prompt during provisioning.](images/mfa.png) - -After a successful MFA, the provisioning flow asks the user to create and validate a PIN. This PIN must observe any PIN complexity requirements that you deployed to the environment. - -![Create a PIN during provisioning.](images/createPin.png) +:::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."::: ### 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 logon 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 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 logon 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 WHFB using the **key trust** deployment model, and want to migrate to the **cloud Kerberos trust** deployment model, follow these steps: +If you deployed Windows Hello for Business using the *key trust* deployment model, and want to migrate to the *cloud Kerberos trust* deployment model, follow these steps: 1. [Set up Azure AD 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 the device using Windows Hello for Business with line of sight to a domain controller (DC). Without line of sight to DC, even when the policy is set to "UseCloudTrustForOnPremAuth", the system will fall back to key trust if cloud Kerberos trust login fails +1. For hybrid Azure AD 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. +> +> Without line of sight to a DC, even when the policy is set to "UseCloudTrustForOnPremAuth", the system will fall back to key trust if cloud Kerberos trust login fails. ## Migrate from certificate trust deployment model to cloud Kerberos trust > [!IMPORTANT] -> There is no direct migration path from certificate trust deployment to cloud Kerberos trust deployment. +> There is no *direct* migration path from *certificate trust* deployment to *cloud Kerberos trust* deployment. The Windows Hello container must be deleted before you can migrate to cloud Kerberos trust. -If you have deployed WHFB using a **certificate trust** deployment model, and want to use **cloud Kerberos trust**, you will need to clean up the existing deployments and redeploy by following these steps: +If you have deployed Windows Hello for Business using a *certificate trust* deployment model, and want to use *cloud Kerberos trust*, you must redeploy Windows Hello for Business by following these steps: 1. Disable the certificate trust policy 1. [Enable cloud Kerberos trust via Group Policy or Intune](#configure-windows-hello-for-business-policy) 1. Remove the certificate trust credential using the command `certutil -deletehellocontainer` from the user context -1. Reboot or sign out and sign back in -1. Provision Windows Hello for Business (Enroll PIN/Face/Fingerprint) +1. Sign out and sign back in +1. Provision Windows Hello for Business using a method of your choice > [!NOTE] -> For hybrid Azure AD joined devices, sign in with new credentials while having line of sight to a DC. +> For hybrid Azure AD joined devices, users must perform the first sign in with new credentials while having line of sight to a DC. ## Troubleshooting -If you encounter issues or want to share feedback about Windows Hello for Business cloud Kerberos trust, share via the Windows Feedback Hub app by following these steps: +If you encounter issues or want to share feedback about Windows Hello for Business cloud Kerberos trust, share via the *Windows Feedback Hub* app by following these steps: -1. Open **Feedback Hub**, and make sure that you're signed in. +1. Open **Feedback Hub**, and make sure that you're signed in 1. Submit feedback by selecting the following categories: - - Category: Security and Privacy - - Subcategory: Windows Hello PIN + - Category: Security and Privacy + - Subcategory: Windows Hello PIN ## Frequently Asked Questions @@ -277,13 +260,30 @@ Windows Hello for Business cloud Kerberos trust looks for a writeable DC to exch ### Do I need line of sight to a domain controller to use Windows Hello for Business cloud Kerberos trust? Windows Hello for Business cloud Kerberos trust requires line of sight to a domain controller for some scenarios: + - The first sign-in or unlock with Windows Hello for Business after provisioning - When attempting to access an on-premises resource from a Hybrid Azure AD joined device ### Can I use RDP/VDI with Windows Hello for Business cloud Kerberos trust? -Windows Hello for Business cloud Kerberos trust cannot be used as a supplied credential with RDP/VDI. Similar to key trust, cloud Kerberos trust can be used for RDP with [remote credential guard](/windows/security/identity-protection/remote-credential-guard) or if a [certificate is enrolled into Windows Hello for Business](hello-deployment-rdp-certs.md) for this purpose. +Windows Hello for Business cloud Kerberos trust cannot be used as a supplied credential with RDP/VDI. Similar to key trust, cloud Kerberos trust can be used for RDP with [remote credential guard][WIN-2] or if a [certificate is enrolled into Windows Hello for Business](hello-deployment-rdp-certs.md) for this purpose. ### Do all my domain controllers need to be fully patched as per the prerequisites for me to use Windows Hello for Business cloud Kerberos trust? No, only the number necessary to handle the load from all cloud Kerberos trust devices. + +--- + +[AZ-1]: /azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises +[AZ-2]: /azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises#install-the-azure-ad-kerberos-powershell-module +[AZ-3]: /azure/active-directory/fundamentals/active-directory-how-to-find-tenant +[AZ-4]: /azure/active-directory/devices/troubleshoot-device-dsregcmd + +[SERV-1]: /windows-server/administration/performance-tuning/role/active-directory-server/capacity-planning-for-active-directory-domain-services +[TS-1]: /troubleshoot/windows-client/group-policy/create-and-manage-central-store + +[MEM-1]: /mem/intune/protect/identity-protection-windows-settings) +[WIN-1]: /windows/client-management/mdm/passportforwork-csp +[WIN-2]: /windows/security/identity-protection/remote-credential-guard +[SUP-1]: +[SUP-2]: diff --git a/windows/security/identity-protection/hello-for-business/images/azuread-kerberos-object.png b/windows/security/identity-protection/hello-for-business/images/azuread-kerberos-object.png new file mode 100644 index 0000000000..a1cffd3665 Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/azuread-kerberos-object.png differ diff --git a/windows/security/identity-protection/hello-for-business/images/haadj-whfb-pin-provisioning.gif b/windows/security/identity-protection/hello-for-business/images/haadj-whfb-pin-provisioning.gif new file mode 100644 index 0000000000..7bff02eada Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/haadj-whfb-pin-provisioning.gif differ