From a170dd75530a10e3fb34ad2fa57e58b1e0da2aec Mon Sep 17 00:00:00 2001 From: Paolo Matarazzo <74918781+paolomatarazzo@users.noreply.github.com> Date: Wed, 28 Dec 2022 14:26:54 -0500 Subject: [PATCH] updates --- .../hello-hybrid-key-trust.md | 38 +++++++++++-------- .../includes/dc-certificate-template.md | 11 ++++++ .../hello-for-business/toc.yml | 2 + 3 files changed, 35 insertions(+), 16 deletions(-) diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md index 29de80a2e4..66d3a83c8b 100644 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md @@ -1,7 +1,7 @@ --- title: Windows Hello for Business hybrid key trust deployment description: Learn how to deploy Windows Hello for Business in a hybrid key trust scenario. -ms.date: 12/20/2022 +ms.date: 12/28/2022 appliesto: - ✅ Windows 10 and later - ✅ Windows Server 2016 and later @@ -11,23 +11,23 @@ ms.topic: how-to [!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-key-trust.md)] -Windows Hello for Business replaces password sign-in with strong authentication, using an asymmetric key pair. This deployment guide provides the information to deploy Windows Hello for Business in a hybrid key trust trust scenario. +Windows Hello for Business replaces password sign-in with strong authentication, using an asymmetric key pair. This deployment guide describes how to deploy Windows Hello for Business in a hybrid key trust scenario. Hybrid environments are distributed systems that enable organizations to use on-premises and Azure AD-based identities and 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. > [!IMPORTANT] -> Windows Hello for Business *cloud Kerberos trust* is the recommended deployment model when compared to the *key trust model*. For more information see [cloud Kerberos trust deployment](hello-hybrid-cloud-kerberos-trust.md). +> Windows Hello for Business *cloud Kerberos trust* is the recommended deployment model when compared to the *key trust model*. For more information, see [cloud Kerberos trust deployment](hello-hybrid-cloud-kerberos-trust.md). ## Prerequisites -Review the following section to ensure that you have the required prerequisites for a hybrid key trust deployment. +The following prerequisites must be met for a hybrid key trust deployment. ### Directories and directory synchronization Hybrid Windows Hello for Business needs two directories: -- an on-premises Active Directory -- an Azure Active Directory tenant +- An on-premises Active Directory +- An Azure Active Directory tenant The two directories must be synchronized with [Azure AD Connect Sync][AZ-1], which synchronizes user accounts from the on-premises Active Directory to Azure AD.\ During the Window Hello for Business provisioning process, users register the public portion of their Windows Hello for Business credential with Azure AD. *Azure AD Connect Sync* synchronizes the Windows Hello for Business public key to Active Directory. @@ -35,19 +35,19 @@ During the Window Hello for Business provisioning process, users register the pu > [!NOTE] > Windows Hello for Business Hybrid key trust is not supported if the users' on-premises UPN suffix cannot be added as a verified domain in Azure AD. -Ensure that you have [adequate Domain Controllers](/windows/security/identity-protection/hello-for-business/hello-adequate-domain-controllers) in each Active Directory site where users will be authenticating with Windows Hello for Business. +Ensure that you have [adequate Domain Controllers](hello-adequate-domain-controllers.md) in each Active Directory site where users will be authenticating with Windows Hello for Business. ### Authentication to Azure AD Authentication to Azure AD can be configured with or without federation: -- for non-federated environments, you must deploy [password hash synchronization](/azure/active-directory/hybrid/whatis-phs) or [Azure Active Directory Pass-through-Authentication](/azure/active-directory/connect/active-directory-aadconnect-pass-through-authentication) -- for federated environments, you can use Active Directory Federation Services (AD FS) or third-party federation services +- [Password hash synchronization][AZ-6] or [Azure Active Directory pass-through-authentication][AZ-7] is required for non-federated environments +- Active Directory Federation Services (AD FS) or third-party federation services are required for federated environments ### Device registration -The Windows client devices where Windows Hello for Business will be provisioned, must be registered in Azure AD. This ensures that only approved computers are used with that Azure AD tenant. You can *Azure AD join* or *hybrid Azure AD join* to register devices to Azure AD.\ -For *hybrid Azure AD joined* devices, review the guidance on the [Plan your hybrid Azure Active Directory join implementation](/azure/active-directory/devices/hybrid-azuread-join-plan) page. +The Windows devices must be registered in Azure AD. Devices can be registered in Azure AD using either *Azure AD join* or *hybrid Azure AD join*.\ +For *hybrid Azure AD joined* devices, review the guidance on the [Plan your hybrid Azure Active Directory join implementation][AZ-8] page. ### Public Key Infrastructure @@ -58,11 +58,11 @@ An enterprise PKI is required as *trust anchor* for authentication. Domain contr 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](/azure/multi-factor-authentication/multi-factor-authentication) +- [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 -For more information how to configure Azure AD Multi-Factor Authentication, see [Configure Azure AD Multi-Factor Authentication settings](/azure/multi-factor-authentication/multi-factor-authentication-whats-next).\ -For more information how to configure Active Directory Federation Services (AD FS) to provide additional multi-factor authentication, see [Configure Azure MFA as authentication provider with AD FS](/windows-server/identity/ad-fs/operations/configure-ad-fs-2016-and-azure-mfa). +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]. ### Device management @@ -79,8 +79,14 @@ Once the prerequisites are met, deploying Windows Hello for Business with a hybr > [!div class="nextstepaction"] > [Next: configure and validate the Public Key Infrastructure >](hello-hybrid-key-trust-validate-pki.md) - [AZ-1]: /azure/active-directory/hybrid/how-to-connect-sync-whatis +[AZ-2]: /azure/multi-factor-authentication/multi-factor-authentication +[AZ-3]: /azure/multi-factor-authentication/multi-factor-authentication-whats-next [AZ-4]: /azure/active-directory/devices/troubleshoot-device-dsregcmd -[AZ-5]: /azure/active-directory/connect/active-directory-aadconnectsync-feature-scheduler \ No newline at end of file +[AZ-5]: /azure/active-directory/connect/active-directory-aadconnectsync-feature-scheduler +[AZ-6]: /azure/active-directory/hybrid/whatis-phs +[AZ-7]: /azure/active-directory/connect/active-directory-aadconnect-pass-through-authentication +[AZ-8]: /azure/active-directory/devices/hybrid-azuread-join-plan + +[SER-1]: /windows-server/identity/ad-fs/operations/configure-ad-fs-2016-and-azure-mfa \ No newline at end of file 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 ba828af53d..0b99b3bb9b 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 @@ -11,6 +11,17 @@ Domain controllers automatically request a domain controller certificate (if pub By default, the Active Directory CA provides and publishes the *Kerberos Authentication* certificate template. The cryptography configuration included in the template is based on older and less performant cryptography APIs. To ensure domain controllers request the proper certificate with the best available cryptography, use the *Kerberos Authentication* certificate template as a *baseline* to create an updated domain controller certificate template. +> [!IMPORTANT] +> The certificates issued to the domain controllers must meet the following requirements: +> - The *Certificate Revocation List (CRL)* distribution point extension must points to a valid CRL, or an *Authority Information Access (AIA)* extension that points to an Online Certificate Status Protocol (OCSP) responder +> - Optionally, the certificate *Subject* section could contain the directory path of the server object (the distinguished name) +> - The certificate *Key Usage* section must contain *Digital Signature* and *Key Encipherment* +> - 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. + Sign in to a CA or management workstations with *Domain Administrator* equivalent credentials. 1. Open the **Certification Authority** management console diff --git a/windows/security/identity-protection/hello-for-business/toc.yml b/windows/security/identity-protection/hello-for-business/toc.yml index 16e5fbceaf..2cb12193d1 100644 --- a/windows/security/identity-protection/hello-for-business/toc.yml +++ b/windows/security/identity-protection/hello-for-business/toc.yml @@ -33,6 +33,8 @@ href: hello-hybrid-key-trust.md - name: Configure and validate the PKI href: hello-hybrid-key-trust-validate-pki.md + - name: Configure and provision Windows Hello for Business + href: hello-hybrid-key-trust-provision.md - name: Certificate trust deployment items: - name: Overview