deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-05-18 08:17:23 +00:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

updates

Browse Source
This commit is contained in:
Paolo Matarazzo 2023-01-06 10:29:16 -05:00
parent fec8029dd3
commit e17ea59bcc
2 changed files with 186 additions and 170 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

83
windows/security/identity-protection/credential-guard/credential-guard-considerations.md
View File

@ -1,7 +1,7 @@
---
title: Considerations when using Windows Defender Credential Guard
description: Considerations and recommendations for certain scenarios when using Windows Defender Credential Guard in Windows.
ms.date: 08/31/2017
description: Considerations and recommendations for certain scenarios when using Windows Defender Credential Guard.
ms.date: 01/06/2023
ms.topic: article
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
@ -10,56 +10,70 @@ appliesto:
# Considerations when using Windows Defender Credential Guard
Passwords are still weak. We recommend that in addition to deploying Windows Defender Credential Guard, organizations move away from passwords to other authentication methods, such as physical smart cards, virtual smart cards, or Windows Hello for Business.
It's recommended that in addition to deploying Windows Defender Credential Guard, organizations move away from passwords to other authentication methods, such as Windows Hello for Business, FIDO 2 security keys or smart cards.
Windows Defender Credential Guard uses hardware security, so some features such as Windows To Go, aren't supported.
## Wi-fi and VPN considerations
## Wi-fi and VPN Considerations
When you enable Windows Defender Credential Guard, you can no longer use NTLM classic authentication for Single Sign-On. You'll be forced to enter your credentials to use these protocols and can't save the credentials for future use.\
If you're using WiFi and VPN endpoints that are based on MS-CHAPv2, they're subject to similar attacks as for NTLMv1.
When you enable Windows Defender Credential Guard, you can no longer use NTLM classic authentication for Single Sign-On. You'll be forced to enter your credentials to use these protocols and can't save the credentials for future use. If you're using WiFi and VPN endpoints that are based on MS-CHAPv2, they're subject to similar attacks as for NTLMv1. For WiFi and VPN connections, Microsoft recommends that organizations move from MSCHAPv2-based connections such as PEAP-MSCHAPv2 and EAP-MSCHAPv2, to certificate-based authentication such as PEAP-TLS or EAP-TLS.
For WiFi and VPN connections, it's recommended to move from MSCHAPv2-based connections (such as PEAP-MSCHAPv2 and EAP-MSCHAPv2), to certificate-based authentication (such as PEAP-TLS or EAP-TLS).
## Kerberos Considerations
## Kerberos considerations
When you enable Windows Defender Credential Guard, you can no longer use Kerberos unconstrained delegation or DES encryption. Unconstrained delegation could allow attackers to extract Kerberos keys from the isolated LSA process. Use constrained or resource-based Kerberos delegation instead.
When you enable Windows Defender Credential Guard, you can no longer use Kerberos unconstrained delegation or DES encryption. Unconstrained delegation could allow attackers to extract Kerberos keys from the isolated LSA process.\
Use constrained or resource-based Kerberos delegation instead.
## 3rd Party Security Support Providers Considerations
## 3rd party Security Support Providers considerations
Some 3rd party Security Support Providers (SSPs and APs) might not be compatible with Windows Defender Credential Guard because it doesn't allow third-party SSPs to ask for password hashes from LSA. However, SSPs and APs still get notified of the password when a user logs on and/or changes their password. Any use of undocumented APIs within custom SSPs and APs aren't supported. We recommend that custom implementations of SSPs/APs are tested with Windows Defender Credential Guard. SSPs and APs that depend on any undocumented or unsupported behaviors fail. For example, using the KerbQuerySupplementalCredentialsMessage API isn't supported. Replacing the NTLM or Kerberos SSPs with custom SSPs and APs. For more info, see [Restrictions around Registering and Installing a Security Package](/windows/win32/secauthn/restrictions-around-registering-and-installing-a-security-package) on MSDN.
Some 3rd party Security Support Providers (SSPs and APs) might not be compatible with Windows Defender Credential Guard because it doesn't allow third-party SSPs to ask for password hashes from LSA. However, SSPs and APs still get notified of the password when a user logs on and/or changes their password. Any use of undocumented APIs within custom SSPs and APs aren't supported.\
It's recommended that custom implementations of SSPs/APs are tested with Windows Defender Credential Guard. SSPs and APs that depend on any undocumented or unsupported behaviors fail. For example, using the KerbQuerySupplementalCredentialsMessage API isn't supported. Replacing the NTLM or Kerberos SSPs with custom SSPs and APs.
## Upgrade Considerations
For more information, see [Restrictions around Registering and Installing a Security Package](/windows/win32/secauthn/restrictions-around-registering-and-installing-a-security-package).
As the depth and breadth of protections provided by Windows Defender Credential Guard are increased, subsequent releases of Windows 10 with Windows Defender Credential Guard running may impact scenarios that were working in the past. For example, Windows Defender Credential Guard may block the use of a particular type of credential or a particular component to prevent malware from taking advantage of vulnerabilities. Test scenarios required for operations in an organization before upgrading a device using Windows Defender Credential Guard.
## Upgrade considerations
### Saved Windows Credentials Protected
As the depth and breadth of protections provided by Windows Defender Credential Guard are increased, new releases of Windows with Windows Defender Credential Guard running may impact scenarios that were working in the past. For example, Windows Defender Credential Guard may block the use of a particular type of credential or a particular component to prevent malware from taking advantage of vulnerabilities.
Starting with Windows 10, version 1511, domain credentials that are stored with Credential Manager are protected with Windows Defender Credential Guard. Credential Manager allows you to store three types of credentials: Windows credentials, certificate-based credentials, and generic credentials. Generic credentials such as user names and passwords that you use to log on to websites aren't protected since the applications require your cleartext password. If the application doesn't need a copy of the password, they can save domain credentials as Windows credentials that are protected. Windows credentials are used to connect to other computers on a network.
Test scenarios required for operations in an organization before upgrading a device using Windows Defender Credential Guard.
## Saved Windows credentials protected
Domain credentials that are stored in *Credential Manager* are protected with Windows Defender Credential Guard. Credential Manager allows you to store three types of credentials:
- Windows credentials
- Certificate-based credentials
- Generic credentials
Generic credentials, such as user names and passwords that you use to log on to websites, aren't protected since the applications require your clear-text password. If the application doesn't need a copy of the password, they can save domain credentials as Windows credentials that are protected. Windows credentials are used to connect to other computers on a network.
The following considerations apply to the Windows Defender Credential Guard protections for Credential Manager:
* Windows credentials saved by Remote Desktop Client can't be sent to a remote host. Attempts to use saved Windows credentials fail, displaying the error message "Logon attempt failed."
* Applications that extract Windows credentials fail.
* When credentials are backed up from a PC that has Windows Defender Credential Guard enabled, the Windows credentials can't be restored. If you need to back up your credentials, you must do this before you enable Windows Defender Credential Guard. Otherwise, you can't restore those credentials.
- Windows credentials saved by the Remote Desktop client can't be sent to a remote host. Attempts to use saved Windows credentials fail, displaying the error message "Logon attempt failed."
- Applications that extract Windows credentials fail
- When credentials are backed up from a PC that has Windows Defender Credential Guard enabled, the Windows credentials can't be restored. If you need to back up your credentials, you must do this before you enable Windows Defender Credential Guard. Otherwise, you can't restore those credentials
## Clearing TPM Considerations
## Clearing TPM considerations
Virtualization-based Security (VBS) uses the TPM to protect its key. So when the TPM is cleared then the TPM protected key used to encrypt VBS secrets is lost.
Virtualization-based Security (VBS) uses the TPM to protect its key. When the TPM is cleared, the TPM protected key used to encrypt VBS secrets is lost.
>[!WARNING]
> Clearing the TPM results in loss of protected data for all features that use VBS to protect data. <br>
> When a TPM is cleared ALL features, which use VBS to protect data can no longer decrypt their protected data.
> Clearing the TPM results in loss of protected data for all features that use VBS to protect data.
>
> When a TPM is cleared, **all** features that use VBS to protect data can no longer decrypt their protected data.
As a result Credential Guard can no longer decrypt protected data. VBS creates a new TPM protected key for Credential Guard. Credential Guard uses the new key to protect new data. However, the previously protected data is lost forever.
As a result, Credential Guard can no longer decrypt protected data. VBS creates a new TPM protected key for Credential Guard. Credential Guard uses the new key to protect new data. However, the previously protected data is lost forever.
>[!NOTE]
> Credential Guard obtains the key during initialization. So the data loss will only impact persistent data and occur after the next system startup.
> Credential Guard obtains the key during initialization. The data loss will only impact persistent data and occur after the next system startup.
### Windows credentials saved to Credential Manager
Since Credential Manager can't decrypt saved Windows Credentials, they're deleted. Applications should prompt for credentials that were previously saved. If saved again, then Windows credentials are protected Credential Guard.
### Domain-joined device’s automatically provisioned public key
### Domain-joined device's automatically provisioned public key
Beginning with Windows 10 and Windows Server 2016, domain-devices automatically provision a bound public key, for more information about automatic public key provisioning, see [Domain-joined Device Public Key Authentication](/windows-server/security/kerberos/domain-joined-device-public-key-authentication).
Active Directory domain-joined devices automatically provision a bound public key, for more information about automatic public key provisioning, see [Domain-joined Device Public Key Authentication](/windows-server/security/kerberos/domain-joined-device-public-key-authentication).
Since Credential Guard can't decrypt the protected private key, Windows uses the domain-joined computer's password for authentication to the domain. Unless additional policies are deployed, there should not be a loss of functionality. If a device is configured to only use public key, then it can't authenticate with password until that policy is disabled. For more information on Configuring devices to only use public key, see [Domain-joined Device Public Key Authentication](/windows-server/security/kerberos/domain-joined-device-public-key-authentication).
@ -70,29 +84,22 @@ Also if any access control checks including authentication policies require devi
On domain-joined devices, DPAPI can recover user keys using a domain controller from the user's domain. If a domain-joined device has no connectivity to a domain controller, then recovery isn't possible.
>[!IMPORTANT]
> Best practice when clearing a TPM on a domain-joined device is to be on a network with connectivity to domain controllers. This ensures DPAPI functions and the user does not experience strange behavior. <br>
Auto VPN configuration is protected with user DPAPI. User may not be able to use VPN to connect to domain controllers since the VPN configurations are lost.
> Best practice when clearing a TPM on a domain-joined device is to be on a network with connectivity to domain controllers. This ensures DPAPI functions and the user does not experience strange behavior.
Auto VPN configuration is protected with user DPAPI. User may not be able to use VPN to connect to domain controllers since the VPN configurations are lost.
If you must clear the TPM on a domain-joined device without connectivity to domain controllers, then you should consider the following.
Domain user sign-in on a domain-joined device after clearing a TPM for as long as there's no connectivity to a domain controller:
|Credential Type | Windows version | Behavior
|Credential Type | Behavior
|---|---|---|
| Certificate (smart card or Windows Hello for Business) | All | All data protected with user DPAPI is unusable and user DPAPI doesn't work at all. |
| Password | Windows 10 v1709 or later | If the user signed in with a certificate or password prior to clearing the TPM, then they can sign-in with password and user DPAPI is unaffected.
| Password | Windows 10 v1703 | If the user signed in with a password prior to clearing the TPM, then they can sign-in with that password and are unaffected.
| Password | Windows 10 v1607 or earlier | Existing user DPAPI protected data is unusable. User DPAPI is able to protect new data.
| Certificate (smart card or Windows Hello for Business) | All data protected with user DPAPI is unusable and user DPAPI doesn't work at all. |
| Password | If the user signed in with a certificate or password prior to clearing the TPM, then they can sign-in with password and user DPAPI is unaffected. |
Once the device has connectivity to the domain controllers, DPAPI recovers the user's key and data protected prior to clearing the TPM can be decrypted.
#### Impact of DPAPI failures on Windows Information Protection
When data protected with user DPAPI is unusable, then the user loses access to all work data protected by Windows Information Protection. The impact includes: Outlook 2016 is unable to start and work protected documents can't be opened. If DPAPI is working, then newly created work data is protected and can be accessed.
When data protected with user DPAPI is unusable, then the user loses access to all work data protected by Windows Information Protection. The impact includes: Outlook is unable to start and work protected documents can't be opened. If DPAPI is working, then newly created work data is protected and can be accessed.
**Workaround:** Users can resolve the problem by connecting their device to the domain and rebooting or using their Encrypting File System Data Recovery Agent certificate. For more information about Encrypting File System Data Recovery Agent certificate, see [Create and verify an Encrypting File System (EFS) Data Recovery Agent (DRA) certificate](/windows/threat-protection/windows-information-protection/create-and-verify-an-efs-dra-certificate).
## See also
- [What is virtualization-based security?](https://www.linkedin.com/learning/microsoft-cybersecurity-stack-advanced-identity-and-endpoint-protection/what-is-virtualization-based-security)

263
windows/security/identity-protection/hello-for-business/hello-faq.yml
View File

@ -24,48 +24,22 @@ title: Windows Hello for Business Frequently Asked Questions (FAQ)
summary: |
sections:
- name: Ignored
- name: Concepts
questions:
- question: What is Windows Hello for Business cloud Kerberos trust?
- question: What's the difference between Windows Hello and Windows Hello for Business?
answer: |
Windows Hello for Business *cloud Kerberos trust* is a **trust model** that enables Windows Hello for Business deployment using the infrastructure introduced for supporting [security key sign-in on Hybrid Azure AD-joined devices and on-premises resource access on Azure AD Joined devices](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises). Cloud Kerberos trust is the preferred deployment model if you do not need to support certificate authentication scenarios. For more information, see [cloud Kerberos trust deployment](/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust).
- question: What about virtual smart cards?
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.
- question: What about convenience PIN?
answer: |
While *convenience PIN* provides a convenient way to sign in to Windows, it stills uses a password for authentication. Customers using *convenience PINs* should move to **Windows Hello for Business**. New Windows deployments should deploy Windows Hello for Business and not convenience PINs. Microsoft will be deprecating convenience PINs in the future and will publish the date early to ensure customers have adequate lead time to deploy Windows Hello for Business.
- question: Can I use Windows Hello for Business key trust and RDP?
answer: |
Remote Desktop Protocol (RDP) doesn't currently support using key-based authentication and self-signed certificates as supplied credentials. However, you can deploy certificates in the key trust model to enable RDP. For more information, see [Deploying certificates to key trust users to enable RDP](hello-deployment-rdp-certs.md). In addition, Windows Hello for Business key trust can be also used with RDP with [Windows Defender Remote Credential Guard](../remote-credential-guard.md) without deploying certificates.
- question: Can I deploy Windows Hello for Business by using Microsoft Configuration Manager?
answer: |
Windows Hello for Business deployments using Configuration Manager should follow the hybrid deployment model that uses Active Directory Federation Services. Starting in Configuration Manager version 1910, certificate-based authentication with Windows Hello for Business settings isn't supported. Key-based authentication is still valid with Configuration Manager. For more information, see [Windows Hello for Business settings in Configuration Manager](/configmgr/protect/deploy-use/windows-hello-for-business-settings).
- question: Can I deploy Windows Hello for Business by using Microsoft Intune?
answer: |
Windows Hello for Business deployments using Intune allow for a great deal of flexibility in deployment. For more information, see [Integrate Windows Hello for Business with Microsoft Intune](/mem/intune/protect/windows-hello).
- question: How many users can enroll for Windows Hello for Business on a single Windows 10 computer?
answer: |
The maximum number of supported enrollments on a single Windows 10 computer is 10. This lets 10 users each enroll their face and up to 10 fingerprints. For devices with more than 10 users, we strongly encourage the use of FIDO2 security keys.
- question: Can I use Windows Hello for Business credentials in private browser mode or "incognito" mode?
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 represents the biometric framework provided in Windows. Windows Hello lets users use biometrics to sign in to their devices by securely storing their user name and password and releasing it for authentication when the user successfully identifies themselves using biometrics. Windows Hello for Business uses asymmetric keys protected by the device's security module that requires a user gesture (PIN or biometrics) to authenticate.
- question: How can a PIN be more secure than a password?
answer: |
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](feature-multifactor-unlock.md) feature.
- 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.
- question: What's a container?
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.
@ -73,10 +47,136 @@ sections:
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.\
:::image type="content" source="images/passport-fig3-logicalcontainer.png" alt-text="logical container with set of keys":::
- 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?
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.
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.
- name: Management and operations
questions:
- question: Can I deploy and manage Windows Hello for Business using Microsoft Intune?
answer: |
Yes, hybrid and cloud-only Windows Hello for Business deployments can use Microsoft Intune. For more information, see [Integrate Windows Hello for Business with Microsoft Intune](/mem/intune/protect/windows-hello).
- question: How do I delete a Windows Hello for Business container on a device?
answer: |
You can effectively disable Windows Hello for Business by launching `certutil.exe -deleteHelloContainer` on the end device under a user account, and then restarting the device.
- question: What happens when a user forgets their PIN?
answer: |
If the user can sign in with a password, they can reset their PIN by selecting the *I forgot my PIN* link in the Settings app. Users can reset also their PIN from the lock screen by selecting the *I forgot my PIN* link on the PIN credential provider.
For on-premises deployments, devices must be connected to their on-premises network (domain controllers and/or certificate authority) to reset their PINs. Hybrid deployments can onboard their Azure tenant to use the Windows Hello for Business PIN reset service to reset their PINs. Non-destructive PIN reset works without access to the corporate network. Destructive PIN reset requires access to the corporate network. For more details about destructive and non-destructive PIN reset, see [PIN reset](/windows/security/identity-protection/hello-for-business/hello-feature-pin-reset).
- question: Does Windows Hello for Business prevent the use of simple PINs?
answer: |
Yes. Our simple PIN algorithm looks for and disallows any PIN that has a constant delta from one digit to the next. The algorithm counts the number of steps required to reach the next digit, overflowing at 10 ('zero').
So, for example:
- The PIN 1111 has a constant delta of (0,0,0), so it isn't allowed
- The PIN 1234 has a constant delta of (1,1,1), so it isn't allowed
- The PIN 1357 has a constant delta of (2,2,2), so it isn't allowed
- The PIN 9630 has a constant delta of (7,7,7), so it isn't allowed
- The PIN 1593 has a constant delta of (4,4,4), so it isn't allowed
- The PIN 7036 has a constant delta of (3,3,3), so it isn't allowed
- The PIN 1231 doesn't have a constant delta (1,1,8), 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.
- name: Design and planning
questions:
- question: How many users can enroll for Windows Hello for Business on a single Windows device?
answer: |
The maximum number of supported enrollments on a single device is 10. This lets 10 users each enroll their face and up to 10 fingerprints. For devices with more than 10 users, or for users that sign-in to many devices (for example, a support technician), it's recommended the use of FIDO2 security keys.
- question: Can Windows Hello for Business work in air-gapped environments?
answer: |
Yes. You can use the on-premises Windows Hello for Business deployment and combine it with a third-party MFA provider that doesn't require internet connectivity to achieve an air-gapped Windows Hello for Business deployment.
- question: What attributes are synchronized by Azure AD Connect with Windows Hello for Business?
answer: |
Review [Azure AD Connect sync: Attributes synchronized to Azure Active Directory](/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized) for a list of attributes that sync based on scenarios. The base scenarios that include Windows Hello for Business are the [Windows 10](/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized#windows-10) scenario and the [Device writeback](/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized#device-writeback) scenario. Your environment may include other attributes.
- question: Can I use third-party authentication providers with Windows Hello for Business?
answer: |
Yes, if you're using federated hybrid deployment, you can use any third-party that provides an Active Directory Federation Services (AD FS) multi-factor authentication adapter. A list of third-party MFA adapters can be found [here](/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs#microsoft-and-third-party-additional-authentication-methods).
- question: Does Windows Hello for Business work with third-party federation servers?
answer: |
Windows Hello for Business works with any third-party federation servers that support the protocols used during the provisioning experience.<br><br>
| Protocol | Description |
| :--- | :--- |
| [[MS-KPP]: Key Provisioning Protocol](/openspecs/windows_protocols/ms-kpp/25ff7bd8-50e3-4769-af23-bcfd0b4d4567) | Specifies the Key Provisioning Protocol, which defines a mechanism for a client to register a set of cryptographic keys on a user and device pair. |
| [[MS-OAPX]: OAuth 2.0 Protocol Extensions](/openspecs/windows_protocols/ms-oapx/7612efd4-f4c8-43c3-aed6-f5c5ce359da2)| Specifies the OAuth 2.0 Protocol Extensions, which are used to extend the OAuth 2.0 Authorization Framework. These extensions enable authorization features such as resource specification, request identifiers, and log in hints. |
| [[MS-OAPXBC]: OAuth 2.0 Protocol Extensions for Broker Clients](/openspecs/windows_protocols/ms-oapxbc/2f7d8875-0383-4058-956d-2fb216b44706) | Specifies the OAuth 2.0 Protocol Extensions for Broker Clients, extensions to RFC6749 (the OAuth 2.0 Authorization Framework) that allow a broker client to obtain access tokens on behalf of calling clients. |
| [[MS-OIDCE]: OpenID Connect 1.0 Protocol Extensions](/openspecs/windows_protocols/ms-oidce/718379cf-8bc1-487e-962d-208aeb8e70ee) | Specifies the OpenID Connect 1.0 Protocol Extensions. These extensions define other claims to carry information about the user, including the user principal name, a locally unique identifier, a time for password expiration, and a URL for password change. These extensions also define more provider meta-data that enables the discovery of the issuer of access tokens and gives additional information about provider capabilities. |
- question: Can I enroll local Windows accounts in Windows Hello for Business?
answer: |
Windows Hello for Business is not designed to work with local accounts.
- question: I have extended Active Directory to Azure Active Directory. Can I use the on-premises deployment model?
answer: |
No. If your organization is using Microsoft cloud services, then you must use a hybrid deployment model. On-premises deployments are exclusive to organizations who need more time before moving to the cloud and exclusively use Active Directory.
- question: Can I wear a mask to enroll or unlock using Windows Hello face authentication?
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.
- name: Cloud Kerberos trust
questions:
- question: What is Windows Hello for Business cloud Kerberos trust?
answer: |
Windows Hello for Business *cloud Kerberos trust* is a **trust model** that enables Windows Hello for Business deployment using the infrastructure introduced for supporting [security key sign-in on Hybrid Azure AD-joined devices and on-premises resource access on Azure AD Joined devices](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises). Cloud Kerberos trust is the preferred deployment model if you do not need to support certificate authentication scenarios. For more information, see [cloud Kerberos trust deployment](/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust).
- name: Features
questions:
- question: Can I use an external Windows Hello compatible camera when my computer has a built-in Windows Hello compatible camera?
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).
- question: What about virtual smart cards?
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.
- question: What about convenience PIN?
answer: |
While *convenience PIN* provides a convenient way to sign in to Windows, it stills uses a password for authentication. Customers using *convenience PINs* should move to **Windows Hello for Business**. New Windows deployments should deploy Windows Hello for Business and not convenience PINs. Microsoft will be deprecating convenience PINs in the future and will publish the date early to ensure customers have adequate lead time to deploy Windows Hello for Business.
- question: Can I use Windows Hello for Business key trust and RDP?
answer: |
Remote Desktop Protocol (RDP) doesn't currently support using key-based authentication and self-signed certificates as supplied credentials. However, you can deploy certificates in the key trust model to enable RDP. For more information, see [Deploying certificates to key trust users to enable RDP](hello-deployment-rdp-certs.md). In addition, Windows Hello for Business key trust can be also used with RDP with [Windows Defender Remote Credential Guard](../remote-credential-guard.md) without deploying certificates.
- question: Can I deploy Windows Hello for Business by using Microsoft Configuration Manager?
answer: |
Windows Hello for Business deployments using Configuration Manager should follow the hybrid deployment model that uses Active Directory Federation Services. Starting in Configuration Manager version 1910, certificate-based authentication with Windows Hello for Business settings isn't supported. Key-based authentication is still valid with Configuration Manager. For more information, see [Windows Hello for Business settings in Configuration Manager](/configmgr/protect/deploy-use/windows-hello-for-business-settings).
- question: Can I use Windows Hello for Business credentials in private browser mode or "incognito" mode?
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.
- question: How does Windows Hello for Business work with Azure AD registered devices?
answer: |
@ -88,17 +188,10 @@ sections:
For more information, please read [Azure AD registered devices](/azure/active-directory/devices/concept-azure-ad-register).
- question: I have Windows Server 2016 domain controller(s), so why is the Key Admins group missing?
answer: |
The **Key Admins** and **Enterprise Key Admins** groups are created when you install the first Windows Server 2016 domain controller into a domain. Domain controllers running previous versions of Windows Server can't translate the security identifier (SID) to a name. To resolve this issue, transfer the PDC emulator domain role to a domain controller running Windows Server 2016.
- 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 when my computer has a built-in Windows Hello compatible camera?
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).
- 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: |
@ -118,11 +211,6 @@ sections:
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 happens when a user forgets their PIN?
answer: |
If the user can sign in with a password, they can reset their PIN by selecting the "I forgot my PIN" link in Settings. Beginning with Windows 10 1709, users can reset their PIN above the lock screen by selecting the "I forgot my PIN" link on the PIN credential provider.
For on-premises deployments, devices must be well-connected to their on-premises network (domain controllers and/or certificate authority) to reset their PINs. Hybrid customers can onboard their Azure tenant to use the Windows Hello for Business PIN reset service to reset their PINs. Non-destructive PIN reset works without access to the corporate network. Destructive PIN reset requires access to the corporate network. For more details about destructive and non-destructive PIN reset, see [PIN reset](/windows/security/identity-protection/hello-for-business/hello-feature-pin-reset).
- question: What URLs do I need to allow for a hybrid deployment?
answer: |
@ -155,13 +243,6 @@ sections:
The **certificate trust** model authenticates to Active Directory by using a certificate. Because this authentication uses a certificate, domain controllers running previous versions of Windows Server can authenticate the user. Therefore, you need to issue certificates to users, but you don't need Windows Server 2016 domain controllers. The certificate used in certificate trust uses the TPM-protected private key to request a certificate from your enterprise's issuing certificate authority.
- question: Do I need Windows Server 2016 domain controllers?
answer: |
There are many deployment options from which to choose. Some of those options require an adequate number of Windows Server 2016 domain controllers in the site where you've deployed Windows Hello for Business. There are other deployment options that use existing Windows Server 2008 R2 or later domain controllers. Choose the deployment option that best suits your environment.
- question: What attributes are synchronized by Azure AD Connect with Windows Hello for Business?
answer: |
Review [Azure AD Connect sync: Attributes synchronized to Azure Active Directory](/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized) for a list of attributes that sync based on scenarios. The base scenarios that include Windows Hello for Business are the [Windows 10](/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized#windows-10) scenario and the [Device writeback](/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized#device-writeback) scenario. Your environment may include other attributes.
- question: Is Windows Hello for Business multi-factor authentication?
answer: |
@ -199,80 +280,8 @@ sections:
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).
- question: Can I wear a mask to enroll or unlock using Windows Hello face authentication?
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 unenrolling from face authentication and only using PIN or fingerprint.
- question: What's the difference between Windows Hello and Windows Hello for Business?
answer: |
Windows Hello represents the biometric framework provided in Windows 10. Windows Hello lets users use biometrics to sign in to their devices by securely storing their user name and password and releasing it for authentication when the user successfully identifies themselves using biometrics. Windows Hello for Business uses asymmetric keys protected by the device's security module that requires a user gesture (PIN or biometrics) to authenticate.
- question: Why can't I enroll biometrics for my local, built-in administrator?
answer: |
Windows 10 doesn't allow the local administrator to enroll biometric gestures (face or fingerprint).
- question: I have extended Active Directory to Azure Active Directory. Can I use the on-premises deployment model?
answer: |
No. If your organization is using Microsoft cloud services, then you must use a hybrid deployment model. On-premises deployments are exclusive to organizations who need more time before moving to the cloud and exclusively use Active Directory.
- question: Does Windows Hello for Business prevent the use of simple PINs?
answer: |
Yes. Our simple PIN algorithm looks for and disallows any PIN that has a constant delta from one digit to the next. The algorithm counts the number of steps required to reach the next digit, overflowing at 10 ('zero').
So, for example:
- The PIN 1111 has a constant delta of (0,0,0), so it isn't allowed
- The PIN 1234 has a constant delta of (1,1,1), so it isn't allowed
- The PIN 1357 has a constant delta of (2,2,2), so it isn't allowed
- The PIN 9630 has a constant delta of (7,7,7), so it isn't allowed
- The PIN 1593 has a constant delta of (4,4,4), so it isn't allowed
- The PIN 7036 has a constant delta of (3,3,3), so it isn't allowed
- The PIN 1231 doesn't have a constant delta (1,1,8), 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.
- question: How does PIN caching work with Windows Hello for Business?
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.
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.
- 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.
- 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: Can Windows Hello for Business work in air-gapped environments?
answer: |
Yes. You can use the on-premises Windows Hello for Business deployment and combine it with a third-party MFA provider that doesn't require internet connectivity to achieve an air-gapped Windows Hello for Business deployment.
- question: Can I use third-party authentication providers with Windows Hello for Business?
answer: |
Yes, if you're using federated hybrid deployment, you can use any third-party that provides an Active Directory Federation Services (AD FS) multi-factor authentication adapter. A list of third-party MFA adapters can be found [here](/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs#microsoft-and-third-party-additional-authentication-methods).
- question: Does Windows Hello for Business work with third-party federation servers?
answer: |
Windows Hello for Business works with any third-party federation servers that support the protocols used during the provisioning experience.<br><br>
| Protocol | Description |
| :--- | :--- |
| [[MS-KPP]: Key Provisioning Protocol](/openspecs/windows_protocols/ms-kpp/25ff7bd8-50e3-4769-af23-bcfd0b4d4567) | Specifies the Key Provisioning Protocol, which defines a mechanism for a client to register a set of cryptographic keys on a user and device pair. |
| [[MS-OAPX]: OAuth 2.0 Protocol Extensions](/openspecs/windows_protocols/ms-oapx/7612efd4-f4c8-43c3-aed6-f5c5ce359da2)| Specifies the OAuth 2.0 Protocol Extensions, which are used to extend the OAuth 2.0 Authorization Framework. These extensions enable authorization features such as resource specification, request identifiers, and log in hints. |
| [[MS-OAPXBC]: OAuth 2.0 Protocol Extensions for Broker Clients](/openspecs/windows_protocols/ms-oapxbc/2f7d8875-0383-4058-956d-2fb216b44706) | Specifies the OAuth 2.0 Protocol Extensions for Broker Clients, extensions to RFC6749 (the OAuth 2.0 Authorization Framework) that allow a broker client to obtain access tokens on behalf of calling clients. |
| [[MS-OIDCE]: OpenID Connect 1.0 Protocol Extensions](/openspecs/windows_protocols/ms-oidce/718379cf-8bc1-487e-962d-208aeb8e70ee) | Specifies the OpenID Connect 1.0 Protocol Extensions. These extensions define other claims to carry information about the user, including the user principal name, a locally unique identifier, a time for password expiration, and a URL for password change. These extensions also define more provider meta-data that enables the discovery of the issuer of access tokens and gives additional information about provider capabilities. |
- question: Does Windows Hello for Business work with Mac and Linux clients?
answer: |
Windows Hello for Business is a feature of Windows 10. 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).
Windows Hello for Business is a feature of the Windows platform. At this time, Microsoft isn't developing clients for other platforms.
- 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.