Remove and update Windows Hello for Business images and add information about Windows Hello authentication technology

This commit is contained in:
Paolo Matarazzo
2024-01-09 09:18:08 -05:00
parent 70d8928df9
commit 72195c7f44
8 changed files with 63 additions and 24 deletions

View File

@ -159,4 +159,18 @@ Learn more about Windows Hello for Business features and how to configure them:
[MEM-3]: /mem/intune/configuration/custom-settings-configure [MEM-3]: /mem/intune/configuration/custom-settings-configure
[MEM-4]: /windows/client-management/mdm/passportforwork-csp [MEM-4]: /windows/client-management/mdm/passportforwork-csp
[MEM-5]: /mem/intune/protect/endpoint-security-account-protection-policy [MEM-5]: /mem/intune/protect/endpoint-security-account-protection-policy
[MEM-6]: /mem/intune/protect/identity-protection-configure [MEM-6]: /mem/intune/protect/identity-protection-configure
<!--
MDM user policy registry path:
"HKLM:SOFTWARE\Microsoft\Policies\PassportForWork\<tenantID>\< userSid>\Policies".
MDM device policy registry path:
"HKLM:SOFTWARE\Microsoft\Policies\PassportForWork\<tenantID>\Device\Policies".
GP user policy registry paths:
"HKEY_USERS:<userSID>\SOFTWARE\Policies\Microsoft\PassportForWork"
GP device policy registry path:
"HKLM:SOFTWARE\Policies\Microsoft\PassportForWork".
-->

View File

