Completed the 1803 update to How it works

- includes new Technical Deep Dive section
2025-06-07 18:17:22 +00:00 · 2018-05-10 17:59:36 -07:00 · 2018-05-10 17:59:36 -07:00 · 022c8c5912
commit 022c8c5912
parent e8c1543586
30 changed files with 593 additions and 221 deletions
--- a/windows/security/identity-protection/hello-for-business/feature-multifactor-unlock.md
+++ b/windows/security/identity-protection/hello-for-business/feature-multifactor-unlock.md
@ -15,26 +15,27 @@ ms.date: 03/20/2018
 **Requirements:**
 * Windows Hello for Business deployment (Hybrid or On-premises)
-* Hybird Azure AD joined (Hybrid deployments)
+* Azure AD joined device (Cloud and Hybrid deployments)
 * Hybrid Azure AD joined (Hybrid deployments)
 * Domain Joined (on-premises deployments) 
 * Windows 10, version 1709
 * Bluetooth, Bluetooth capable phone - optional
 Windows, today, natively only supports the use of a single credential (password, PIN, fingerprint, face, etc.) for unlocking a device. Therefore, if any of those credentials are compromised (shoulder surfed), an attacker could gain access to the system.
-Windows 10 offers Multifactor device unlock by extending Windows Hello with trusted signals, administrators can configure Windows 10 to request a combination of factors and trusted signals to unlock their devices. 
+Windows 10 offers Multi-factor device unlock by extending Windows Hello with trusted signals, administrators can configure Windows 10 to request a combination of factors and trusted signals to unlock their devices. 
-Which organizations can take advanage of Multifactor unlock? Those who:
+Which organizations can take advantage of Multi-factor unlock? Those who:
 * Have expressed that PINs alone do not meet their security needs.
 * Want to prevent Information Workers from sharing credentials.
-* Want their orgs to comply with regulatory two-factor authentication policy.
+* Want their organizations to comply with regulatory two-factor authentication policy.
-* Want to retain the familiar Windows logon UX and not settle for a custom solution.
+* Want to retain the familiar Windows sign-in user experience and not settle for a custom solution.
-You enable multifactor unlock using Group Policy.  The **Configure device unlock factors** policy setting is located under **Computer Configuration\Administrative Templates\Windows Components\Windows Hello for Business**.
+You enable multi-factor unlock using Group Policy.  The **Configure device unlock factors** policy setting is located under **Computer Configuration\Administrative Templates\Windows Components\Windows Hello for Business**.
 ## The Basics: How it works
-First unlock factor credential provider and Second unlock credential provider are repsonsible for the bulk of the configuration.  Each of these components contains a globally unqiue identifier (GUID) that represents a different Windows credential provider.  With the policy setting enabled, users unlock the device using at least one credenital provider from each category before Windows allows the user to proceed to their desktop.
+First unlock factor credential provider and Second unlock credential provider are responsible for the bulk of the configuration.  Each of these components contains a globally unique identifier (GUID) that represents a different Windows credential provider.  With the policy setting enabled, users unlock the device using at least one credential provider from each category before Windows allows the user to proceed to their desktop.
 The policy setting has three components:
 * First unlock factor credential provider
@ -60,7 +61,7 @@ Supported credential providers include:
 The default credential providers for the **First unlock factor credential provider** include:
 * PIN
 * Fingerprint
-* Facial Recongition
+* Facial Recognition
 The default credential providers for the **Second unlock factor credential provider** include:
 * Trusted Signal
@ -76,7 +77,7 @@ For example, if you include the PIN and fingerprint credential providers in both
 The **Signal rules for device unlock** setting contains the rules the Trusted Signal credential provider uses to satisfy unlocking the device.
 ### Rule element
