1803 (RS4) Content Refresh

- Redesigned the how it works section with more techincal information.
- added artwork
- made FAQ its own page
- made Videos its own page
- first of many significant changes for 1803

windows/security/identity-protection/hello-for-business/hello-faq.md

@@ -0,0 +1,94 @@
+---
+title: Windows Hello for Business Frequently Asked Questions
+description: Windows Hello for Business FAQ 
+keywords: identity, PIN, biometric, Hello, passport
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security, mobile
+author: mikestephens-MS
+ms.author: mstephen
+localizationpriority: high
+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 virutal 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* proivded by convenience PIN, but it stills uses a password for authentication.  Microsoft recommends customers using Windows 10 and conveience 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?
+
+Watch Principal Program Manager Karanbir Singh's Ignite 2017 presentation **Microsoft's guide for going password-less**
+
+[Microsoft's password-less strategy](hello-videos.md#Microsoftspasswordlessstrategy)
+
+## 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#WindowsHelloforBusinessuserenrollmentexperience)
+
+## What happens when my user forgets their PIN?
+
+If the user can sign-in with a password, they can reset their PIN by clicking the "I forgot my PIN" link in settings.  Beginning with the Fall Creators Update, users can reset their PIN above the lock screen by clicking the "I forgot my PIN" link on the PIN credential provider.
+
+[Windows Hello for Business forgotten PIN user experience](hello-videos.md#WindowsHelloforBusinessforgottenPINuserexperience)
+
+For on-premises deployments, devices must be well connected to their on-premises network (domain controllers and/or certificate authority) to reset their PINs.  Hybrid customers can onboard their Azure tenant to use the Windows Hello for Business PIN reset service to reset their PINs 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 multifactor 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](hello-features.md#multifactor-unlock) in [Windows Hello for Business Features](hello-features.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 username 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
+* 1234 has a constant delta of 1, so it is not allowed
+* 1357 has a constant delta of 2, so it is not allowed
+* 9630 has a constant delta of -3, so it is not allowed
+* 1231 does not have a constant delta, so it is okay
+* 1593 does not have a constant delta, so it is okay
+
+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.  
+
+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 occurence where you cannot authenticate with biometrics, you need a fall back mechansim that is not a password.  The PIN is the fall back mechansim.  Disabling or hiding the PIN credential provider disabled the use of biometrics.
+
+## 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 |
+| :---: | :--- |
+| [[MS-KPP]: Key Provisioning Protocol](https://msdn.microsoft.com/en-us/library/mt739755.aspx) | Specifies the Key Provisioning Protocol, which defines a mechanism for a client to register a set of cryptographic keys on a user and device pair. |
+| [[MS-OAPX]: OAuth 2.0 Protocol Extensions](https://msdn.microsoft.com/en-us/library/dn392779.aspx)| Specifies the OAuth 2.0 Protocol Extensions, which are used to extend the OAuth 2.0 Authorization Framework. These extensions enable authorization features such as resource specification, request identifiers, and login hints. |  
+| [[MS-OAPXBC]: OAuth 2.0 Protocol Extensions for Broker Clients](https://msdn.microsoft.com/en-us/library/mt590278.aspx) | Specifies the OAuth 2.0 Protocol Extensions for Broker Clients, extensions to RFC6749 (The OAuth 2.0 Authorization Framework) that allow a broker client to obtain access tokens on behalf of calling clients. |
+| [[MS-OIDCE]: OpenID Connect 1.0 Protocol Extensions](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 metadata 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 inqury at [whfbfeedback@microsoft.com](mailto:whfbfeedback@microsoft.com?subject=collaboration)
+

windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md

@@ -0,0 +1,53 @@
+---
+title: How Windows Hello for Business works - Authentication
+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
+---
+# 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 AD join authentication to Azure Active Directory](#AzureADjoinauthenticationtoAzureActiveDirectory)<br>
+[Azure AD join authentication to Active Direcotry using a Key](#AzureADjoinauthenticationtoActiveDirecotryusingaKey)<br>
+[Azure AD join authentication to Active Directory using a Certificate](#AzureADjoinauthenticationtoActiveDirectoryusingaCertificate)
+[Hybrid Azure AD join authentication using a Key](#HybridAzureADjoinauthenticationusingaKey)<br>
+[Hybrid Azure AD join authentication using a Certificate](#HybridAzureADjoinauthenticationusingaCertificate)<br>
+
+
+## Azure AD join authentication to Azure Active Directory
+
+
+
+[Return to top](#WindowsHelloforBusinessandAuthentication)
+## Azure AD join authentication to Active Direcotry using a Key
+
+
+
+
+[Return to top](#WindowsHelloforBusinessandAuthentication)
+## Azure AD join authentication to Active Directory using a Certificate
+
+
+[Return to top](#WindowsHelloforBusinessandAuthentication)
+## Hybrid Azure AD join authentication using a Key
+
+
+
+
+[Return to top](#WindowsHelloforBusinessandAuthentication)
+## Hybrid Azure AD join authentication using a Certificate
+
+
+
+
+[Return to top](#WindowsHelloforBusinessandAuthentication)
+
+

windows/security/identity-protection/hello-for-business/hello-how-it-works-device-registration.md

@@ -0,0 +1,83 @@
+---
+title: How Windows Hello for Business works - Device Registration
+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
+---
+# Windows Hello for Business and Device Registration
+Device Registration is a prerequisite to Windows Hello for Business provisioning.  Device registration occurs regardless of a cloud, hybrid, or on-premises deployments.  For cloud and hybrid deployments, devices register with Azure Active Directory. For on-premises deployments, devices registered with the enterprise device registration service hosted by Active Directory Federation Services (AD FS).
+
+[Azure AD joined in Managed environments](#AzureADjoinedinManagedenvironments)<br>
+[Azure AD joined in Federated environments](#AzureADjoinedinFederatedenvironments)<br>
+[Hybrid Azure AD joined in Managed environments](#HybridAzureADjoinedinManagedenvironments)<br>
+[Hybrid Azure AD joined in Federated environments](#HybridAzureADjoinedinFederatedenvironments)<br>
+
+
+
+
+## Azure AD joined in Managed environments
+![Azure AD joined in Managed environments](images/howitworks/devreg-aadj-managed.png)
+
+| Phase  | Description  |
+| :----: | :----------- |
+|A | The most common way Azure AD joined devices register with Azure is during the out-of-box-experience (OOBE) where it loads the Azure AD join web application in the Cloud Experience Host (CXH) application.  The application sends a GET request to the Azure OpenID configuration endpoint to discover authorization endpoints.  Azure returns the OpenID configuration, which includes the authorization endpoints, to application as JSON document.|
+|B | The application builds a sign-in request for the authorization end point and collects user credentials.|
+|C |  After the user proivides their username (in UPN format), the application sends a GET request to Azure to discover corresponding realm information for the user.  This determines if the environment is managed or federated.  Azure returns the information in a JSON object.  The application determines the environment is managed (non-federated).<br>The last step in this phase has the application create an authentiation buffer and if in OOBE, temporarily caches it for automatic sign-in at the end of OOBE.  The application POSTs the credentials to Azure Active Directory where they are validated.  Azure Active Directory returns an ID token with claims.|
+|D | The application looks for MDM terms of use (the mdm_tou_url claim). If present, the application retrieves the terms of use from the claim's value, present the contents to the user, and waits for the user to accept the terms of use.  This step is optiona and skipped if the claim is not present or if the claim value is empty.|
+|E | The application sends a device regisitration discovery request to the Azure Device Registration Service (ADRS).  Azure DRS returns a discovery data document, which returns tenant specific URIs to complete device registration.|
+|F | The application creates TPM bound (preferred) RSA 2048 bit key-pair known as the device key (dkpub/dkpriv).  The appplication create a certificate request using dkpub and the public key and signs the certificate request with using dkpriv.  Next, the application derives second key pair from the TPM's storage root key.  This is the transport key (tkpub/tkpriv).|
+|G | The application sends a device registration request to Azure DRS that includes the ID token, certificate request, tkpub, and attestation data.  Azure DRS validates the ID token, creates a device ID, and creates a certificate based on the included certificate request. Azure DRS then writes a device object in Azure Active Directory and sends the device ID and the device certificate to the client.|
+|H |  Device registration completes by receiveing the device ID and the device certificate from Azure DRS.  The device ID is saved for future reference (viewable from dsregcmd.exe /status), and the device certicate is installed in the Personal store of the computer.  With device registration complete, the process continues with MDM enrollment.|
+
+[Return to top](#WindowsHelloforBusinessandDeviceRegistration)
+## Azure AD joined in Federated environments
+![Azure AD joined in Managed environments](images/howitworks/devreg-aadj-federated.png)
+
+| Phase  | Description  |
+| :----: | :----------- |
+|A | The most common way Azure AD joined devices register with Azure is during the out-of-box-experience (OOBE) where it loads the Azure AD join web application in the Cloud Experience Host (CXH) application.  The application sends a GET request to the Azure OpenID configuration endpoint to discover authorization endpoints.  Azure returns the OpenID configuration, which includes the authorization endpoints, to application as JSON document.|
+|B | The application builds a sign-in request for the authorization end point and collects user credentials.|
+|C |  After the user proivides their username (in UPN format), the application sends a GET request to Azure to discover corresponding realm information for the user.  This determines if the environment is managed or federated.  Azure returns the information in a JSON object.  The application determines the environment is managed (non-federated).<br>The application redirects to the AuthURL value (on-premises STS sign-in page) in the returned JSON realm object.  The application collects credentials through the STS web page.|
+|D | The application POST the credential to the on-premises STS, which may require additional factors of authentication.  The on-premises STS authenticates the user and returns a token.   The application POSTs the token to Azure Active Directory for authentication.  Azure Active Directory validates the token and returns an ID token with claims.|
+|E | The application looks for MDM terms of use (the mdm_tou_url claim). If present, the application retrieves the terms of use from the claim's value, present the contents to the user, and waits for the user to accept the terms of use.  This step is optiona and skipped if the claim is not present or if the claim value is empty.|
+|F | The application sends a device regisitration discovery request to the Azure Device Registration Service (ADRS).  Azure DRS returns a discovery data document, which returns tenant specific URIs to complete device registration.|
+|G | The application creates TPM bound (preferred) RSA 2048 bit key-pair known as the device key (dkpub/dkpriv).  The appplication create a certificate request using dkpub and the public key and signs the certificate request with using dkpriv.  Next, the application derives second key pair from the TPM's storage root key.  This is the transport key (tkpub/tkpriv).|
+|H | The application sends a device registration request to Azure DRS that includes the ID token, certificate request, tkpub, and attestation data.  Azure DRS validates the ID token, creates a device ID, and creates a certificate based on the included certificate request. Azure DRS then writes a device object in Azure Active Directory and sends the device ID and the device certificate to the client.|
+|I |  Device registration completes by receiveing the device ID and the device certificate from Azure DRS.  The device ID is saved for future reference (viewable from dsregcmd.exe /status), and the device certicate is installed in the Personal store of the computer.  With device registration complete, the process continues with MDM enrollment.|
+
+[Return to top](#WindowsHelloforBusinessandDeviceRegistration)
+## Hybrid Azure AD joined in Managed environments
+![Hybrid Azure AD joined in Managed environments](images/howitworks/devreg-hybrid-haadj-managed.png)
+
+| Phase  | Description  |
+| :----: | :----------- |
+| A | The user signs in to a domain joined Windows 10 computers using domain credentials.  This can be username and password or smart card authentication.  The user sign-in triggers the Automatic Device Join task.|
+|B | The task queries Active Directory using the LDAP protocol for the keywords attribute on service connection point stored in the configuration partition in Active Directory (CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=corp,DC=contoso,DC=com).  The value returned in the keywords attribute determines if device registration is directed to Azure Device Registration Service (ADRS) or the enterprise device registration service hosted on-premises.|
+|C | For the managed environment, the task creates an initial authentication credential in the form of a self-signed certificate.  The task write the certificate to the userCertificate attribute on the computer object in Active Directory using LDAP.
+|D |The computer cannot authenticate to Azure DRS until a device object representing the computer that includes the certificate on the userCertificate attribute is created in Azure Active Directory.  Azure AD Connect detects an attribute change.  On the next synchronization cycle, Azure AD Connect sends the userCertificate, object GUID, and computer SID to Azure DRS.  Azure DRS uses the attribute information to create a device object in Azure Active Directory.|
+|E | The Automatic Device Join task triggers with each user sign-in and tries to autheticate the computer to Azure Active Directory using the corresponding private key of the public key in the userCertificate attribute.  Azure Active Directory authenticates the computer and issues a ID token to the computer.|
+|F | The task creates TPM bound (preferred) RSA 2048 bit key-pair known as the device key (dkpub/dkpriv).  The appplication create a certificate request using dkpub and the public key and signs the certificate request with using dkpriv.  Next, the application derives second key pair from the TPM's storage root key.  This is the transport key (tkpub/tkpriv).|
+|G | The task sends a device registration request to Azure DRS that includes the ID token, certificate request, tkpub, and attestation data.  Azure DRS validates the ID token, creates a device ID, and creates a certificate based on the included certificate request. Azure DRS then updates the device object in Azure Active Directory and sends the device ID and the device certificate to the client.|
+|H | Device registration completes by receiveing the device ID and the device certificate from Azure DRS.  The device ID is saved for future reference (viewable from dsregcmd.exe /status), and the device certicate is installed in the Personal store of the computer.  With device registration complete, the task exits.|
+
+[Return to top](#WindowsHelloforBusinessandDeviceRegistration)
+## Hybrid Azure AD joined in Federated environments
+![Hybrid Azure AD joined in Managed environments](images/howitworks/devreg-hybrid-haadj-federated.png)
+
+| Phase  | Description  |
+| :----: | :----------- |
+| A | The user signs in to a domain joined Windows 10 computers using domain credentials.  This can be username and password or smart card authentication.  The user sign-in triggers the Automatic Device Join task.|
+|B | The task queries Active Directory using the LDAP protocol for the keywords attribute on service connection point stored in the configuration partition in Active Directory (CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=corp,DC=contoso,DC=com).  The value returned in the keywords attribute determines if device registration is directed to Azure Device Registration Service (ADRS) or the enterprise device registration service hosted on-premises.|
+|C | For the federated environments, the computer authenticates the enterprise device registration endpoint using Windows integreated authentication.  The enterprise device registration service creates and returns a token that includes claims for the object GUID, computer SID, and domain joined state. The task submits the token and claims to Azure Active Directory where it is validated.  Azure Active Directory returns an ID token to the running task.
+|D | The application creates TPM bound (preferred) RSA 2048 bit key-pair known as the device key (dkpub/dkpriv).  The appplication create a certificate request using dkpub and the public key and signs the certificate request with using dkpriv.  Next, the application derives second key pair from the TPM's storage root key.  This is the transport key (tkpub/tkpriv).|
+|E | To provide SSO for on-premises federated application, the task requests an enterprise PRT from the on-premises STS. Windows Server 2016 running the Active Directory Federation Services role validate the request and return it the running task.|
+|F | The task sends a device registration request to Azure DRS that includes the ID token, certificate request, tkpub, and attestation data.  Azure DRS validates the ID token, creates a device ID, and creates a certificate based on the included certificate request. Azure DRS then writes a device object in Azure Active Directory and sends the device ID and the device certificate to the client.  Device registration completes by receiveing the device ID and the device certificate from Azure DRS.  The device ID is saved for future reference (viewable from dsregcmd.exe /status), and the device certicate is installed in the Personal store of the computer.  With device registration complete, the task exits.|
+|G |If device writeback is enabled, on it's next synchronization cycle, Azure AD Connect requests updates from Azure Active Directory.  Azure Active Directory correlates the device object with a matching synchronized computer object. Azure AD Connect receives the device object that includes the object GUID and computer SID and writes the device object to Active Directory.|
+
+[Return to top](#WindowsHelloforBusinessandDeviceRegistration)

windows/security/identity-protection/hello-for-business/hello-how-it-works-new.md

@@ -0,0 +1,17 @@
+---
+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]

windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md

@@ -0,0 +1,63 @@
+---
+title: How Windows Hello for Business works - Provisioning
+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
+---
+# 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
+- 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 Federated environment](#AzureADjoinedprovisioninginaFederatedenvironment)<br>
+[Hybrid Azure AD joined provisioning in a Key Trust deployment](#HybridAzureADjoinedprovisioninginaKeyTrustdeployment)<br>
+[Hybrid Azure AD joined provisioning in a Certificate Trust deployment](#HybridAzureADjoinedprovisioninginaCertificateTrustdeployment)<br>
+[Hybrid Azure AD joined provisioning in a synchronous Certificate Trust deployment](#HybridAzureADjoinedprovisioninginasynchronousCertificateTrustdeployment)<br>
+[Domain joined provisioning in an On-premises Key Trust deployment](#DomainjoinedprovisioninginanOnpremisesKeyTrustdeployment)<br>
+[Domain joined provisioning in an On-premises Certificate Trust deployment](#DomainjoinedprovisioninginanOnpremisesCertificateTrustdeployment)<br>
+
+
+
+## Azure AD joined provisioning in a Managed environment
+![Azure AD joined provisioning in a Managed environment](images/howitworks/prov-aadj-managed.png)
+
+
+[Return to top](#WindowsHelloforBusinessProvisioning)
+## Azure AD joined provisioning in a Federated environment
+
+
+
+[Return to top](#WindowsHelloforBusinessProvisioning)
+## Hybrid Azure AD joined provisioning in a Key Trust deployment
+
+
+
+[Return to top](#WindowsHelloforBusinessProvisioning)
+## Hybrid Azure AD joined provisioning in a Certificate Trust deployment
+
+
+
+[Return to top](#WindowsHelloforBusinessProvisioning)
+## Hybrid Azure AD joined provisioning in a synchronous Certificate Trust deployment
+
+
+
+[Return to top](#WindowsHelloforBusinessProvisioning)
+## Domain joined provisioning in an On-premises Key Trust deployment
+
+
+
+[Return to top](#WindowsHelloforBusinessProvisioning)
+## Domain joined provisioning in an On-premises Certificate Trust deployment
+
+
+
+[Return to top](#WindowsHelloforBusinessProvisioning)

windows/security/identity-protection/hello-for-business/hello-how-it-works-tech-deep-dive.md

@@ -0,0 +1,40 @@
+---
+title: How Windows Hello for Business works - Techincal Deep Dive
+description: Explains registration, authentication, key material, and infrastructure for Windows Hello for Business.
+keywords: identity, PIN, biometric, Hello, passport, WHFB, hybrid, key-trust, works 
+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
+---
+# Technical Deep Dive
+Windows Hello for Business authentication works through collection of components and infrastructure working together.  You can group the infrastructure and components in three categorities:
+- [Registration](#Registration)
+- [Provisioning](#Provisioning)
+- [Authentication](#Authentication)
+
+## Registration
+
+Registration is a fundemenatl prerequisite for Windows Hello for Business.  Without registration, Windows Hello for Business provisioning cannot start.  Registation is where the device **registers** its identity with the identity provider.  For cloud and hybrid deployments, the identity provider is Azure Active Directory and the device registers with the Azure Device Registration Service (ADRS).  For on-premises deployments, the identity provider is Active Directory Federation Services (AD FS), and the device registers with the enterprise device registration service hosted on the federation servers (AD FS). 
+
+[How Device Registration Works](hello-how-it-works-device-registration.md)
+
+
+## Provisioning
+
+Provisioning is when the user uses one form of authetnication to request a new Windows Hello for Business credential.  Typically the user signs in to Windows using username and password.  The provisioning flow requires a second factor of authentication before it will create a strong, two-factor Windows Hello for Business credential.<br>
+After successfully completing the second factor of authentication, the user is asked to enroll biometrics (if avaiable on the device) and create PIN as a backup gesture.  Windows then registers the public version of the Windows Hello for Business credential with the identity provider.<br>
+For cloud and hybrid deployments, the identity provider is Azure Active Directory and the user registers their key with the Azure Device Registration Service (ADRS).  For on-premises deployments, the identity provider is Active Directory Federation Services (AD FS), and the user registeres their key with the enterprise device regisration service hosted on the federation servers.<br>
+Provision can occur automatically through the out-of-box-experience (OOBE) on Azure Active Directory joined devices, or on hybrid Azure Active Directory joined devices where the user or device is influenced by Windows Hello for Business policy settings.  Users can start provisioning through **Add PIN** from Windows Settings.  Watch the [Windows Hello for Business enrollment experience](hello-videos.md#windowshelloforbusinessuserenrollmentexperience) from our [Videos](hello-videos.md) page.
+
+[How Windows Hello for Business provisioning works](hello-how-it-works-provisioning.md)
+
+## Authentication
+
+Authentication using Windows Hello for Business is the goal, and the first step in getting to a passwordless environment.  With the device registered, and provisioning complete. Users can sign-in to Windows 10 using biometrics or a PIN.  PIN is the most common gesture and is avaiable on most computers and devices.  Regardless of the gesture used, authentication occurs using the private portion of the Windows Hello for Business credential.  The PIN nor the private portion of the credential are never sent to the identity provider, and the PIN is not stored on the device.  It is user provided entropy when performing operations that use the private portion of the credential.
+
+[How Windows Hello for Business authentication works](hello-how-it-works-authentication.md)

windows/security/identity-protection/hello-for-business/hello-how-it-works-technology.md

@@ -0,0 +1,116 @@
+---
+title: How Windows Hello for Business works - Technology and Terms
+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
+---
+# Technolgy and Terms
+
+
+## Trusted Platform Module
+
+-   A Trusted Platform Module (TPM) is a hardware component that provides unique security features.
+
+    Windows 10 leverages security characteristics of a TPM for measuring boot integrity sequence (and based on that, unlocking automatically BitLocker protected drives), for protecting credentials or for health attestation.
+
+    A TPM implements controls that meet the specification described by the Trusted Computing Group (TCG). At the time of this writing, there are two versions of TPM specification produced by TCG that are not compatible with each other:
+
+    -   The first TPM specification, version 1.2, was published in February 2005 by the TCG and standardized under ISO / IEC 11889 standard.
+    -   The latest TPM specification, referred to as TPM 2.0, was released in April 2014 and has been approved by the ISO/IEC Joint Technical Committee (JTC) as ISO/IEC 11889:2015.
+
+    Windows 10 uses the TPM for cryptographic calculations as part of health attestation and to protect the keys for BitLocker, Windows Hello, virtual smart cards, and other public key certificates. For more information, see [TPM requirements in Windows 10](https://go.microsoft.com/fwlink/p/?LinkId=733948).
+
+    Windows 10 recognizes versions 1.2 and 2.0 TPM specifications produced by the TCG. For the most recent and modern security features, Windows 10 supports only TPM 2.0. 
+
+    TPM 2.0 provides a major revision to the capabilities over TPM 1.2:
+
+    -   Update crypto strength to meet modern security needs
+
+        -   Support for SHA-256 for PCRs
+        -   Support for HMAC command
+
+    -   Cryptographic algorithms flexibility to support government needs
+
+        -   TPM 1.2 is severely restricted in terms of what algorithms it can support
+        -   TPM 2.0 can support arbitrary algorithms with minor updates to the TCG specification documents
+
+    -   Consistency across implementations
+
+        -   The TPM 1.2 specification allows vendors wide latitude when choosing implementation details
+        -   TPM 2.0 standardizes much of this behavior
+
+
+
+
+This section describes endorsement key (EK) (that acts as an identity card for TPM), storage root key (SRK) (that protect keys) and attestation identity key (AIK) (that can report platform state) are used for health attestation reporting.
+
+In a simplified manner, the TPM is a passive component with limited resources. It can calculate random numbers, RSA keys, decrypt short data, store hashes taken when booting the device.  A TPM incorporates in a single component:
+* A RSA 2048-bit key generator
+* A random number generator
+* Nonvolatile memory for storing EK, SRK, and AIK keys
+* A cryptographic engine to encrypt, decrypt, and sign
+* Volatile memory for storing the PCRs and RSA keys
+
+## 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. 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 
+

windows/security/identity-protection/hello-for-business/hello-identity-verification.md

@@ -10,7 +10,7 @@ ms.pagetype: security, mobile
 author: mikestephens-MS
 ms.author: mstephen
 localizationpriority: high
-ms.date: 03/26/2018
+ms.date: 05/05/2018
 ---
 # Windows Hello for Business
 
@@ -68,85 +68,3 @@ The table shows the minimum requirements for each deployment.
 | Windows Server 2016 AD FS with [KB4088889 update](https://support.microsoft.com/en-us/help/4088889) | Windows Server 2016 AD FS with [KB4088889 update](https://support.microsoft.com/en-us/help/4088889) |
 | AD FS with Azure MFA Server, or</br>AD FS with 3rd Party MFA Adapter | AD FS with Azure MFA Server, or</br>AD FS with 3rd Party MFA Adapter |
 | Azure Account, optional for Azure MFA billing | Azure Account, optional for Azure MFA billing |
-
-## Frequently Asked Questions
-
-### 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?
-
-Watch Senior Program Manager Karanbir Singh's Ignite 2017 presentation **Microsoft's guide for going password-less**
-
-> [!VIDEO https://www.youtube.com/embed/mXJS615IGLM]
-
-### 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.
-
-> [!VIDEO https://www.youtube.com/embed/FJqHPTZTpNM]
- 
-</br>
-
-> [!VIDEO https://www.youtube.com/embed/etXJsZb8Fso]
-
-
-
-
-### What happens when my user forgets their PIN?
-
-If the user can sign-in with a password, they can reset their PIN by clicking the "I forgot my PIN" link in settings.  Beginning with the Fall Creators Update, users can reset their PIN above the lock screen by clicking the "I forgot my PIN" link on the PIN credential provider.
-
-> [!VIDEO https://www.youtube.com/embed/KcVTq8lTlkI]
-
-For on-premises deployments, devices must be well connected to their on-premises network (domain controllers and/or certificate authority) to reset their PINs.  Hybrid customers can onboard their Azure tenant to use the Windows Hello for Business PIN reset service to reset their PINs 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 multifactor 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](https://docs.microsoft.com/en-us/windows/access-protection/hello-for-business/hello-features#multifactor-unlock) in [Windows Hello for Business Features](#hello-features.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 username 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
-* 1234 has a constant delta of 1, so it is not allowed
-* 1357 has a constant delta of 2, so it is not allowed
-* 9630 has a constant delta of -3, so it is not allowed
-* 1231 does not have a constant delta, so it is okay
-* 1593 does not have a constant delta, so it is okay
-
-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.  
-
-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 occurence where you cannot authenticate with biometrics, you need a fall back mechansim that is not a password.  The PIN is the fall back mechansim.  Disabling or hiding the PIN credential provider disabled the use of biometrics.
-
-### 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 |
-| :---: | :--- |
-| [[MS-KPP]: Key Provisioning Protocol](https://msdn.microsoft.com/en-us/library/mt739755.aspx) | Specifies the Key Provisioning Protocol, which defines a mechanism for a client to register a set of cryptographic keys on a user and device pair. |
-| [[MS-OAPX]: OAuth 2.0 Protocol Extensions](https://msdn.microsoft.com/en-us/library/dn392779.aspx)| Specifies the OAuth 2.0 Protocol Extensions, which are used to extend the OAuth 2.0 Authorization Framework. These extensions enable authorization features such as resource specification, request identifiers, and login hints. |  
-| [[MS-OAPXBC]: OAuth 2.0 Protocol Extensions for Broker Clients](https://msdn.microsoft.com/en-us/library/mt590278.aspx) | Specifies the OAuth 2.0 Protocol Extensions for Broker Clients, extensions to RFC6749 (The OAuth 2.0 Authorization Framework) that allow a broker client to obtain access tokens on behalf of calling clients. |
-| [[MS-OIDCE]: OpenID Connect 1.0 Protocol Extensions](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 metadata 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 inqury at [whfbfeedback@microsoft.com](mailto:whfbfeedback@microsoft.com?subject=collaboration)
-

windows/security/identity-protection/hello-for-business/hello-videos.md

@@ -0,0 +1,40 @@
+---
+title: Windows Hello for Business Videos
+description: Windows Hello for Business Videos 
+keywords: identity, PIN, biometric, Hello, passport, video, watch, passwordless
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security, mobile
+author: mikestephens-MS
+ms.author: mstephen
+localizationpriority: high
+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, Multifactor Unlock, and Dyanmic 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]
+ 
+</br>
+
+> [!VIDEO https://www.youtube.com/embed/etXJsZb8Fso]
+
+## Windows Hello for Business forgotten PIN user experience
+
+If the user can sign-in with a password, they can reset their PIN by clicking the "I forgot my PIN" link in settings.  Beginning with the Fall Creators Update, users can reset their PIN above the lock screen by clicking the "I forgot my PIN" link on the PIN credential provider.
+
+> [!VIDEO https://www.youtube.com/embed/KcVTq8lTlkI]
+
+For on-premises deployments, devices must be well connected to their on-premises network (domain controllers and/or certificate authority) to reset their PINs.  Hybrid customers can onboard their Azure tenant to use the Windows Hello for Business PIN reset service to reset their PINs without access to their corporate network.

windows/security/identity-protection/hello-for-business/toc.md

@@ -45,3 +45,6 @@
 
 ## [Windows Hello for Business Features](hello-features.md)
 ### [Multifactor Unlock](feature-multifactor-unlock.md)
+
+## [Windows Hello for Business Frequently Asked Questions (FAQ)](hello-faq.md)
+### [Windows Hello for Business Videos](hello-videos.md)