fix links and Acrolinx

This commit is contained in:
Aaron Czechowski
2022-07-30 15:59:26 -07:00
parent 81a6f6814b
commit 971cc46cca
12 changed files with 512 additions and 502 deletions

View File

@ -12,46 +12,56 @@ ms.date: 01/26/2022
ms.reviewer:
---
# Windows Defender Credential Guard: Known issues
# Windows Defender Credential Guard: Known issues
**Applies to**
- Windows 10
- Windows 11
- Windows Server 2016
- Windows Server 2019
Windows Defender Credential Guard has certain application requirements. Windows Defender Credential Guard blocks specific authentication capabilities. So applications that require such capabilities won't function when it's enabled. For more information, see [Application requirements](/windows/access-protection/credential-guard/credential-guard-requirements#application-requirements).
The following known issue has been fixed in the [Cumulative Security Update for November 2017](https://support.microsoft.com/help/4051033):
Windows Defender Credential Guard has certain application requirements. Windows Defender Credential Guard blocks specific authentication capabilities. So applications that require such capabilities won't function when it's enabled. For more information, see [Application requirements](credential-guard-requirements.md#application-requirements).
- Scheduled tasks with domain user-stored credentials fail to run when Credential Guard is enabled. The task fails and reports Event ID 104 with the following message: <br>
"Task Scheduler failed to log on \Test. <br>
Failure occurred in LogonUserExEx. <br>
User Action: Ensure the credentials for the task are correctly specified. <br>
Additional Data: Error Value: 2147943726. 2147943726: ERROR\_LOGON\_FAILURE (The user name or password is incorrect)."
- When enabling NTLM audit on the domain controller, an Event ID 8004 with an indecipherable username format is logged. You also get a similar user name in a user logon failure event 4625 with error 0xC0000064 on the machine itself. For example:
> Log Name: Microsoft-Windows-NTLM/Operational
Source: Microsoft-Windows-Security-Netlogon
Event ID: 8004
Task Category: Auditing NTLM
Level: Information
Description:
Domain Controller Blocked Audit: Audit NTLM authentication to this domain controller.
Secure Channel name: \<Secure Channel Name>
User name:
@@CyBAAAAUBQYAMHArBwUAMGAoBQZAQGA1BAbAUGAyBgOAQFAhBwcAsGA6AweAgDA2AQQAMEAwAANAgDA1AQLAIEADBQRAADAtAANAYEA1AwQA0CA5AAOAMEAyAQLAYDAxAwQAEDAEBwMAMEAwAgMAMDACBgRA0HA
The following known issues have been fixed in the [Cumulative Security Update for November 2017](https://support.microsoft.com/topic/november-27-2017-kb4051033-os-build-14393-1914-447b6b88-e75d-0a24-9ab9-5dcda687aaf4):
- Scheduled tasks with domain user-stored credentials fail to run when Credential Guard is enabled. The task fails and reports Event ID 104 with the following message:
```console
Task Scheduler failed to log on '\Test'.
Failure occurred in 'LogonUserExEx'.
User Action: Ensure the credentials for the task are correctly specified.
Additional Data: Error Value: 2147943726. 2147943726: ERROR\_LOGON\_FAILURE (The user name or password is incorrect).
```
- When you enable NTLM audit on the domain controller, an Event ID 8004 with an indecipherable username format is logged. You also get a similar user name in a user logon failure event 4625 with error 0xC0000064 on the machine itself. For example:
```console
Log Name: Microsoft-Windows-NTLM/Operational
Source: Microsoft-Windows-Security-Netlogon
Event ID: 8004
Task Category: Auditing NTLM
Level: Information
Description:
Domain Controller Blocked Audit: Audit NTLM authentication to this domain controller.
Secure Channel name: <Secure Channel Name>
User name:
@@CyBAAAAUBQYAMHArBwUAMGAoBQZAQGA1BAbAUGAyBgOAQFAhBwcAsGA6AweAgDA2AQQAMEAwAANAgDA1AQLAIEADBQRAADAtAANAYEA1AwQA0CA5AAOAMEAyAQLAYDAxAwQAEDAEBwMAMEAwAgMAMDACBgRA0HA
Domain name: NULL
- This event stems from a scheduled task running under local user context with the [Cumulative Security Update for November 2017](https://support.microsoft.com/topic/november-27-2017-kb4051033-os-build-14393-1914-447b6b88-e75d-0a24-9ab9-5dcda687aaf4) or later and happens when Credential Guard is enabled.
- The username appears in an unusual format because local accounts arent protected by Credential Guard. The task also fails to execute.
- As a workaround, run the scheduled task under a domain user or the computer's SYSTEM account.
```
- This event stems from a scheduled task running under local user context with the [Cumulative Security Update for November 2017](https://support.microsoft.com/topic/november-27-2017-kb4051033-os-build-14393-1914-447b6b88-e75d-0a24-9ab9-5dcda687aaf4) or later and happens when Credential Guard is enabled.
- The username appears in an unusual format because local accounts aren't protected by Credential Guard. The task also fails to execute.
- As a workaround, run the scheduled task under a domain user or the computer's SYSTEM account.
The following known issues have been fixed by servicing releases made available in the Cumulative Security Updates for April 2017:
- [KB4015217 Windows Defender Credential Guard generates double bad password count on Active Directory domain-joined Windows machines](https://support.microsoft.com/help/4015217/windows-10-update-kb4015217)
- [KB4015217 Windows Defender Credential Guard generates double bad password count on Active Directory domain-joined Windows machines](https://support.microsoft.com/topic/april-11-2017-kb4015217-os-build-14393-1066-and-14393-1083-b5f79067-98bd-b4ec-8b81-5d858d7dc722)
This issue can potentially lead to unexpected account lockouts. See also Microsoft® Knowledge Base articles [KB4015219](https://support.microsoft.com/help/4015219/windows-10-update-kb4015219) and [KB4015221](https://support.microsoft.com/help/4015221/windows-10-update-kb4015221)
This issue can potentially lead to unexpected account lockouts. For more information, see the following support articles:
- [KB4015219](https://support.microsoft.com/topic/april-11-2017-kb4015219-os-build-10586-873-68b8e379-aafa-ea6c-6b29-56d19785e657)
- [KB4015221](https://support.microsoft.com/topic/april-11-2017-kb4015221-os-build-10240-17354-743f52bc-a484-d23f-71f5-b9957cbae0e6)
## Known issues involving third-party applications
@ -59,61 +69,47 @@ The following issue affects MSCHAPv2:
- [Credential guard doesn't work with MSCHAPv2 configurations, of which Cisco ISE is a very popular enterprise implementation](https://quickview.cloudapps.cisco.com/quickview/bug/CSCul55352).
The following issue affects the Java GSS API. See the following Oracle bug database article:
The following issue affects the Java GSS API. See the following Oracle bug database article:
- [JDK-8161921: Windows Defender Credential Guard doesn't allow sharing of TGT with Java](http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8161921)
When Windows Defender Credential Guard is enabled on Windows, the Java GSS API won't authenticate. This is expected behavior because Windows Defender Credential Guard blocks specific application authentication capabilities and won't provide the TGT session key to applications regardless of registry key settings. For more information, see [Application requirements](/windows/access-protection/credential-guard/credential-guard-requirements#application-requirements).
When Windows Defender Credential Guard is enabled on Windows, the Java GSS API won't authenticate. This is expected behavior because Windows Defender Credential Guard blocks specific application authentication capabilities and won't provide the TGT session key to applications regardless of registry key settings. For more information, see [Application requirements](credential-guard-requirements.md#application-requirements).
The following issue affects Cisco AnyConnect Secure Mobility Client:
- [Blue screen on Windows computers running Hypervisor-Protected Code Integrity and Windows Defender Credential Guard with Cisco Anyconnect 4.3.04027](https://quickview.cloudapps.cisco.com/quickview/bug/CSCvc66692) \*
*Registration required to access this article.
- [Blue screen on Windows computers running Hypervisor-Protected Code Integrity and Windows Defender Credential Guard with Cisco Anyconnect 4.3.04027](https://quickview.cloudapps.cisco.com/quickview/bug/CSCvc66692)
The following issue affects McAfee Application and Change Control (MACC):
- [KB88869 Windows machines exhibit high CPU usage with McAfee Application and Change Control (MACC) installed when Windows Defender Credential Guard is enabled](https://kc.mcafee.com/corporate/index?page=content&id=KB88869) <sup>[1]</sup>
The following issue affects AppSense Environment Manager.
For more information, see the following Knowledge Base article:
- [Installing AppSense Environment Manager on Windows machines causes LSAISO.exe to exhibit high CPU usage when Windows Defender Credential Guard is enabled](http://www.appsense.com/kb/160525073917945) <sup>[1]</sup> \**
- [KB88869 Windows machines exhibit high CPU usage with McAfee Application and Change Control (MACC) installed when Windows Defender Credential Guard is enabled](https://kcm.trellix.com/corporate/index?page=content&id=KB88869) <sup>[Note 1](#bkmk_note1)</sup>
The following issue affects Citrix applications:
- Windows machines exhibit high CPU usage with Citrix applications installed when Windows Defender Credential Guard is enabled. <sup>[1]</sup>
<sup>[1]</sup> Products that connect to Virtualization Based Security (VBS) protected processes can cause Windows Defender Credential Guard-enabled Windows 10, Windows 11, Windows Server 2016, or Windows Server 2019 machines to exhibit high CPU usage. For technical and troubleshooting information, see the following Microsoft Knowledge Base article:
- Windows machines exhibit high CPU usage with Citrix applications installed when Windows Defender Credential Guard is enabled. <sup>[Note 1](#bkmk_note1)</sup>
- [KB4032786 High CPU usage in the LSAISO process on Windows](/troubleshoot/windows-client/performance/lsaiso-process-high-cpu-usage)
For further technical information on LSAISO.exe, see the MSDN article: [Isolated User Mode (IUM) Processes](/windows/win32/procthread/isolated-user-mode--ium--processes)
\** Registration is required to access this article.
<a name="bkmk_note1"></a>
> [!NOTE]
> **Note 1**: Products that connect to Virtualization Based Security (VBS) protected processes can cause Windows Defender Credential Guard-enabled Windows 10, Windows 11, Windows Server 2016, or Windows Server 2019 machines to exhibit high CPU usage. For technical and troubleshooting information, see [KB4032786 High CPU usage in the LSAISO process on Windows](/troubleshoot/windows-client/performance/lsaiso-process-high-cpu-usage).
>
> For more technical information on LSAISO.exe, see [Isolated User Mode (IUM) Processes](/windows/win32/procthread/isolated-user-mode--ium--processes).
## Vendor support
See the following article on Citrix support for Secure Boot:
- [Citrix Support for Secure Boot](https://www.citrix.com/blogs/2016/12/08/windows-server-2016-hyper-v-secure-boot-support-now-available-in-xenapp-7-12/)
For more information on Citrix support for Secure Boot, see [Citrix Support for Secure Boot](https://www.citrix.com/blogs/2016/12/08/windows-server-2016-hyper-v-secure-boot-support-now-available-in-xenapp-7-12/)
Windows Defender Credential Guard isn't supported by either these products, products versions, computer systems, or Windows 10 versions:
Windows Defender Credential Guard isn't supported by the following products, products versions, computer systems, or Windows 10 versions:
- For Windows Defender Credential Guard on Windows with McAfee Encryption products, see:
[Support for Hypervisor-Protected Code Integrity and Windows Defender Credential Guard on Windows with McAfee encryption products](https://kc.mcafee.com/corporate/index?page=content&id=KB86009)
- [Support for Hypervisor-Protected Code Integrity and Windows Defender Credential Guard on Windows with McAfee encryption products](https://kcm.trellix.com/corporate/index?page=content&id=KB86009KB86009)
- For Windows Defender Credential Guard on Windows with Check Point Endpoint Security Client, see:
[Check Point Endpoint Security Client support for Microsoft Windows Defender Credential Guard and Hypervisor-Protected Code Integrity features](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk113912)
- [Check Point Endpoint Security Client support for Microsoft Windows Defender Credential Guard and Hypervisor-Protected Code Integrity features](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk113912)
- For Windows Defender Credential Guard on Windows with VMWare Workstation
[Windows host fails when running VMWare Workstation when Windows Defender Credential Guard is enabled](https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2146361)
- ["VMware Workstation and Device/Credential Guard are not compatible" error in VMware Workstation on Windows 10 host (2146361)](https://kb.vmware.com/s/article/2146361)
- For Windows Defender Credential Guard on Windows with specific versions of the Lenovo ThinkPad
[ThinkPad support for Hypervisor-Protected Code Integrity and Windows Defender Credential Guard in Microsoft Windows ThinkPad](https://support.lenovo.com/in/en/solutions/ht503039)
- [ThinkPad support for Hypervisor-Protected Code Integrity and Windows Defender Credential Guard in Microsoft Windows](https://support.lenovo.com/in/en/solutions/ht503039)
- For Windows Defender Credential Guard on Windows with Symantec Endpoint Protection
[Windows devices with Windows Defender Credential Guard and Symantec Endpoint Protection 12.1](https://www.symantec.com/connect/forums/windows-10-device-guard-credentials-guard-and-sep-121)
- [Windows devices with Windows Defender Credential Guard and Symantec Endpoint Protection 12.1](https://www.symantec.com/connect/forums/windows-10-device-guard-credentials-guard-and-sep-121)
This isn't a comprehensive list. Check whether your product vendor, product version, or computer system, supports Windows Defender Credential Guard on systems that run Windows or specific versions of Windows. Specific computer system models may be incompatible with Windows Defender Credential Guard.
This list isn't comprehensive. Check whether your product vendor, product version, or computer system supports Windows Defender Credential Guard on systems that run Windows or specific versions of Windows. Specific computer system models may be incompatible with Windows Defender Credential Guard.
Microsoft encourages third-party vendors to contribute to this page by providing relevant product support information and by adding links to their own product support statements.
Microsoft encourages third-party vendors to contribute to this page by providing relevant product support information and by adding links to their own product support statements.

View File

@ -1,5 +1,5 @@
---
title: How Windows Hello for Business works - Technology and Terms
title: How Windows Hello for Business works - technology and terms
description: Explore technology and terms associated with Windows Hello for Business. Learn how Windows Hello for Business works.
ms.prod: m365-security
author: GitPrakhar13
@ -11,275 +11,340 @@ localizationpriority: medium
ms.date: 10/08/2018
ms.reviewer:
---
# Technology and Terms
# Technology and terms
**Applies to:**
- Windows 10
- Windows 11
- [Attestation Identity Keys](#attestation-identity-keys)
- [Azure AD Joined](#azure-ad-joined)
- [Azure AD Registered](#azure-ad-registered)
- [Certificate Trust](#certificate-trust)
- [Cloud Deployment](#cloud-deployment)
- [Cloud Experience Host](#cloud-experience-host)
- [Deployment Type](#deployment-type)
- [Endorsement Key](#endorsement-key)
- [Federated Environment](#federated-environment)
- [Hybrid Azure AD Joined](#hybrid-azure-ad-joined)
- [Hybrid Deployment](#hybrid-deployment)
- [Join Type](#join-type)
- [Key Trust](#key-trust)
- [Managed Environment](#managed-environment)
- [On-premises Deployment](#on-premises-deployment)
- [Pass-through Authentication](#pass-through-authentication)
- [Password Hash Synchronization](#password-hash-sync)
- [Primary Refresh Token](#primary-refresh-token)
- [Storage Root Key](#storage-root-key)
- [Trust Type](#trust-type)
- [Trusted Platform Module](#trusted-platform-module)
<hr>
## Attestation identity keys
## Attestation Identity Keys
Because the endorsement certificate is unique for each device and does not change, the usage of it may present privacy concerns because it's theoretically possible to track a specific device. To avoid this privacy problem, Windows issues a derived attestation anchor based on the endorsement certificate. This intermediate key, which can be attested to an endorsement key, is the Attestation Identity Key (AIK) and the corresponding certificate is called the AIK certificate. This AIK certificate is issued by a Microsoft cloud service.
Because the endorsement certificate is unique for each device and doesn't change, the usage of it may present privacy concerns because it's theoretically possible to track a specific device. To avoid this privacy problem, Windows issues a derived attestation anchor based on the endorsement certificate. This intermediate key, which can be attested to an endorsement key, is the Attestation Identity Key (AIK) and the corresponding certificate is called the AIK certificate. This AIK certificate is issued by a Microsoft cloud service.
> [!NOTE]
> The AIK certificate must be provisioned in conjunction with a third-party service like the Microsoft Cloud CA service. After it is provisioned, the AIK private key can be used to report platform configuration. Windows creates a signature over the platform log state (and a monotonic counter value) at each boot by using the AIK.
> The AIK is an asymmetric (public/private) key pair that is used as a substitute for the EK as an identity for the TPM for privacy purposes. The private portion of an AIK is never revealed or used outside the TPM and can only be used inside the TPM for a limited set of operations. Furthermore, it can only be used for signing, and only for limited, TPM-defined operations.
Windows creates AIKs protected by the TPM, if available, that are 2048-bit RSA signing keys. Microsoft hosts a cloud service called Microsoft Cloud CA to establish cryptographically that it is communicating with a real TPM and that the TPM possesses the presented AIK. After the Microsoft Cloud CA service has established these facts, it will issue an AIK certificate to the Windows device.
Windows creates AIKs protected by the TPM, if available, that are 2048-bit RSA signing keys. Microsoft hosts a cloud service called Microsoft Cloud CA to establish cryptographically that it's communicating with a real TPM and that the TPM possesses the presented AIK. After the Microsoft Cloud CA service has established these facts, it will issue an AIK certificate to the Windows device.
Many existing devices that will upgrade to Windows 10 will not have a TPM, or the TPM will not contain an endorsement certificate. **To accommodate those devices, Windows 10 or Windows 11 allows the issuance of AIK certificates without the presence of an endorsement certificate.** Such AIK certificates are not issued by Microsoft Cloud CA. Note that this is not as trustworthy as an endorsement certificate that is burned into the device during manufacturing, but it will provide compatibility for advanced scenarios like Windows Hello for Business without TPM.
Many existing devices that will upgrade to Windows 10 won't have a TPM, or the TPM won't contain an endorsement certificate. **To accommodate those devices, Windows 10 or Windows 11 allows the issuance of AIK certificates without the presence of an endorsement certificate.** Such AIK certificates aren't issued by Microsoft Cloud CA. This behavior isn't as trustworthy as an endorsement certificate that is burned into the device during manufacturing, but it will provide compatibility for advanced scenarios like Windows Hello for Business without TPM.
In the issued AIK certificate, a special OID is added to attest that endorsement certificate was used during the attestation process. This information can be leveraged by a relying party to decide whether to reject devices that are attested using AIK certificates without an endorsement certificate or accept them. Another scenario can be to not allow access to high-value assets from devices that are attested by an AIK certificate that is not backed by an endorsement certificate.
In the issued AIK certificate, a special OID is added to attest that endorsement certificate was used during the attestation process. This information can be used by a relying party to decide whether to reject devices that are attested using AIK certificates without an endorsement certificate or accept them. Another scenario can be to not allow access to high-value assets from devices that are attested by an AIK certificate that's not backed by an endorsement certificate.
### Related topics
[Endorsement Key](#endorsement-key), [Storage Root Key](#storage-root-key), [Trusted Platform Module](#trusted-platform-module)
### Related to attestation identity keys
### More information
- [Windows Client Certificate Enrollment Protocol: Glossary](/openspecs/windows_protocols/ms-wcce/719b890d-62e6-4322-b9b1-1f34d11535b4#gt_70efa425-6b46-462f-911d-d399404529ab)
- [TPM Library Specification](https://trustedcomputinggroup.org/resource/tpm-library-specification/)
- [Endorsement key](#endorsement-key)
- [Storage root key](#storage-root-key)
- [Trusted platform module](#trusted-platform-module)
### More information about attestation identity keys
[Return to Top](hello-how-it-works-technology.md)
## Azure AD Joined
Azure AD Join is intended for organizations that desire to be cloud-first or cloud-only. There is no restriction on the size or type of organizations that can deploy Azure AD Join. Azure AD Join works well even in an hybrid environment and can enable access to on-premise applications and resources.
### Related topics
[Join Type](#join-type), [Hybrid Azure AD Joined](#hybrid-azure-ad-joined)
- [Windows client certificate enrollment protocol: glossary](/openspecs/windows_protocols/ms-wcce/719b890d-62e6-4322-b9b1-1f34d11535b4#gt_70efa425-6b46-462f-911d-d399404529ab)
- [TPM library specification](https://trustedcomputinggroup.org/resource/tpm-library-specification/)
### More information
- [Introduction to device management in Azure Active Directory](/azure/active-directory/device-management-introduction).
## Azure Active Directory join
[Return to Top](hello-how-it-works-technology.md)
## Azure AD Registered
The goal of Azure AD registered devices is to provide you with support for the Bring Your Own Device (BYOD) scenario. In this scenario, a user can access your organization's Azure Active Directory controlled resources using a personal device.
### Related topics
[Azure AD Joined](#azure-ad-joined), [Hybrid Azure AD Joined](#hybrid-azure-ad-joined), [Join Type](#join-type)
Azure Active Directory (Azure AD) join is intended for organizations that desire to be cloud-first or cloud-only. There's no restriction on the size or type of organizations that can deploy Azure AD join. Azure AD join also works in a hybrid environment and can enable access to on-premises applications and resources.
### More information
- [Introduction to device management in Azure Active Directory](/azure/active-directory/device-management-introduction)
### Related to Azure AD join
- [Join type](#join-type)
- [Hybrid Azure AD join](#hybrid-azure-ad-join)
[Return to Top](hello-how-it-works-technology.md)
## Certificate Trust
The certificate trust model uses a securely issued certificate based on the user's Windows Hello for Business identity to authenticate to on-premises Active Directory. The certificate trust model is supported in hybrid and on-premises deployments and is compatible with Windows Server 2008 R2 and later domain controllers.
### More information about Azure AD join
### Related topics
[Deployment Type](#deployment-type), [Hybrid Azure AD Joined](#hybrid-azure-ad-joined), [Hybrid Deployment](#hybrid-deployment), [Key Trust](#key-trust), [On-premises Deployment](#on-premises-deployment), [Trust Type](#trust-type)
[Introduction to device identity in Azure AD](/azure/active-directory/devices/overview).
### More information
- [Windows Hello for Business Planning Guide](hello-planning-guide.md)
## Azure AD registration
[Return to Top](hello-how-it-works-technology.md)
## Cloud Deployment
The Windows Hello for Business Cloud deployment is exclusively for organizations using cloud-based identities and resources. Device management is accomplished using Intune or a modern management alternative. Cloud deployments use Azure AD joined or Azure AD registered device join types.
The goal of Azure AD-registered devices is to provide you with support for the _bring your own device_ (BYOD) scenario. In this scenario, a user can access your organization's Azure AD-controlled resources using a personal device.
### Related topics
[Azure AD Joined](#azure-ad-joined), [Azure AD Registered](#azure-ad-registered), [Deployment Type](#deployment-type), [Join Type](#join-type)
### Related to Azure AD registration
[Return to Top](hello-how-it-works-technology.md)
## Cloud Experience Host
In Windows 10 and Windows 11, Cloud Experience Host is an application used while joining the workplace environment or Azure AD for rendering the experience when collecting your company-provided credentials. Once you enroll your device to your workplace environment or Azure AD, your organization will be able to manage your PC and collect information about you (including your location). It might add or remove apps or content, change settings, disable features, prevent you from removing your company account, or reset your PC.
- [Azure AD join](#azure-active-directory-join)
- [Hybrid Azure AD join](#hybrid-azure-ad-join)
- [Join type](#join-type)
### Related topics
[Windows Hello for Business](./hello-identity-verification.md), [Managed Windows Hello in Organization](./hello-manage-in-organization.md)
### More information about Azure AD registration
### More information
- [Windows Hello for Business and Device Registration](./hello-how-it-works-device-registration.md)
[Introduction to device identity in Azure AD](/azure/active-directory/devices/overview).
[Return to Top](hello-how-it-works-technology.md)
## Certificate trust
The certificate trust model uses a securely issued certificate based on the user's Windows Hello for Business identity to authenticate to on-premises Active Directory. The certificate trust model is supported in hybrid and on-premises deployments and is compatible with Windows Server 2008 R2 and later domain controllers.
### Related to certificate trust
- [Deployment type](#deployment-type)
- [Hybrid Azure AD join](#hybrid-azure-ad-join)
- [Hybrid deployment](#hybrid-deployment)
- [Key trust](#key-trust)
- [On-premises deployment](#on-premises-deployment)
- [Trust type](#trust-type)
### More information about certificate trust
[Windows Hello for Business planning guide](hello-planning-guide.md)
## Cloud deployment
The Windows Hello for Business cloud deployment is exclusively for organizations using cloud-based identities and resources. Device management is accomplished using Intune or a modern management alternative. Cloud deployments use Azure AD-joined or Azure AD-registered devices.
### Related to cloud deployment
- [Azure AD join](#azure-active-directory-join)
- [Azure AD registration](#azure-ad-registration)
- [Deployment type](#deployment-type)
- [Join type](#join-type)
## Cloud experience host
In Windows 10 and Windows 11, cloud experience host is an application used while joining the workplace environment or Azure AD for rendering the experience when collecting your company-provided credentials. Once you enroll your device to your workplace environment or Azure AD, your organization will be able to manage your PC and collect information about you (including your location). It might add or remove apps or content, change settings, disable features, prevent you from removing your company account, or reset your PC.
### Related to cloud experience host
- [Windows Hello for Business](./hello-identity-verification.md)
- [Managed Windows Hello in organization](./hello-manage-in-organization.md)
### More information on cloud experience host
[Windows Hello for Business and device registration](./hello-how-it-works-device-registration.md)
## Deployment type
Windows Hello for Business has three deployment models to accommodate the needs of different organizations. The three deployment models include:
## Deployment Type
Windows Hello for Business has three deployment models to accommodate the needs of different organizations. The three deployment models include:
- Cloud
- Hybrid
- On-Premises
- On-premises
### Related topics
[Cloud Deployment](#cloud-deployment), [Hybrid Deployment](#hybrid-deployment), [On-premises Deployment](#on-premises-deployment)
### Related to deployment type
### More information
- [Windows Hello for Business Planning Guide](hello-planning-guide.md)
- [Cloud deployment](#cloud-deployment)
- [Hybrid deployment](#hybrid-deployment)
- [On-premises deployment](#on-premises-deployment)
[Return to Top](hello-how-it-works-technology.md)
## Endorsement Key
### More information about deployment type
[Windows Hello for Business planning guide](hello-planning-guide.md)
## Endorsement key
The TPM has an embedded unique cryptographic key called the endorsement key. The TPM endorsement key is a pair of asymmetric keys (RSA size 2048 bits).
The endorsement key public key is generally used for sending securely sensitive parameters, such as when taking possession of the TPM that contains the defining hash of the owner password. The EK private key is used when creating secondary keys like AIKs.
The endorsement key public key is used for sending securely sensitive parameters, such as when taking possession of the TPM that contains the defining hash of the owner password. The EK private key is used when creating secondary keys like AIKs.
The endorsement key acts as an identity card for the TPM.
The endorsement key is often accompanied by one or two digital certificates:
- One certificate is produced by the TPM manufacturer and is called the **endorsement certificate**. The endorsement certificate is used to prove the authenticity of the TPM (for example, that it's a real TPM manufactured by a specific chip maker) to local processes, applications, or cloud services. The endorsement certificate is created during manufacturing or the first time the TPM is initialized by communicating with an online service.
- The other certificate is produced by the platform builder and is called the **platform certificate** to indicate that a specific TPM is integrated with a certain device.
- One certificate is produced by the TPM manufacturer and is called the **endorsement certificate**. The endorsement certificate is used to prove the authenticity of the TPM (for example, that it's a real TPM manufactured by a specific chip maker) to local processes, applications, or cloud services. The endorsement certificate is created during manufacturing or the first time the TPM is initialized by communicating with an online service.
- The other certificate is produced by the platform builder and is called the **platform certificate** to indicate that a specific TPM is integrated with a certain device.
For certain devices that use firmware-based TPM produced by Intel or Qualcomm, the endorsement certificate is created when the TPM is initialized during the OOBE of Windows 10 and Windows 11.
### Related topics
[Attestation Identity Keys](#attestation-identity-keys), [Storage Root Key](#storage-root-key), [Trusted Platform Module](#trusted-platform-module)
### Related to endorsement key
### More information
- [Understand the TPM endorsement key](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc770443(v=ws.11)).
- [TPM Library Specification](https://trustedcomputinggroup.org/resource/tpm-library-specification/)
- [Attestation identity keys](#attestation-identity-keys)
- [Storage root key](#storage-root-key)
- [Trusted platform module](#trusted-platform-module)
[Return to Top](hello-how-it-works-technology.md)
## Federated Environment
Primarily for large enterprise organizations with more complex authentication requirements, on-premises directory objects are synchronized with Azure Active Directory and users accounts are managed on-premises. With AD FS, users have the same password on-premises and in the cloud and they do not have to sign in again to use Office 365 or other Azure-based applications. This federated authentication model can provide additional authentication requirements, such as smart card-based authentication or a third-party multi-factor authentication and is typically required when organizations have an authentication requirement not natively supported by Azure AD.
### More information about endorsement key
### Related topics
[Hybrid Deployment](#hybrid-deployment), [Managed Environment](#managed-environment), [Pass-through authentication](#pass-through-authentication), [Password Hash Sync](#password-hash-sync)
- [Understand the TPM endorsement key](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc770443(v=ws.11))
- [TPM library specification](https://trustedcomputinggroup.org/resource/tpm-library-specification/)
### More information
- [Choosing the right authentication method for your Azure Active Directory hybrid identity solution](/azure/active-directory/hybrid/choose-ad-authn)
## Federated environment
Primarily for large enterprise organizations with more complex authentication requirements, on-premises directory objects are synchronized with Azure AD and users accounts are managed on-premises. With AD FS, users have the same password on-premises and in the cloud and they don't have to sign in again to use Office 365 or other Azure-based applications. This federated authentication model can provide extra authentication requirements, such as smart card-based authentication or a third-party multi-factor authentication and is typically required when organizations have an authentication requirement not natively supported by Azure AD.
### Related to federated environment
- [Hybrid deployment](#hybrid-deployment)
- [Managed environment](#managed-environment)
- [Pass-through authentication](#pass-through-authentication)
- [Password hash sync](#password-hash-sync)
### More information about federated environment
[Choose the right authentication method for your Azure AD hybrid identity solution](/azure/active-directory/hybrid/choose-ad-authn)
## Hybrid Azure AD join
[Return to Top](hello-how-it-works-technology.md)
## Hybrid Azure AD Joined
For more than a decade, many organizations have used the domain join to their on-premises Active Directory to enable:
- IT departments to manage work-owned devices from a central location.
- Users to sign in to their devices with their Active Directory work or school accounts.
Typically, organizations with an on-premises footprint rely on imaging methods to provision devices, and they often use or group policy (GP) to manage them.
- Users to sign in to their devices with their Active Directory work or school accounts.
If your environment has an on-premises AD footprint and you also want benefit from the capabilities provided by Azure Active Directory, you can implement hybrid Azure AD-joined devices. These are devices that are both, joined to your on-premises Active Directory and your Azure Active Directory.
Typically, organizations with an on-premises footprint rely on imaging methods to provision devices, and they often use or group policy to manage them.
### Related topics
[Azure AD Joined](#azure-ad-joined), [Azure AD Registered](#azure-ad-registered), [Hybrid Deployment](#hybrid-deployment)
If your environment has an on-premises AD footprint and you also want benefit from the capabilities provided by Azure AD, you can implement hybrid Azure AD-joined devices. These devices are joined to both your on-premises Active Directory and your Azure AD.
### More information
- [Introduction to device management in Azure Active Directory](/azure/active-directory/device-management-introduction)
### Related to hybrid Azure AD join
[Return to Top](hello-how-it-works-technology.md)
## Hybrid Deployment
The Windows Hello for Business hybrid deployment is for organizations that have both on-premises and cloud resources that are accessed using a managed or federated identity that is synchronized with Azure Active Directory. Hybrid deployments support devices that are Azure AD registered, Azure AD joined, and hybrid Azure AD joined. The Hybrid deployment model supports two trust types for on-premises authentication, key trust and certificate trust.
- [Azure AD join](#azure-active-directory-join)
- [Azure AD registration](#azure-ad-registration)
- [Hybrid deployment](#hybrid-deployment)
### Related topics
[Azure AD Joined](#azure-ad-joined), [Azure AD Registered](#azure-ad-registered), [Hybrid Azure AD Joined](#hybrid-azure-ad-joined),
### More information about hybrid Azure AD join
### More information
- [Windows Hello for Business Planning Guide](hello-planning-guide.md)
[Introduction to device identity in Azure AD](/azure/active-directory/devices/overview)
## Hybrid deployment
The Windows Hello for Business hybrid deployment is for organizations that have both on-premises and cloud resources that are accessed using a managed or federated identity that's synchronized with Azure AD. Hybrid deployments support devices that are Azure AD-registered, Azure AD-joined, and hybrid Azure AD-joined. The Hybrid deployment model supports two trust types for on-premises authentication, key trust and certificate trust.
### Related to hybrid deployment
- [Azure AD join](#azure-active-directory-join)
- [Azure AD registration](#azure-ad-registration)
- [Hybrid Azure AD join](#hybrid-azure-ad-join)
### More information about hybrid deployment
[Windows Hello for Business planning guide](hello-planning-guide.md)
[Return to Top](hello-how-it-works-technology.md)
## Join type
Join type is how devices are associated with Azure Active Directory. For a device to authenticate to Azure Active Directory it must be registered or joined.
Join type is how devices are associated with Azure AD. For a device to authenticate to Azure AD it must be registered or joined.
Registering a device to Azure AD enables you to manage a device's identity. When a device is registered, Azure AD device registration provides the device with an identity that is used to authenticate the device when a user signs-in to Azure AD. You can use the identity to enable or disable a device.
When combined with a mobile device management(MDM) solution such as Microsoft Intune, the device attributes in Azure AD are updated with additional information about the device. This allows you to create conditional access rules that enforce access from devices to meet your standards for security and compliance. For more information on enrolling devices in Microsoft Intune, see Enroll devices for management in Intune .
When combined with a mobile device management (MDM) solution such as Microsoft Intune, the device attributes in Azure AD are updated with additional information about the device. This behavior allows you to create conditional access rules that enforce access from devices to meet your standards for security and compliance. For more information on enrolling devices in Microsoft Intune, see Enroll devices for management in Intune.
Joining a device is an extension to registering a device. This means, it provides you with all the benefits of registering a device and in addition to this, it also changes the local state of a device. Changing the local state enables your users to sign-in to a device using an organizational work or school account instead of a personal account.
Joining a device is an extension to registering a device. This method provides you with all the benefits of registering a device, and changes the local state of a device. Changing the local state enables your users to sign-in to a device using an organizational work or school account instead of a personal account.
### Related topics
[Azure AD Joined](#azure-ad-joined), [Azure AD Registered](#azure-ad-registered), [Hybrid Azure AD Joined](#hybrid-azure-ad-joined)
### Related to join type
### More information
- [Introduction to device management in Azure Active Directory](/azure/active-directory/device-management-introduction)
- [Azure AD join](#azure-active-directory-join)
- [Azure AD registration](#azure-ad-registration)
- [Hybrid Azure AD join](#hybrid-azure-ad-join)
[Return to Top](hello-how-it-works-technology.md)
## Key Trust
The key trust model uses the user's Windows Hello for Business identity to authenticate to on-premises Active Directory. The key trust model is supported in hybrid and on-premises deployments and requires Windows Server 2016 domain controllers.
### More information about join type
### Related topics
[Certificate Trust](#certificate-trust), [Deployment Type](#deployment-type), [Hybrid Azure AD Joined](#hybrid-azure-ad-joined), [Hybrid Deployment](#hybrid-deployment), [On-premises Deployment](#on-premises-deployment), [Trust Type](#trust-type)
[Introduction to device identity in Azure AD](/azure/active-directory/devices/overview)
### More information
- [Windows Hello for Business Planning Guide](hello-planning-guide.md)
## Key trust
[Return to Top](hello-how-it-works-technology.md)
## Managed Environment
Managed environments are for non-federated environments where Azure Active Directory manages the authentication using technologies such as Password Hash Synchronization and Pass-through Authentication rather than a federation service such as Active Directory Federation Services.
The key trust model uses the user's Windows Hello for Business identity to authenticate to on-premises Active Directory. The key trust model is supported in hybrid and on-premises deployments and requires Windows Server 2016 domain controllers.
### Related topics
[Federated Environment](#federated-environment), [Pass-through authentication](#pass-through-authentication), [Password Hash Synchronization](#password-hash-sync)
### Related to key trust
[Return to Top](#technology-and-terms)
## On-premises Deployment
The Windows Hello for Business on-premises deployment is for organizations that exclusively have on-premises resources that are accessed using Active Directory identities. On-premises deployments support domain joined devices. The on-premises deployment model supports two authentication trust types, key trust and certificate trust.
- [Certificate trust](#certificate-trust)
- [Deployment type](#deployment-type)
- [Hybrid Azure AD join](#hybrid-azure-ad-join)
- [Hybrid deployment](#hybrid-deployment)
- [On-premises deployment](#on-premises-deployment)
- [Trust type](#trust-type)
### Related topics
[Cloud Deployment](#cloud-deployment), [Deployment Type](#deployment-type), [Hybrid Deployment](#hybrid-deployment)
### More information about key trust
### More information
- [Windows Hello for Business Planning Guide](hello-planning-guide.md)
[Windows Hello for Business planning guide](hello-planning-guide.md)
## Managed environment
Managed environments are for non-federated environments where Azure AD manages the authentication using technologies such as Password Hash Synchronization and Pass-through Authentication rather than a federation service such as Active Directory Federation Services (ADFS).
### Related to managed environment
- [Federated environment](#federated-environment)
- [Pass-through authentication](#pass-through-authentication)
- [Password hash synchronization](#password-hash-sync)
## On-premises deployment
The Windows Hello for Business on-premises deployment is for organizations that exclusively have on-premises resources that are accessed using Active Directory identities. On-premises deployments support domain joined devices. The on-premises deployment model supports two authentication trust types, key trust and certificate trust.
### Related to on-premises deployment
- [Cloud deployment](#cloud-deployment)
- [Deployment type](#deployment-type)
- [Hybrid deployment](#hybrid-deployment)
### More information about on-premises deployment
[Windows Hello for Business planning guide](hello-planning-guide.md)
[Return to Top](hello-how-it-works-technology.md)
## Pass-through authentication
Provides a simple password validation for Azure AD authentication services using a software agent running on one or more on-premises servers to validate the users directly with your on-premises Active Directory. With pass-through authentication (PTA), you synchronize on-premises Active Directory user account objects with Office 365 and manage your users on-premises. Allows your users to sign in to both on-premises and Office 365 resources and applications using their on-premises account and password. This configuration validates users' passwords directly against your on-premises Active Directory without sending password hashes to Office 365. Companies with a security requirement to immediately enforce on-premises user account states, password policies, and logon hours would use this authentication method. With seamless single sign-on, users are automatically signed in to Azure AD when they are on their corporate devices and connected to your corporate network.
### Related topics
[Federated Environment](#federated-environment), [Managed Environment](#managed-environment), [Password Hash Synchronization](#password-hash-sync)
Pass-through authentication provides a simple password validation for Azure AD authentication services. It uses a software agent that runs on one or more on-premises servers to validate the users directly with your on-premises Active Directory. With pass-through authentication (PTA), you synchronize on-premises Active Directory user account objects with Office 365 and manage your users on-premises. Allows your users to sign in to both on-premises and Office 365 resources and applications using their on-premises account and password. This configuration validates users' passwords directly against your on-premises Active Directory without sending password hashes to Office 365. Companies with a security requirement to immediately enforce on-premises user account states, password policies, and sign-in hours would use this authentication method. With seamless single sign-on, users are automatically signed in to Azure AD when they are on their corporate devices and connected to your corporate network.
### Related to pass-through authentication
### More information
- [Choosing the right authentication method for your Azure Active Directory hybrid identity solution](/azure/security/azure-ad-choose-authn)
- [Federated environment](#federated-environment)
- [Managed environment](#managed-environment)
- [Password hash synchronization](#password-hash-sync)
[Return to Top](hello-how-it-works-technology.md)
## Password Hash Sync
The simplest way to enable authentication for on-premises directory objects in Azure AD. With password hash sync (PHS), you synchronize your on-premises Active Directory user account objects with Office 365 and manage your users on-premises. Hashes of user passwords are synchronized from your on-premises Active Directory to Azure AD so that the users have the same password on-premises and in the cloud. When passwords are changed or reset on-premises, the new password hashes are synchronized to Azure AD so that your users can always use the same password for cloud resources and on-premises resources. The passwords are never sent to Azure AD or stored in Azure AD in clear text. Some premium features of Azure AD, such as Identity Protection, require PHS regardless of which authentication method is selected. With seamless single sign-on, users are automatically signed in to Azure AD when they are on their corporate devices and connected to your corporate network.
### More information about pass-through authentication
### Related topics
[Federated Environment](#federated-environment), [Managed Environment](#managed-environment), [Pass-through authentication](#pass-through-authentication)
[Choose the right authentication method for your Azure AD hybrid identity solution](/azure/active-directory/hybrid/choose-ad-authn)
### More information
- [Choosing the right authentication method for your Azure Active Directory hybrid identity solution](/azure/security/azure-ad-choose-authn)
## Password hash sync
[Return to Top](hello-how-it-works-technology.md)
## Primary Refresh Token
SSO relies on special tokens obtained for each of the types of applications above. These are in turn used to obtain access tokens to specific applications. In the traditional Windows Integrated authentication case using Kerberos, this token is a Kerberos TGT (ticket-granting ticket). For Azure AD and AD FS applications we call this a Primary Refresh Token (PRT). This is a [JSON Web Token](http://openid.net/specs/draft-jones-json-web-token-07.html) containing claims about both the user and the device.
Password hash sync is the simplest way to enable authentication for on-premises directory objects in Azure AD. With password hash sync (PHS), you synchronize your on-premises Active Directory user account objects with Office 365 and manage your users on-premises. Hashes of user passwords are synchronized from your on-premises Active Directory to Azure AD so that the users have the same password on-premises and in the cloud. When passwords are changed or reset on-premises, the new password hashes are synchronized to Azure AD so that your users can always use the same password for cloud resources and on-premises resources. The passwords are never sent to Azure AD or stored in Azure AD in clear text. Some premium features of Azure AD, such as Identity Protection, require PHS regardless of which authentication method is selected. With seamless single sign-on, users are automatically signed in to Azure AD when they are on their corporate devices and connected to your corporate network.
The PRT is initially obtained during Windows Logon (user sign-in/unlock) in a similar way the Kerberos TGT is obtained. This is true for both Azure AD joined and hybrid Azure AD-joined devices. In personal devices registered with Azure AD, the PRT is initially obtained upon Add Work or School Account (in a personal device the account to unlock the device is not the work account but a consumer account e.g. hotmail.com, live.com, outlook.com, etc.).
### Related to password hash sync
The PRT is needed for SSO. Without it, the user will be prompted for credentials when accessing applications every time. Please also note that the PRT contains information about the device. This means that if you have any [device-based conditional access](/azure/active-directory/active-directory-conditional-access-policy-connected-applications) policy set on an application, without the PRT, access will be denied.
- [Federated environment](#federated-environment)
- [Managed environment](#managed-environment)
- [Pass-through authentication](#pass-through-authentication)
[Return to Top](#technology-and-terms)
## Storage Root Key
The storage root key (SRK) is also an asymmetric key pair (RSA with a minimum of 2048 bits length). The SRK has a major role and is used to protect TPM keys, so that these keys cannot be used without the TPM. The SRK key is created when the ownership of the TPM is taken.
### More information about password hash sync
### Related topics
[Attestation Identity Keys](#attestation-identity-keys), [Endorsement Key](#endorsement-key), [Trusted Platform Module](#trusted-platform-module)
[Choose the right authentication method for your Azure AD hybrid identity solution](/azure/active-directory/hybrid/choose-ad-authn)
### More information
[TPM Library Specification](https://trustedcomputinggroup.org/resource/tpm-library-specification/)
## Primary refresh token
Single sign on (SSO) relies on special tokens obtained for each of the types of applications above. These special tokens are then used to obtain access tokens to specific applications. In the traditional Windows Integrated authentication case using Kerberos, this token is a Kerberos TGT (ticket-granting ticket). For Azure AD and AD FS applications, this token is a _primary refresh token_ (PRT). It's a [JSON Web Token](https://openid.net/specs/draft-jones-json-web-token-07.html) that contains claims about both the user and the device.
The PRT is initially obtained during Windows user sign-in or unlock in a similar way the Kerberos TGT is obtained. This behavior is true for both Azure AD joined and hybrid Azure AD-joined devices. For personal devices registered with Azure AD, the PRT is initially obtained upon Add Work or School Account. For a personal device the account to unlock the device isn't the work account, but a consumer account. For example, hotmail.com, live.com, or outlook.com.
The PRT is needed for SSO. Without it, the user will be prompted for credentials when accessing applications every time. The PRT also contains information about the device. If you have any [device-based conditional access](/azure/active-directory/conditional-access/concept-conditional-access-grant) policy set on an application, without the PRT, access will be denied.
## Storage root key
The storage root key (SRK) is also an asymmetric key pair (RSA with a minimum of 2048-bits length). The SRK has a major role and is used to protect TPM keys, so that these keys can't be used without the TPM. The SRK key is created when the ownership of the TPM is taken.
### Related to storage root key
- [Attestation identity keys](#attestation-identity-keys)
- [Endorsement key](#endorsement-key)
- [Trusted platform module](#trusted-platform-module)
### More information about storage root key
[TPM library specification](https://trustedcomputinggroup.org/resource/tpm-library-specification/)
[Return to Top](hello-how-it-works-technology.md)
## Trust type
The trust type determines how a user authenticates to the Active Directory to access on-premises resources. There are two trust types, key trust and certificate trust. The hybrid and on-premises deployment models support both trust types. The trust type does not affect authentication to Azure Active Directory. Windows Hello for Business authentication to Azure Active Directory always uses the key, not a certificate (excluding smart card authentication in a federated environment).
### Related topics
[Certificate Trust](#certificate-trust), [Hybrid Deployment](#hybrid-deployment), [Key Trust](#key-trust), [On-premises Deployment](#on-premises-deployment)
The trust type determines how a user authenticates to the Active Directory to access on-premises resources. There are two trust types, key trust and certificate trust. The hybrid and on-premises deployment models support both trust types. The trust type doesn't affect authentication to Azure AD. Windows Hello for Business authentication to Azure AD always uses the key, not a certificate (excluding smart card authentication in a federated environment).
### More information
- [Windows Hello for Business Planning Guide](hello-planning-guide.md)
### Related to trust type
[Return to Top](hello-how-it-works-technology.md)
## Trusted Platform Module
- [Certificate trust](#certificate-trust)
- [Hybrid deployment](#hybrid-deployment)
- [Key trust](#key-trust)
- [On-premises deployment](#on-premises-deployment)
A Trusted Platform Module (TPM) is a hardware component that provides unique security features.<br>
### More information about trust type
Windows leverages security characteristics of a TPM for measuring boot integrity sequence (and based on that, unlocking automatically BitLocker protected drives), for protecting credentials or for health attestation.
[Windows Hello for Business planning guide](hello-planning-guide.md)
## Trusted platform module
A trusted platform module (TPM) is a hardware component that provides unique security features.
Windows uses security characteristics of a TPM for the following functions:
- Measuring boot integrity sequence. Based on that sequence, it automatically unlocks BitLocker-protected drives
- Protecting credentials
- Health attestation
A TPM implements controls that meet the specification described by the Trusted Computing Group (TCG). There are currently two versions of the TPM specification produced by TCG that aren't compatible with each other:
A TPM implements controls that meet the specification described by the Trusted Computing Group (TCG). At the time of this writing, there are two versions of TPM specification produced by TCG that are not compatible with each other:
- The first TPM specification, version 1.2, was published in February 2005 by the TCG and standardized under ISO / IEC 11889 standard.
- The latest TPM specification, referred to as TPM 2.0, was released in April 2014 and has been approved by the ISO/IEC Joint Technical Committee (JTC) as ISO/IEC 11889:2015.
@ -290,27 +355,29 @@ Windows recognizes versions 1.2 and 2.0 TPM specifications produced by the TCG.
TPM 2.0 provides a major revision to the capabilities over TPM 1.2:
- Update cryptography strength to meet modern security needs
- Support for SHA-256 for PCRs
- Support for HMAC command
- Support for SHA-256 for PCRs
- Support for HMAC command
- Cryptographic algorithms flexibility to support government needs
- TPM 1.2 is severely restricted in terms of what algorithms it can support
- TPM 2.0 can support arbitrary algorithms with minor updates to the TCG specification documents
- TPM 1.2 is severely restricted in terms of what algorithms it can support
- TPM 2.0 can support arbitrary algorithms with minor updates to the TCG specification documents
- Consistency across implementations
- The TPM 1.2 specification allows vendors wide latitude when choosing implementation details
- TPM 2.0 standardizes much of this behavior
- The TPM 1.2 specification allows vendors wide latitude when choosing implementation details
- TPM 2.0 standardizes much of this behavior
In a simplified manner, the TPM is a passive component with limited resources. It can calculate random numbers, RSA keys, decrypt short data, store hashes taken when booting the device. A TPM incorporates in a single component:
- A RSA 2048-bit key generator
In a simplified manner, the TPM is a passive component with limited resources. It can calculate random numbers, RSA keys, decrypt short data, store hashes taken when booting the device. A TPM incorporates in a single component:
- An RSA 2048-bit key generator
- A random number generator
- Nonvolatile memory for storing EK, SRK, and AIK keys
- A cryptographic engine to encrypt, decrypt, and sign
- Volatile memory for storing the PCRs and RSA keys
### Related to trusted platform module
### Related topics
[Attestation Identity Keys](#attestation-identity-keys), [Endorsement Key](#endorsement-key), [Storage Root Key](#storage-root-key)
- [Attestation identity keys](#attestation-identity-keys)
- [Endorsement key](#endorsement-key)
- [Storage root key](#storage-root-key)
### More information
- [TPM Library Specification](https://trustedcomputinggroup.org/resource/tpm-library-specification/)
### More information about trusted platform module
[Return to Top](hello-how-it-works-technology.md)
[TPM library specification](https://trustedcomputinggroup.org/resource/tpm-library-specification/)

View File

@ -37,37 +37,37 @@ Windows Hello lets users authenticate to:
- A Microsoft account.
- An Active Directory account.
- A Microsoft Azure Active Directory (Azure AD) account.
- Identity Provider Services or Relying Party Services that support [Fast ID Online (FIDO) v2.0](https://go.microsoft.com/fwlink/p/?LinkId=533889) authentication.
- Identity Provider Services or Relying Party Services that support [Fast ID Online (FIDO) v2.0](https://fidoalliance.org/) authentication.
After an initial two-step verification of the user during enrollment, Windows Hello is set up on the user's device and Windows asks the user to set a gesture, which can be a biometric, such as a fingerprint, or a PIN. The user provides the gesture to verify their identity. Windows then uses Windows Hello to authenticate users.
As an administrator in an enterprise or educational organization, you can create policies to manage Windows Hello for Business use on Windows 10-based devices that connect to your organization.
As an administrator in an enterprise or educational organization, you can create policies to manage Windows Hello for Business use on Windows 10-based devices that connect to your organization.
## Biometric sign-in
Windows Hello provides reliable, fully integrated biometric authentication based on facial recognition or fingerprint matching. Windows Hello uses a combination of special infrared (IR) cameras and software to increase accuracy and guard against spoofing. Major hardware vendors are shipping devices that have integrated Windows Hello-compatible cameras. Fingerprint reader hardware can be used or added to devices that don't currently have it. On devices that support Windows Hello, an easy biometric gesture unlocks users' credentials.
- **Facial recognition**. This type of biometric recognition uses special cameras that see in IR light, which allows them to reliably tell the difference between a photograph or scan and a living person. Several vendors are shipping external cameras that incorporate this technology, and major laptop manufacturers are incorporating it into their devices, as well.
- **Fingerprint recognition**. This type of biometric recognition uses a capacitive fingerprint sensor to scan your fingerprint. Fingerprint readers have been available for Windows computers for years, but the current generation of sensors is significantly more reliable and less error-prone. Most existing fingerprint readers (whether external or integrated into laptops or USB keyboards) work with Windows 10 and Windows 11.
- **Fingerprint recognition**. This type of biometric recognition uses a capacitive fingerprint sensor to scan your fingerprint. Fingerprint readers have been available for Windows computers for years, but the current generation of sensors is more reliable and less error-prone. Most existing fingerprint readers work with Windows 10 and Windows 11, whether they're external or integrated into laptops or USB keyboards.
Windows stores biometric data that is used to implement Windows Hello securely on the local device only. The biometric data doesn't roam and is never sent to external devices or servers. Because Windows Hello only stores biometric identification data on the device, there's no single collection point an attacker can compromise to steal biometric data. For more information about biometric authentication with Windows Hello for Business, see [Windows Hello biometrics in the enterprise](hello-biometrics-in-enterprise.md).
## The difference between Windows Hello and Windows Hello for Business
- Individuals can create a PIN or biometric gesture on their personal devices for convenient sign-in. This use of Windows Hello is unique to the device on which it is set up, but can use a simple password hash depending on an individual's account type. This configuration is referred to as Windows Hello convenience PIN and it is not backed by asymmetric (public/private key) or certificate-based authentication.
- Individuals can create a PIN or biometric gesture on their personal devices for convenient sign-in. This use of Windows Hello is unique to the device on which it's set up, but can use a password hash depending on an individual's account type. This configuration is referred to as Windows Hello convenience PIN and it's not backed by asymmetric (public/private key) or certificate-based authentication.
- **Windows Hello for Business**, which is configured by Group Policy or mobile device management (MDM) policy, always uses key-based or certificate-based authentication. This makes it much more secure than **Windows Hello convenience PIN**.
- **Windows Hello for Business**, which is configured by group policy or mobile device management (MDM) policy, always uses key-based or certificate-based authentication. This behavior makes it more secure than **Windows Hello convenience PIN**.
## Benefits of Windows Hello
Reports of identity theft and large-scale hacking are frequent headlines. Nobody wants to be notified that their user name and password have been exposed.
You may wonder [how a PIN can help protect a device better than a password](hello-why-pin-is-better-than-password.md). Passwords are shared secrets; they are entered on a device and transmitted over the network to the server. An intercepted account name and password can be used by anyone, anywhere. Because they're stored on the server, a server breach can reveal those stored credentials.
You may wonder [how a PIN can help protect a device better than a password](hello-why-pin-is-better-than-password.md). Passwords are shared secrets; they're entered on a device and transmitted over the network to the server. An intercepted account name and password can be used by anyone, anywhere. Because they're stored on the server, a server breach can reveal those stored credentials.
In Windows 10 and later, Windows Hello replaces passwords. When an identity provider supports keys, the Windows Hello provisioning process creates a cryptographic key pair bound to the Trusted Platform Module (TPM), if a device has a TPM 2.0, or in software. Access to these keys and obtaining a signature to validate user possession of the private key is enabled only by the PIN or biometric gesture. The two-step verification that takes place during Windows Hello enrollment creates a trusted relationship between the identity provider and the user when the public portion of the public/private key pair is sent to an identity provider and associated with a user account. When a user enters the gesture on the device, the identity provider knows from the combination of Hello keys and gesture that this is a verified identity and provides an authentication token that allows Windows to access resources and services.
In Windows 10 and later, Windows Hello replaces passwords. When an identity provider supports keys, the Windows Hello provisioning process creates a cryptographic key pair bound to the Trusted Platform Module (TPM), if a device has a TPM 2.0, or in software. Access to these keys and obtaining a signature to validate user possession of the private key is enabled only by the PIN or biometric gesture. The two-step verification that takes place during Windows Hello enrollment creates a trusted relationship between the identity provider and the user when the public portion of the public/private key pair is sent to an identity provider and associated with a user account. When a user enters the gesture on the device, the identity provider knows that it's a verified identity, because of the combination of Windows Hello keys and gestures. It then provides an authentication token that allows Windows to access resources and services.
>[!NOTE]
>Windows Hello as a convenience sign-in uses regular username and password authentication, without the user entering the password.
> [!NOTE]
> Windows Hello as a convenience sign-in uses regular username and password authentication, without the user entering the password.
:::image type="content" alt-text="How authentication works in Windows Hello." source="images/authflow.png" lightbox="images/authflow.png":::
@ -79,15 +79,15 @@ Windows Hello helps protect user identities and user credentials. Because the us
- Windows Hello credentials are based on certificate or asymmetrical key pair. Windows Hello credentials can be bound to the device, and the token that is obtained using the credential is also bound to the device.
- Identity provider (such as Active Directory, Azure AD, or a Microsoft account) validates user identity and maps the Windows Hello public key to a user account during the registration step.
- An identity provider validates the user identity and maps the Windows Hello public key to a user account during the registration step. Example providers are Active Directory, Azure AD, or a Microsoft account.
- Keys can be generated in hardware (TPM 1.2 or 2.0 for enterprises, and TPM 2.0 for consumers) or software, based on the policy. To guarantee that keys are generated in hardware, you must set policy.
- Authentication is the two-factor authentication with the combination of a key or certificate tied to a device and something that the person knows (a PIN) or something that the person is (biometrics). The Windows Hello gesture does not roam between devices and is not shared with the server. Biometrics templates are stored locally on a device. The PIN is never stored or shared.
- Authentication is the two-factor authentication with the combination of a key or certificate tied to a device and something that the person knows (a PIN) or something that the person is (biometrics). The Windows Hello gesture doesn't roam between devices and isn't shared with the server. Biometrics templates are stored locally on a device. The PIN is never stored or shared.
- The private key never leaves a device when using TPM. The authenticating server has a public key that is mapped to the user account during the registration process.
- PIN entry and biometric gesture both trigger Windows 10 and later to use the private key to cryptographically sign data that is sent to the identity provider. The identity provider verifies the user's identity and authenticates the user.
- PIN entry and biometric gesture both trigger Windows 10 and later to use the private key to cryptographically sign data that is sent to the identity provider. The identity provider verifies the user's identity and authenticates the user.
- Personal (Microsoft account) and corporate (Active Directory or Azure AD) accounts use a single container for keys. All keys are separated by identity providers' domains to help ensure user privacy.
@ -97,25 +97,21 @@ For details, see [How Windows Hello for Business works](hello-how-it-works.md).
## Comparing key-based and certificate-based authentication
Windows Hello for Business can use either keys (hardware or software) or certificates in hardware or software. Enterprises that have a public key infrastructure (PKI) for issuing and managing end user certificates can continue to use PKI in combination with Windows Hello for Business. Enterprises that do not use PKI or want to reduce the effort associated with managing user certificates can rely on key-based credentials for Windows Hello. This still uses certificates on the domain controllers as a root of trust. Starting with Windows 10 21H2, there is a feature called cloud trust for hybrid deployments which uses Azure AD as the root of trust. Cloud trust uses key-based credentials for Windows Hello but does not require certificates on the domain controller.
Windows Hello for Business can use either keys (hardware or software) or certificates in hardware or software. Enterprises that have a public key infrastructure (PKI) for issuing and managing end user certificates can continue to use PKI in combination with Windows Hello for Business. Enterprises that don't use PKI or want to reduce the effort associated with managing user certificates can rely on key-based credentials for Windows Hello. This functionality still uses certificates on the domain controllers as a root of trust. Starting with Windows 10 version 21H2, there's a feature called cloud trust for hybrid deployments, which uses Azure AD as the root of trust. Cloud trust uses key-based credentials for Windows Hello but doesn't require certificates on the domain controller.
Windows Hello for Business with a key, including cloud trust, does not support supplied credentials for RDP. RDP does not support authentication with a key or a self signed certificate. RDP with Windows Hello for Business is supported with certificate based deployments as a supplied credential. Windows Hello for Business with a key credential can be used with [Windows Defender Remote Credential Guard](../remote-credential-guard.md).
Windows Hello for Business with a key, including cloud trust, doesn't support supplied credentials for RDP. RDP doesn't support authentication with a key or a self signed certificate. RDP with Windows Hello for Business is supported with certificate based deployments as a supplied credential. Windows Hello for Business with a key credential can be used with [Windows Defender Remote Credential Guard](../remote-credential-guard.md).
## Learn more
[Implementing strong user authentication with Windows Hello for Business](https://www.microsoft.com/en-us/itshowcase/implementing-strong-user-authentication-with-windows-hello-for-business)
[Implementing strong user authentication with Windows Hello for Business](https://www.microsoft.com/insidetrack/implementing-strong-user-authentication-with-windows-hello-for-business)
[Implementing Windows Hello for Business at Microsoft](https://www.microsoft.com/en-us/itshowcase/implementing-windows-hello-for-business-at-microsoft)
[Implementing Windows Hello for Business at Microsoft](https://www.microsoft.com/insidetrack/implementing-windows-hello-for-business-at-microsoft)
[Introduction to Windows Hello](/learn/?l=eH7yoY2BC_9106218949), video presentation on Microsoft Virtual Academy
[Windows Hello for Business: Authentication](https://youtu.be/WPmzoP_vMek): In this video, learn about Windows Hello for Business and how it's used to sign-in and access resources.
[Windows Hello face authentication](/windows-hardware/design/device-experiences/windows-hello-face-authentication)
[Windows 10: Disrupting the Revolution of Cyber-Threats with Revolutionary Security!](https://go.microsoft.com/fwlink/p/?LinkId=533890)
[Windows 10: The End Game for Passwords and Credential Theft?](https://go.microsoft.com/fwlink/p/?LinkId=533891)
## Related topics
## Related articles
- [How Windows Hello for Business works](hello-how-it-works.md)
- [Manage Windows Hello for Business in your organization](hello-manage-in-organization.md)