-You represent signal rules in XML.  Each signal rule has an starting and ending **rule** element that contains the **schemaVersion** attribute and value.  The current supported scheam version is 1.0.<br>
+You represent signal rules in XML.  Each signal rule has an starting and ending **rule** element that contains the **schemaVersion** attribute and value.  The current supported schema version is 1.0.<br>
 **Example**
 ```
 <rule schemaVersion="1.0">
@ -91,7 +92,7 @@ Each rule element has a **signal** element.  All signal elements have a **type**
 | type| "bluetooth" or "ipConfig" (Windows 10, version 1709)| 
 #### Bluetooth
-You define the bluetooth signal with additional attribute in the signal elment. The bluetooth configuration does not use any other elements. You can end the signal element with short ending tag "\/>".
+You define the bluetooth signal with additional attribute in the signal element. The bluetooth configuration does not use any other elements. You can end the signal element with short ending tag "\/>".
 |Attribute|Value|Required|
 |---------|-----|--------|
@ -248,7 +249,7 @@ This example configures the same as example 2 using compounding And elements.  T
 ### How to configure Multifactor Unlock policy settings
-You need a Windows 10, version 1709 workstation to run the Group Policy Management Console, which provides the latest Windows Hello for Business  Group Policy settings, which includes muiltifactor unlock. To run the Group Policy Management Console, you need to install the Remote Server Administration Tools for Windows 10. You can download these tools from the [Microsoft Download Center](https://www.microsoft.com/en-us/download/details.aspx?id=45520). Install the Remote Server Administration Tools for Windows 10 on a computer running Windows 10, version 1709.
+You need a Windows 10, version 1709 workstation to run the Group Policy Management Console, which provides the latest Windows Hello for Business  Group Policy settings, which includes multi-factor unlock. To run the Group Policy Management Console, you need to install the Remote Server Administration Tools for Windows 10. You can download these tools from the [Microsoft Download Center](https://www.microsoft.com/en-us/download/details.aspx?id=45520). Install the Remote Server Administration Tools for Windows 10 on a computer running Windows 10, version 1709.
 Alternatively, you can create copy the .ADMX and .ADML files from a Windows 10, version 1703 to their respective language folder on a Windows Server or you can create a Group Policy Central Store and copy them their respective language folder. See [How to create and manage the Central Store for Group Policy Administrative Templates in Windows](https://support.microsoft.com/help/3087759/how-to-create-and-manage-the-central-store-for-group-policy-administrative-templates-in-windows) for more information.
@ -277,7 +278,7 @@ The Group Policy object contains the policy settings needed to trigger Windows H
 11. Click **Ok** to close the **Group Policy Management Editor**. Use the **Group Policy Management Console** to deploy the newly created Group Policy object to your organization's computers.
 ## Troubleshooting
-Mulitfactor unlock writes events to event log under **Application and Services Logs\Microsoft\Windows\HelloForBusiness** with the category name **Device Unlock**.
+Multi-factor unlock writes events to event log under **Application and Services Logs\Microsoft\Windows\HelloForBusiness** with the category name **Device Unlock**.
 ### Events
--- a/windows/security/identity-protection/hello-for-business/hello-faq.md
+++ b/windows/security/identity-protection/hello-for-business/hello-faq.md
@ -14,13 +14,16 @@ ms.date: 05/05/2018
 # Windows Hello for Business Frequently Ask Questions
 ## What about virtual smart cards?
 Windows Hello for Business is the modern, two-factor credential for Windows 10.  Microsoft will be deprecating virtual smart cards in the future but not date at this time.  Customers using Windows 10 and 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 new Windows 10 deployments to use Windows Hello for Business. Virtual smart card remain supported for Windows 7 and Windows 8.
 ## What about convenience PIN?
 Microsoft is committed to its vision of a <u>world without passwords.</u> We recognize the *convenience* provided by convenience PIN, but it stills uses a password for authentication.  Microsoft recommends customers using Windows 10 and convenience PINs should move to Windows Hello for Business.  New Windows 10 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. 
 ## Can I deploy Windows Hello for Business using System Center Configuration Manager?
 Windows Hello for Business deployments using System Center Configuration Manager need to move to the hybrid deployment model that uses Active Directory Federation Services. Deployments using System Center Configuration Manager will no long be supported after November 2018.
 ## What is the password-less strategy?
@ -30,6 +33,7 @@ Watch Principal Program Manager Karanbir Singh's Ignite 2017 presentation **Micr
 [Microsoft's password-less strategy](hello-videos.md#Microsofts-passwordless-strategy)
 ## What is the user experience for Windows Hello for Business?
 The user experience for Windows Hello for Business occurs after user sign-in, after you deploy Windows Hello for Business policy settings to your environment.
 [Windows Hello for Business user enrollment experience](hello-videos.md#Windows-Hello-for-Business-user-enrollment-experience)
@ -43,21 +47,27 @@ If the user can sign-in with a password, they can reset their PIN by clicking th
 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 on-board their Azure tenant to use the Windows Hello for Business PIN reset service to reset their PINs without access to their corporate network.
 ## Do I need Windows Server 2016 domain controllers?
 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 have 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
 ## Is Windows Hello for Business multifactor authentication?
 Windows Hello for Business is two-factor authentication based the observed authentication factors of: something you have, something you know, and something part of you.  Windows Hello for Business incorporates two of these factors: something you have (the user's private key protected by the device's security module) and something you know (your PIN). With the proper hardware, you can enhance the user experience by introducing biometrics. Using biometrics, you can replace the "something you know" authentication factor with the "something that is part of you" factor, with the assurances that users can fall back to the "something you know factor".
 ## Can I use PIN and biometrics to unlock my device?
 Starting in Windows 10, version 1709, you can use multi-factor unlock to require the user to provide an additional factor to unlock the device.  Authentication remains two-factor, but another factor is required before Windows allows the user to reach the desktop.  Read more about [multifactor unlock](feature-multifactor-unlock.md).
 ## What is the difference between Windows Hello and Windows Hello for Business
 Windows Hello represents the biometric framework provided in Windows 10.  Windows Hello enables users to use biometrics to sign into 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.
 ## I have extended Active Directory to Azure Active Directory.  Can I use the on-prem deployment model?
 No. If your organization is federated or using online services, such as Office 365 or OneDrive, then you must use a hybrid deployment model.  On-premises deployments are exclusive to organization who need more time before moving to the cloud and exclusively use Active Directory.
 ## Does Windows Hello for Business prevent the use of simple PINs?
 Yes. Our simple PIN algorithm looks for and disallows any PIN that has a constant delta from one digit to the next.  This prevents repeating numbers, sequential numbers and simple patterns.
 So, for example:
 * 1111 has a constant delta of 0, so it is not allowed
@ -70,16 +80,25 @@ So, for example:
 This algorithm does not apply to alphanumeric PINs.
 ## How does PIN caching work with Windows Hello for Business?
 Windows Hello for Business provides a PIN caching user experience 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 considered transactional keys, which means the user is always prompted when accessing the key.  
-Beginning with Windows 10, Fall Creators Update, 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 will not prompt the user for the PIN.  
+Beginning with Windows 10, version 1709, Windows Hello for Business used as a smart card (smart card emulation that is enabled by default) provides the same user experience of default smart card PIN caching.  Each process requesting a private key operation will prompt the user for the PIN on first use.  Subsequent private key operations will not 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 does not receive the PIN, but rather the ticket that grants them private key operations.  Windows 10 does not provide any Group Policy settings to adjust this caching.
 ## Can I disable the PIN while using Windows Hello for Business?
 No. The movement away from passwords is accomplished by gradually reducing the use of the password.  In the occurrence where you cannot authenticate with biometrics, you need a fall back mechanism that is not a password.  The PIN is the fall back mechanism.  Disabling or hiding the PIN credential provider disabled the use of biometrics.
 ## How keys are protected
 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 does not 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 a variety of known and potential attacks, including PIN brute-force attacks. The TPM provides an additional layer of protection after an account lockout, too. When the TPM has locked the key material, the user will have to reset the PIN (which means he or she will have to use MFA to re-authenticate to the IDP before the IDP allows him or her to re-register).
 ## Does Windows Hello for Business work with third party federation servers?
 Windows Hello for Business can work with any third-party federation servers that support the protocols used during provisioning experience.  Interested third-parties can inquiry at [whfbfeedback@microsoft.com](mailto:whfbfeedback@microsoft.com?subject=collaboration)
 | Protocol | Description |
@ -90,5 +109,6 @@ Windows Hello for Business can work with any third-party federation servers that
 | [[MS-OIDCE]: OpenID Connect 1.0 Protocol Extensions](https://msdn.microsoft.com/en-us/library/mt766592.aspx) | Specifies the OpenID Connect 1.0 Protocol Extensions. These extensions define additional claims to carry information about the end 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 additional provider meta-data that enable the discovery of the issuer of access tokens and give additional information about provider capabilities. |
 ## Does Windows Hello for Business work with Mac and Linux clients?
 Windows Hello for Business is a feature of Windows 10. At this time, Microsoft is not 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)
--- a/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md
+++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md
@ -13,41 +13,76 @@ ms.date: 05/05/2018
 # Windows Hello for Business and Authentication
 Windows Hello for Business authentication is passwordless, two-factor authentication.  Authenticating with Windows Hello for Business provides a convenient sign-in experience that authenticates the user to both Azure Active Directory and Active Directory resources.<br>
-Azure Active Directory joined devices authenticate to Azure during sign-in and can optionaly authenticate to Active Directory.  Hybrid Azure Active Directory joined devices authenticate to Active Directory during sign-in, and authenticate to Azure Active Directory in the background.<br>
+Azure Active Directory joined devices authenticate to Azure during sign-in and can optional authenticate to Active Directory.  Hybrid Azure Active Directory joined devices authenticate to Active Directory during sign-in, and authenticate to Azure Active Directory in the background.<br>
-[Azure AD join authentication to Azure Active Directory](#AzureADjoinauthenticationtoAzureActiveDirectory)<br>
+[Azure AD join authentication to Azure Active Directory](#Azure-AD-join-authentication-to-Azure-Active-Directory)<br>
-[Azure AD join authentication to Active Direcotry using a Key](#AzureADjoinauthenticationtoActiveDirecotryusingaKey)<br>
+[Azure AD join authentication to Active Direcotry using a Key](#Azure-AD-join-authentication-to-Active-Direcotry-using-a-Key)<br>
-[Azure AD join authentication to Active Directory using a Certificate](#AzureADjoinauthenticationtoActiveDirectoryusingaCertificate)
+[Azure AD join authentication to Active Directory using a Certificate](#Azure-AD-join-authentication-to-Active-Directory-using-a-Certificate)<br>
-[Hybrid Azure AD join authentication using a Key](#HybridAzureADjoinauthenticationusingaKey)<br>
+[Hybrid Azure AD join authentication using a Key](#Hybrid-Azure-AD-join-authentication-using-a-Key)<br>
-[Hybrid Azure AD join authentication using a Certificate](#HybridAzureADjoinauthenticationusingaCertificate)<br>
+[Hybrid Azure AD join authentication using a Certificate](#Hybrid-Azure-AD-join-authentication-using-a-Certificate)<br>
 ## Azure AD join authentication to Azure Active Directory
 ![Azure AD join authentication to Azure Active Directory](images/howitworks/auth-aadj-cloud.png)
 | Phase  | Description  |
 | :----: | :----------- |
 |A | Authentication begins when the users dismisses the lock screen, which triggers winlogon to show the Windows Hello for Business credential provider.  The user provides their Windows Hello gesture (PIN or biometrics).  The credential provider packages these credentials and returns them to winlogon.  Winlogon passes the collected credentials to lsass. Lsass passes the collected credentials to the Cloud Authentication security support provider, referred to as the Cloud AP provider.| 
 |B | The Cloud AP provider requests a nonce from Azure Active Directory.  Azure AD returns a nonce. The Cloud AP provider signs the nonce using the user's private key and returns the signed nonce to the Azure Active Directory.|
 |C | Azure Active Directory validates the signed nonce using the user's securely registered public key against the nonce signature.  After validating the signature, Azure AD then validates the returned signed nonce. After validating the nonce, Azure AD creates a PRT with session key that is encrypted to the device's transport key and returns it to the Cloud AP provider.|
 |D | The Cloud AP provider receives the encrypted PRT with session key.  Using the device's private transport key, the Cloud AP provider decrypt the session key and protects the session key using the device's TPM.|
 |E | The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT, and informs winlogon of the success authentication.  Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.| 
 [Return to top](#Windows-Hello-for-Business-and-Authentication)
 ## Azure AD join authentication to Active Directory using a Key
 ![Azure AD join authentication to Active Direotory using a Key](images/howitworks/auth-aadj-keytrust-kerb.png)
-
+| Phase  | Description  |
-[Return to top](#WindowsHelloforBusinessandAuthentication)
+| :----: | :----------- |
-## Azure AD join authentication to Active Direcotry using a Key
+|A | Authentication to Active Directory from a Azure AD joined device begins with the user first attempts to use a resource that needs Kerberos authentication.  The Kerberos security support provider, hosted in lsass, uses metadata from the Windows Hello for Business key to get a hint of the user's domain.  Using the hint, the provider uses the DClocator service to locate a 2016 domain controller. After the provider locates an active 2016 domain controller, the provider uses the private key to sign the Kerberos pre-authentication data.|
 |B | The Kerberos provider sends the signed pre-authentication data and its public key (in the form of a self-signed certificate) to the Key Distribution Center (KDC) service running on the 2016 domain controller in the form of a KERB_AS_REQ.<br>The 2016 domain controller determines the certificate is a self-signed certificate.  It retrieves the public key from the certificate included in the KERB_AS_REQ and searches for the public key in Active Directory.  It validates the UPN for authentication request matches the UPN registered in Active Directory and validates the signed pre-authentication data using the public key from Active Directory.  On success, the KDC returns a TGT to the client with its certificate in a KERB_AS_REP.|
 |C | The Kerberos provider ensures it can trust the response from the domain controller. First, it ensures the KDC certificate chains to a root certificate that is trusted by the device.  Next, it ensures the certificate is within its validity period and that it has not be revoked.  The Kerberos provider then verifies the certificate has the KDC Authentication present and that the subject alternate name listed in the KDC's certificate matches the domain name to which the user is authenticating. After passing this criteria, Kerberos returns the TGT to lsass, where it is cached and used for subsequent service ticket requests.|
-
+[Return to top](#Windows-Hello-for-Business-and-Authentication)
 [Return to top](#WindowsHelloforBusinessandAuthentication)
 ## Azure AD join authentication to Active Directory using a Certificate
 ![Azure AD join authentication to Active Directory using a Certificate](images/howitworks/auth-aadj-certtrust-kerb.png)
 | Phase  | Description  |
 | :----: | :----------- |
 |A | Authentication to Active Directory from a Azure AD joined device begins with the user first attempts to use a resource that needs Kerberos authentication.  The Kerberos security support provider, hosted in lsass, uses information from the certificate to get a hint of the user's domain. Kerberos can use the distinguished name of the user found in the subject of the certificate, or it can use the user principal name of the user found in the subject alternate name of the certificate.  Using the hint, the provider uses the DClocator service to locate a domain controller. After the provider locates an active domain controller, the provider use the private key to sign the Kerberos pre-authentication data.|
 |B | The Kerberos provider sends the signed pre-authentication data and  user's certificate, which includes the public key, to the Key Distribution Center (KDC) service running on the domain controller in the form of a KERB_AS_REQ.<br>The domain controller determines the certificate is not self-signed certificate.  The domain controller ensures the certificate chains to trusted root certificate, is within its validity period, can be used for authentication, and has not been revoked.  It retrieves the public key and UPN from the certificate included in the KERB_AS_REQ and searches for the UPN in Active Directory.  It validates the signed pre-authentication data using the public key from the certificate.  On success, the KDC returns a TGT to the client with its certificate in a KERB_AS_REP.|
 |C | The Kerberos provider ensures it can trust the response from the domain controller. First, it ensures the KDC certificate chains to a root certificate that is trusted by the device.  Next, it ensures the certificate is within its validity period and that it has not be revoked.  The Kerberos provider then verifies the certificate has the KDC Authentication present and that the subject alternate name listed in the KDC's certificate matches the domain name to which the user is authenticating. After passing this criteria, Kerberos returns the TGT to lsass, where it is cached and used for subsequent service ticket requests.|
-[Return to top](#WindowsHelloforBusinessandAuthentication)
+[Return to top](#Windows-Hello-for-Business-and-Authentication)
 ## Hybrid Azure AD join authentication using a Key
 ![Hybrid Azure AD join authentication using a Key](images/howitworks/auth-haadj-keytrust.png)
 | Phase  | Description  |
 | :----: | :----------- |
 |A | Authentication begins when the users dismisses the lock screen, which triggers winlogon to show the Windows Hello for Business credential provider.  The user provides their Windows Hello gesture (PIN or biometrics).  The credential provider packages these credentials and returns them to winlogon.  Winlogon passes the collected credentials to lsass. Lsass passes the collected credentials to the Kerberos security support provider.  The Kerberos provider gets domain hints from the domain joined workstation to locate a domain controller for the user.|
 |B | The Kerberos provider sends the signed pre-authentication data and the user's public key (in the form of a self-signed certificate) to the Key Distribution Center (KDC) service running on the 2016 domain controller in the form of a KERB_AS_REQ.<br>The 2016 domain controller determines the certificate is a self-signed certificate.  It retrieves the public key from the certificate included in the KERB_AS_REQ and searches for the public key in Active Directory.  It validates the UPN for authentication request matches the UPN registered in Active Directory and validates the signed pre-authentication data using the public key from Active Directory.  On success, the KDC returns a TGT to the client with its certificate in a KERB_AS_REP.| 
 |C | The Kerberos provider ensures it can trust the response from the domain controller. First, it ensures the KDC certificate chains to a root certificate that is trusted by the device.  Next, it ensures the certificate is within its validity period and that it has not be revoked.  The Kerberos provider then verifies the certificate has the KDC Authentication present and that the subject alternate name listed in the KDC's certificate matches the domain name to which the user is authenticating. 
 |D | After passing this criteria, Kerberos returns the TGT to lsass, where it is cached and used for subsequent service ticket requests.|
 |E | Lsass informs winlogon of the success authentication.  Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.|
 |F | While Windows loads the user's desktop, lsass passes the collected credentials to the Cloud Authentication security support provider, referred to as the Cloud AP provider.  The Cloud AP provider requests a nonce from Azure Active Directory.  Azure AD returns a nonce.|
 |G |  The Cloud AP provider signs the nonce using the user's private key and returns the signed nonce to the Azure Active Directory.  Azure Active Directory validates the signed nonce using the user's securely registered public key against the nonce signature.  After validating the signature, Azure AD then validates the returned signed nonce. After validating the nonce, Azure AD creates a PRT with session key that is encrypted to the device's transport key and returns it to the Cloud AP provider.<br>The Cloud AP provider receives the encrypted PRT with session key.  Using the device's private transport key, the Cloud AP provider decrypt the session key and protects the session key using the device's TPM.<br>The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT.|
-
+[Return to top](#Windows-Hello-for-Business-and-Authentication)
 [Return to top](#WindowsHelloforBusinessandAuthentication)
 ## Hybrid Azure AD join authentication using a Certificate
-
+![Hybrid Azure AD join authentication using a Certificate](images/howitworks/auth-haadj-certtrust.png)
-
+
-
+| Phase  | Description  |
-
+| :----: | :----------- |
-[Return to top](#WindowsHelloforBusinessandAuthentication)
+|A | Authentication begins when the users dismisses the lock screen, which triggers winlogon to show the Windows Hello for Business credential provider.  The user provides their Windows Hello gesture (PIN or biometrics).  The credential provider packages these credentials and returns them to winlogon.  Winlogon passes the collected credentials to lsass. Lsass passes the collected credentials to the Kerberos security support provider.  The Kerberos provider gets domain hints from the domain joined workstation to locate a domain controller for the user.|
 |B | The Kerberos provider sends the signed pre-authentication data and  user's certificate, which includes the public key, to the Key Distribution Center (KDC) service running on the domain controller in the form of a KERB_AS_REQ.<br>The domain controller determines the certificate is not self-signed certificate.  The domain controller ensures the certificate chains to trusted root certificate, is within its validity period, can be used for authentication, and has not been revoked.  It retrieves the public key and UPN from the certificate included in the KERB_AS_REQ and searches for the UPN in Active Directory.  It validates the signed pre-authentication data using the public key from the certificate.  On success, the KDC returns a TGT to the client with its certificate in a KERB_AS_REP.| 
 |C | The Kerberos provider ensures it can trust the response from the domain controller. First, it ensures the KDC certificate chains to a root certificate that is trusted by the device.  Next, it ensures the certificate is within its validity period and that it has not be revoked.  The Kerberos provider then verifies the certificate has the KDC Authentication present and that the subject alternate name listed in the KDC's certificate matches the domain name to which the user is authenticating. 
 |D | After passing this criteria, Kerberos returns the TGT to lsass, where it is cached and used for subsequent service ticket requests.|
 |E | Lsass informs winlogon of the success authentication.  Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.|
 |F | While Windows loads the user's desktop, lsass passes the collected credentials to the Cloud Authentication security support provider, referred to as the Cloud AP provider.  The Cloud AP provider requests a nonce from Azure Active Directory.  Azure AD returns a nonce.|
 |G |  The Cloud AP provider signs the nonce using the user's private key and returns the signed nonce to the Azure Active Directory.  Azure Active Directory validates the signed nonce using the user's securely registered public key against the nonce signature.  After validating the signature, Azure AD then validates the returned signed nonce. After validating the nonce, Azure AD creates a PRT with session key that is encrypted to the device's transport key and returns it to the Cloud AP provider.<br>The Cloud AP provider receives the encrypted PRT with session key.  Using the device's private transport key, the Cloud AP provider decrypt the session key and protects the session key using the device's TPM.<br>The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT.|
 [Return to top](#Windows-Hello-for-Business-and-Authentication)
--- a/windows/security/identity-protection/hello-for-business/hello-how-it-works-new.md
+++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works-new.md
@ -1,17 +0,0 @@
 ---
 title: How Windows Hello for Business works - Overview
 description: Explains registration, authentication, key material, and infrastructure for Windows Hello for Business.
 ms.prod: w10
 ms.mktglfcycl: deploy
 ms.sitesec: library
 ms.pagetype: security
 author: mikestephens-MS
 ms.author: mstephen
 localizationpriority: high
 ms.date: 05/05/2018
 ---
 # Overview
 Windows Hello for Business is a modern, two-factor credential that is the more secure alternative to passwords.  Windows.  Whether you are cloud or on-premises, Windows Hello for Business has a deployment option for you.  For cloud deployments, you can use Windows Hello for Business with Azure Active Directory joined, Hybrid Azure Active Direcotry joined, or Azure Active Directory registered devices.  Windows Hello for Business also works for domain joined devices. 
 Watch this quick video where Pieter Wigleven gives a simple explanation of how Windows Hello for Business works and some of its supporting features.
 > [!VIDEO https://www.youtube.com/embed/G-GJuDWbBE8]
--- a/windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md
+++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md
@ -12,52 +12,130 @@ ms.date: 05/05/2018
 ---
 # Windows Hello for Business Provisioning
 Windows Hello for Business provisioning enables a user to enroll a new, strong, two-factor credential that they can use for passwordless authentication.  Provisioning experience vary based on:
- How device is joined to Azure Active Directory
+- How the device is joined to Azure Active Directory
 - The Windows Hello for Business deployment type
 - If the environment is managed or federated
-[Azure AD joined provisioning in a Managed environment](#AzureADjoinedprovisioninginaManagedenvironment)<br>
+[Azure AD joined provisioning in a Managed environment](#Azure-AD-joined-provisioning-in-a-Managed-environment)<br>
-[Azure AD joined provisioning in a Federated environment](#AzureADjoinedprovisioninginaFederatedenvironment)<br>
+[Azure AD joined provisioning in a Federated environment](#Azure-AD-joined-provisioning-in-a-Federated-environment)<br>
-[Hybrid Azure AD joined provisioning in a Key Trust deployment](#HybridAzureADjoinedprovisioninginaKeyTrustdeployment)<br>
+[Hybrid Azure AD joined provisioning in a Key Trust deployment](#Hybrid-Azure-AD-joined-provisioning-in-a-Key-Trust-deployment)<br>
-[Hybrid Azure AD joined provisioning in a Certificate Trust deployment](#HybridAzureADjoinedprovisioninginaCertificateTrustdeployment)<br>
+[Hybrid Azure AD joined provisioning in a Certificate Trust deployment](#Hybrid-Azure-AD-joined-provisioning-in-a-Certificate-Trust-deployment)<br>
-[Hybrid Azure AD joined provisioning in a synchronous Certificate Trust deployment](#HybridAzureADjoinedprovisioninginasynchronousCertificateTrustdeployment)<br>
+[Hybrid Azure AD joined provisioning in a synchronous Certificate Trust deployment](#Hybrid-Azure-AD-joined-provisioning-in-a-synchronous-Certificate-Trust-deployment)<br>
-[Domain joined provisioning in an On-premises Key Trust deployment](#DomainjoinedprovisioninginanOnpremisesKeyTrustdeployment)<br>
+[Domain joined provisioning in an On-premises Key Trust deployment](#Domain-joined-provisioning-in-an-Onpremises-Key-Trust-deployment)<br>
-[Domain joined provisioning in an On-premises Certificate Trust deployment](#DomainjoinedprovisioninginanOnpremisesCertificateTrustdeployment)<br>
+[Domain joined provisioning in an On-premises Certificate Trust deployment](#Domain-joined-provisioning-in-an-Onpremises-Certificate-Trust-deployment)<br>
 ## Azure AD joined provisioning in a Managed environment
 ![Azure AD joined provisioning in a Managed environment](images/howitworks/prov-aadj-managed.png)
 | Phase  | Description  |
 | :----: | :----------- |
 | A|The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.<br>Users must provide two factors of authentication.  In this phase, the user has already provided one factor of authentication, typically user name and password.  Azure MFA services provides the second factor of authentication.  If the user has performed Azure MFA within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they are not prompted for MFA because the current MFA remains valid.<br>Azure Active Directory validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
 |B | After receiving a ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor.  If the application detects a biometric sensor, it gives the user the choice to enroll biometrics.  After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics).  The user provides and confirms their PIN.  Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data.  This is the user key (ukpub/ukpriv).|
 |C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration.  Azure DRS validates the MFA claim remains current.  On successful validation, Azure DRS locates the user's object in Azure Active Directory, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Azure Active Directory returns a key ID to the application which signals the end of user provisioning and the application exits.|
-[Return to top](#WindowsHelloforBusinessProvisioning)
+
 [Return to top](#Windows-Hello-for-Business-Provisioning)
 ## Azure AD joined provisioning in a Federated environment
 ![Azure AD joined provisioning in a Managed environment](images/howitworks/prov-aadj-federated.png)
 | Phase  | Description  |
 | :----: | :----------- |
 | A|The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.<br>  In a federated environment, the plug-in sends the token request to the on-premises STS, such as Active Directory Federation Services.  The on-premises STS authenticates the user and determines if the user should perform another factor of authentication.<br>Users must provide two factors of authentication.  In this phase, the user has already provided one factor of authentication, typically user name and password.  Azure MFA services provides the second factor of authentication.  If the user has performed Azure MFA within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they are not prompted for MFA because the current MFA remains valid.<br> The on-premises STS server issues a enterprise token on successful MFA.  The application sends the token to Azure Active Directory.<br>Azure Active Directory validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
 |B | After receiving a ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor.  If the application detects a biometric sensor, it gives the user the choice to enroll biometrics.  After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics).  The user provides and confirms their PIN.  Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data.  This is the user key (ukpub/ukpriv).|
 |C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration.  Azure DRS validates MFA claim remains current.  On successful validation, Azure DRS locates the user's object in Azure Active Directory, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Azure Active Directory returns key ID to the application which signals the end of user provisioning and the application exits.|
 [Return to top](#Windows-Hello-for-Business-Provisioning)
 ## Hybrid Azure AD joined provisioning in a Key Trust deployment in a Managed envrionment
 ![Hybrid Azure AD joined provisioning in a Key Trust deployment in a Managed ennvironment](images/howitworks/prov-haadj-keytrust-managed.png)
 | Phase  | Description  |
 | :----: | :----------- |
 | A|The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.<br>Users must provide two factors of authentication.  In this phase, the user has already provided one factor of authentication, typically user name and password.  Azure MFA services provides the second factor of authentication.  If the user has performed Azure MFA within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they are not prompted for MFA because the current MFA remains valid.<br>Azure Active Directory validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
 |B | After receiving a ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor.  If the application detects a biometric sensor, it gives the user the choice to enroll biometrics.  After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics).  The user provides and confirms their PIN.  Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data.  This is the user key (ukpub/ukpriv).|
 |C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration.  Azure DRS validates the MFA claim remains current.  On successful validation, Azure DRS locates the user's object in Azure Active Directory, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Azure Active Directory returns a key ID to the application which signals the end of user provisioning and the application exits.|
 |D | Azure AD Connect requests updates on its next synchronization cycle.  Azure Active Directory sends the user's public key that was securely registered through provisioning.  AAD Connect receives the public key and writes it to user's msDS-KeyCredentialLink attribute in Active Directory.|
 > [!IMPORTANT]
 > The newly provisionied user will not be able to sign in using Windows Hello for Business until Azure AD Connect successfully synchronizes the public key to the on-premises Active Directory.
-[Return to top](#WindowsHelloforBusinessProvisioning)
+
-## Hybrid Azure AD joined provisioning in a Key Trust deployment
+[Return to top](#Windows-Hello-for-Business-Provisioning)
 ## Hybrid Azure AD joined provisioning in a Certificate Trust deployment in a Managed environment
 ![Hybrid Azure AD joined provisioning in a Certificate Trust deployment in a Managed environment](images/howitworks/prov-haadj-certtrust-managed.png)
 | Phase  | Description  |
 | :----: | :----------- |
 | A|The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.<br>Users must provide two factors of authentication.  In this phase, the user has already provided one factor of authentication, typically user name and password.  Azure MFA services provides the second factor of authentication.  If the user has performed Azure MFA within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they are not prompted for MFA because the current MFA remains valid.<br>Azure Active Directory validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
 |B | After receiving a ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor.  If the application detects a biometric sensor, it gives the user the choice to enroll biometrics.  After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics).  The user provides and confirms their PIN.  Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data.  This is the user key (ukpub/ukpriv).|
 |C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration.  Azure DRS validates the MFA claim remains current.  On successful validation, Azure DRS locates the user's object in Azure Active Directory, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Azure Active Directory returns a key ID to the application, which represents the end of user key registration.|
 |D | The certificate request portion of provisioning begins after the application receives a successful response from key registration.  The application creates a PKCS#10 certificate request.  The key used in the certificate request is the same key that was securely provisioned.<br> The application sends the certificate request, which includes the public key, to the certificate registration authority hosted on the Active Directory Federation Services (AD FS) farm.<br>  After receiving the certificate request, the certificate registration authority queries Active Directory for the msDS-KeyCredentailsLink for a list of registered public keys.|
 |E | The registration authority validates the public key in the certificate request matches a registered key for the user.<br>  If the public key in the certificate is not found in the list of registered public keys, certificate enrollment is deferred until Phase F completes.  The application is informed of the deferment and exits to the user's desktop.  The automatic certificate enrollment client triggers the Azure AD Web Account Manager plug-in to retry the certificate enrollment at 24, 85, 145, 205, 265, and 480 minutes after phase C successfully completes.  The user must remain signed in for automatic certificate enrollment to trigger certificate enrollment.  If the user signs out, automatic certificate enrollment is triggered approximately 30 minutes after the user's next sign in.<br> After validating the public key, the registration authority signs the certificate request using its enrollment agent certificate.|
 |G |The registration authority sends the certificate request to the enterprise issuing certificate authority. The certificate authority validates the certificate request is signed by a valid enrollment agent and, on success, issues a certificate and returns it to the registration authority that then returns the certificate to the application.|
 |H | The application receives the newly issued certificate and installs the it into the Personal store of the user.  This signals the end of provisioning.|    
 |F | Azure AD Connect requests updates on its next synchronization cycle.  Azure Active Directory sends the user's public key that was securely registered through provisioning.  AAD Connect receives the public key and writes it to user's msDS-KeyCredentialLink attribute in Active Directory.|
 > [!IMPORTANT]
 > The newly provisionied user will not be able to sign in using Windows Hello for Business until Azure AD Connect successfully synchronizes the public key to the on-premises Active Directory.
 [Return to top](#Windows-Hello-for-Business-Provisioning)
 ## Hybrid Azure AD joined provisioning in a synchronous Certificate Trust deployment in a Managed environmnet
 ![Hybrid Azure AD joined provisioning in a synchronous Certificate Trust deployment in a Managed environment](images/howitworks/prov-haadj-instant-certtrust-managed.png)
-[Return to top](#WindowsHelloforBusinessProvisioning)
+| Phase  | Description  |
-## Hybrid Azure AD joined provisioning in a Certificate Trust deployment
+| :----: | :----------- |
 | A|The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.<br>Users must provide two factors of authentication.  In this phase, the user has already provided one factor of authentication, typically user name and password.  Azure MFA services provides the second factor of authentication.  If the user has performed Azure MFA within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they are not prompted for MFA because the current MFA remains valid.<br>Azure Active Directory validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
 |B | After receiving a ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor.  If the application detects a biometric sensor, it gives the user the choice to enroll biometrics.  After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics).  The user provides and confirms their PIN.  Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data.  This is the user key (ukpub/ukpriv).|
 |C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration.  Azure DRS validates the MFA claim remains current.  On successful validation, Azure DRS locates the user's object in Azure Active Directory, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Azure Active Directory returns a key ID and a key receipt to the application, which represents the end of user key registration.|
 |D | The certificate request portion of provisioning begins after the application receives a successful response from key registration.  The application creates a PKCS#10 certificate request.  The key used in the certificate request is the same key that was securely provisioned.<br> The application sends the key receipt and certificate request, which includes the public key, to the certificate registration authority hosted on the Active Directory Federation Services (AD FS) farm.<br>  After receiving the certificate request, the certificate registration authority queries Active Directory for the msDS-KeyCredentailsLink for a list of registered public keys.|
 |E | The registration authority validates the public key in the certificate request matches a registered key for the user.<br>  If the public key in the certificate is not found in the list of registered public keys, it then validates the key receipt to confirm the key was securely registered with Azure.<br>After validating the key receipt or public key, the registration authority signs the certificate request using its enrollment agent certificate.|
 |F |The registration authority sends the certificate request to the enterprise issuing certificate authority. The certificate authority validates the certificate request is signed by a valid enrollment agent and, on success, issues a certificate and returns it to the registration authority that then returns the certificate to the application.|
 |G | The application receives the newly issued certificate and installs the it into the Personal store of the user.  This signals the end of provisioning.|    
 > [!IMPORTANT]
 > Synchronous certificate enrollment does not depend on Azure AD Connect to syncrhonize the user's public key to issue the Windows Hello for Business authentication certificate.  Users can sign-in using the certificate immediately after provisioning completes.  Azure AD Connect continues to synchronize the public key to Active Directory, but is not show in this flow.
 [Return to top](#Windows-Hello-for-Business-Provisioning)
 ## Hybrid Azure AD joined provisioning in a synchronous Certificate Trust deployment in a Federated environment
 ![Hybrid Azure AD joined provisioning in a synchronous Certificate Trust deployment in a Fedeerated environment](images/howitworks/prov-haadj-instant-certtrust-federated.png)
-[Return to top](#WindowsHelloforBusinessProvisioning)
+| Phase  | Description  |
-## Hybrid Azure AD joined provisioning in a synchronous Certificate Trust deployment
+| :----: | :----------- |
 | A|The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.<br>  In a federated environment, the plug-in sends the token request to the on-premises STS, such as Active Directory Federation Services.  The on-premises STS authenticates the user and determines if the user should perform another factor of authentication.<br>Users must provide two factors of authentication.  In this phase, the user has already provided one factor of authentication, typically user name and password.  Azure MFA services (or a third party MFA service) provides the second factor of authentication.<br> The on-premises STS server issues a enterprise token on successful MFA.  The application sends the token to Azure Active Directory.<br>Azure Active Directory validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
 |B | After receiving a ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor.  If the application detects a biometric sensor, it gives the user the choice to enroll biometrics.  After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics).  The user provides and confirms their PIN.  Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data.  This is the user key (ukpub/ukpriv).|
 |C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration.  Azure DRS validates the MFA claim remains current.  On successful validation, Azure DRS locates the user's object in Azure Active Directory, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Azure Active Directory returns a key ID and a key receipt to the application, which represents the end of user key registration.|
 |D | The certificate request portion of provisioning begins after the application receives a successful response from key registration.  The application creates a PKCS#10 certificate request.  The key used in the certificate request is the same key that was securely provisioned.<br> The application sends the key receipt and certificate request, which includes the public key, to the certificate registration authority hosted on the Active Directory Federation Services (AD FS) farm.<br>  After receiving the certificate request, the certificate registration authority queries Active Directory for the msDS-KeyCredentailsLink for a list of registered public keys.|
 |E | The registration authority validates the public key in the certificate request matches a registered key for the user.<br>  If the public key in the certificate is not found in the list of registered public keys, it then validates the key receipt to confirm the key was securely registered with Azure.<br>After validating the key receipt or public key, the registration authority signs the certificate request using its enrollment agent certificate.|
 |F |The registration authority sends the certificate request to the enterprise issuing certificate authority. The certificate authority validates the certificate request is signed by a valid enrollment agent and, on success, issues a certificate and returns it to the registration authority that then returns the certificate to the application.|
 |G | The application receives the newly issued certificate and installs the it into the Personal store of the user.  This signals the end of provisioning.| 
 > [!IMPORTANT]
 > Synchronous certificate enrollment does not depend on Azure AD Connect to syncrhonize the user's public key to issue the Windows Hello for Business authentication certificate.  Users can sign-in using the certificate immediately after provisioning completes.  Azure AD Connect continues to synchronize the public key to Active Directory, but is not show in this flow.
-
+[Return to top](#Windows-Hello-for-Business-Provisioning)
 [Return to top](#WindowsHelloforBusinessProvisioning)
 ## Domain joined provisioning in an On-premises Key Trust deployment
 ![Domain joined provisioning in an On-premises Key Trust deployment](images/howitworks/prov-onprem-keytrust.png)
 | Phase  | Description  |
 | :----: | :----------- |
 |A| The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Enterprise Device Registration Service (EDRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.<br>  In an on-premises deployment, the plug-in sends the token request to the on-premises STS, such as Active Directory Federation Services.  The on-premises STS authenticates the user and determines if the user should perform another factor of authentication.<br>Users must provide two factors of authentication.  In this phase, the user has already provided one factor of authentication, typically user name and password.  Azure MFA server (or a third party MFA service) provides the second factor of authentication.<br> The on-premises STS server issues a enterprise DRS token on successful MFA.|
 | B| After receiving a EDRS access token, the application detects if the device has a Windows Hello biometric compatible sensor.  If the application detects a biometric sensor, it gives the user the choice to enroll biometrics.  After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics).  The user provides and confirms their PIN.  Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data.  This is the user key (ukpub/ukpriv).|
 |C | The application sends the EDRS token, ukpub, attestation data, and device information to the Enterprise DRS for user key registration.  Enterprise DRS validates the MFA claim remains current.  On successful validation, the Enterprise DRS locates the user's object in Active Directory, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. The Enterprise DRS returns a key ID to the application, which represents the end of user key registration.|
-
+[Return to top](#Windows-Hello-for-Business-Provisioning)
 [Return to top](#WindowsHelloforBusinessProvisioning)
 ## Domain joined provisioning in an On-premises Certificate Trust deployment
 ![Domain joined provisioning in an On-premises Certificate Trust deployment](images/howitworks/prov-onprem-certtrust.png)
 | Phase  | Description  |
 | :----: | :----------- |
 |A| The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Enterprise Device Registration Service (EDRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.<br>  In an on-premises deployment, the plug-in sends the token request to the on-premises STS, such as Active Directory Federation Services.  The on-premises STS authenticates the user and determines if the user should perform another factor of authentication.<br>Users must provide two factors of authentication.  In this phase, the user has already provided one factor of authentication, typically user name and password.  Azure MFA server (or a third party MFA service) provides the second factor of authentication.<br> The on-premises STS server issues a enterprise DRS token on successful MFA.|
 | B| After receiving a EDRS access token, the application detects if the device has a Windows Hello biometric compatible sensor.  If the application detects a biometric sensor, it gives the user the choice to enroll biometrics.  After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics).  The user provides and confirms their PIN.  Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data.  This is the user key (ukpub/ukpriv).|
 |C | The application sends the EDRS token, ukpub, attestation data, and device information to the Enterprise DRS for user key registration.  Enterprise DRS validates the MFA claim remains current.  On successful validation, the Enterprise DRS locates the user's object in Active Directory, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. The Enterprise DRS returns a key ID to the application, which represents the end of user key registration.|
 |D | The certificate request portion of provisioning begins after the application receives a successful response from key registration.  The application creates a PKCS#10 certificate request.  The key used in the certificate request is the same key that was securely provisioned.<br> The application sends the certificate request, which includes the public key, to the certificate registration authority hosted on the Active Directory Federation Services (AD FS) farm.<br>  After receiving the certificate request, the certificate registration authority queries Active Directory for the msDS-KeyCredentailsLink for a list of registered public keys.|
 |E | The registration authority validates the public key in the certificate request matches a registered key for the user.<br>  After validating the  public key, the registration authority signs the certificate request using its enrollment agent certificate.|
 |F |The registration authority sends the certificate request to the enterprise issuing certificate authority. The certificate authority validates the certificate request is signed by a valid enrollment agent and, on success, issues a certificate and returns it to the registration authority that then returns the certificate to the application.|
 |G | The application receives the newly issued certificate and installs the it into the Personal store of the user.  This signals the end of provisioning.|
-
+[Return to top](#Windows-Hello-for-Business-Provisioning)
 [Return to top](#WindowsHelloforBusinessProvisioning)
--- a/windows/security/identity-protection/hello-for-business/hello-how-it-works-technology.md
+++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works-technology.md
@ -10,9 +10,247 @@ ms.author: mstephen
 localizationpriority: high
 ms.date: 05/05/2018
 ---
-# Technolgy and Terms
+# Technology and Terms
 - [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)
 - [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](#Onpremises-Deployment)
 - [Pass-through Authentication](#Passthrough-Authentication)
 - [Password Hash Synchronization](#Password-Hash-Synchronization)
 - [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
 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 10 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 10 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 10 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 10-based 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 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.
 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.
 ### Related topics
 [Endorsement Key](#Endorsement-Key), [Storage Root Key](#Storage-Root-Key), [Trusted Platform Module](#Trusted-Platform-Module)
 ### More information
 - [Windows Client Certificate Enrollment Protocol: Glossary](https://msdn.microsoft.com/en-us/library/cc249746.aspx#gt_70efa425-6b46-462f-911d-d399404529ab)
 - [TPM Library Specification](https://trustedcomputinggroup.org/resource/tpm-library-specification/)
 [Return to Top](#Technology-and-Terms)
 ## 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)
 ### More information
 - [Introduction to device management in Azure Active Directory](https://docs.microsoft.com/en-us/azure/active-directory/device-management-introduction).
 [Return to Top](#Technology-and-Terms)
 ## 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)
 ### More information
 - [Introduction to device management in Azure Active Directory](https://docs.microsoft.com/en-us/azure/active-directory/device-management-introduction)
 [Return to Top](#Technology-and-Terms)
 ## 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 topics
 [Deployment Type](#Deployment-Type), [Hybrid Azure AD Joined](#Hybrid-Azure-AD-Joined), [Hybrid Deployment](#Hybrid-Deployment), [Key Trust](#Key-Trust), [On-premises Deployment](#Onpremises-Deployment), [Trust Type](#Trust-Type)
 ### More information 
 - [Windows Hello for Business Planning Guide](hello-planning-guide.md)
 [Return to Top](#Technology-and-Terms)
 ## 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.
 ### Related topics
 [Azure AD Joined](#Azure-AD-Joined), [Azure AD Registered](#Azure-AD-Registered), [Deployment Type](#Deployment-Type), [Join Type](#Join-Type)
 [Return to Top](#Technology-and-Terms)
 ## 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
 ### Related topics
 [Cloud Deployment](#Cloud-Deployment), [Hybrid Deployment](#Hybrid-Deployment), [On-premises Deployment](#Onpremises-Deployment)
 ### More information
 - [Windows Hello for Business Planning Guide](hello-planning-guide.md)
 [Return to Top](#Technology-and-Terms)
 ## 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 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.
 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.
 ### Related topics
 [Attestation Identity Keys](#Attestation-Identity-Keys), [Storage Root Key](#Storage-Root-Key), [Trusted Platform Module](#Trusted-Platform-Module)
 ### More information
 - [Understand the TPM endorsement key](https://go.microsoft.com/fwlink/p/?LinkId=733952).
 - [TPM Library Specification](https://trustedcomputinggroup.org/resource/tpm-library-specification/)
 [Return to Top](#Technology-and-Terms)
 ## 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.
 ### Related topics
 [Hybrid Deployment](#Hybrid-Deployment), [Managed Environment](#Managed-Environment), [Pass-through authentication](#Passthrough-authentication), [Password Hash Sync](#Password-Hash-Sync)
 ### More information
 - [Choosing the right authentication method for your Azure Active Directory hybrid identity solution](https://docs.microsoft.com/en-us/azure/security/azure-ad-choose-authn)
 [Return to Top](#Technology-and-Terms)
 ## 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 System Center Configuration Manager (SCCM) or group policy (GP) to manage them.
 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.
 ### Related topics
 [Azure AD Joined](#Azure-AD-Joined), [Azure AD Registered](#Azure-AD-Registered), [Hybrid Deployment](#Hybrid-Deployment)
 ### More information
 - [Introduction to device management in Azure Active Directory](https://docs.microsoft.com/en-us/azure/active-directory/device-management-introduction)
 [Return to Top](#Technology-and-Terms)
 ## 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.
 ### Related topics
 [Azure AD Joined](#Azure-AD-Joined), [Azure AD Registered](#Azure-AD-Registered), [Hybrid Azure AD Joined](#Hybrid-Azure-AD-Joined), 
 ### More information
 - [Windows Hello for Business Planning Guide](hello-planning-guide.md)
 [Return to Top](#Technology-and-Terms)
 ## 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.
 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 .
 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.
 ### Related topics
 [Azure AD Joined](#Azure-AD-Joined), [Azure AD Registered](#Azure-AD-Registered), [Hybrid Azure AD Joined](#Hybrid-Azure-AD-Joined)
 ### More information
 - [Introduction to device management in Azure Active Directory](https://docs.microsoft.com/en-us/azure/active-directory/device-management-introduction)
 [Return to Top](#Technology-and-Terms)
 ## Key Trust
 The key trust model uses  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 requires Windows Server 2016 domain controllers.
 ### 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](#Onpremises-Deployment), [Trust Type](#Trust-Type), [Trust Type](#Trust-Type)
 ### More information
 - [Windows Hello for Business Planning Guide](hello-planning-guide.md)
 [Return to Top](#Technology-and-Terms)
 ## 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. 
 ### Related topics
 [Federated Environment](#Federated-Environment), [Pass-through authentication](#Passthrough-authentication), [Password Hash Synchronization](#Password-Hash-Synchronization)
 [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.
 ### Related topics
 [Cloud Deployment](#Cloud-Deployment), [Deployment Type](#Deployment-Type), [Hybrid Deployment](#Hybrid-Deployment)
 ### More information
 - [Windows Hello for Business Planning Guide](hello-planning-guide.md)
 [Return to Top](#Technology-and-Terms)
 ## 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-Synchronization)
 ### More information
 - [Choosing the right authentication method for your Azure Active Directory hybrid identity solution](https://docs.microsoft.com/en-us/azure/security/azure-ad-choose-authn)
 [Return to Top](#Technology-and-Terms)
 ## 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.
 ### Related topics
 [Federated Environment](#Federated-Environment), [Managed Environment](#Managed-Environment), [Pass-through authentication](#Passthrough-authentication)
 ### More information
 - [Choosing the right authentication method for your Azure Active Directory hybrid identity solution](https://docs.microsoft.com/en-us/azure/security/azure-ad-choose-authn)
 [Return to Top](#Technology-and-Terms)
 ## 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.
 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 domain 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.).
 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](https://docs.microsoft.com/en-us/azure/active-directory/active-directory-conditional-access-policy-connected-applications) policy set on an application, without the PRT, access will be denied.
 [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.
 ### Related topics
 [Attestation Identity Keys](#Attestation-Identity-Keys), [Endorsement Key](#Endorsement-Key), [Trusted Platform Module](#Trusted-Platform-Module)
 ### More information
 [TPM Library Specification](https://trustedcomputinggroup.org/resource/tpm-library-specification/)
 [Return to Top](#Technology-and-Terms)
 ## 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 Auzre 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](#Onpremises-Deployment)
 ### More information
 - [Windows Hello for Business Planning Guide](hello-planning-guide.md)
 [Return to Top](#Technology-and-Terms)
 ## Trusted Platform Module
 -   A Trusted Platform Module (TPM) is a hardware component that provides unique security features.
@ -57,60 +295,27 @@ In a simplified manner, the TPM is a passive component with limited resources. I
 * A cryptographic engine to encrypt, decrypt, and sign
 * Volatile memory for storing the PCRs and RSA keys
 ## 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).
+### Related topics
 [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/)
 [Return to Top](#Technology-and-Terms)
 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 acts as an identity card for the TPM. For more information, see [Understand the TPM endorsement key](https://go.microsoft.com/fwlink/p/?LinkId=733952).
 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.
 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.
 ## 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 10 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 10 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 10 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 10-based 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 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.
 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.
 ## 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.
 ## 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.
 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 domain 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.).
 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](https://docs.microsoft.com/en-us/azure/active-directory/active-directory-conditional-access-policy-connected-applications) policy set on an application, without the PRT, access will be denied.
 ## Azure AD Registered
 ## Azure AD Joined
 ## Hybrid Azure AD Joined
 ## Managed Environment
 ## Federated Environment
 ## Cloud Deployment
 ## Hybrid Deployment
 ## On-premises Deployment 
--- a/windows/security/identity-protection/hello-for-business/hello-how-it-works.md
+++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works.md
@ -1,114 +1,32 @@
 ---
-title: How Windows Hello for Business works (Windows 10)
+title: How Windows Hello for Business works
 description: Explains registration, authentication, key material, and infrastructure for Windows Hello for Business.
 ms.prod: w10
 ms.mktglfcycl: deploy
 ms.sitesec: library
 ms.pagetype: security
-author: DaniHalfin
+author: mikestephens-MS
-ms.localizationpriority: high
+ms.author: mstephen
-ms.author: daniha
+localizationpriority: high
-ms.date: 10/16/2017
+ms.date: 05/05/2018
 ---
 # How Windows Hello for Business works
 **Applies to**
-   Windows 10
+-   Windows 10
 -   Windows 10 Mobile
 Windows Hello for Business requires a registered device. When the device is set up, its user can use the device to authenticate to services. This topic explains how device registration works, what happens when a user requests authentication, how key material is stored and processed, and which servers and infrastructure components are involved in different parts of this process.
 ## Register a new user or device
 A goal of device registration is to allow a user to open a brand-new device, securely join an organizational network to download and manage organizational data, and create a new Windows Hello gesture to secure the device. Microsoft refers to the process of setting up a device for use with Windows Hello as registration.
 > [!NOTE]
 >This is separate from the organizational configuration required to use Windows Hello with Active Directory or Azure Active Directory (Azure AD); that configuration information is in [Manage Windows Hello for Business in your organization](hello-manage-in-organization.md). Organizational configuration must be completed before users can begin to register.  
 The registration process works like this: 
 1. The user configures an account on the device. This account can be a local account on the device, a domain account stored in the on-premises Active Directory domain, a Microsoft account, or an Azure AD account. For a new device, this step may be as simple as signing in with a Microsoft account. Signing in with a Microsoft account on a Windows 10 device automatically sets up Windows Hello on the device; users don’t have to do anything extra to enable it. 
 2. To sign in using that account, the user has to enter the existing credentials for it. The identity provider (IDP) that “owns” the account receives the credentials and authenticates the user. This IDP authentication may include the use of an existing second authentication factor, or proof. For example, a user who registers a new device by using an Azure AD account will have to provide an SMS-based proof that Azure AD sends. 
 3. When the user has provided the proof to the IDP, the user enables PIN authentication. The PIN will be associated with this particular credential. When the user sets the PIN, it becomes usable immediately 
 The PIN chosen is associated with the combination of the active account and that specific device. The PIN must comply with whatever length and complexity policy the account administrator has configured; this policy is enforced on the device side. Other registration scenarios that Windows Hello supports are:
 - A user who upgrades from the Windows 8.1 operating system will sign in by using the existing enterprise password. That triggers a second authentication factor from the IDP side (if required); after receiving and returning a proof, such as a text message or voice code, the IDP authenticates the user to the upgraded Windows 10 device, and the user can set his or her PIN.
 - A user who typically uses a smart card to sign in will be prompted to set up a PIN the first time he or she signs in to a Windows 10 device the user has not previously signed in to.
 - A user who typically uses a virtual smart card to sign in will be prompted to set up a PIN the first time he or she signs in to a Windows 10 device the user has not previously signed in to.
 When the user has completed this process, Windows Hello generates a new public–private key pair on the device. The TPM generates and protects this private key; if the device doesn’t have a TPM, the private key is encrypted and stored in software. This initial key is referred to as the protector key. It’s associated only with a single gesture; in other words, if a user registers a PIN, a fingerprint, and a face on the same device, each of those gestures will have a unique protector key. Each unique gesture generates a unique protector key. The protector key securely wraps the authentication key. The container has only one authentication key, but there can be multiple copies of that key wrapped with different unique protector keys. Windows Hello also generates an administrative key that the user or administrator can use to reset credentials, when necessary. In addition to the protector key, TPM-enabled devices generate a block of data that contains attestations from the TPM.
 At this point, the user has a PIN gesture defined on the device and an associated protector key for that PIN gesture. That means he or she is able to securely sign in to the device with the PIN and thus that he or she can establish a trusted session with the device to add support for a biometric gesture as an alternative for the PIN. When you add a biometric gesture, it follows the same basic sequence: the user authenticates to the system by using his or her PIN, and then registers the new biometric (“smile for the camera!”), after which Windows generates a unique key pair and stores it securely. Future sign-ins can then use either the PIN or the registered biometric gestures.
 ## What’s a container?
 You’ll often hear the term *container* used in reference to mobile device management (MDM) solutions. Windows Hello uses the term, too, but in a slightly different way. Container in this context is shorthand for a logical grouping of key material or data. Windows 10 Hello uses a single container that holds user key material for personal accounts, including key material associated with the user’s Microsoft account or with other consumer identity providers, and credentials associated with a workplace or school account.
 The container holds enterprise credentials only on devices that have been registered with an organization; it contains key material for the enterprise IDP, such as on-premises Active Directory or Azure AD. 
 It’s important to keep in mind 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 Windows Hello stores are protected without the creation of actual containers or folders.
 The container actually 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](images/passport-fig3-logicalcontainer.png)
 Containers can contain several types of key material:
 - An authentication key, which is always an asymmetric public–private key pair. This key pair is generated during registration. It must be unlocked each time it’s accessed, by using either the user’s PIN or a previously generated biometric gesture. The authentication key exists until the user resets the PIN, at which time a new key will be generated. When the new key is generated, all the key material that the old key previously protected must be decrypted and re-encrypted using the new key.
 - Virtual smart card keys are generated when a virtual smart card is generated and stored securely in the container. They’re available whenever the user’s container is unlocked.
 - The IDP key. These keys can be either symmetric or asymmetric, depending on which IDP you use. A single container may contain zero or more IDP keys, with some restrictions (for example, the enterprise container can contain zero or one IDP keys). IDP keys are stored in the container. For certificate-based Windows Hello for Work, when the container is unlocked, applications that require access to the IDP key or key pair can request access. IDP keys are used to sign or encrypt authentication requests or tokens sent from this device to the IDP. IDP keys are typically long-lived but could have a shorter lifetime than the authentication key. Microsoft accounts, Active Directory accounts, and Azure AD accounts all require the use of asymmetric key pairs. The device generates public and private keys, registers the public key with the IDP (which stores it for later verification), and securely stores the private key. For enterprises, the IDP keys can be generated in two ways:
    - The IDP key pair can be associated with an enterprise Certificate Authority (CA) through the Windows Network Device Enrollment Service (NDES), described more fully in [Network Device Enrollment Service Guidance](https://technet.microsoft.com/library/hh831498.aspx). In this case, Windows Hello requests a new certificate with the same key as the certificate from the existing PKI. This option lets organizations that have an existing PKI continue to use it where appropriate. Given that many applications, such as popular virtual private network systems, require the use of certificates, when you deploy Windows Hello in this mode, it allows a faster transition away from user passwords while still preserving certificate-based functionality. This option also allows the enterprise to store additional certificates in the protected container.
    - The IDP can generate the IDP key pair directly, which allows quick, lower-overhead deployment of Windows Hello in environments that don’t have or need a PKI.
 ## How keys are protected
 Any time key material is generated, it must be protected against attack. The most robust way to do this is through specialized hardware. There’s a long history of using hardware security modules (HSMs) to generate, store, and process keys for security-critical applications. Smart cards are a special type of HSM, as are devices that are compliant with the Trusted Computing Group TPM standard. Wherever possible, the Windows Hello for Work implementation takes advantage of onboard TPM hardware to generate and protect keys. However, Windows Hello and Windows Hello for Work do not require an onboard TPM. Administrators can choose to allow key operations in software, in which case any user who has (or can escalate to) administrative rights on the device can use the IDP keys to sign requests. As an alternative, in some scenarios, devices that don’t have a TPM can be remotely authenticated by using a device that does have a TPM, in which case all the sensitive operations are performed with the TPM and no key material is exposed.
 Whenever possible, Microsoft recommends the use of TPM hardware. The TPM protects against a variety of known and potential attacks, including PIN brute-force attacks. The TPM provides an additional layer of protection after an account lockout, too. When the TPM has locked the key material, the user will have to reset the PIN (which means he or she will have to use MFA to reauthenticate to the IDP before the IDP allows him or her to re-register). Resetting the PIN means that all keys and certificates encrypted with the old key material will be removed.
 ## Authentication
 When a user wants to access protected key material, the authentication process begins with the user entering a PIN or biometric gesture to unlock the device, a process sometimes called releasing the key. Think of it like using a physical key to unlock a door: before you can unlock the door, you need to remove the key from your pocket or purse. The user's PIN unlocks the protector key for the container on the device. When that container is unlocked, applications (and thus the user) can use whatever IDP keys reside inside the container.
 These keys are used to sign requests that are sent to the IDP, requesting access to specified resources. It’s important to understand that although the keys are unlocked, applications cannot use them at will. Applications can use specific APIs to request operations that require key material for particular actions (for example, decrypt an email message or sign in to a website). Access through these APIs doesn’t require explicit validation through a user gesture, and the key material isn’t exposed to the requesting application. Rather, the application asks for authentication, encryption, or decryption, and the Windows Hello layer handles the actual work and returns the results. Where appropriate, an application can request a forced authentication even on an unlocked device. Windows prompts the user to reenter the PIN or perform an authentication gesture, which adds an extra level of protection for sensitive data or actions. For example, you can configure the Microsoft Store to require reauthentication any time a user purchases an application, even though the same account and PIN or gesture were already used to unlock the device.
 For example, the authentication process for Azure Active Directory works like this:
 1.	The client sends an empty authentication request to the IDP. (This is merely for the handshake process.)
 2.	The IDP returns a challenge, known as a nonce.
 3.	The device signs the nonce with the appropriate private key.
 4.	The device returns the original nonce, the signed nonce, and the ID of the key used to sign the nonce.
 5.	The IDP fetches the public key that the key ID specified, uses it to verify the signature on the nonce, and verifies that the nonce the device returned matches the original.
 6.	If all the checks in step 5 succeed, the IDP returns two data items: a symmetric key, which is encrypted with the device’s public key, and a security token, which is encrypted with the symmetric key.
 7.	The device uses its private key to decrypt the symmetric key, and then uses that symmetric key to decrypt the token.
 8.	The device makes a normal authentication request for the original resource, presenting the token from the IDP as its proof of authentication.
 When the IDP validates the signature, it is verifying that the request came from the specified user and device. The private key specific to the device signs the nonce, which allows the IDP to determine the identity of the requesting user and device so that it can apply policies for content access based on user, device type, or both together. For example, an IDP could allow access to one set of resources only from mobile devices and a different set from desktop devices.
 ## The infrastructure
 Windows Hello depends on having compatible IDPs available to it. As of this writing, that means you have four deployment possibilities: 
 - Use an existing Windows-based PKI centered around Active Directory Certificate Services. This option requires additional infrastructure, including a way to issue certificates to users. You can use NDES to register devices directly, or Microsoft Intune where it’s available to manage mobile device participation in Windows Hello. 
 - The normal discovery mechanism that clients use to find domain controllers and global catalogs relies on Domain Name System (DNS) SRV records, but those records don’t contain version data. Windows 10 computers will query DNS for SRV records to find all available Active Directory servers, and then query each server to identify those that can act as Windows Hello IDPs. The number of authentication requests your users generate, where your users are located, and the design of your network all drive the number of Windows Server 2016 domain controllers required. 
 - Azure AD can act as an IDP either by itself or alongside an on-premises AD DS forest. Organizations that use Azure AD can register devices directly without having to join them to a local domain by using the capabilities the Azure AD Device Registration service provides. In addition to the IDP, Windows Hello requires an MDM system. This system can be the cloud-based Intune if you use Azure AD, or an on-premises System Center Configuration Manager deployment that meets the system requirements described in the Deployment requirements section of this document.
 Windows Hello for Business is a modern, two-factor credential that is the more secure alternative to passwords.  Windows.  Whether you are cloud or on-premises, Windows Hello for Business has a deployment option for you.  For cloud deployments, you can use Windows Hello for Business with Azure Active Directory joined, Hybrid Azure Active Directory joined, or Azure Active Directory registered devices.  Windows Hello for Business also works for domain joined devices. 
 Watch this quick video where Pieter Wigleven gives a simple explanation of how Windows Hello for Business works and some of its supporting features.
 > [!VIDEO https://www.youtube.com/embed/G-GJuDWbBE8]
 ## Technical Deep Dive
 Windows Hello for Business is a distributed system that uses several components to accomplish device registration, provisioning, and authentication. Use this section to gain a better understanding of each of the components and how they support Windows Hello for Business.
 - [Technology and Terminology](hello-how-it-works-technology.md)
 - [Device Registration](hello-how-it-works-device-registration.md)
 - [Provisioning](hello-how-it-works-provisioning.md)
 - [Authentication](hello-how-it-works-authentication.md)
 ## Related topics
--- a/windows/security/identity-protection/hello-for-business/hello-overview.md
+++ b/windows/security/identity-protection/hello-for-business/hello-overview.md
@ -6,15 +6,16 @@ ms.prod: w10
 ms.mktglfcycl: deploy
 ms.sitesec: library
 ms.pagetype: security, mobile
-author: DaniHalfin
+author: mikestephens-MS
 ms.author: mstephen
 ms.localizationpriority: high
-ms.date: 07/27/2017
+ms.date: 05/05/2018
 ---
 # Windows Hello for Business Overview
 **Applies to**
 -   Windows 10
-   Windows 10 Mobile
+
 In Windows 10, Windows Hello for Business replaces passwords with strong two-factor authentication on PCs and mobile devices. This authentication consists of a new type of user credential that is tied to a device and uses a biometric or PIN.
--- a/windows/security/identity-protection/hello-for-business/hello-videos.md
+++ b/windows/security/identity-protection/hello-for-business/hello-videos.md
@ -14,15 +14,18 @@ ms.date: 05/05/2018
 #Windows Hello for Business Videos
 ## Overview of Windows Hello for Business and Features
 Watch Pieter Wigleven explain Windows Hello for Business, Multi-factor Unlock, and Dynamic Lock
 > [!VIDEO https://www.youtube.com/embed/G-GJuDWbBE8]
 ## Microsoft's passwordless strategy
 Watch Karanbir Singh's Ignite 2017 presentation **Microsoft's guide for going password-less**
 > [!VIDEO https://www.youtube.com/embed/mXJS615IGLM]
 ## Windows Hello for Business user enrollment experience
 The user experience for Windows Hello for Business occurs after user sign-in, after you deploy Windows Hello for Business policy settings to your environment.
 > [!VIDEO https://www.youtube.com/embed/FJqHPTZTpNM]
--- a/windows/security/identity-protection/hello-for-business/images/howitworks/auth-aadj-certtrust-kerb.png
+++ b/windows/security/identity-protection/hello-for-business/images/howitworks/auth-aadj-certtrust-kerb.png
--- a/windows/security/identity-protection/hello-for-business/images/howitworks/auth-aadj-cloud.png
+++ b/windows/security/identity-protection/hello-for-business/images/howitworks/auth-aadj-cloud.png
--- a/windows/security/identity-protection/hello-for-business/images/howitworks/auth-aadj-kerb-certtrust.png
+++ b/windows/security/identity-protection/hello-for-business/images/howitworks/auth-aadj-kerb-certtrust.png
--- a/windows/security/identity-protection/hello-for-business/images/howitworks/auth-aadj-kerb-keytrust.png
+++ b/windows/security/identity-protection/hello-for-business/images/howitworks/auth-aadj-kerb-keytrust.png
--- a/windows/security/identity-protection/hello-for-business/images/howitworks/auth-aadj-keytrust-kerb.png
+++ b/windows/security/identity-protection/hello-for-business/images/howitworks/auth-aadj-keytrust-kerb.png
--- a/windows/security/identity-protection/hello-for-business/images/howitworks/auth-haadj-certtrust.png
+++ b/windows/security/identity-protection/hello-for-business/images/howitworks/auth-haadj-certtrust.png
--- a/windows/security/identity-protection/hello-for-business/images/howitworks/auth-haadj-keytrust.png
+++ b/windows/security/identity-protection/hello-for-business/images/howitworks/auth-haadj-keytrust.png
--- a/windows/security/identity-protection/hello-for-business/images/howitworks/devreg-aadj-federated.png
+++ b/windows/security/identity-protection/hello-for-business/images/howitworks/devreg-aadj-federated.png
--- a/windows/security/identity-protection/hello-for-business/images/howitworks/devreg-aadj-managed.png
+++ b/windows/security/identity-protection/hello-for-business/images/howitworks/devreg-aadj-managed.png
--- a/windows/security/identity-protection/hello-for-business/images/howitworks/devreg-hybrid-haadj-federated.png
+++ b/windows/security/identity-protection/hello-for-business/images/howitworks/devreg-hybrid-haadj-federated.png
--- a/windows/security/identity-protection/hello-for-business/images/howitworks/devreg-hybrid-haadj-managed.png
+++ b/windows/security/identity-protection/hello-for-business/images/howitworks/devreg-hybrid-haadj-managed.png
--- a/windows/security/identity-protection/hello-for-business/images/howitworks/prov-aadj-federated.png
+++ b/windows/security/identity-protection/hello-for-business/images/howitworks/prov-aadj-federated.png
--- a/windows/security/identity-protection/hello-for-business/images/howitworks/prov-aadj-managed.png
+++ b/windows/security/identity-protection/hello-for-business/images/howitworks/prov-aadj-managed.png
--- a/windows/security/identity-protection/hello-for-business/images/howitworks/prov-haadj-certtrust-managed.png
+++ b/windows/security/identity-protection/hello-for-business/images/howitworks/prov-haadj-certtrust-managed.png
--- a/windows/security/identity-protection/hello-for-business/images/howitworks/prov-haadj-certtrust.png
+++ b/windows/security/identity-protection/hello-for-business/images/howitworks/prov-haadj-certtrust.png
--- a/windows/security/identity-protection/hello-for-business/images/howitworks/prov-haadj-instant-certtrust-federated.png
+++ b/windows/security/identity-protection/hello-for-business/images/howitworks/prov-haadj-instant-certtrust-federated.png
--- a/windows/security/identity-protection/hello-for-business/images/howitworks/prov-haadj-instant-certtrust-managed.png
+++ b/windows/security/identity-protection/hello-for-business/images/howitworks/prov-haadj-instant-certtrust-managed.png
--- a/windows/security/identity-protection/hello-for-business/images/howitworks/prov-haadj-instant-certtrust.png
+++ b/windows/security/identity-protection/hello-for-business/images/howitworks/prov-haadj-instant-certtrust.png
--- a/windows/security/identity-protection/hello-for-business/images/howitworks/prov-haadj-keytrust-managed.png
+++ b/windows/security/identity-protection/hello-for-business/images/howitworks/prov-haadj-keytrust-managed.png
--- a/windows/security/identity-protection/hello-for-business/retired/hello-how-it-works.md
+++ b/windows/security/identity-protection/hello-for-business/retired/hello-how-it-works.md
@ -0,0 +1,122 @@
 ---
 title: How Windows Hello for Business works (Windows 10)
 description: Explains registration, authentication, key material, and infrastructure for Windows Hello for Business.
 ms.prod: w10
 ms.mktglfcycl: deploy
 ms.sitesec: library
 ms.pagetype: security
 author: DaniHalfin
 ms.localizationpriority: high
 ms.author: daniha
 ms.date: 10/16/2017
 ---
 # How Windows Hello for Business works
 **Applies to**
 -   Windows 10
 -   Windows 10 Mobile
 Windows Hello for Business requires a registered device. When the device is set up, its user can use the device to authenticate to services. This topic explains how device registration works, what happens when a user requests authentication, how key material is stored and processed, and which servers and infrastructure components are involved in different parts of this process.
 ## Register a new user or device
 A goal of device registration is to allow a user to open a brand-new device, securely join an organizational network to download and manage organizational data, and create a new Windows Hello gesture to secure the device. Microsoft refers to the process of setting up a device for use with Windows Hello as registration.
 > [!NOTE]
 >This is separate from the organizational configuration required to use Windows Hello with Active Directory or Azure Active Directory (Azure AD); that configuration information is in [Manage Windows Hello for Business in your organization](hello-manage-in-organization.md). Organizational configuration must be completed before users can begin to register.  
 The registration process works like this: 
 1. The user configures an account on the device. This account can be a local account on the device, a domain account stored in the on-premises Active Directory domain, a Microsoft account, or an Azure AD account. For a new device, this step may be as simple as signing in with a Microsoft account. Signing in with a Microsoft account on a Windows 10 device automatically sets up Windows Hello on the device; users don’t have to do anything extra to enable it. 
 2. To sign in using that account, the user has to enter the existing credentials for it. The identity provider (IDP) that “owns” the account receives the credentials and authenticates the user. This IDP authentication may include the use of an existing second authentication factor, or proof. For example, a user who registers a new device by using an Azure AD account will have to provide an SMS-based proof that Azure AD sends. 
 3. When the user has provided the proof to the IDP, the user enables PIN authentication. The PIN will be associated with this particular credential. When the user sets the PIN, it becomes usable immediately 
 The PIN chosen is associated with the combination of the active account and that specific device. The PIN must comply with whatever length and complexity policy the account administrator has configured; this policy is enforced on the device side. Other registration scenarios that Windows Hello supports are:
 - A user who upgrades from the Windows 8.1 operating system will sign in by using the existing enterprise password. That triggers a second authentication factor from the IDP side (if required); after receiving and returning a proof, such as a text message or voice code, the IDP authenticates the user to the upgraded Windows 10 device, and the user can set his or her PIN.
 - A user who typically uses a smart card to sign in will be prompted to set up a PIN the first time he or she signs in to a Windows 10 device the user has not previously signed in to.
 - A user who typically uses a virtual smart card to sign in will be prompted to set up a PIN the first time he or she signs in to a Windows 10 device the user has not previously signed in to.
 When the user has completed this process, Windows Hello generates a new public–private key pair on the device. The TPM generates and protects this private key; if the device doesn’t have a TPM, the private key is encrypted and stored in software. This initial key is referred to as the protector key. It’s associated only with a single gesture; in other words, if a user registers a PIN, a fingerprint, and a face on the same device, each of those gestures will have a unique protector key. Each unique gesture generates a unique protector key. The protector key securely wraps the authentication key. The container has only one authentication key, but there can be multiple copies of that key wrapped with different unique protector keys. Windows Hello also generates an administrative key that the user or administrator can use to reset credentials, when necessary. In addition to the protector key, TPM-enabled devices generate a block of data that contains attestations from the TPM.
 At this point, the user has a PIN gesture defined on the device and an associated protector key for that PIN gesture. That means he or she is able to securely sign in to the device with the PIN and thus that he or she can establish a trusted session with the device to add support for a biometric gesture as an alternative for the PIN. When you add a biometric gesture, it follows the same basic sequence: the user authenticates to the system by using his or her PIN, and then registers the new biometric (“smile for the camera!”), after which Windows generates a unique key pair and stores it securely. Future sign-ins can then use either the PIN or the registered biometric gestures.
 ## What’s a container?
 You’ll often hear the term *container* used in reference to mobile device management (MDM) solutions. Windows Hello uses the term, too, but in a slightly different way. Container in this context is shorthand for a logical grouping of key material or data. Windows 10 Hello uses a single container that holds user key material for personal accounts, including key material associated with the user’s Microsoft account or with other consumer identity providers, and credentials associated with a workplace or school account.
 The container holds enterprise credentials only on devices that have been registered with an organization; it contains key material for the enterprise IDP, such as on-premises Active Directory or Azure AD. 
 It’s important to keep in mind 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 Windows Hello stores are protected without the creation of actual containers or folders.
 The container actually 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](images/passport-fig3-logicalcontainer.png)
 Containers can contain several types of key material:
 - An authentication key, which is always an asymmetric public–private key pair. This key pair is generated during registration. It must be unlocked each time it’s accessed, by using either the user’s PIN or a previously generated biometric gesture. The authentication key exists until the user resets the PIN, at which time a new key will be generated. When the new key is generated, all the key material that the old key previously protected must be decrypted and re-encrypted using the new key.
 - Virtual smart card keys are generated when a virtual smart card is generated and stored securely in the container. They’re available whenever the user’s container is unlocked.
 - The IDP key. These keys can be either symmetric or asymmetric, depending on which IDP you use. A single container may contain zero or more IDP keys, with some restrictions (for example, the enterprise container can contain zero or one IDP keys). IDP keys are stored in the container. For certificate-based Windows Hello for Work, when the container is unlocked, applications that require access to the IDP key or key pair can request access. IDP keys are used to sign or encrypt authentication requests or tokens sent from this device to the IDP. IDP keys are typically long-lived but could have a shorter lifetime than the authentication key. Microsoft accounts, Active Directory accounts, and Azure AD accounts all require the use of asymmetric key pairs. The device generates public and private keys, registers the public key with the IDP (which stores it for later verification), and securely stores the private key. For enterprises, the IDP keys can be generated in two ways:
    - The IDP key pair can be associated with an enterprise Certificate Authority (CA) through the Windows Network Device Enrollment Service (NDES), described more fully in [Network Device Enrollment Service Guidance](https://technet.microsoft.com/library/hh831498.aspx). In this case, Windows Hello requests a new certificate with the same key as the certificate from the existing PKI. This option lets organizations that have an existing PKI continue to use it where appropriate. Given that many applications, such as popular virtual private network systems, require the use of certificates, when you deploy Windows Hello in this mode, it allows a faster transition away from user passwords while still preserving certificate-based functionality. This option also allows the enterprise to store additional certificates in the protected container.
    - The IDP can generate the IDP key pair directly, which allows quick, lower-overhead deployment of Windows Hello in environments that don’t have or need a PKI.
 ## How keys are protected
 Any time key material is generated, it must be protected against attack. The most robust way to do this is through specialized hardware. There’s a long history of using hardware security modules (HSMs) to generate, store, and process keys for security-critical applications. Smart cards are a special type of HSM, as are devices that are compliant with the Trusted Computing Group TPM standard. Wherever possible, the Windows Hello for Work implementation takes advantage of onboard TPM hardware to generate and protect keys. However, Windows Hello and Windows Hello for Work do not require an onboard TPM. Administrators can choose to allow key operations in software, in which case any user who has (or can escalate to) administrative rights on the device can use the IDP keys to sign requests. As an alternative, in some scenarios, devices that don’t have a TPM can be remotely authenticated by using a device that does have a TPM, in which case all the sensitive operations are performed with the TPM and no key material is exposed.
 Whenever possible, Microsoft recommends the use of TPM hardware. The TPM protects against a variety of known and potential attacks, including PIN brute-force attacks. The TPM provides an additional layer of protection after an account lockout, too. When the TPM has locked the key material, the user will have to reset the PIN (which means he or she will have to use MFA to reauthenticate to the IDP before the IDP allows him or her to re-register). Resetting the PIN means that all keys and certificates encrypted with the old key material will be removed.
 ## Authentication
 When a user wants to access protected key material, the authentication process begins with the user entering a PIN or biometric gesture to unlock the device, a process sometimes called releasing the key. Think of it like using a physical key to unlock a door: before you can unlock the door, you need to remove the key from your pocket or purse. The user's PIN unlocks the protector key for the container on the device. When that container is unlocked, applications (and thus the user) can use whatever IDP keys reside inside the container.
 These keys are used to sign requests that are sent to the IDP, requesting access to specified resources. It’s important to understand that although the keys are unlocked, applications cannot use them at will. Applications can use specific APIs to request operations that require key material for particular actions (for example, decrypt an email message or sign in to a website). Access through these APIs doesn’t require explicit validation through a user gesture, and the key material isn’t exposed to the requesting application. Rather, the application asks for authentication, encryption, or decryption, and the Windows Hello layer handles the actual work and returns the results. Where appropriate, an application can request a forced authentication even on an unlocked device. Windows prompts the user to reenter the PIN or perform an authentication gesture, which adds an extra level of protection for sensitive data or actions. For example, you can configure the Microsoft Store to require reauthentication any time a user purchases an application, even though the same account and PIN or gesture were already used to unlock the device.
 For example, the authentication process for Azure Active Directory works like this:
 1.	The client sends an empty authentication request to the IDP. (This is merely for the handshake process.)
 2.	The IDP returns a challenge, known as a nonce.
 3.	The device signs the nonce with the appropriate private key.
 4.	The device returns the original nonce, the signed nonce, and the ID of the key used to sign the nonce.
 5.	The IDP fetches the public key that the key ID specified, uses it to verify the signature on the nonce, and verifies that the nonce the device returned matches the original.
 6.	If all the checks in step 5 succeed, the IDP returns two data items: a symmetric key, which is encrypted with the device’s public key, and a security token, which is encrypted with the symmetric key.
 7.	The device uses its private key to decrypt the symmetric key, and then uses that symmetric key to decrypt the token.
 8.	The device makes a normal authentication request for the original resource, presenting the token from the IDP as its proof of authentication.
 When the IDP validates the signature, it is verifying that the request came from the specified user and device. The private key specific to the device signs the nonce, which allows the IDP to determine the identity of the requesting user and device so that it can apply policies for content access based on user, device type, or both together. For example, an IDP could allow access to one set of resources only from mobile devices and a different set from desktop devices.
 ## The infrastructure
 Windows Hello depends on having compatible IDPs available to it. As of this writing, that means you have four deployment possibilities: 
 - Use an existing Windows-based PKI centered around Active Directory Certificate Services. This option requires additional infrastructure, including a way to issue certificates to users. You can use NDES to register devices directly, or Microsoft Intune where it’s available to manage mobile device participation in Windows Hello. 
 - The normal discovery mechanism that clients use to find domain controllers and global catalogs relies on Domain Name System (DNS) SRV records, but those records don’t contain version data. Windows 10 computers will query DNS for SRV records to find all available Active Directory servers, and then query each server to identify those that can act as Windows Hello IDPs. The number of authentication requests your users generate, where your users are located, and the design of your network all drive the number of Windows Server 2016 domain controllers required. 
 - Azure AD can act as an IDP either by itself or alongside an on-premises AD DS forest. Organizations that use Azure AD can register devices directly without having to join them to a local domain by using the capabilities the Azure AD Device Registration service provides. In addition to the IDP, Windows Hello requires an MDM system. This system can be the cloud-based Intune if you use Azure AD, or an on-premises System Center Configuration Manager deployment that meets the system requirements described in the Deployment requirements section of this document.
 ## Related topics
 - [Windows Hello for Business](hello-identity-verification.md)
 - [Manage Windows Hello for Business in your organization](hello-manage-in-organization.md)
 - [Why a PIN is better than a password](hello-why-pin-is-better-than-password.md)
 - [Prepare people to use Windows Hello](hello-prepare-people-to-use.md)
 - [Windows Hello and password changes](hello-and-password-changes.md)
 - [Windows Hello errors during PIN creation](hello-errors-during-pin-creation.md)
 - [Event ID 300 - Windows Hello successfully created](hello-event-300.md)
 - [Windows Hello biometrics in the enterprise](hello-biometrics-in-enterprise.md)
--- a/windows/security/identity-protection/hello-for-business/toc.md
+++ b/windows/security/identity-protection/hello-for-business/toc.md
@ -2,6 +2,12 @@
 ## [Windows Hello for Business Overview](hello-overview.md)
 ## [How Windows Hello for Business works](hello-how-it-works.md)
 ### [Technical Deep Dive](hello-how-it-works.md#Technical-Deep-Dive)
 #### [Technology and Terminology](hello-how-it-works-technology.md)
 #### [Device Registration](hello-how-it-works-device-registration.md)
 #### [Provisioning](hello-how-it-works-provisioning.md)
 #### [Authentication](hello-how-it-works-authentication.md)
 ## [Manage Windows Hello for Business in your organization](hello-manage-in-organization.md)
 ## [Why a PIN is better than a password](hello-why-pin-is-better-than-password.md)
 ## [Prepare people to use Windows Hello](hello-prepare-people-to-use.md)