From 5cada839ebca123fe89d7ba703cf2dd5e249c982 Mon Sep 17 00:00:00 2001 From: Paolo Matarazzo <74918781+paolomatarazzo@users.noreply.github.com> Date: Thu, 29 Dec 2022 08:03:35 -0500 Subject: [PATCH] updates --- .../hello-hybrid-cloud-kerberos-trust.md | 2 +- .../hello-hybrid-key-trust-provision.md | 53 +++++++++++++++++-- .../hello-hybrid-key-trust-validate-pki.md | 13 +++-- .../includes/dc-certificate-template.md | 6 +-- 4 files changed, 58 insertions(+), 16 deletions(-) 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 3f7bb9918a..0bcb259d6a 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: Windows Hello for Business Cloud Kerberos trust deployment +title: Windows Hello for Business cloud Kerberos trust deployment description: Learn how to deploy Windows Hello for Business in a cloud Kerberos trust scenario. ms.date: 11/1/2022 appliesto: diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-provision.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-provision.md index 8d6706dae8..e683871c88 100644 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-provision.md +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-provision.md @@ -1,12 +1,53 @@ - -The configuration for Windows Hello for Business is grouped in four categories. These categories are: -### Configure AD - Creating Security Groups +--- +title: Windows Hello for Business key trust clients configuration and enrollment +description: Learn how to configure devices to enroll in Windows Hello for Business in a hybrid key trust scenario. +ms.date: 11/1/2022 +appliesto: +- ✅ Windows 10 and later +ms.topic: tutorial +--- -Windows Hello for Business uses a security group to simplify the deployment and management. +# Configure a Windows Hello for Business policy and deploy it to the devices - hybrid key trust + +After the prerequisites are met and the PKI configuration is validated, Windows Hello for business must be enabled on the Windows devices. Follow the instructions below to configure your devices using either Microsoft Intune or group policy (GPO). + +## 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). + +### [:::image type="icon" source="../../images/icons/intune.svg"::: **Intune**](#tab/intune) + +For Azure AD joined devices and hybrid Azure AD joined devices enrolled in Intune, you can use Intune policies to manage Windows Hello for Business. + +Windows Hello for Business can be enabled using device enrollment or device configuration policy. Device enrollment policy is only applied at device enrollment time. Any modifications to the configuration in Intune won't apply to already enrolled devices. Device configuration policy is applied after device enrollment. Changes to this policy type in Intune are applied to already enrolled devices. + +#### Enable Windows Hello for Business + +If you already enabled Windows Hello for Business, you can skip to **configure the 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 using the device enrollment policy: + +1. Sign in to the [Microsoft Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431). +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) + +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 devices](/mem/intune/configuration/settings-catalog). + +### [:::image type="icon" source="../../images/icons/group-policy.svg"::: **GPO**](#tab/gpo) + +For hybrid Azure AD joined devices, you can use GPOs to manage Windows Hello for Business. #### Create the Windows Hello for Business Users Security Group -The Windows Hello for Business Users group is used to make it easy to deploy Windows Hello for Business in phases. You assign Group Policy and Certificate template permissions to this group to simplify the deployment by simply 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. +The Windows Hello for Business Users group is used to make it easy to deploy Windows Hello for Business in phases. You assign Group Policy and Certificate template permissions to this group to simplify the deployment by simply 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. Sign-in a domain controller or management workstation with *Domain Admin* equivalent credentials. @@ -17,6 +58,8 @@ Sign-in a domain controller or management workstation with *Domain Admin* equiva 5. Type **Windows Hello for Business Users** in the **Group Name** text box. 6. Click **OK**. +--- + ## Windows Hello for Business Group Policy The Windows Hello for Business Group Policy object delivers the correct Group Policy settings to the user, which enables them to enroll and use Windows Hello for Business to authenticate to Azure and Active Directory diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md index 83902d8223..1af49e3f0e 100644 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md @@ -13,7 +13,7 @@ ms.topic: tutorial Windows Hello for Business must have a Public Key Infrastructure (PKI) when using the *key trust* or *certificate trust* models. The domain controllers must have a certificate, which serves as a *root of trust* for clients. The certificate ensures that clients don't communicate with rogue domain controllers. -Key trust deployments do not need client issued certificates for on-premises authentication. Active Directory user accounts are automatically configured for public key mapping by Azure AD Connect synchronizing the public key of the registered Windows Hello for Business credential to an attribute on the user's Active Directory object. +Key trust deployments do not need client issued certificates for on-premises authentication. Active Directory user accounts are configured for public key mapping by Azure AD Connect Sync, which synchronizes the public key of the Windows Hello for Business credential to an attribute on the user's Active Directory object. You can use a Windows Server-based PKI or a third-party Enterprise certification authority. The requirements for the domain controller certificate are shown below. For more details, see [Requirements for domain controller certificates from a third-party CA][SERV-1]. @@ -54,9 +54,10 @@ Expand the following sections to configure the PKI for Windows Hello for Busines > [!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. + > [!IMPORTANT] -> For Azure AD joined device to authenticate to and use on-premises resources, ensure you: -> - Install the root certificate authority certificate for your organization in the user's trusted root certificate store +> For Azure AD 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 @@ -79,7 +80,7 @@ Expand the following sections to configure the PKI for Windows Hello for Busines
-Publish certificate templates to the CA +Publish certificate template to the CA A certification authority can only issue certificates for certificate templates that are published to it. If you have more than one CA, and you want more CAs to issue certificates based on the certificate template, then you must publish the certificate template to them. @@ -88,10 +89,8 @@ Sign in to the CA or management workstations with **Enterprise Admin** equivalen 1. Open the **Certification Authority** management console 1. Expand the parent node from the navigation pane 1. Select **Certificate Templates** in the navigation pane -1. Right-click the **Certificate Templates** node. Select **New > Certificate Template** to issue +1. Right-click the **Certificate Templates** node. Select **New > Certificate Template to issue** 1. In the **Enable Certificates Templates** window, select the *Domain Controller Authentication (Kerberos)* template you created in the previous steps > select **OK** -1. If you published the *Domain Controller Authentication (Kerberos)* certificate template, then unpublish the certificate templates you included in the superseded templates list - - To unpublish a certificate template, right-click the certificate template you want to unpublish and select **Delete**. Select **Yes** to confirm the operation 1. Close the console
diff --git a/windows/security/identity-protection/hello-for-business/includes/dc-certificate-template.md b/windows/security/identity-protection/hello-for-business/includes/dc-certificate-template.md index 0b99b3bb9b..ee9a0109bf 100644 --- a/windows/security/identity-protection/hello-for-business/includes/dc-certificate-template.md +++ b/windows/security/identity-protection/hello-for-business/includes/dc-certificate-template.md @@ -19,8 +19,8 @@ By default, the Active Directory CA provides and publishes the *Kerberos Authent > - Optionally, the certificate *Basic Constraints* section should contain: `[Subject Type=End Entity, Path Length Constraint=None]` > - The certificate *Enhanced Key Usage* section must contain Client Authentication (`1.3.6.1.5.5.7.3.2`), Server Authentication (`1.3.6.1.5.5.7.3.1`), and KDC Authentication (`1.3.6.1.5.2.3.5`) > - The certificate *Subject Alternative Name* section must contain the Domain Name System (DNS) name -> - The certificate template must have an extension that has the value **DomainController**"**, encoded as a [BMPstring](/windows/win32/seccertenroll/about-bmpstring). If you are using Windows Server Enterprise Certificate Authority, this extension is already included in the domain controller certificate template -> - The domain controller certificate must be installed in the local computer's certificate store. +> - The certificate template must have an extension that has the value `DomainController`, encoded as a [BMPstring](/windows/win32/seccertenroll/about-bmpstring). If you are using Windows Server Enterprise Certificate Authority, this extension is already included in the domain controller certificate template +> - The domain controller certificate must be installed in the local computer's certificate store Sign in to a CA or management workstations with *Domain Administrator* equivalent credentials. @@ -42,7 +42,7 @@ Sign in to a CA or management workstations with *Domain Administrator* equivalen - Select **DNS name** from the **Include this information in alternate subject** list - Clear all other items 1. On the **Cryptography** tab: - - select **Key Storage Provider** from the **Provider Category** list + - Select **Key Storage Provider** from the **Provider Category** list - Select **RSA** from the **Algorithm name** list - Type *2048* in the **Minimum key size** text box - Select **SHA256** from the **Request hash** list