@ -23,23 +23,23 @@ sections:
The statement *PIN is stronger than Password* is not directed at the strength of the entropy used by the PIN. It's about the difference between providing entropy versus continuing the use of a symmetric key (the password). The TPM has anti-hammering features that thwart brute-force PIN attacks (an attacker's continuous attempt to try all combination of PINs). Some organizations may worry about shoulder surfing. For those organizations, rather than increase the complexity of the PIN, implement the [Multifactor Unlock](multifactor-unlock.md) feature. The statement *PIN is stronger than Password* is not directed at the strength of the entropy used by the PIN. It's about the difference between providing entropy versus continuing the use of a symmetric key (the password). The TPM has anti-hammering features that thwart brute-force PIN attacks (an attacker's continuous attempt to try all combination of PINs). Some organizations may worry about shoulder surfing. For those organizations, rather than increase the complexity of the PIN, implement the [Multifactor Unlock](multifactor-unlock.md) feature.
- question: What's a container? - question: What's a container?
answer: | 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. 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 an organization's account.
The container holds enterprise credentials only on devices that have been registered with an organization (key material for the enterprise IDP, such as on-premises Active Directory or Microsoft Entra ID). The container holds organization's credentials only on devices that are *registered* with the organization.
> [!NOTE] > [!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. > 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.
The container contains a set of keys, some of which are used to protect other keys. The following image shows an example: the protector key is used to encrypt the authentication key, and the authentication key is used to encrypt the individual keys stored in the container. Each logical container holds one or more sets of keys.\ The container contains a set of keys, some of which are used to protect other keys. The following image illustrates an example: the *protector key* is used to encrypt the *authentication key*, and the authentication key is used to encrypt the individual keys stored in the container. Each logical container holds one or more sets of keys.\
:::image type="content" source="images/hello-container.png" alt-text="logical container with set of keys"::: :::image type="content" source="images/hello-container.png" alt-text="logical container with set of keys":::
Containers can contain several types of key material: 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. - 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 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. 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 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. - 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? - question: How are keys protected?
answer: | answer: |
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. 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? - question: How does PIN caching work with Windows Hello for Business?
answer: | 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. 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. 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.

View File

@ -7,7 +7,10 @@ ms.topic: concept-article
# How Windows Hello for Business works # How Windows Hello for Business works
Windows Hello for Business is a distributed system that requires multiple technologies to work together. To simplify the explanation of how Windows Hello for Business works, it can be broken down into five phases. Two of these phases are required only for certain deployment scenarios. Windows Hello for Business is a distributed system that requires multiple technologies to work together. To simplify the explanation of how Windows Hello for Business works, let's break it down into five phases. Two of these phases are required only for certain deployment scenarios.
> [!NOTE]
> The deployment scenarios are described in the article: [Plan a Windows Hello for Business deployment](deploy/index.md).
:::row::: :::row:::
:::column span=""::: :::column span="":::
@ -80,7 +83,7 @@ Windows Hello for Business is a distributed system that requires multiple techno
:::column span="3"::: :::column span="3":::
In this last phase, users can sign-in to Windows using biometrics or a PIN. Regardless of the gesture used, authentication occurs using the private portion of the Windows Hello for Business credential. In this last phase, users can sign-in to Windows using biometrics or a PIN. Regardless of the gesture used, authentication occurs using the private portion of the Windows Hello for Business credential.
The user provides a gesture, and the IdP validates the user identity by mapping the user account to the public key used during the key registration phase. The user provides a gesture, and the IdP validates the user identity by mapping the user account to the public key used during the provisioning phase.
:::column-end::: :::column-end:::
:::row-end::: :::row-end:::
@ -96,17 +99,23 @@ All devices included in the Windows Hello for Business deployment must go throug
When a device is registered, the IdP provides the device with an identity that is used to authenticate the device when a user signs-in. When a device is registered, the IdP provides the device with an identity that is used to authenticate the device when a user signs-in.
The device registration type is called *join type*. For more information, see [how device registration works](/entra/identity/devices/device-registration-how-it-works). The device registration type is called *join type*.
For more information and detailed sequence diagrams, see [how device registration works](/entra/identity/devices/device-registration-how-it-works).
## Provisioning ## Provisioning
The first step in the usage of Windows Hello is setting up a *container*. This is called the *provisioning* step.
Windows Hello provisioning is triggered once device registration completes, and after the device receives a policy that enables Windows Hello. A Cloud Experience Host (CXH) window is launched to take the user through the Windows Hello provisioning flow.
The IdP validates the user identity and maps the Windows Hello public key to a user account during the registration step. The IdP validates the user identity and maps the Windows Hello public key to a user account during the registration step.
The provisioning phase begins once device registration completes, and after the device receives a policy that enables Windows Hello for Business. The provisioning phase begins
1. When the policy is received, if all the prerequisites are met, the user can configure WHfB 1. When the policy is received, if all the prerequisites are met, the user is prompted to use Windows Hello
> [!NOTE] > [!NOTE]
> The list of prerequisites varies depending on the deployment tyep. > The list of prerequisites varies depending on the deployment type.
1. The user *enrolls* in Windows Hello by authenticating to the IdP with MFA 1. The user *enrolls* in Windows Hello by authenticating to the IdP with MFA
1. After successful MFA, the user must provide a bio gesture (if available) and PIN, which trigger a key pair generation and registration with the IdP 1. After successful MFA, the user must provide a bio gesture (if available) and PIN, which trigger a key pair generation and registration with the IdP
@ -126,14 +135,14 @@ The provisioning phase begins once device registration completes, and after the
Personal (Microsoft account) and Work or School (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. Personal (Microsoft account) and Work or School (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.
Windows Hello also generates an *administrative key*. The administrative key can be used to reset credentials when necessary. For example, when using the PIN reset service. In addition to the protector key, TPM-enabled devices generate a block of data that contains attestations from the TPM. Windows Hello also generates an *administrative key*. The administrative key can be used to reset credentials when necessary. For example, when using the [PIN reset service](pin-reset.md). In addition to the protector key, TPM-enabled devices generate a block of data that contains attestations from the TPM.
Access to these keys, and obtaining a signature to validate user possession of the private key, is enabled only by the PIN or biometric gesture. The two-step verification that takes place during Windows Hello enrollment creates a trusted relationship between the IdP and the user when the public portion of the public/private key pair is sent to an identity provider and associated with a user account. When a user enters the gesture on the device, the identity provider knows that it's a verified identity, because of the combination of Windows Hello keys and gestures. It then provides an authentication token that allows Windows to access resources and services. Access to these keys, and obtaining a signature to validate user possession of the private key, is enabled only by the PIN or biometric gesture. The two-step verification that takes place during Windows Hello enrollment creates a trusted relationship between the IdP and the user when the public portion of the public/private key pair is sent to an identity provider and associated with a user account. When a user enters the gesture on the device, the identity provider knows that it's a verified identity, because of the combination of Windows Hello keys and gestures. It then provides an authentication token that allows Windows to access resources and services.
The Device Registration Service writes the key to the user object in Microsoft Entra ID. The Device Registration Service writes the key to the user object in Microsoft Entra ID.
For on-premises scenarios, the key is written to Active Directory by AD FS. For on-premises scenarios, the key is written to Active Directory by AD FS.
For more information, see [how provisioning works](how-it-works-provisioning.md). For more information and detailed sequence diagrams, see [how provisioning works](how-it-works-provisioning.md).
To learn more how Windows uses the TPM in support of Windows Hello for Business, see [How Windows uses the Trusted Platform Module](../../hardware-security/tpm/how-windows-uses-the-tpm.md). To learn more how Windows uses the TPM in support of Windows Hello for Business, see [How Windows uses the Trusted Platform Module](../../hardware-security/tpm/how-windows-uses-the-tpm.md).
@ -158,7 +167,7 @@ For certificate deployments, after registering the key, the client generates a c
## Authentication ## Authentication
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. Windows Hello credentials are based on certificate or asymmetrical key pair. Windows Hello credentials, and the token that is obtained using those credentials, are bound to the device.
Authentication is the two-factor authentication with the combination of: Authentication is the two-factor authentication with the combination of:
@ -168,16 +177,16 @@ Authentication is the two-factor authentication with the combination of:
PIN entry and biometric gesture both trigger Windows 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. PIN entry and biometric gesture both trigger Windows 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.
The PIN or the private portion of the credential are ever sent to the IdP, and the PIN isn't stored on the device. The PIN and bio gestures are *user-provided entropy* when performing operations that use the private portion of the credential. The PIN or the private portion of the credential are never sent to the IdP, and the PIN isn't stored on the device. The PIN and bio gestures are *user-provided entropy* when performing operations that use the private portion of the credential.
When a user wants to access protected key material, the authentication process begins with the user entering a PIN or biometric gesture to unlock the device, a process sometimes called releasing the key. Think of it like using a physical key to unlock a door: before you can unlock the door, you need to remove the key from your pocket or purse. The user's PIN unlocks the protector key for the container on the device. When that container is unlocked, applications (and thus the user) can use whatever IDP keys reside inside the container. When a user wants to access protected key material, the authentication process begins with the user entering a PIN or biometric gesture to unlock the device, a process sometimes called *releasing the key*. Think of it like using a physical key to unlock a door: before you can unlock the door, you need to remove the key from your pocket or purse. The user's PIN unlocks the protector key for the container on the device. When that container is unlocked, applications (and thus the user) can use whatever IDP keys reside inside the container.
These keys are used to sign requests that are sent to the IdP, requesting access to specified resources. These keys are used to sign requests that are sent to the IdP, requesting access to specified resources.
> [!IMPORTANT] > [!IMPORTANT]
> Although the keys are unlocked, applications cannot use them at will. Applications can use specific APIs to request operations that require key material for particular actions (for example, decrypt an email message or sign in to a website). Access through these APIs doesn't require explicit validation through a user gesture, and the key material isn't exposed to the requesting application. Rather, the application asks for authentication, encryption, or decryption, and the Windows Hello layer handles the actual work and returns the results. Where appropriate, an application can request a forced authentication even on an unlocked device. Windows prompts the user to reenter the PIN or perform an authentication gesture, which adds an extra level of protection for sensitive data or actions. For example, you can configure an application to require re-authentication anytime a specific operation is performed, even though the same account and PIN or gesture were already used to unlock the device. > Although the keys are unlocked, applications cannot use them at will. Applications can use specific APIs to request operations that require key material for particular actions (for example, decrypt an email message or sign in to a website). Access through these APIs doesn't require explicit validation through a user gesture, and the key material isn't exposed to the requesting application. Rather, the application asks for authentication, encryption, or decryption, and the Windows Hello layer handles the actual work and returns the results. Where appropriate, an application can request a forced authentication even on an unlocked device. Windows prompts the user to reenter the PIN or perform an authentication gesture, which adds an extra level of protection for sensitive data or actions. For example, you can configure an application to require re-authentication anytime a specific operation is performed, even though the same account and PIN or gesture were already used to unlock the device.
For more information, read [how authentication works](how-it-works-authentication.md). For more information and detailed sequence diagrams, see [how authentication works](how-it-works-authentication.md).
### Primary refresh token ### Primary refresh token
@ -187,6 +196,11 @@ The PRT is initially obtained during sign-in or unlock in a similar way the Kerb
The PRT is needed for SSO. Without it, users would be prompted for credentials every time they access applications. 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) policies set on an application, without the PRT access is denied. The PRT is needed for SSO. Without it, users would be prompted for credentials every time they access applications. 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) policies set on an application, without the PRT access is denied.
> [!TIP]
> The Windows Hello for Business key meets Microsoft Entra multifactor authentication (MFA) requirements and reduces the number of MFA prompts users will see when accessing resources.
>
> For more information, see [What is a Primary Refresh Token](/azure/active-directory/devices/concept-primary-refresh-token#when-does-a-prt-get-an-mfa-claim).
### Windows Hello for Business and password changes ### Windows Hello for Business and password changes
Changing a user account password doesn't affect sign-in or unlock, since Windows Hello for Business uses a key or certificate. Changing a user account password doesn't affect sign-in or unlock, since Windows Hello for Business uses a key or certificate.

Binary file not shown.

After

Width:  |  Height:  |  Size: 730 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 52 KiB

After

Width:  |  Height:  |  Size: 129 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 9.1 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 1.4 MiB

After

Width:  |  Height:  |  Size: 758 KiB

View File

@ -18,12 +18,23 @@ Windows Hello for Business is two-factor authentication based on the observed au
When using Windows Hello for Business, the PIN isn't a symmetric key, whereas the password is a symmetric key. With passwords, there's a server that has some representation of the password. With Windows Hello for Business, the PIN is user-provided entropy used to load the private key in the Trusted Platform Module (TPM). The server doesn't have a copy of the PIN. For that matter, the Windows client doesn't have a copy of the current PIN either. The user must provide the entropy, the TPM-protected key, and the TPM that generated that key in order to successfully access the private key. When using Windows Hello for Business, the PIN isn't a symmetric key, whereas the password is a symmetric key. With passwords, there's a server that has some representation of the password. With Windows Hello for Business, the PIN is user-provided entropy used to load the private key in the Trusted Platform Module (TPM). The server doesn't have a copy of the PIN. For that matter, the Windows client doesn't have a copy of the current PIN either. The user must provide the entropy, the TPM-protected key, and the TPM that generated that key in order to successfully access the private key.
The statement *PIN is stronger than Password* is not directed at the strength of the entropy used by the PIN. It's about the difference between providing entropy versus continuing the use of a symmetric key (the password). The TPM has anti-hammering features that thwart brute-force PIN attacks (an attacker's continuous attempt to try all combination of PINs). Some organizations may worry about shoulder surfing. For those organizations, rather than increase the complexity of the PIN, implement the [Multifactor Unlock](multifactor-unlock.md) feature. The statement *PIN is stronger than Password* is not directed at the strength of the entropy used by the PIN. It's about the difference between providing entropy versus continuing the use of a symmetric key (the password). The TPM has anti-hammering features that thwart brute-force PIN attacks (an attacker's continuous attempt to try all combination of PINs). Some organizations may worry about shoulder surfing. For those organizations, rather than increase the complexity of the PIN, implement the [Multifactor Unlock](multifactor-unlock.md) feature.
> [!TIP]
> The Windows Hello for Business key meets Microsoft Entra multifactor authentication (MFA) requirements and reduces the number of MFA prompts users will see when accessing resources.
>
> For more information, see [What is a Primary Refresh Token](/azure/active-directory/devices/concept-primary-refresh-token#when-does-a-prt-get-an-mfa-claim).
--> -->
Windows Hello is an authentication technology built into Windows, targeted at both consumer and organizations. Windows Hello is designed to provide enhanced security and improved ease of use when compared with passwords.
Security
On devices with a TPM, Windows Hello provides enhanced security through phish-resistant two-factor authentication. Authentication requires a PIN (something the user knows) or biometric data (something the user is), coupled with possession of the device itself containing the hardware-bound credential (something the user has). There is no symmetric secret (password) which can be stolen from a server or phished from a user and used remotely.
Ease of use
With compatible hardware, the user can log in with face or fingerprint, which is much easier and more convenient than typing in a credential. For users without biometrics, a PIN can be shorter and easier to remember than a complex password. The use of a PIN doesn't compromise security, since Windows Hello has built-in brute force protection and the PIN never leaves the device.
With FIDO/WebAuthn, Windows Hello can also be used to log in to supported websites, which reduces the need to remember or manage multiple complex passwords for a user's online accounts.
Windows Hello is an authentication feature that allows users to sign in to their Windows devices using a PIN, facial recognition, fingerprint scanning, or iris scanning, instead of a traditional password. Windows Hello is an authentication feature that allows users to sign in to their Windows devices using a PIN, facial recognition, fingerprint scanning, or iris scanning, instead of a traditional password.
Windows Hello addresses the following problems with passwords: Windows Hello addresses the following problems with passwords: