mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-18 11:53:37 +00:00
updates
This commit is contained in:
@ -28,34 +28,20 @@ sections:
|
|||||||
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. It's important to understand that 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.
|
These keys are used to sign requests that are sent to the IDP, requesting access to specified resources. It's important to understand that 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 about the different authentication flows used by Windows Hello for Business, see [Windows Hello for Business and Authentication](hello-how-it-works-authentication.md)
|
For more information about the different authentication flows used by Windows Hello for Business, see [Windows Hello for Business and Authentication](hello-how-it-works-authentication.md)
|
||||||
- question: Can I disable the PIN while using Windows Hello for Business?
|
- question: What happens after a user registers a PIN during the Windows Hello for Business enrollment process?
|
||||||
answer: |
|
|
||||||
No. The movement away from passwords is accomplished by gradually reducing the use of the password. In situations where you can't authenticate by using biometrics, you need a fallback mechanism that isn't a password. The PIN is the fallback mechanism. Disabling or hiding the PIN credential provider will disable the use of biometrics.
|
|
||||||
- question: What happens after a user registers a PIN during the Windows Hello for Business enrollmnet process?
|
|
||||||
answer: |
|
answer: |
|
||||||
Windows Hello generates a new public-private key pair on the device. The TPM generates and protects this private key; if the device doesn't have a TPM, the private key is encrypted and stored in software. This initial key is referred to as the *protector key*. It's associated only with a single gesture; in other words, if a user registers a PIN, a fingerprint, and a face on the same device, each of those gestures will have a unique protector key. **Each unique gesture generates a unique protector key**. The protector key securely wraps the *authentication key*. The container has only one authentication key, but there can be multiple copies of that key wrapped with different unique protector keys. Windows Hello also generates an administrative key that the user or administrator can use to reset credentials, when necessary (for example, wehn 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 generates a new public-private key pair on the device. The TPM generates and protects this private key; if the device doesn't have a TPM, the private key is encrypted and stored in software. This initial key is referred to as the *protector key*. It's associated only with a single gesture; in other words, if a user registers a PIN, a fingerprint, and a face on the same device, each of those gestures will have a unique protector key. **Each unique gesture generates a unique protector key**. The protector key securely wraps the *authentication key*. The container has only one authentication key, but there can be multiple copies of that key wrapped with different unique protector keys. Windows Hello also generates an administrative key that the user or administrator can use to reset credentials, when necessary (for example, wehn 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.
|
||||||
At this point, the user has a PIN gesture defined on the device and an associated protector key for that PIN gesture. That means the user is able to securely sign in to the device with the PIN and thus be able to establish a trusted session with the device to add support for a biometric gesture as an alternative for the PIN. When you add a biometric gesture, it follows the same basic sequence: the user authenticates to the system by using the PIN, and then registers the new biometric, after which Windows generates a unique key pair and stores it securely. Future sign-ins can then use either the PIN or the registered biometric gestures.
|
At this point, the user has a PIN gesture defined on the device and an associated protector key for that PIN gesture. That means the user is able to securely sign in to the device with the PIN and thus be able to establish a trusted session with the device to add support for a biometric gesture as an alternative for the PIN. When you add a biometric gesture, it follows the same basic sequence: the user authenticates to the system by using the PIN, and then registers the new biometric, after which Windows generates a unique key pair and stores it securely. Future sign-ins can then use either the PIN or the registered biometric gestures.
|
||||||
- question: What's a container?
|
- question: What's a container?
|
||||||
answer: |
|
answer: |
|
||||||
In the context of Windows Hello for Business, it's shorthand for 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 a workplace or school account.
|
||||||
The container holds enterprise credentials only on devices that have been registered with an organization; it contains key material for the enterprise IDP, such as on-premises Active Directory or Azure AD.
|
The container holds enterprise credentials only on devices that have been registered with an organization; it contains key material for the enterprise IDP, such as on-premises Active Directory or Azure AD.
|
||||||
Note that 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 of Windows Hello stores, are protected without the creation of actual containers or folders.
|
Note that 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 of 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 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.\
|
||||||
:::image type="content" source="images/passport-fig3-logicalcontainer.png" alt-text="logical container with set of keys":::
|
:::image type="content" source="images/passport-fig3-logicalcontainer.png" alt-text="logical container with set of keys":::
|
||||||
- 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 Work implementation takes advantage of onboard TPM hardware to generate and protect keys. Administrators can choose to allow key operations in software but, whenever possible, 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 meansthe 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 meansthe 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: Does Windows Hello for Business work with non-Windows operating systems?
|
|
||||||
answer: |
|
|
||||||
Windows Hello for Business is a feature of the Windows platform. At this time, Microsoft isn't developing clients for other platforms. However, Microsoft is open to third-parties who are interested in moving these platforms away from passwords. Interested third-parties can get more information by emailing [whfbfeedback@microsoft.com](mailto:whfbfeedback@microsoft.com?subject=collaboration).
|
|
||||||
- question: Does Windows Hello for Business work with Azure Active Directory Domain Services (Azure AD DS) clients?
|
|
||||||
answer: |
|
|
||||||
No, Azure AD DS is a separately managed environment in Azure, and hybrid device registration with cloud Azure AD isn't available for it via Azure AD Connect. Hence, Windows Hello for Business doesn't work with Azure AD DS.
|
|
||||||
- question: How are keys protected?
|
|
||||||
answer: |
|
|
||||||
Wherever possible, Windows Hello for Business takes advantage of Trusted Platform Module (TPM) 2.0 hardware to generate and protect keys. However, Windows Hello and Windows Hello for Business don't require a TPM. Administrators can choose to allow key operations in software.
|
|
||||||
|
|
||||||
Whenever possible, Microsoft strongly recommends the use of TPM hardware. The TPM protects against various 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 need to reset the PIN (which means they'll need to use MFA to reauthenticate to the IDP before the IDP allows them to re-register).
|
|
||||||
- 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. Azure AD and Active Directory sign-in keys are cached under lock. This means the keys remain available for use without prompting, as long as the user is interactively signed-in. Microsoft Account sign-in keys are transactional keys, which means the user is always prompted when accessing the key.
|
Windows Hello for Business provides a PIN caching user experience by using a ticketing system. Rather than caching a PIN, processes cache a ticket they can use to request private key operations. Azure AD and Active Directory sign-in keys are cached under lock. This means the keys remain available for use without prompting, as long as the user is interactively signed-in. Microsoft Account sign-in keys are transactional keys, which means the user is always prompted when accessing the key.
|
||||||
@ -63,7 +49,26 @@ sections:
|
|||||||
Beginning with Windows 10, version 1709, Windows Hello for Business used as a smart card (smart card emulation that is enabled by default) provides the same user experience of default smart card PIN caching. Each process requesting a private key operation will prompt the user for the PIN on first use. Subsequent private key operations won't prompt the user for the PIN.
|
Beginning with Windows 10, version 1709, Windows Hello for Business used as a smart card (smart card emulation that is enabled by default) provides the same user experience of default smart card PIN caching. Each process requesting a private key operation will prompt the user for the PIN on first use. Subsequent private key operations won't prompt the user for the PIN.
|
||||||
|
|
||||||
The smart card emulation feature of Windows Hello for Business verifies the PIN and then discards the PIN in exchange for a ticket. The process doesn't receive the PIN, but rather the ticket that grants them private key operations. Windows 10 doesn't provide any Group Policy settings to adjust this caching.
|
The smart card emulation feature of Windows Hello for Business verifies the PIN and then discards the PIN in exchange for a ticket. The process doesn't receive the PIN, but rather the ticket that grants them private key operations. Windows 10 doesn't provide any Group Policy settings to adjust this caching.
|
||||||
|
- question: Where is Windows Hello biometrics data stored?
|
||||||
|
answer: |
|
||||||
|
When you enroll in Windows Hello, a representation of your biometrics, called an enrollment profile, is created more information can be found on [Windows Hello face authentication](/windows-hardware/design/device-experiences/windows-hello-face-authentication). This enrollment profile biometrics data is device specific, is stored locally on the device, and does not leave the device or roam with the user. Some external fingerprint sensors store biometric data on the fingerprint module itself rather than on Windows device. Even in this case, the biometrics data is stored locally on those modules, is device specific, doesn't roam, never leaves the module, and is never sent to Microsoft cloud or external server. For more details, see [Windows Hello biometrics in the enterprise](/windows/security/identity-protection/hello-for-business/hello-biometrics-in-enterprise#where-is-windows-hello-data-stored).
|
||||||
|
- question: What is the format used to store Windows Hello biometrics data on the device?
|
||||||
|
answer: |
|
||||||
|
Windows Hello biometrics data is stored on the device as an encrypted template database. The data from the biometrics sensor (like face camera or fingerprint reader) creates a data representation—or graph—that is then encrypted before it's stored on the device. Each biometrics sensor on the device which is used by Windows Hello (face or fingerprint) will have its own biometric database file where template data is stored. Each biometrics database file is encrypted with unique, randomly generated key that is encrypted to the system using AES encryption producing an SHA256 hash.
|
||||||
|
- question: Who has access on Windows Hello biometrics data?
|
||||||
|
answer: |
|
||||||
|
Since Windows Hello biometrics data is stored in encrypted format, no user, or any process other than Windows Hello has access to it.
|
||||||
|
- question: What's the difference between non-destructive and destructive PIN reset?
|
||||||
|
answer: |
|
||||||
|
Windows Hello for Business has two types of PIN reset: non-destructive and destructive. Organizations running Windows 10 version 1903 and later and Azure Active Directory can take advantage of the Microsoft PIN Reset service. Once on-boarded to a tenant and deployed to computers, users who have forgotten their PINs can authenticate to Azure, provide a second factor of authentication, and reset their PIN without reprovisioning a new Windows Hello for Business enrollment. This flow is a non-destructive PIN reset because the user doesn't delete the current credential and obtain a new one. For more information, see [PIN Reset](hello-feature-pin-reset.md).
|
||||||
|
|
||||||
|
Organizations that have the on-premises deployment of Windows Hello for Business, or those not using Windows 10 version 1903 and later can use destructive PIN reset. With destructive PIN reset, users that have forgotten their PIN can authenticate by using their password and then performing a second factor of authentication to reprovision their Windows Hello for Business credential. Reprovisioning deletes the old credential and requests a new credential and certificate. On-premises deployments need network connectivity to their domain controllers, Active Directory Federation Services, and their issuing certificate authority to perform a destructive PIN reset. For hybrid Azure Active Directory joined devices, destructive PIN reset is only supported with the certificate trust model and the latest updates to Active Directory Federation Services.
|
||||||
|
- question: When is Windows Hello biometrics database file created? How is a user enrolled into Windows Hello face or fingerprint authentication?
|
||||||
|
answer: |
|
||||||
|
Windows Hello biometrics template database file is created on the device only when a user is enrolled into Windows Hello biometrics-based authentication. Your workplace or IT administrator may have turned certain authentication functionality, however, it is always your choice if you want to use Windows Hello or an alternative method, like a PIN. Users can check their current enrollment into Windows Hello biometrics by going to sign-in options on their device. Go to **Start > Settings > Accounts > Sign-in** options. If you don't see Windows Hello in Sign-in options, then it may not be available for your device or blocked by admin via policy. Admins can request users to enroll into Windows Hello during Autopilot or during the initial setup of the device. Admins can disallow users to enroll into biometrics via Windows Hello for Business policy configurations. However, when allowed via policy configurations, enrollment into Windows Hello biometrics is always optional for users.
|
||||||
|
- question: When is Windows Hello biometrics database file deleted? How can a user be unenrolled from Windows Hello face or fingerprint authentication?
|
||||||
|
answer: |
|
||||||
|
To remove Windows Hello and any associated biometric identification data from the device, user can go to **Start > Settings > Accounts > Sign-in options**. Select the Windows Hello biometrics authentication method you want to remove, and then select **Remove**. This will u-enroll the user from Windows Hello biometrics authentication and will also delete the associated biometrics template database file. For more details, see [Windows sign-in options and account protection (microsoft.com)](https://support.microsoft.com/en-us/windows/windows-sign-in-options-and-account-protection-7b34d4cf-794f-f6bd-ddcc-e73cdf1a6fbf#bkmk_helloandprivacy).
|
||||||
|
|
||||||
- name: Management and operations
|
- name: Management and operations
|
||||||
questions:
|
questions:
|
||||||
@ -93,7 +98,16 @@ sections:
|
|||||||
- The PIN 1872 doesn't have a constant delta (7,9,5), so it's allowed
|
- The PIN 1872 doesn't have a constant delta (7,9,5), so it's allowed
|
||||||
|
|
||||||
This check prevents repeating numbers, sequential numbers, and simple patterns. It always results in a list of 100 disallowed PINs (independent of the PIN length). This algorithm doesn't apply to alphanumeric PINs.
|
This check prevents repeating numbers, sequential numbers, and simple patterns. It always results in a list of 100 disallowed PINs (independent of the PIN length). This algorithm doesn't apply to alphanumeric PINs.
|
||||||
|
- question: Which diagnostic data is collected when Windows Hello for Business is enabled?
|
||||||
|
answer: |
|
||||||
|
To help Microsoft keep things working properly, to help detecting and preventing fraud, and to continue improving Windows Hello, diagnostic data about how people use Windows Hello is collected. For example:
|
||||||
|
- Data about whether people sign in with their face, iris, fingerprint, or PIN
|
||||||
|
- The number of times they use it
|
||||||
|
- Whether it works or not
|
||||||
|
All this is valuable information that helps Microsoft building a better product. The data is pseudonymized, does not include biometric information, and is encrypted before it is transmitted to Microsoft. You can choose to stop sending diagnostic data to Microsoft at any time. [Learn more about diagnostic data in Windows](https://support.microsoft.com/en-us/windows/diagnostics-feedback-and-privacy-in-windows-28808a2b-a31b-dd73-dcd3-4559a5199319).
|
||||||
|
- question: Can I disable the PIN while using Windows Hello for Business?
|
||||||
|
answer: |
|
||||||
|
No. The movement away from passwords is accomplished by gradually reducing the use of the password. In situations where you can't authenticate by using biometrics, you need a fallback mechanism that isn't a password. The PIN is the fallback mechanism. Disabling or hiding the PIN credential provider will disable the use of biometrics.
|
||||||
|
|
||||||
- name: Design and planning
|
- name: Design and planning
|
||||||
questions:
|
questions:
|
||||||
@ -128,13 +142,53 @@ sections:
|
|||||||
- question: Can I wear a mask to enroll or unlock using Windows Hello face authentication?
|
- question: Can I wear a mask to enroll or unlock using Windows Hello face authentication?
|
||||||
answer: |
|
answer: |
|
||||||
Wearing a mask to enroll is a security concern because other users wearing a similar mask may be able to unlock your device. The product group is aware of this behavior and is investigating this article further. Remove a mask if you're wearing one when you enroll or unlock with Windows Hello face authentication. If your working environment doesn't allow you to remove a mask temporarily, consider un-enrolling from face authentication and only using PIN or fingerprint.
|
Wearing a mask to enroll is a security concern because other users wearing a similar mask may be able to unlock your device. The product group is aware of this behavior and is investigating this article further. Remove a mask if you're wearing one when you enroll or unlock with Windows Hello face authentication. If your working environment doesn't allow you to remove a mask temporarily, consider un-enrolling from face authentication and only using PIN or fingerprint.
|
||||||
|
- question: What are the biometric requirements for Windows Hello for Business?
|
||||||
|
answer: |
|
||||||
|
Read [Windows Hello biometric requirements](/windows-hardware/design/device-experiences/windows-hello-biometric-requirements) for more information.
|
||||||
|
- question: How does Windows Hello for Business work with Azure AD registered devices?
|
||||||
|
answer: |
|
||||||
|
A user will be prompted to set up a Windows Hello for Business key on an Azure AD registered devices if the feature is enabled by policy. If the user has an existing Windows Hello container, the Windows Hello for Business key will be enrolled in that container and will be protected using existing gestures.
|
||||||
|
|
||||||
|
If a user has signed into their Azure AD registered device with Windows Hello, their Windows Hello for Business key will be used to authenticate the user's work identity when they try to use Azure AD resources. The Windows Hello for Business key meets Azure AD multi-factor authentication (MFA) requirements and reduces the number of MFA prompts users will see when accessing resources.
|
||||||
|
|
||||||
|
It's possible to Azure AD register a domain joined device. If the domain joined device has a convenience PIN, sign in with the convenience PIN will no longer work. This configuration isn't supported by Windows Hello for Business.
|
||||||
|
|
||||||
|
For more information, please read [Azure AD registered devices](/azure/active-directory/devices/concept-azure-ad-register).
|
||||||
|
- question: Does Windows Hello for Business work with non-Windows operating systems?
|
||||||
|
answer: |
|
||||||
|
Windows Hello for Business is a feature of the Windows platform. At this time, Microsoft isn't developing clients for other platforms. However, Microsoft is open to third-parties who are interested in moving these platforms away from passwords. Interested third-parties can get more information by emailing [whfbfeedback@microsoft.com](mailto:whfbfeedback@microsoft.com?subject=collaboration).
|
||||||
|
- question: Does Windows Hello for Business work with Azure Active Directory Domain Services (Azure AD DS) clients?
|
||||||
|
answer: |
|
||||||
|
No, Azure AD DS is a separately managed environment in Azure, and hybrid device registration with cloud Azure AD isn't available for it via Azure AD Connect. Hence, Windows Hello for Business doesn't work with Azure AD DS.
|
||||||
|
- question: Is Windows Hello for Business considered multi-factor authentication?
|
||||||
|
answer: |
|
||||||
|
Windows Hello for Business is two-factor authentication based on the observed authentication factors of: *something you have*, *something you know*, and *something that's part of you*. Windows Hello for Business incorporates two of these factors: something you have (the user's private key protected by the device's security module) and something you know (your PIN). With the proper hardware, you can enhance the user experience by introducing biometrics. By using biometrics, you can replace the "something you know" authentication factor with the "something that is part of you" factor, with the assurances that users can fall back to the "something you know factor".
|
||||||
|
|
||||||
|
> [!NOTE]
|
||||||
|
> The Windows Hello for Business key meets Azure AD multi-factor authentication (MFA) requirements and reduces the number of MFA prompts users will see when accessing resources.
|
||||||
|
- question: Which is a better or more secure for of authentication, key or certificate?
|
||||||
|
answer: |
|
||||||
|
Both types of authentication provide the same security; one is not more secure than the other.
|
||||||
|
The trust models of your deployment determine how you authenticate to Active Directory (on-premises). Both key trust and certificate trust use the same hardware-backed, two-factor credential. The differences between the two trust types is the issuing end entity certificates:
|
||||||
|
- The *key trust* model authenticates to Active Directory by using a raw key. Key trust authenticate doesn't require an enterprise issued certificate, therefore you don't need to issue certificates to users (domain controller certificates are still needed)
|
||||||
|
- The *certificate trust* model authenticates to Active Directory by using a certificate. Therefore, you need to issue certificates to users. The certificate used in certificate trust uses the TPM-protected private key to request a certificate from your enterprise's issuing CA.
|
||||||
|
- question: Can I use a *convenience PIN* with Azure Active Directory?
|
||||||
|
answer: |
|
||||||
|
No. While it's possible to set a convenience PIN on Azure AD joined and hybrid Azure AD joined devices, convenience PIN isn't supported for Azure AD user accounts (including synchronized identities). Convenience PIN is only supported for on-premises Active Directory users and local account users.
|
||||||
|
- question: What URLs do I need to allow for a hybrid deployment?
|
||||||
|
answer: |
|
||||||
|
For a list of required URLs, see [Microsoft 365 Common and Office Online](/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide#microsoft-365-common-and-office-online).
|
||||||
|
|
||||||
|
If your environment uses Microsoft Intune, see [Network endpoints for Microsoft Intune](/mem/intune/fundamentals/intune-endpoints).
|
||||||
|
|
||||||
- name: Features
|
- name: Features
|
||||||
questions:
|
questions:
|
||||||
- question: Can I use an external Windows Hello compatible camera when my computer has a built-in Windows Hello compatible camera?
|
- question: Can I use an external Windows Hello compatible camera when my computer has a built-in Windows Hello compatible camera?
|
||||||
answer: |
|
answer: |
|
||||||
Yes. Starting with Windows 10, version 21H1 an external Windows Hello compatible camera can be used if a device already supports an internal Windows Hello camera. When both cameras are present, the external camera is used for face authentication. For more information, see [IT tools to support Windows 10, version 21H1](https://techcommunity.microsoft.com/t5/windows-it-pro-blog/it-tools-to-support-windows-10-version-21h1/ba-p/2365103). However, using external Hello cameras and accessories is restricted if ESS is enabled, please see [Windows Hello Enhanced Sign-in Security](/windows-hardware/design/device-experiences/windows-hello-enhanced-sign-in-security#pluggableperipheral-biometric-sensors).
|
Yes. Starting with Windows 10, version 21H1 an external Windows Hello compatible camera can be used if a device already supports an internal Windows Hello camera. When both cameras are present, the external camera is used for face authentication. For more information, see [IT tools to support Windows 10, version 21H1](https://techcommunity.microsoft.com/t5/windows-it-pro-blog/it-tools-to-support-windows-10-version-21h1/ba-p/2365103). However, using external Hello cameras and accessories is restricted if ESS is enabled, please see [Windows Hello Enhanced Sign-in Security](/windows-hardware/design/device-experiences/windows-hello-enhanced-sign-in-security#pluggableperipheral-biometric-sensors).
|
||||||
|
- question: Can I use an external Windows Hello compatible camera or other Windows Hello compatible accessory when my laptop lid is closed or docked?
|
||||||
|
answer: |
|
||||||
|
Some laptops and tablets with keyboards that close may not use an external Windows Hello compatible camera or other Windows Hello compatible accessory when the computer is docked with the lid closed. The issue has been addressed in Windows 11, version 22H2.
|
||||||
- question: What about virtual smart cards?
|
- question: What about virtual smart cards?
|
||||||
answer: |
|
answer: |
|
||||||
Windows Hello for Business is the modern, two-factor credential for Windows. Microsoft will be deprecating virtual smart cards in the future, but no date is set at this time. Customers using virtual smart cards should move to Windows Hello for Business. Microsoft will publish the date early to ensure customers have adequate lead time to move to Windows Hello for Business. Microsoft recommends that new Windows deployments use Windows Hello for Business.
|
Windows Hello for Business is the modern, two-factor credential for Windows. Microsoft will be deprecating virtual smart cards in the future, but no date is set at this time. Customers using virtual smart cards should move to Windows Hello for Business. Microsoft will publish the date early to ensure customers have adequate lead time to move to Windows Hello for Business. Microsoft recommends that new Windows deployments use Windows Hello for Business.
|
||||||
@ -150,109 +204,9 @@ sections:
|
|||||||
- question: Can I use Windows Hello for Business credentials in private browser mode or "incognito" mode?
|
- question: Can I use Windows Hello for Business credentials in private browser mode or "incognito" mode?
|
||||||
answer: |
|
answer: |
|
||||||
Windows Hello for Business credentials need access to device state, which is not available in private browser mode or incognito mode. Hence it can't be used in private browser or Incognito mode.
|
Windows Hello for Business credentials need access to device state, which is not available in private browser mode or incognito mode. Hence it can't be used in private browser or Incognito mode.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
- question: How does Windows Hello for Business work with Azure AD registered devices?
|
|
||||||
answer: |
|
|
||||||
A user will be prompted to set up a Windows Hello for Business key on an Azure AD registered devices if the feature is enabled by policy. If the user has an existing Windows Hello container, the Windows Hello for Business key will be enrolled in that container and will be protected using their existing gestures.
|
|
||||||
|
|
||||||
If a user has signed into their Azure AD registered device with Windows Hello, their Windows Hello for Business key will be used to authenticate the user's work identity when they try to use Azure AD resources. The Windows Hello for Business key meets Azure AD multi-factor authentication (MFA) requirements and reduces the number of MFA prompts users will see when accessing resources.
|
|
||||||
|
|
||||||
It's possible to Azure AD register a domain joined device. If the domain joined device has a convenience PIN, sign in with the convenience PIN will no longer work. This configuration isn't supported by Windows Hello for Business.
|
|
||||||
|
|
||||||
For more information, please read [Azure AD registered devices](/azure/active-directory/devices/concept-azure-ad-register).
|
|
||||||
|
|
||||||
- question: Can I use a convenience PIN with Azure Active Directory?
|
|
||||||
answer: |
|
|
||||||
It's currently possible to set a convenience PIN on Azure Active Directory Joined or Hybrid Active Directory Joined devices. However, convenience PIN isn't supported for Azure Active Directory user accounts (synchronized identities included). It's only supported for on-premises Domain Joined users and local account users.
|
|
||||||
|
|
||||||
|
|
||||||
- question: Can I use an external Windows Hello compatible camera or other Windows Hello compatible accessory when my laptop lid is closed or docked?
|
|
||||||
answer: |
|
|
||||||
Some laptops and tablets with keyboards that close may not use an external Windows Hello compatible camera or other Windows Hello compatible accessory when the computer is docked with the lid closed. The issue has been addressed in Windows 11, version 22H2.
|
|
||||||
|
|
||||||
- question: Why does authentication fail immediately after provisioning hybrid key trust?
|
|
||||||
answer: |
|
|
||||||
In a hybrid deployment, a user's public key must sync from Azure AD to AD before it can be used to authenticate against a domain controller. This sync is handled by Azure AD Connect and will occur during a normal sync cycle.
|
|
||||||
|
|
||||||
- question: What is the password-less strategy?
|
|
||||||
answer: |
|
|
||||||
Watch Principal Program Manager Karanbir Singh's **Microsoft's guide for going password-less** Ignite 2017 presentation.
|
|
||||||
|
|
||||||
[Microsoft's password-less strategy](hello-videos.md#microsofts-passwordless-strategy)
|
|
||||||
|
|
||||||
- question: What is the user experience for Windows Hello for Business?
|
|
||||||
answer: |
|
|
||||||
The user experience for Windows Hello for Business occurs after the user signs in, after you deploy Windows Hello for Business policy settings to your environment.
|
|
||||||
|
|
||||||
|
|
||||||
- question: What URLs do I need to allow for a hybrid deployment?
|
|
||||||
answer: |
|
|
||||||
Communicating with Azure Active Directory uses the following URLs:
|
|
||||||
- enterpriseregistration.windows.net
|
|
||||||
- login.microsoftonline.com
|
|
||||||
- login.windows.net
|
|
||||||
- account.live.com
|
|
||||||
- accountalt.azureedge.net
|
|
||||||
- secure.aadcdn.microsoftonline-p.com
|
|
||||||
|
|
||||||
If your environment uses Microsoft Intune, you will also need these other URLs:
|
|
||||||
- enrollment.manage.microsoft.com
|
|
||||||
- portal.manage.microsoft.com
|
|
||||||
|
|
||||||
- question: What's the difference between non-destructive and destructive PIN reset?
|
|
||||||
answer: |
|
|
||||||
Windows Hello for Business has two types of PIN reset: non-destructive and destructive. Organizations running Windows 10 version 1903 and later and Azure Active Directory can take advantage of the Microsoft PIN Reset service. Once on-boarded to a tenant and deployed to computers, users who have forgotten their PINs can authenticate to Azure, provide a second factor of authentication, and reset their PIN without reprovisioning a new Windows Hello for Business enrollment. This flow is a non-destructive PIN reset because the user doesn't delete the current credential and obtain a new one. For more information, see [PIN Reset](hello-feature-pin-reset.md).
|
|
||||||
|
|
||||||
Organizations that have the on-premises deployment of Windows Hello for Business, or those not using Windows 10 version 1903 and later can use destructive PIN reset. With destructive PIN reset, users that have forgotten their PIN can authenticate by using their password and then performing a second factor of authentication to reprovision their Windows Hello for Business credential. Reprovisioning deletes the old credential and requests a new credential and certificate. On-premises deployments need network connectivity to their domain controllers, Active Directory Federation Services, and their issuing certificate authority to perform a destructive PIN reset. For hybrid Azure Active Directory joined devices, destructive PIN reset is only supported with the certificate trust model and the latest updates to Active Directory Federation Services.
|
|
||||||
|
|
||||||
- question: |
|
|
||||||
Which is a better or more secure for of authentication, key or certificate?
|
|
||||||
answer: |
|
|
||||||
Both types of authentication provide the same security; one is not more secure than the other.
|
|
||||||
The trust models of your deployment determine how you authenticate to Active Directory (on-premises). Both key trust and certificate trust use the same hardware-backed, two-factor credential. The differences between the two trust types is the issuing end entity certificates:
|
|
||||||
- The *key trust* model authenticates to Active Directory by using a raw key. Key trust authenticate doesn't require an enterprise issued certificate, therefore you don't need to issue certificates to users (domain controller certificates are still needed)
|
|
||||||
- The *certificate trust* model authenticates to Active Directory by using a certificate. Therefore, you need to issue certificates to users. The certificate used in certificate trust uses the TPM-protected private key to request a certificate from your enterprise's issuing CA.
|
|
||||||
|
|
||||||
|
|
||||||
- question: Is Windows Hello for Business multi-factor authentication?
|
|
||||||
answer: |
|
|
||||||
Windows Hello for Business is two-factor authentication based on the observed authentication factors of: something you have, something you know, and something that's part of you. Windows Hello for Business incorporates two of these factors: something you have (the user's private key protected by the device's security module) and something you know (your PIN). With the proper hardware, you can enhance the user experience by introducing biometrics. By using biometrics, you can replace the "something you know" authentication factor with the "something that is part of you" factor, with the assurances that users can fall back to the "something you know factor".
|
|
||||||
|
|
||||||
- question: Where is Windows Hello biometrics data stored?
|
|
||||||
answer: |
|
|
||||||
When you enroll in Windows Hello, a representation of your face called an enrollment profile is created more information can be found on [Windows Hello face authentication](/windows-hardware/design/device-experiences/windows-hello-face-authentication). This enrollment profile biometrics data is device specific, is stored locally on the device, and does not leave the device or roam with the user. Some external fingerprint sensors store biometric data on the fingerprint module itself rather than on Windows device. Even in this case, the biometrics data is stored locally on those modules, is device specific, doesn't roam, never leaves the module, and is never sent to Microsoft cloud or external server. For more details, see [Windows Hello biometrics in the enterprise](/windows/security/identity-protection/hello-for-business/hello-biometrics-in-enterprise#where-is-windows-hello-data-stored).
|
|
||||||
|
|
||||||
- question: What is the format used to store Windows Hello biometrics data on the device?
|
|
||||||
answer: |
|
|
||||||
Windows Hello biometrics data is stored on the device as an encrypted template database. The data from the biometrics sensor (like face camera or fingerprint reader) creates a data representation—or graph—that is then encrypted before it’s stored on the device. Each biometrics sensor on the device which is used by Windows Hello (face or fingerprint) will have its own biometric database file where template data is stored. Each biometrics database file is encrypted with unique, randomly generated key that is encrypted to the system using AES encryption producing an SHA256 hash.
|
|
||||||
|
|
||||||
- question: Who has access on Windows Hello biometrics data?
|
|
||||||
answer: |
|
|
||||||
Since Windows Hello biometrics data is stored in encrypted format, no user, or any process other than Windows Hello has access to it.
|
|
||||||
|
|
||||||
- question: When is Windows Hello biometrics database file created? How is a user enrolled into Windows Hello face or fingerprint authentication?
|
|
||||||
answer: |
|
|
||||||
Windows Hello biometrics template database file is created on the device only when a user is enrolled into Windows Hello biometrics-based authentication. Your workplace or IT administrator may have turned certain authentication functionality, however, it is always your choice if you want to use Windows Hello or an alternative method, like a pin. Users can check their current enrollment into Windows Hello biometrics by going to sign-in options on their device. Go to **Start** > **Settings** > **Accounts** > **Sign-in** options. Or just select on **Go to Sign-in options**. To enroll into Windows Hello, user can go to **Start** > **Settings** > **Accounts** > **Sign-in** options, select the Windows Hello method that they want to set up, and then select **Set up**. If you don't see Windows Hello in Sign-in options, then it may not be available for your device or blocked by admin via policy. Admins can by policy request users to enroll into Windows Hello during autopilot or during initial setup of the device. Admins can disallow users to enroll into biometrics via Windows hello for business policy configurations. However, when allowed via policy configurations, enrollment into Windows Hello biometrics is always optional for users.
|
|
||||||
|
|
||||||
- question: When is Windows Hello biometrics database file deleted? How can a user be unenrolled from Windows Hello face or fingerprint authentication?
|
|
||||||
answer: |
|
|
||||||
To remove Windows Hello and any associated biometric identification data from the device, user can go to **Start** > **Settings** > **Accounts** > **Sign-in options**. Select the Windows Hello biometrics authentication method you want to remove, and then select **Remove**. This will unenroll the user from Windows Hello biometrics auth and will also delete the associated biometrics template database file. For more details, see [Windows sign-in options and account protection (microsoft.com)](https://support.microsoft.com/en-us/windows/windows-sign-in-options-and-account-protection-7b34d4cf-794f-f6bd-ddcc-e73cdf1a6fbf#bkmk_helloandprivacy).
|
|
||||||
|
|
||||||
- question: What about any diagnostic data coming out when WHFB is enabled?
|
|
||||||
answer: |
|
|
||||||
To help us keep things working properly, to help detect and prevent fraud, and to continue improving Windows Hello, we collect diagnostic data about how people use Windows Hello. For example, data about whether people sign in with their face, iris, fingerprint, or PIN; the number of times they use it; and whether it works or not is all valuable information that helps us build a better product. The data is pseudonymized, does not include biometric information, and is encrypted before it is transmitted to Microsoft. You can choose to stop sending diagnostic data to Microsoft at any time. [Learn more about diagnostic data in Windows](https://support.microsoft.com/en-us/windows/diagnostics-feedback-and-privacy-in-windows-28808a2b-a31b-dd73-dcd3-4559a5199319).
|
|
||||||
|
|
||||||
- question: What are the biometric requirements for Windows Hello for Business?
|
|
||||||
answer: |
|
|
||||||
Read [Windows Hello biometric requirements](/windows-hardware/design/device-experiences/windows-hello-biometric-requirements) for more information.
|
|
||||||
|
|
||||||
- question: Can I use both a PIN and biometrics to unlock my device?
|
- question: Can I use both a PIN and biometrics to unlock my device?
|
||||||
answer: |
|
answer: |
|
||||||
Starting in Windows 10, version 1709, you can use multi-factor unlock to require users to provide an extra factor to unlock their device. Authentication remains two-factor, but another factor is required before Windows allows the user to reach the desktop. To learn more, see [Multifactor Unlock](feature-multifactor-unlock.md).
|
You can use *multi-factor unlock* to require users to provide an extra factor to unlock their device. Authentication remains two-factor, but another factor is required before Windows allows the user to reach the desktop. To learn more, see [Multifactor Unlock](feature-multifactor-unlock.md).
|
||||||
|
|
||||||
- name: Cloud Kerberos trust
|
- name: Cloud Kerberos trust
|
||||||
questions:
|
questions:
|
||||||
@ -276,3 +230,9 @@ sections:
|
|||||||
- question: 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?
|
- question: 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?
|
||||||
answer: |
|
answer: |
|
||||||
No, only the number necessary to handle the load from all cloud Kerberos trust devices.
|
No, only the number necessary to handle the load from all cloud Kerberos trust devices.
|
||||||
|
|
||||||
|
- name: Key trust
|
||||||
|
questions:
|
||||||
|
- question: Why does authentication fail immediately after provisioning hybrid key trust?
|
||||||
|
answer: |
|
||||||
|
In a hybrid deployment, a user's public key must sync from Azure AD to AD before it can be used to authenticate against a domain controller. This sync is handled by Azure AD Connect and will occur during a normal sync cycle.
|
Reference in New Issue
Block a user