 +2. Under **Diagnostic data**, turn on the **If data viewing is enabled, you can see your diagnostics data** option. + +  ### Download the Diagnostic Data Viewer Download the app from the [Microsoft Store Diagnostic Data Viewer](https://www.microsoft.com/en-us/store/p/diagnostic-data-viewer/9n8wtrrsq8f7?rtc=1) page. @@ -42,7 +44,11 @@ You must start this app from the **Settings** panel. **To start the Diagnostic Data Viewer** 1. Go to **Start**, select **Settings** > **Privacy** > **Diagnostics & feedback**. -2. Under **Diagnostic data**, select the **Diagnostic Data Viewer** button.
-OR-
Go to **Start** and search for _Diagnostic Data Viewer_.
+2. Under **Diagnostic data**, select the **Diagnostic Data Viewer** button.
+
+ 
-OR-
+
+ Go to **Start** and search for _Diagnostic Data Viewer_.
3. Close the Diagnostic Data Viewer app, use your device as you normally would for a few days, and then open Diagnostic Data Viewer again to review the updated list of diagnostic data.
@@ -52,18 +58,34 @@ You must start this app from the **Settings** panel.
### Use the Diagnostic Data Viewer
The Diagnostic Data Viewer provides you with the following features to view and filter your device's diagnostic data.
-- **View your diagnostic events.** In the left column, you can review your diagnostic events. These events reflect activities that occurred and were sent to Microsoft.
Selecting an event opens the detailed JSON view, which provides the exact details uploaded to Microsoft. Microsoft uses this info to continually improve the Windows operating system. +- **View your diagnostic events.** In the left column, you can review your diagnostic events. These events reflect activities that occurred and were sent to Microsoft. -- **Search your diagnostic events.** The **Search** box at the top of the screen lets you search amongst all of the diagnostic event details. The returned search results include any diagnostic event that contains the matching text.
Selecting an event opens the detailed JSON view, with the matching text highlighted. + Selecting an event opens the detailed JSON view, which provides the exact details uploaded to Microsoft. Microsoft uses this info to continually improve the Windows operating system. + +  -- **Filter your diagnostic event categories.** The apps Menu button opens the detailed menu. In here, you'll find a list of diagnostic event categories, which define how the events are used by Microsoft.
Selecting a check box lets you filter between the diagnostic event categories. +- **Search your diagnostic events.** The **Search** box at the top of the screen lets you search amongst all of the diagnostic event details. The returned search results include any diagnostic event that contains the matching text. -- **Help to make your Windows experience better.** Microsoft samples diagnostic data from a small amount of devices to make big improvements to the Windows operating system and ultimately, your experience. If you’re a part of this small device group and you experience issues, Microsoft will collect the associated event diagnostic data, allowing your info to potentially help fix the issue for others.
To signify your contribution, you’ll see this icon () if your device is part of the sampling group. In addition, if any of your diagnostic data events are sent from your device to Microsoft to help make improvements, you’ll see this icon (). + Selecting an event opens the detailed JSON view, with the matching text highlighted. -- **Provide diagnostic event feedback.** The **Feedback** icon opens the Feedback Hub app, letting you provide feedback about the Diagnostic Data Viewer and the diagnostic events.
Selecting a specific event in the Diagnostic Data Viewer automatically fills in the field in the Feedback Hub. You can add your comments to the box labeled, **Give us more detail (optional)**. +- **Filter your diagnostic event categories.** The apps Menu button opens the detailed menu. In here, you'll find a list of diagnostic event categories, which define how the events are used by Microsoft. + + Selecting a check box lets you filter between the diagnostic event categories. + +  + +- **Help to make your Windows experience better.** Microsoft only needs diagnostic data from a small amount of devices to make big improvements to the Windows operating system and ultimately, your experience. If you’re a part of this small device group and you experience issues, Microsoft will collect the associated event diagnostic data, allowing your info to potentially help fix the issue for others. + + To signify your contribution, you’ll see this icon () if your device is part of the group. In addition, if any of your diagnostic data events are sent from your device to Microsoft to help make improvements, you’ll see this icon (). + +- **Provide diagnostic event feedback.** The **Feedback** icon opens the Feedback Hub app, letting you provide feedback about the Diagnostic Data Viewer and the diagnostic events. + +  + + Selecting a specific event in the Diagnostic Data Viewer automatically fills in the field in the Feedback Hub. You can add your comments to the box labeled, **Give us more detail (optional)**. - >[!Important] - >All content in the Feedback Hub is publicly viewable. Therefore, make sure you don't put any personal info into your feedback comments. + >[!Important] + >All content in the Feedback Hub is publicly viewable. Therefore, make sure you don't put any personal info into your feedback comments. ## Turn off data viewing When you're done reviewing your diagnostic data, you should turn of data viewing. @@ -71,10 +93,17 @@ When you're done reviewing your diagnostic data, you should turn of data viewing **To turn off data viewing** 1. Go to **Start**, select **Settings** > **Privacy** > **Diagnostics & feedback**. -2. Under **Diagnostic data**, turn off the **If data viewing is enabled, you can see your diagnostics data** option.
 +2. Under **Diagnostic data**, turn off the **If data viewing is enabled, you can see your diagnostics data** option. + +  ## View additional diagnostic data in the View problem reports tool You can review additional Windows Error Reporting diagnostic data in the **View problem reports** tool. This tool provides you with a summary of various crash reports that are sent to Microsoft as part of Windows Error Reporting. We use this data to find and fix specific issues that are hard to replicate and to improve the Windows operating system. **To view your Windows Error Reporting diagnostic data** -1. Go to **Start**, select **Control Panel** > **All Control Panel Items** > **Security and Maintenance** > **Problem Reports**.
-OR-
Go to **Start** and search for _Problem Reports_.
The **Review problem reports** tool opens, showing you your Windows Error Reporting reports, along with a status about whether it was sent to Microsoft.
+1. Go to **Start**, select **Control Panel** > **All Control Panel Items** > **Security and Maintenance** > **Problem Reports**.
-OR-
+ Go to **Start** and search for _Problem Reports_.
+
+ The **Review problem reports** tool opens, showing you your Windows Error Reporting reports, along with a status about whether it was sent to Microsoft.
+
+ 
diff --git a/windows/privacy/images/ddv-event-feedback.png b/windows/privacy/images/ddv-event-feedback.png
index 393a0514b3..61c1c15e99 100644
Binary files a/windows/privacy/images/ddv-event-feedback.png and b/windows/privacy/images/ddv-event-feedback.png differ
diff --git a/windows/privacy/images/ddv-event-view-basic.png b/windows/privacy/images/ddv-event-view-basic.png
index 6d629af194..5668e13bec 100644
Binary files a/windows/privacy/images/ddv-event-view-basic.png and b/windows/privacy/images/ddv-event-view-basic.png differ
diff --git a/windows/privacy/images/ddv-event-view-filter.png b/windows/privacy/images/ddv-event-view-filter.png
index b463a8d6cc..addd53271d 100644
Binary files a/windows/privacy/images/ddv-event-view-filter.png and b/windows/privacy/images/ddv-event-view-filter.png differ
diff --git a/windows/privacy/images/ddv-event-view.png b/windows/privacy/images/ddv-event-view.png
index 8bb2319afb..264add2d9c 100644
Binary files a/windows/privacy/images/ddv-event-view.png and b/windows/privacy/images/ddv-event-view.png differ
diff --git a/windows/privacy/images/ddv-export.png b/windows/privacy/images/ddv-export.png
new file mode 100644
index 0000000000..25e62858db
Binary files /dev/null and b/windows/privacy/images/ddv-export.png differ
diff --git a/windows/security/identity-protection/hello-for-business/feature-multifactor-unlock.md b/windows/security/identity-protection/hello-for-business/feature-multifactor-unlock.md
index 31116809dd..5bc351b6ed 100644
--- a/windows/security/identity-protection/hello-for-business/feature-multifactor-unlock.md
+++ b/windows/security/identity-protection/hello-for-business/feature-multifactor-unlock.md
@@ -8,33 +8,37 @@ ms.sitesec: library
ms.pagetype: security, mobile
author: mikestephens-MS
ms.author: mstephen
-ms.localizationpriority: medium
+localizationpriority: high
ms.date: 03/20/2018
---
# Multifactor Unlock
+**Applies to:**
+- Windows 10
+
**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 advantage 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 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 +64,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 +80,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.
+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.
**Example**
```
+The fully qualified domain name of your organizations internal DNS suffix where any part of the fully qualified domain name in this setting exists in the computer's primary DNS suffix. The **signal** element may contain one or more **dnsSuffix** elements.
**Example**
```
+```
+
+**Example**
+```
+
+
+|Value | Description|
+|:----:|:-----------|
+|Open| The wireless network is an open network that does not require any authentication or encryption.|
+|WEP| The wireless network is protected using Wired Equivalent Privacy.|
+|WPA-Personal| The wireless network is protected using Wi-Fi Protected Access.|
+|WPA-Enterprise| The wireless network is protected using Wi-Fi Protected Access-Enterprise.|
+|WPA2-Personal| The wireless network is protected using Wi-Fi Protected Access 2, which typically uses a pre-shared key.|
+|WPA2-Enterprise| The wireless network is protected using Wi-Fi Protected Access 2-Enterprise.|
+
+**Example**
+```
+
+**Example**
+```
+
+**Example**
+```
+
+
+3. In the Azure portal, you can verify that the Microsoft PIN reset service is integrated from the **Enterprise applications**, **All applications** blade.
-3. In the Azure portal, you can verify that Intune and the PIN reset service were integrated from the Enterprise applications - All applications blade as shown in the following screenshot:
-
-4. Log in to [this website](https://login.windows.net/common/oauth2/authorize?response_type=code&client_id=9115dd05-fad5-4f9c-acc7-305d08b1b04e&resource=https%3A%2F%2Fcred.microsoft.com%2F&redirect_uri=ms-appx-web%3A%2F%2FMicrosoft.AAD.BrokerPlugin%2F9115dd05-fad5-4f9c-acc7-305d08b1b04e&state=6765f8c5-f4a7-4029-b667-46a6776ad611&prompt=admin_consent) using your Intune tenant admin credentials and, again, choose **Accept** to give consent for the service to access your account.
-#### Configure Windows devices to use PIN reset
+#### Configure Windows devices to use PIN reset using Group Policy
+You configure Windows 10 to use the Microsoft PIN Reset service using the computer configuration portion of a Group Policy object.
+1. Using the Group Policy Management Console (GPMC), scope a domain-based Group Policy to computer accounts in Active Directory.
+2. Edit the Group Policy object from step 1.
+3. Enable the **Use PIN Recovery** policy setting located under **Computer Configuration->Administrative Templates->Windows Components->Windows Hello for Business**.
+4. Close the Group Policy Management Editor to save the Group Policy object. Close the GPMC.
+
+#### Configure Windows devices to use PIN reset using Microsoft Intune
To configure PIN reset on Windows devices you manage, use an [Intune Windows 10 custom device policy](https://docs.microsoft.com/en-us/intune/custom-settings-windows-10) to enable the feature. Configure the policy using the following Windows policy configuration service provider (CSP):
-- **For devices** - **./Device/Vendor/MSFT/PassportForWork/*tenant ID*/Policies/EnablePinRecovery**
+##### Create a PIN Reset Device configuration profile using Microsoft Intune
-*tenant ID* refers to your Azure Active Directory, Directory ID which you can obtain from the **Properties** page of Azure Active Directory.
-
-Set the value for this CSP to **True**.
-
-Read the [Steps to reset the passcode](https://docs.microsoft.com/en-us/intune/device-windows-pin-reset#steps-to-reset-the-passcode) section to remotely reset a PIN on an Intune managed device.
+1. Sign-in to [Azure Portal](https://portal.azure.com) using a tenant administrator account.
+2. You need your tenant ID to complete the following task. You can discovery your tenant ID viewing the **Properties** of your Azure Active Directory from the Azure Portal. You can also use the following command in a command Window on any Azure AD joined or hybrid Azure AD joined computer.
+```
+dsregcmd /status | findstr -snip "tenantid"
+```
+3. Navigate to the Microsoft Intune blade. Click **Device configuration**. Click **Profiles**. Click **Create profile**.
+4. Type **Use PIN Recovery** in the **Name** field. Select **Windows 10 and later** from the **Platform** list. Select **Custom** from the **Profile type** list.
+5. In the **Custom OMA-URI Settings** blade, Click **Add**.
+6. In the **Add Row** blade, type **PIN Reset Settings** in the **Name** field. In the **OMA-URI** field, type **./Device/Vendor/MSFT/PassportForWork/*tenant ID*/Policies/EnablePinRecovery** where *tenant ID* is your Azure Active Directory tenant ID from step 2.
+7. Select **Boolean** from the **Data type** list and select **True** from the **Value** list.
+8. Click **OK** to save the row configuration. Click **OK** to close the **Custom OMA-URI Settings blade. Click **Create** to save the profile.
+
+##### Assign the PIN Reset Device configuration profile using Microsoft Intune
+1. Sign-in to [Azure Portal](https://portal.azure.com) using a tenant administrator account.
+2. Navigate to the Microsoft Intune blade. Click **Device configuration**. Click **Profiles**. From the list of device configuration profiles, click the profile that contains the PIN reset configuration.
+3. In the device configuration profile, click **Assignments**.
+4. Use the **Include** and/or **Exclude** tabs to target the device configuration profile to select groups.
### On-premises Deployments
** Requirements**
* Active Directory
* On-premises Windows Hello for Business deployment
-* Reset from settings - Windows 10, version 1703
-* Reset above Lock - Windows 10, version 1709
+* Reset from settings - Windows 10, version 1703, Professional
+* Reset above Lock - Windows 10, version 1709, Professional
-On-premises deployments provide users with the ability to reset forgotton PINs either through the settings page or from above the user's lock screen. Users must know or be provided their password for authentication, must perform a second factor of authentication, and then reprovision Windows Hello for Business.
+On-premises deployments provide users with the ability to reset forgotten PINs either through the settings page or from above the user's lock screen. Users must know or be provided their password for authentication, must perform a second factor of authentication, and then re-provision Windows Hello for Business.
>[!IMPORTANT]
->Users must have corporate network connectivity to domain controllers and the AD FS server to reset their PINs.
+>Users must have corporate network connectivity to domain controllers and the federation service to reset their PINs.
#### Reset PIN from Settings
1. Sign-in to Windows 10, version 1703 or later using an alternate credential.
@@ -136,20 +162,108 @@ On-premises deployments provide users with the ability to reset forgotton PINs e
1. On Windows 10, version 1709, click **I forgot my PIN** from the Windows Sign-in
2. Enter your password and press enter.
3. Follow the instructions provided by the provisioning process
- 4. When finished, unlock your desktop using your newly creeated PIN.
+ 4. When finished, unlock your desktop using your newly created PIN.
>[!NOTE]
-> Visit the [Frequently Asked Questions](https://docs.microsoft.com/en-us/windows/access-protection/hello-for-business/hello-identity-verification#frequently-asked-questions) section of the Windows Hello for Business page and watch the **What happens when the user forgets their PIN?** video.
+> Visit the [Windows Hello for Business Videos](https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-videos.md) page and watch the [Windows Hello for Business forgotten PIN user experience](https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-videos#windows-hello-for-business-forgotten-pin-user-experience) video.
-## Privileged Credentials
+## Dual Enrollment
**Requirements**
* Hybrid and On-premises Windows Hello for Business deployments
-* Domain Joined or Hybrid Azure joined devices
+* Enterprise Joined or Hybrid Azure joined devices
* Windows 10, version 1709
-The privileged credentials scenario enables administrators to perform elevated, administrative functions by enrolling both their non-privileged and privileged credentials on their device.
+> [!NOTE]
+> This feature was previously known as **Privileged Credential** but was renamed to **Dual Enrollment** to prevent any confusion with the **Privileged Access Workstation** feature.
-By design, Windows 10 does not enumerate all Windows Hello for Business users from within a user's session. Using the computer Group Policy setting, Allow enumeration of emulated smart card for all users, you can configure a device to all this enumeration on selected devices.
+> [!IMPORTANT]
+> Dual enrollment does not replace or provide the same security as Privileged Access Workstations feature. Microsoft encourages enterprises to use the Privileged Access Workstations for their privileged credential users. Enterprises can consider Windows Hello for Business dual enrollment in situations where the Privileged Access feature cannot be used. Read [Privileged Access Workstations](https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/privileged-access-workstations) for more information.
-With this setting, administrative users can sign-in to Windows 10, version 1709 using their non-privileged Windows Hello for Business credentials for normal workflow such as email, but can launch Microsoft Managment Consoles (MMCs), Remote Desktop Services clients, and other applications by selecting **Run as different user** or **Run as administrator**, selecting the privileged user account, and providing their PIN. Administrators can also take advantage of this feature with command line applications by using **runas.exe** combined with the **/smartcard** argument. This enables administrators to perform their day-to-day operations without needing to sign-in and out, or use fast user switching when alternativing between privileged and non-privileged workloads.
+Dual enrollment enables administrators to perform elevated, administrative functions by enrolling both their non-privileged and privileged credentials on their device.
+
+By design, Windows 10 does not enumerate all Windows Hello for Business users from within a user's session. Using the computer Group Policy setting, **Allow enumeration of emulated smart card for all users**, you can configure a device to enumerate all enrolled Windows Hello for Business credentials on selected devices.
+
+With this setting, administrative users can sign-in to Windows 10, version 1709 using their non-privileged Windows Hello for Business credentials for normal work flow such as email, but can launch Microsoft Management Consoles (MMCs), Remote Desktop Services clients, and other applications by selecting **Run as different user** or **Run as administrator**, selecting the privileged user account, and providing their PIN. Administrators can also take advantage of this feature with command line applications by using **runas.exe** combined with the **/smartcard** argument. This enables administrators to perform their day-to-day operations without needing to sign-in and out, or use fast user switching when alternating between privileged and non-privileged workloads.
+
+> [!IMPORTANT]
+> You must configure a Windows 10 computer for Windows Hello for Business dual enrollment before either user (privileged or non-privileged) provisions Windows Hello for Business. Dual enrollment is a special setting that is configured on the Windows Hello container during creation.
+
+### Configure Windows Hello for Business Dual Enroll
+In this task you will
+- Configure Active Directory to support Domain Administrator enrollment
+- Configure Dual Enrollment using Group Policy
+
+#### Configure Active Directory to support Domain Administrator enrollment
+The designed Windows for Business configuration has you give the **Key Admins** (or **KeyCredential Admins** when using domain controllers prior to Windows Server 2016) group read and write permissions to the msDS-KeyCredentialsLink attribute. You provided these permissions at root of the domain and use object inheritance to ensure the permissions apply to all users in the domain regardless of their location within the domain hierarchy.
+
+Active Directory Domain Services uses AdminSDHolder to secure privileged users and groups from unintentional modification by comparing and replacing the security on privileged users and groups to match those defined on the AdminSDHolder object on an hourly cycle. For Windows Hello for Business, your domain administrator account may receive the permissions but will they will disappear from the user object unless you give the AdminSDHolder read and write permissions to the msDS-KeyCredential attribute.
+
+Sign-in to a domain controller or management workstation with access equivalent to _domain administrator_.
+
+1. Type the following command to add the **allow** read and write property permissions for msDS-KeyCredentialLink attribute for the **Key Admins** (or **KeyCredential Admins**) group on the AdminSDHolder object.
+```dsacls "CN=AdminSDHolder,CN=System,**DC=domain,DC=com**" /g "**[domainName\keyAdminGroup]**":RPWP,msDS-KeyCredentialLink```
+where **DC=domain,DC=com** is the LDAP path of your Active Directory domain and **domainName\keyAdminGroup]** is the NetBIOS name of your domain and the name of the group you use to give access to keys based on your deployment. For example:
+```dsacls "CN=AdminSDHolder,CN=System,DC=corp,DC=mstepdemo,DC=net /g "mstepdemo\Key Admins":RPWP,msDS-KeyCredentialLink```
+2. To trigger security descriptor propagation, open **ldp.exe**.
+3. Click **Connection** and select **Connect...** Next to **Server**, type the name of the domain controller that holds the PDC role for the domain. Next to **Port**, type **389** and click **OK**.
+4. Click **Connection** and select **Bind...** Click **OK** to bind as the currently signed-in user.
+5. Click **Browser** and select **Modify**. Leave the **DN** text box blank. Next to **Attribute**, type **RunProtectAdminGroupsTask**. Next to **Values**, type **1**. Click **Enter** to add this to the **Entry List**.
+6. Click **Run** to start the task.
+7. Close LDP.
+
+#### Configuring Dual Enrollment using Group Policy
+You configure Windows 10 to support dual enrollment using the computer configuration portion of a Group Policy object.
+
+1. Using the Group Policy Management Console (GPMC), create a new domain-based Group Policy object and link it to an organizational Unit that contains Active Directory computer objects used by privileged users.
+2. Edit the Group Policy object from step 1.
+3. Enable the **Allow enumeration of emulated smart cards for all users** policy setting located under **Computer Configuration->Administrative Templates->Windows Components->Windows Hello for Business**.
+4. Close the Group Policy Management Editor to save the Group Policy object. Close the GPMC.
+5. Restart computers targeted by this Group Policy object.
+
+The computer is ready for dual enrollment. Sign-in as the privileged user first and enroll for Windows Hello for Business. Once completed, sign-out and sign-in as the non-privileged user and enroll for Windows Hello for Business. You can now use your privileged credential to perform privileged tasks without using your password and without needing to switch users.
+
+## Remote Desktop with Biometrics
+
+> [!Warning]
+> Some information relates to pre-released product that may change before it is commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.
+
+**Requirements**
+- Hybrid and On-premises Windows Hello for Business deployments
+- Azure AD joined, Hybrid Azure AD joined, and Enterprise joined devices
+- Certificate trust deployments
+- Biometric enrollments
+- Windows 10, version 1809
+
+Users using earlier versions of Windows 10 could remote desktop to using Windows Hello for Business but were limited to the using their PIN as their authentication gesture. Windows 10, version 1809 introduces the ability for users to authenticate to a remote desktop session using their Windows Hello for Business biometric gesture. The feature is on by default, so your users can take advantage of it as soon as they upgrade to Windows 10, version 1809.
+
+> [!IMPORTANT]
+> The remote desktop with biometrics feature only works with certificate trust deployments. The feature takes advantage of the redirected smart card capabilities of the remote desktop protocol. Microsoft continues to investigate supporting this feature for key trust deployments.
+
+### How does it work
+It start with creating cryptographic keys. Windows generates and stores cryptographic keys using a software component called a key storage provider (KSP). Software-based keys are created and stored using the Microsoft Software Key Storage Provider. Smart card keys are created and stored using the Microsoft Smart Card Key Storage Provider. Keys created and protected by Windows Hello for Business are created and stored using the Microsoft Passport Key Storage Provider.
+
+A certificate on a smart card starts with creating an asymmetric key pair using the Microsoft Smart Card KSP. Windows requests a certificate based on the key pair from your enterprises issuing certificate authority, which returns a certificate that is stored in the user's Personal certificate store. The private key remains on the smart card and the public key is stored with the certificate. Metadata on the certificate (and the key) store the key storage provider used to create the key (remember the certificate contains the public key).
+
+This same concept applies to Windows Hello for Business. Except, the keys are created using the Microsoft Passport KSP and the user's private key remains protected by the device's security module (TPM) and the user's gesture (PIN/biometric). The certificate APIs hide this complexity. When an application uses a certificate, the certificate APIs locate the keys using the saved key storage provider. The key storage providers directs the certificate APIs on which provider they use to find the private key associated with the certificate. This is how Windows knows you have a smart card certificate without the smart card inserted (and prompts you to insert the smart card).
+
+Windows Hello for Business emulates a smart card for application compatibility. Versions of Windows 10 prior to version 1809, would redirect private key access for Windows Hello for Business certificate to use its emulated smart card using the Microsoft Smart Card KSP, which would enable the user to provide their PIN. Windows 10, version 1809 no longer redirects private key access for Windows Hello for Business certificates to the Microsoft Smart Card KSP-- it continues using the Microsoft Passport KSP. The Microsoft Passport KSP enabled Windows 10 to prompt the user for their biometric gesture or PIN.
+
+### Compatibility
+Users appreciate convenience of biometrics and administrators value the security however, you may experience compatibility issues with your applications and Windows Hello for Business certificates. You can relax knowing a Group Policy setting and a [MDM URI](https://docs.microsoft.com/en-us/windows/client-management/mdm/passportforwork-csp) exist to help you revert to the previous behavior for those users who need it.
+
+
+
+> [!IMPORTANT]
+> The remote desktop with biometric feature does not work with [Dual Enrollment](#dual-enrollment) feature or scenarios where the user provides alternative credentials. Microsoft continues to investigate supporting the feature.\
+
+## 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)
\ No newline at end of file
diff --git 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
new file mode 100644
index 0000000000..7ae1ab1d14
--- /dev/null
+++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md
@@ -0,0 +1,91 @@
+---
+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: 08/19/2018
+---
+# Windows Hello for Business and Authentication
+
+**Applies to:**
+- Windows 10
+
+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.
+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.
+
+[Azure AD join authentication to Azure Active Directory](#Azure-AD-join-authentication-to-Azure-Active-Directory)
+[Azure AD join authentication to Active Direcotry using a Key](#Azure-AD-join-authentication-to-Active-Direcotry-using-a-Key)
+[Azure AD join authentication to Active Directory using a Certificate](#Azure-AD-join-authentication-to-Active-Directory-using-a-Certificate)
+[Hybrid Azure AD join authentication using a Key](#Hybrid-Azure-AD-join-authentication-using-a-Key)
+[Hybrid Azure AD join authentication using a Certificate](#Hybrid-Azure-AD-join-authentication-using-a-Certificate)
+
+
+## Azure AD join authentication to Azure Active Directory
+
+
+| 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
+
+
+
+| 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 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.
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)
+## Azure AD join authentication to Active Directory using a Certificate
+
+
+| 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.
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](#Windows-Hello-for-Business-and-Authentication)
+## Hybrid Azure AD join authentication using a Key
+
+
+| 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.
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.
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.
The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT.|
+
+[Return to top](#Windows-Hello-for-Business-and-Authentication)
+## Hybrid Azure AD join authentication using a Certificate
+
+
+| 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 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.
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.
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.
The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT.|
+
+[Return to top](#Windows-Hello-for-Business-and-Authentication)
+
+
diff --git a/windows/security/identity-protection/hello-for-business/hello-how-it-works-device-registration.md b/windows/security/identity-protection/hello-for-business/hello-how-it-works-device-registration.md
new file mode 100644
index 0000000000..d2f8d995f9
--- /dev/null
+++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works-device-registration.md
@@ -0,0 +1,87 @@
+---
+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: 08/19/2018
+---
+# Windows Hello for Business and Device Registration
+
+**Applies to:**
+- Windows 10
+
+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](#Azure-AD-joined-in-Managed-environments)
+[Azure AD joined in Federated environments](#Azure-AD-joined-in-Federated-environments)
+[Hybrid Azure AD joined in Managed environments](#HybridAzure-AD-joined-in-Managed-environments)
+[Hybrid Azure AD joined in Federated environments](#Hybrid-Azure-AD-joined-in-Federated-environments)
+
+
+
+
+## Azure AD joined in Managed environments
+
+
+| 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 provides their user name (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).
The last step in this phase has the application create an authentication 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 optional and skipped if the claim is not present or if the claim value is empty.|
+|E | The application sends a device registration 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 application 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 receiving 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 certificate is installed in the Personal store of the computer. With device registration complete, the process continues with MDM enrollment.|
+
+[Return to top](#Windows-Hello-for-Business-and-Device-Registration)
+## Azure AD joined in Federated environments
+
+
+| 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 provides their user name (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).
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 optional and skipped if the claim is not present or if the claim value is empty.|
+|F | The application sends a device registration 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 application 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 receiving 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 certificate is installed in the Personal store of the computer. With device registration complete, the process continues with MDM enrollment.|
+
+[Return to top](#Windows-Hello-for-Business-and-Device-Registration)
+## Hybrid Azure AD joined in Managed environments
+
+
+| Phase | Description |
+| :----: | :----------- |
+| A | The user signs in to a domain joined Windows 10 computers using domain credentials. This can be user name 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 authenticate 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 application 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 receiving 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 certificate is installed in the Personal store of the computer. With device registration complete, the task exits.|
+
+[Return to top](#Windows-Hello-for-Business-and-Device-Registration)
+## Hybrid Azure AD joined in Federated environments
+
+
+| Phase | Description |
+| :----: | :----------- |
+| A | The user signs in to a domain joined Windows 10 computers using domain credentials. This can be user name 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 integrated 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 application 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 receiving 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 certificate is installed in the Personal store of the computer. With device registration complete, the task exits.|
+|G |If device write-back 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](#Windows-Hello-for-Business-and-Device-Registration)
\ No newline at end of file
diff --git 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
new file mode 100644
index 0000000000..2251f953d0
--- /dev/null
+++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md
@@ -0,0 +1,145 @@
+---
+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: 08/19/2018
+---
+# Windows Hello for Business Provisioning
+
+**Applies to:**
+- Windows 10
+
+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 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](#Azure-AD-joined-provisioning-in-a-Managed-environment)
+[Azure AD joined provisioning in a Federated environment](#Azure-AD-joined-provisioning-in-a-Federated-environment)
+[Hybrid Azure AD joined provisioning in a Key Trust deployment](#Hybrid-Azure-AD-joined-provisioning-in-a-Key-Trust-deployment)
+[Hybrid Azure AD joined provisioning in a Certificate Trust deployment](#Hybrid-Azure-AD-joined-provisioning-in-a-Certificate-Trust-deployment)
+[Hybrid Azure AD joined provisioning in a synchronous Certificate Trust deployment](#Hybrid-Azure-AD-joined-provisioning-in-a-synchronous-Certificate-Trust-deployment)
+[Domain joined provisioning in an On-premises Key Trust deployment](#Domain-joined-provisioning-in-an-Onpremises-Key-Trust-deployment)
+[Domain joined provisioning in an On-premises Certificate Trust deployment](#Domain-joined-provisioning-in-an-Onpremises-Certificate-Trust-deployment)
+
+
+
+## Azure AD joined provisioning in a Managed environment
+
+
+| 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.
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.
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](#Windows-Hello-for-Business-Provisioning)
+## Azure AD joined provisioning in a Federated environment
+
+
+| 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.
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.
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.
The on-premises STS server issues a enterprise token on successful MFA. The application sends the token to Azure Active Directory.
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
+
+
+| 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.
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.
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](#Windows-Hello-for-Business-Provisioning)
+## Hybrid Azure AD joined provisioning in a Certificate Trust deployment in a Managed environment
+
+
+| 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.
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.
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.
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.
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.
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.
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
+
+
+| 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.
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.
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.
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.
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.
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.
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
+
+
+| 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.
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.
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.
The on-premises STS server issues a enterprise token on successful MFA. The application sends the token to Azure Active Directory.
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.
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.
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.
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.
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)
+## Domain joined provisioning in an On-premises Key Trust deployment
+
+
+| 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.
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.
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.
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)
+## Domain joined provisioning in an On-premises Certificate Trust deployment
+
+
+| 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.
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.
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.
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.
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.
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.
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)
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/hello-how-it-works-tech-deep-dive.md b/windows/security/identity-protection/hello-for-business/hello-how-it-works-tech-deep-dive.md
new file mode 100644
index 0000000000..7297f63ac7
--- /dev/null
+++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works-tech-deep-dive.md
@@ -0,0 +1,44 @@
+---
+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: 08/19/2018
+---
+# Technical Deep Dive
+
+**Applies to:**
+- Windows 10
+
+Windows Hello for Business authentication works through collection of components and infrastructure working together. You can group the infrastructure and components in three categories:
+- [Registration](#Registration)
+- [Provisioning](#Provisioning)
+- [Authentication](#Authentication)
+
+## Registration
+
+Registration is a fundamental prerequisite for Windows Hello for Business. Without registration, Windows Hello for Business provisioning cannot start. Registration 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 authentication to request a new Windows Hello for Business credential. Typically the user signs in to Windows using user name and password. The provisioning flow requires a second factor of authentication before it will create a strong, two-factor Windows Hello for Business credential.
+After successfully completing the second factor of authentication, the user is asked to enroll biometrics (if available 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.
+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 registers their key with the enterprise device registration service hosted on the federation servers.
+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#windows-hello-for-business-user-enrollment-experience) 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)
\ No newline at end of file
diff --git 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
new file mode 100644
index 0000000000..e48b498d4e
--- /dev/null
+++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works-technology.md
@@ -0,0 +1,313 @@
+---
+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: 08/19/2018
+---
+# Technology and Terms
+
+**Applies to:**
+- Windows 10
+
+- [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)
+
+
+## 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 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 Azure Active Directory. Windows Hello for Business authentication to Azure Active Directory always uses the key, not a certificate (excluding smart card authentication in a federated environment).
+
+### Related topics
+[Certificate Trust](#Certificate-Trust), [Hybrid Deployment](#Hybrid-Deployment), [Key Trust](#Key-Trust), [On-premises Deployment](#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.
+
+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.
+
+Windows10 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).
+
+Windows10 recognizes versions 1.2 and 2.0 TPM specifications produced by the TCG. For the most recent and modern security features, Windows10 supports only TPM 2.0.
+
+TPM 2.0 provides a major revision to the capabilities over TPM 1.2:
+
+- Update cryptography strength to meet modern security needs
+ - Support for SHA-256 for PCRs
+ - Support for HMAC command
+- 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
+
+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
+
+
+### 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)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git 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
index e1e4b79c14..8f2df655ab 100644
--- 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
-ms.localizationpriority: medium
-ms.author: daniha
-ms.date: 10/16/2017
+author: mikestephens-MS
+ms.author: mstephen
+localizationpriority: high
+ms.date: 05/05/2018
---
# 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.
-
-
-
-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 10
+Windows Hello for Business is a modern, two-factor credential that is the more secure alternative to passwords. 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
@@ -119,4 +37,4 @@ Windows Hello depends on having compatible IDPs available to it. As of this writ
- [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)
+- [Windows Hello biometrics in the enterprise](hello-biometrics-in-enterprise.md)
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base.md
new file mode 100644
index 0000000000..fab2f25e0b
--- /dev/null
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base.md
@@ -0,0 +1,329 @@
+---
+title: Configure Azure AD joined devices for On-premises Single-Sign On using Windows Hello for Business
+description: Azure Active Directory joined devices in a hybrid Deployment for on-premises single sign-on
+keywords: identity, PIN, biometric, Hello, passport, AADJ, SSO,
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security, mobile
+author: mikestephens-MS
+ms.author: mstephen
+localizationpriority: high
+ms.date: 08/19/2018
+---
+# Configure Azure AD joined devices for On-premises Single-Sign On using Windows Hello for Business
+
+**Applies to**
+- Windows 10
+- Azure Active Directory joined
+- Hybrid Deployment
+- Key trust model
+
+## Prerequisites
+
+Before adding Azure Active Directory (Azure AD) joined devices to your existing hybrid deployment, you need to verify the existing deployment can support Azure AD joined devices. Unlike hybrid Azure AD joined devices, Azure AD joined devices do not have a relationship with your Active Directory domain. This factor changes the way in which users authenticate to Active Directory. Validate the following configurations to ensure they support Azure AD joined devices.
+
+- Azure Active Directory Connect synchronization
+- Device Registration
+- Certificate Revocation List (CRL) Distribution Point (CDP)
+- 2016 Domain Controllers
+- Domain Controller certificate
+
+### Azure Active Directory Connect synchronization
+Azure AD join, as well as hybrid Azure AD join devices register the user's Windows Hello for Business credential with Azure. To enable on-premises authentication, the credential must be synchronized to the on-premises Active Directory, regardless whether you are using a key or a certificate. Ensure you have Azure AD Connect installed and functioning properly. To learn more about Azure AD Connect, read [Integrate your on-premises directories with Azure Active Directory](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect).
+
+If you upgraded your Active Directory schema to the Windows Server 2016 schema after installing Azure AD Connect, run Azure AD Connect and run **Refresh directory schema** from the list of tasks.
+
+
+### Azure Active Directory Device Registration
+A fundamental prerequisite of all cloud and hybrid Windows Hello for Business deployments is device registration. A user cannot provision Windows Hello for Business unless the device from which they are trying to provision has registered with Azure Active Directory. For more information about device registration, read [Introduction to device management in Azure Active Directory](https://docs.microsoft.com/en-us/azure/active-directory/devices/overview).
+
+You can use the **dsregcmd.exe** command to determine if your device is registered to Azure Active Directory.
+
+
+### CRL Distribution Point (CDP)
+
+Certificates issued by a certificate authority can be revoked. When a certificate authority revokes as certificate, it writes information about the certificate into a revocation list. During certificate validation, Windows 10 consults the CRL distribution point within the certificate to get a list of revoked certificates. Validation compares the current certificate with information in the certificate revocation list to determine if the certificate remains valid.
+
+
+
+The preceding domain controller certificate shows a CRL distribution path (CDP) using Active Directory. You can determine this because the value in the URL begins with **ldap**. Using Active Directory for domain joined devices provides a highly available CRL distribution point. However, Azure Active Directory joined devices and users on Azure Active Directory joined devices cannot read data from Active Directory, and certificate validation does not provide an opportunity to authenticate prior to reading the certificate revocation list. This becomes a circular problem as the user is attempting to authenticate, but must read Active Directory to complete the authentication, but the user cannot read Active Directory because they have not authenticated.
+
+To resolve this issue, the CRL distribution point must be a location that is accessible by Azure Active Directory joined devices that does not require authentication. The easiest solution is to publish the CRL distribution point on a web server that uses HTTP (not HTTPS).
+
+If your CRL distribution point does not list an HTTP distribution point, then you need to reconfigure the issuing certificate authority to include an HTTP CRL distribution point, preferably first in the list of distribution points.
+
+### Windows Server 2016 Domain Controllers
+If you are interested in configuring your environment to use the Windows Hello for Business key rather than a certificate, then your environment must have an adequate number of Windows Server 2016 domain controllers. Only Windows Server 2016 domain controllers are capable of authenticating user with a Windows Hello for Business key. What do we mean by adequate? We are glad you asked. Read [Planning an adequate number of Windows Server 2016 Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) to learn more.
+
+If you are interested in configuring your environment to use the Windows Hello for Business certificate rather than key, then you are the right place. The same certificate configuration on the domain controllers is needed, whether you are using Windows Server 2016 domain controllers or domain controllers running earlier versions of Windows Server. You can simply ignore the Windows Server 2016 domain controller requirement.
+
+### Domain Controller Certificates
+
+Certificate authorities write CRL distribution points in certificates as they are issued. If the distribution point changes, then previously issued certificates must be reissued for the certificate authority to include the new CRL distribution point. The domain controller certificate is one the critical components of Azure AD joined devices authenticating to Active Directory
+
+#### Why does Windows need to validate the domain controller certifcate?
+
+Windows Hello for Business enforces the strict KDC validation security feature, which enforces a more restrictive criteria that must be met by the Key Distribution Center (KDC). When authenticating using Windows Hello for Business, the Windows 10 client validates the reply from the domain controller by ensuring all of the following are met:
+
+- The domain controller has the private key for the certificate provided.
+- The root CA that issued the domain controller's certificate is in the device's **Trusted Root Certificate Authorities**.
+- The domain controller's certificate has the **KDC Authentication** enhanced key usage.
+- The domain controller's certificate's subject alternate name has a DNS Name that matches the name of the domain.
+
+## Configuring a CRL Distribution Point for an issuing certificate authority
+
+Use this set of procedures to update your certificate authority that issues your domain controller certificates to include an http-based CRL distribution point.
+
+Steps you will perform include:
+
+- [Configure Internet Information Services to host CRL distribution point](#configure-internet-information-services-to-host-crl-distribution-point)
+- [Prepare a file share to host the certificate revocation list](#prepare-a-file-share-to-host-the-certificate-revocation-list)
+- [Configure the new CRL distribution point in the issuing certificate authority](#Configure-the-new-crl-distribution-point-in-the-issuing-certificate-authority)
+- [Publish CRL](#publish-a-new-crl)
+- [Reissue domain controller certificates](#reissue-domain-controller-certificates)
+
+
+### Configure Internet Information Services to host CRL distribution point
+
+You need to host your new certificate revocation list of a web server so Azure AD joined devices can easily validate certificates without authentication. You can host these files on web servers many ways. The following steps is just one and may be useful for those unfamiliar with adding a new CRL distribution point.
+
+> [!IMPORTANT]
+> Do not configure the IIS server hosting your CRL distribution point to use https or a server authentication certificate. Clients should access the distribution point using http.
+
+#### Installing the Web Server
+
+1. Sign-in to your server as a local administrator and start **Server Manager** if it did not start during your sign in.
+2. Click the **Local Server** node in the navigation pane. Click **Manage** and click **Add Roles and Features**.
+3. In the **Add Role and Features Wizard**, click **Server Selection**. Verify the selected server is the local server. Click **Server Roles**. Select the check box next to **Web Server (IIS)**.
+4. Click **Next** through the remaining options in the wizard, accepting the defaults, and install the Web Server role.
+
+#### Configure the Web Server
+
+1. From **Windows Administrative Tools**, Open **Internet Information Services (IIS) Manager**.
+2. Expand the navigation pane to show **Default Web Site**. Select and then right-click **Default Web site** and click **Add Virtual Directory...**.
+3. In the **Add Virtual Directory** dialog box, type **cdp** in **alias**. For physical path, type or browse for the physical file location where you will host the certificate revocation list. For this example, the path **c:\cdp** is used. Click **OK**.
+
+> [!NOTE]
+> Make note of this path as you will use it later to configure share and file permissions.
+
+4. Select **CDP** under **Default Web Site** in the navigation pane. Double-click **Directory Browsing** in the content pane. Click **Enable** in the details pane.
+5. Select **CDP** under **Default Web Site** in the navigation pane. Double-click **Configuration Editor**.
+6. In the **Section** list, navigate to **system.webServer/security/requestFiltering**.
+
+In the list of named value-pairs in the content pane, configure **allowDoubleEscapting** to **True**. Click **Apply** in the actions pane.
+
+7. Close **Internet Information Services (IIS) Manager**.
+
+#### Create a DNS resource record for the CRL distribution point URL
+
+1. On your DNS server or from an administrative workstation, open **DNS Manager** from **Administrative Tools**.
+2. Expand **Forward Lookup Zones** to show the DNS zone for your domain. Right-click your domain name in the navigation pane and click **New Host (A or AAAA)...**.
+3. In the **New Host** dialog box, type **crl** in **Name**. Type the IP address of the web server you configured in **IP Address**. Click **Add Host**. Click **OK** to close the **DNS** dialog box. Click **Done**.
+
+4. Close the **DNS Manager**.
+
+### Prepare a file share to host the certificate revocation list
+
+These procedures configure NTFS and share permissions on the web server to allow the certificate authority to automatically publish the certificate revocation list.
+
+#### Configure the CDP file share
+
+1. On the web server, open **Windows Explorer** and navigate to the **cdp** folder you created in step 3 of [Configure the Web Server](#configure-the-web-server).
+2. Right-click the **cdp** folder and click **Properties**. Click the **Sharing** tab. Click **Advanced Sharing**.
+3. Select **Share this folder**. Type **cdp$** in **Share name:**. Click **Permissions**.
+
+4. In the **Permissions for cdp$** dialog box, click **Add**.
+5. In the **Select Users, Computers, Service Accounts, or Groups** dialog box, click **Object Types**. In the **Object Types** dialog box, select **Computers**, and then click **OK**.
+7. In the **Select Users, Computers, Service Accounts, or Groups** dialog box, in **Enter the object names to select**, type the name of the server running the certificate authority issuing the certificate revocation list, and then click **Check Names**. Click **OK**.
+8. In the **Permissions for cdp$** dialog box, select the certificate authority from the **Group or user names list**. In the **Permissions for** section, select **Allow** for **Full control**. Click **OK**.
+
+9. In the **Advanced Sharing** dialog box, click **OK**.
+
+#### Disable Caching
+1. On the web server, open **Windows Explorer** and navigate to the **cdp** folder you created in step 3 of [Configure the Web Server](#configure-the-web-server).
+2. Right-click the **cdp** folder and click **Properties**. Click the **Sharing** tab. Click **Advanced Sharing**.
+3. Click **Caching**. Select **No files or programs from the shared folder are available offline**.
+
+4. Click **OK**.
+
+#### Configure NTFS permission for the CDP folder
+
+1. On the web server, open **Windows Explorer** and navigate to the **cdp** folder you created in step 3 of [Configure the Web Server](#configure-the-web-server).
+2. Right-click the **cdp** folder and click **Properties**. Click the **Security** tab.
+3. On the **Security** tab, click Edit.
+5. In the **Permissions for cdp** dialog box, click **Add**.
+
+6. In the **Select Users, Computers, Service Accounts, or Groups** dialog box, click **Object Types**. In the **Object Types** dialog box, select **Computers**. Click **OK**.
+7. In the **Select Users, Computers, Service Accounts, or Groups** dialog box, in **Enter the object names to select**, type the name of the certificate authority, and then click **Check Names**. Click **OK**.
+8. In the **Permissions for cdp** dialog box, select the name of the certificate authority from the **Group or user names** list. In the **Permissions for** section, select **Allow** for **Full control**. Click **OK**.
+9. Click **Close** in the **cdp Properties** dialog box.
+
+
+### Configure the new CRL distribution point and Publishing location in the issuing certifcate authority
+
+The web server is ready to host the CRL distribution point. Now, configure the issuing certificate authority to publish the CRL at the new location and to include the new CRL distribution point
+
+
+#### Configure the CRL distribution Point
+1. On the issuing certificate authority, sign-in as a local administrator. Start the **Certificate Authority** console from **Administrative Tools**.
+2. In the navigation pane, right-click the name of the certificate authority and click **Properties**
+3. Click **Extensions**. On the **Extensions** tab, select **CRL Distribution Point (CDP)** from the **Select extension** list.
+4. On the **Extensions** tab, click **Add**. Type **http://crl.[domainname]/cdp/** in **location**. For example, *http://crl.corp.contoso.com/cdp/* or *http://crl.contoso.com/cdp/* (do not forget the trailing forward slash).
+
+5. Select **\
+```setspn -s http/[FqdnOfNdesServer] [DomainName\\NdesServiceAccount]```
+where **[FqdnOfNdesServer]** is the fully qualified domain name of the NDES server and **[DomainName\NdesServiceAccount]** is the domain name and NDES service account name separated by a backslash (\\). An example of the command looks like the following.
+```setspn -s http/ndes.corp.contoso.com contoso\ndessvc```
+
+> [!NOTE]
+> If you use the same service account for multiple NDES Servers, repeat the following task for each NDES server under which the NDES service runs.
+
+
+
+#### Configure the NDES Service account for delegation
+The NDES service enrolls certificates on behalf of users. Therefore, you want to limit the actions it can perform on behalf of the user. You do this through delegation.
+
+Sign-in a domain controller with a minimum access equivalent to _Domain Admins_.
+
+1. Open **Active Directory Users and Computers**
+2. Locate the NDES Service account (NDESSvc). Right-click and select **Properties**. Click the **Delegation** tab.
+
+3. Select **Trust this user for delegation to specified services only**.
+4. Select **Use any authentication protocol**.
+5. Click **Add**.
+6. Click **Users or Computers...** Type the name of the _NDES Server_ you use to issue Windows Hello for Business authentication certificates to Azure AD joined devices. From the **Avaiable services** list, select **HOST**. Click **OK**.
+
+7. Repeat steps 5 and 6 for each NDES server using this service account.8. Click **Add**.
+8. Click **Users or computers...** Type the name of the issuing certificate authority this NDES service account uses to issue Windows Hello for Business authentication certificates to Azure AD joined devices. From the **Available services** list, select **dcom**. Hold the **CTRL** key and select **HOST**. Click **OK**.
+9. Repeat steps 8 and 9 for each issuing certificate authority from which one or more NDES servers request certificates.
+
+10. Click **OK**. Close **Active Directory Users and Computers**.
+
+### Configure the NDES Role and Certificate Templates
+This task configures the NDES role and the certificate templates the NDES server issues.
+
+#### Configure the NDES Role
+Sign-in to the certificate authority or management workstations with an _Enterprise Admin_ equivalent credentials.
+
+> [!NOTE]
+> If you closed Server Manger from the last set of tasks, start Server Manager and click the action flag that shows a yellow exclamation point.
+
+
+
+1. Click the **Configure Active Directory Certificate Services on the destination server** link.
+2. On the **Credentials** page, click **Next**.
+
+3. On the **Role Services** page, select **Network Device Enrollment Service** and then click **Next**
+
+4. On the **Service Account for NDES** page, select **Specify service account (recommended)**. Click **Select...** Type the user name and password for the NDES service account in the **Windows Security** dialog box. Click **Next**.
+
+5. On the **CA for NDES** page, select **CA name**. Click **Select...**. Select the issuing certificate authority from which the NDES server requests certificates. Click **Next**.
+
+6. On the **RA Information**, click **Next**.
+7. On the **Cryptography for NDES** page, click **Next**.
+8. Review the **Confirmation** page. Click **Configure**.
+
+8. Click **Close** after the configuration completes.
+
+#### Configure Certificate Templates on NDES
+A single NDES server can request a maximum of three certificate template. The NDES server determines which certificate to issue based on the incoming certificate request that is assigned in the Microsoft Intune SCEP certificate profile. The Microsoft Intune SCEP certificate profile has three values.
+* Digital Signature
+* Key Encipherment
+* Key Encipherment, Digital Signature
+
+Each value maps to a registry value name in the NDES server. The NDES server translate an incoming SCEP provide value into the correspond certificate template. The table belows shows the SCEP profile value to the NDES certificate template registry value name
+
+|SCEP Profile Key usage| NDES Registry Value Name|
+|:----------:|:-----------------------:|
+|Digital Signature|SignatureTemplate|
+|Key Encipherment|EncryptionTemplate|
+|Key Encipherment
Digital Signature|GeneralPurposeTemplate|
+
+Ideally, you should match the certificate request with registry value name to keep the configuration intuitive (encryption certificates use the encryptionTemplate, signature certificates use the signature template, etc.). A result of this intuitive design is the potential exponential growth in NDES server. Imagine an organization that needs to issue nine unique signature certificates across their enterprise.
+
+ If the need arises, you can configure a signature certificate in the encryption registry value name or an encryption certificate in the signature registry value to maximize the use of your NDES infrastructure. This unintuitive design requires current and accurate documentation of the configuration to ensure the SCEP certificate profile is configured to enroll the correct certificate, regardless of the actual purpose. Each organization needs to balance ease of configuration and administration with additional NDES infrastructure and the management overhead that comes with it.
+
+Sign-in to the NDES Server with _local administrator_ equivalent credentials.
+
+1. Open an elevated command prompt.
+2. Using the table above, decide which registry value name you will use to request Windows Hello for Business authentication certificates for Azure AD joined devices.
+3. Type the following command
+```reg add HKLM\Software\Microsoft\Cryptography\MSCEP /v [registryValueName] /t REG_SZ /d [certificateTemplateName]```
+where **registryValueName** is one of the three value names from the above table and where **certificateTemplateName** is the name of the certificate template you created for Windows Hello for Business Azure AD joined devices. Example:
+```reg add HKLM\Software\Microsoft\Cryptography\MSCEP /v SignatureTemplate /t REG_SZ /d AADJWHFBAuthentication```
+4. Type **Y** when the command asks for permission to overwrite the existing value.
+5. Close the command prompt.
+
+> [!IMPORTANT]
+> Use the **name** of the certificate template; not the **display name**. The certificate template name does not include spaces. You can view the certificate names by looking at the **General** tab of the certificate template's properties in the **Certifcates Templates** management console (certtmpl.msc).
+
+### Create a Web Application Proxy for the internal NDES URL.
+Certificate enrollment for Azure AD joined devices occurs over the Internet. As a result, the internal NDES URLs must be accessible externally. You can do this easily and securely using Azure Active Directory Application Proxy. Azure AD Application Proxy provides single sign-on and secure remote access for web applications hosted on-premises, such as Network Device Enrollment Services.
+
+Ideally, you configure your Microsoft Intune SCEP certificate profile to use multiple external NDES URLs. This enables Microsoft Intune to round-robin load balance the certificate requests to identically configured NDES Servers (each NDES server can accommodate approximately 300 concurrent requests). Microsoft Intune sends these requests to Azure AD Application Proxies.
+
+Azure AD Application proxies are serviced by lightweight Application Proxy Connector agents. These agents are installed on your on-premises, domain joined devices and make authenticated secure outbound connection to Azure, waiting to process requests from Azure AD Application Proxies. You can create connector groups in Azure Active Directory to assign specific connectors to service specific applications.
+
+Connector group automatically round-robin, load balance the Azure AD Application proxy requests to the connectors within the assigned connector group. This ensures Windows Hello for Business certificate requests have multiple dedicated Azure AD Application Proxy connectors exclusively available to satisfy enrollment requests. Load balancing the NDES servers and connectors should ensure users enroll their Windows Hello for Business certificates in a timely manner.
+
+#### Download and Install the Application Proxy Connector Agent
+Sign-in a workstation with access equivalent to a _domain user_.
+
+1. Sign-in to the [Azure Portal](https://portal.azure.com/) with access equivalent to **Global Administrator**.
+2. Select **All Services**. Type **Azure Active Directory** to filter the list of services. Under **SERVICES**, Click **Azure Active Directory**.
+3. Under **MANAGE**, click **Application proxy**.
+4. Click **Download connector service**. Click **Accept terms & Download**. Save the file (AADApplicationProxyConnectorInstaller.exe) in a location accessible by others on the domain.
+
+5. Sign-in the computer that will run the connector with access equivalent to a _domain user_.
+> [!IMPORTANT]
+> Install a minimum of two Azure Active Directory Proxy connectors for each NDES Application Proxy. Strategtically locate Azure AD application proxy connectors throughout your organization to ensure maximum availablity. Remember, devices running the connector must be able to communicate with Azure and the on-premises NDES servers.
+
+6. Start **AADApplicationProxyConnectorInstaller.exe**.
+7. Read the license terms and then select **I agree to the license terms and conditions**. Click **Install**.
+
+8. Sign-in to Microsoft Azure with access equivalent to **Global Administrator**.
+
+9. When the installation completes. Read the information regarding outbound proxy servers. Click **Close**.
+
+10. Repeat steps 5 - 10 for each device that will run the Azure AD Application Proxy connector for Windows Hello for Business certificate deployments.
+
+#### Create a Connector Group
+Sign-in a workstation with access equivalent to a _domain user_.
+
+1. Sign-in to the [Azure Portal](https://portal.azure.com/) with access equivalent to **Global Administrator**.
+2. Select **All Services**. Type **Azure Active Directory** to filter the list of services. Under **SERVICES**, Click **Azure Active Directory**.
+3. Under **MANAGE**, click **Application proxy**.
+
+4. Click **New Connector Group**. Under **Name**, type **NDES WHFB Connectors**.
+
+5. Select each connector agent in the **Connectors** list that will service Windows Hello for Business certificate enrollment requests.
+6. Click **Save**.
+
+#### Create the Azure Application Proxy
+Sign-in a workstation with access equivalent to a _domain user_.
+
+1. Sign-in to the [Azure Portal](https://portal.azure.com/) with access equivalent to **Global Administrator**.
+2. Select **All Services**. Type **Azure Active Directory** to filter the list of services. Under **SERVICES**, Click **Azure Active Directory**.
+3. Under **MANAGE**, click **Application proxy**.
+4. Click **Configure an app**.
+5. Under **Basic Settings** next to **Name**, type **WHFB NDES 01**. Choose a name that correlates this Azure AD Application Proxy setting with the on-premises NDES server. Each NDES server must have its own Azure AD Application Proxy as two NDES servers cannot share the same internal URL.
+6. Next to **Internal Url**, type the internal fully qualified DNS name of the NDES server associated with this Azure AD Application Proxy. For example, https://ndes.corp.mstepdemo.net). This must match the internal DNS name of the NDES server and ensure you prefix the Url with **https**.
+7. Under **Internal Url**, select **https://** from the first list. In the text box next to **https://**, type the hostname you want to use as your external hostname for the Azure AD Application Proxy. In the list next to the hostname you typed, select a DNS suffix you want to use externally for the Azure AD Application Proxy. It is recommended to use the default, -[tenantName].msapproxy.net where **[tenantName]** is your current Azure Active Directory tenant name (-mstephendemo.msappproxy.net).
+
+8. Select **Passthrough** from the **Pre Authentication** list.
+9. Select **NDES WHFB Connectors** from the **Connector Group** list.
+10. Under **Additional Settings**, select **Default** from **Backend Application Timeout**. Under the **Translate URLLs In** section, select **Yes** next to **Headers** and select **No** next to **Application Body**.
+11. Click **Add**.
+12. Sign-out of the Azure Portal.
+> [!IMPORTANT]
+> Write down the internal and external URLs. You will need this information when you enroll the NDES-Intune Authentication certificate.
+
+
+### Enroll the NDES-Intune Authentication certificate
+This task enrolls a client and server authentication certificate used by the Intune connector and the NDES server.
+
+Sign-in the NDES server with access equivalent to _local administrators_.
+
+1. Start the Local Computer **Certificate Manager** (certlm.msc).
+2. Expand the **Personal** node in the navigation pane.
+3. Right-click **Personal**. Select **All Tasks** and **Request New Certificate**.
+4. Click **Next** on the **Before You Begin** page.
+5. Click **Next** on the **Select Certificate Enrollment Policy** page.
+6. On the **Request Certificates** page, Select the **NDES-Intune Authentication** check box.
+7. Click the **More information is required to enroll for this certificate. Click here to configure settings** link
+ 
+8. Under **Subject name**, select **Common Name** from the **Type** list. Type the internal URL used in the previous task (without the https://, for example **ndes.corp.mstepdemo.net**) and then click **Add**.
+9. Under **Alternative name**, select **DNS** from the **Type** list. Type the internal URL used in the previous task (without the https://, for example **ndes.corp.mstepdemo.net**). Click **Add**. Type the external URL used in the previous task (without the https://, for example **ndes-mstephendemo.msappproxy.net**). Click **Add**. Click **OK** when finished.
+9. Click **Enroll**
+10. Repeat these steps for all NDES Servers used to request Windows Hello for Business authentication certificates for Azure AD joined devices.
+
+### Configure the Web Server Role
+This task configures the Web Server role on the NDES server to use the server authentication certificate.
+
+Sign-in the NDES server with access equivalent to _local administrator_.
+
+1. Start **Internet Information Services (IIS) Manager** from **Administrative Tools**.
+2. Expand the node that has the name of the NDES server. Expand **Sites** and select **Default Web Site**.
+
+3. Click **Bindings...*** under **Actions**. Click **Add**.
+
+4. Select **https** from **Type**. Confirm the value for **Port** is **443**.
+5. Select the certificate you previously enrolled from the **SSL certificate** list. Select **OK**.
+
+6. Select **http** from the **Site Bindings** list. Click **Remove**.
+7. Click **Close** on the **Site Bindings** dialog box.
+8. Close **Internet Information Services (IIS) Manager**.
+
+### Verify the configuration
+This task confirms the TLS configuration for the NDES server.
+
+Sign-in the NDES server with access equivalent to _local administrator_.
+
+#### Disable Internet Explorer Enhanced Security Configuration
+1. Open **Server Manager**. Click **Local Server** from the navigation pane.
+2. Click **On** next to **IE Enhanced Security Configuration** in the **Properties** section.
+3. In the **Internet Explorer Enhanced Security Configuration** dialog, under **Administrators**, select **Off**. Click **OK**.
+4. Close **Server Manager**.
+
+#### Test the NDES web server
+1. Open **Internet Explorer**.
+2. In the navigation bar, type
+```https://[fqdnHostName]/certsrv/mscep/mscep.dll```
+where **[fqdnHostName]** is the fully qualified internal DNS host name of the NDES server.
+
+A web page similar to the following should appear in your web browser. If you do not see similar page, or you get a **503 Service unavailable**, ensure the NDES Service account as the proper user rights. You can also review the application event log for events with the **NetworkDeviceEnrollmentSerice** source.
+
+
+
+Confirm the web site uses the server authentication certificate.
+
+
+
+## Configure Network Device Enrollment Services to work with Microsoft Intune
+You have successfully configured the Network Device Enrollment Services. You must now modify the configuration to work with the Intune Certificate Connector. In this task, you will enable the NDES server and http.sys to handle long URLs.
+
+- Configure NDES to support long URLs
+
+### Configure NDES and HTTP to support long URLs
+Sign-in the NDES server with access equivalent to _local administrator_.
+
+#### Configure the Default Web Site
+1. Start **Internet Information Services (IIS) Manager** from **Administrative Tools**.
+2. Expand the node that has the name of the NDES server. Expand **Sites** and select **Default Web Site**.
+3. In the content pane, double-click **Request Filtering**. Click **Edit Feature Settings...** in the action pane.
+
+4. Select **Allow unlisted file name extensions**.
+5. Select **Allow unlisted verbs**.
+6. Select **Allow high-bit characters**.
+7. Type **30000000** in **Maximum allowed content length (Bytes)**.
+8. Type **65534** in **Maximum URL length (Bytes)**.
+9. Type **65534** in **Maximum query string (Bytes)**.
+10. Click **OK**. Close **Internet Information Services (IIS) Manager**.
+
+#### Configure Parameters for HTTP.SYS
+1. Open an elevated command prompt.
+2. Run the following commands
+```reg add HKLM\CurrentControlSet\Services\HTTP\Parameters /v MaxFieldLength /t REG_DWORD /d 65534```
+```reg add HKLM\CurrentControlSet\Services\HTTP\Parameters /v MaxRequestBytes /t REG_DWORD /d 65534```
+3. Restart the NDES server.
+
+## Download, Install and Configure the Intune Certificate Connector
+The Intune Certificate Connector application enables Microsoft Intune to enroll certificates using your on-premises PKI for users on devices managed by Microsoft Intune.
+
+### Download Intune Certificate Connector
+Sign-in a workstation with access equivalent to a _domain user_.
+
+1. Sign-in to the [Azure Portal](https://portal.azure.com/).
+2. Select **All Services**. Type **Intune** to filter the list of services. Click **Microsoft Intune**.
+
+3. Select **Device Configuration**, and then select **Certificate Authority**.
+
+4. Click **Add**, and then click **Download the certificate connector software** under the **Steps to install connector for SCEP** section.
+
+5. Save the downloaded file (NDESConnectorSetup.exe) to a location accessible from the NDES server.
+6. Sign-out of the Azure Portal.
+
+### Install the Intune Certificate Connector
+Sign-in the NDES server with access equivalent to _domain administrator_.
+
+1. Copy the Intune Certificate Connector Setup (NDESConnectorSetup.exe) downloaded in the previous task locally to the NDES server.
+2. Run **NDESConnectorSetup.exe** as an administrator. If the setup shows a dialog that reads **Microsoft Intune NDES Connector requires HTTP Activation**, ensure you started the application as an administrator, then check HTTP Activation is enabled on the NDES server.
+3. On the **Microsoft Intune** page, click **Next**.
+
+4. Read the **End User License Agreement**. Click **Next** to accept the agreement and to proceed with the installation.
+5. On the **Destination Folder** page, click **Next**.
+6. On the **Installation Options** page, select **SCEP and PFX Profile Distribution** and click **Next**.
+
+7. On the **Client certificate for Microsoft Intune** page, Click **Select**. Select the certificate previously enrolled for the NDES server. Click **Next**.
+
+> [!NOTE]
+> The **Client certificate for Microsoft Intune** page does not update after selecting the client authentication certificate. However, the application rembers the selection and shows it in the next page.
+
+8. On the **Client certificate for the NDES Policy Module** page, verify the certificate information and then click **Next**.
+9. ON the **Ready to install Microsoft Intune Connector** page. Click **Install**.
+
+> [!NOTE]
+> You can review the results of the install using the **SetupMsi.log** file located in the **C:\\NDESConnectorSetupMsi** folder
+
+10. When the installation completes, select **Launch Intune Connector** and click Finish. Proceed to the Configure the Intune Certificate Connector task.
+
+
+### Configure the Intune Certificate Connector
+Sign-in the NDES server with access equivalent to _domain administrator_.
+
+1. The **NDES Connector** user interface should be open from the last task.
+> [!NOTE]
+> If the **NDES Connector** user interface is not open, you can start it from **\
## Device Registration ##
-Organizations wanting to deploy hybrid certificate trust need thier domain joined devices to register to Azure Active Directory. Just as a computer has an identity in Active Directory, that same computer has an identity in the cloud. This ensures that only approved computers are used with that Azure Active Directory. Each computer registers its identity in Azure Active Directory.
+Organizations wanting to deploy hybrid certificate trust need their domain joined devices to register to Azure Active Directory. Just as a computer has an identity in Active Directory, that same computer has an identity in the cloud. This ensures that only approved computers are used with that Azure Active Directory. Each computer registers its identity in Azure Active Directory.
Hybrid certificate trust deployments need the device write back feature. Authentication to the Windows Server 2016 Active Directory Federation Services needs both the user and the computer to authenticate. Typically the users are synchronized, but not devices. This prevents AD FS from authenticating the computer and results in Windows Hello for Business certificate enrollment failures. For this reason, Windows Hello for Business deployments need device writeback, which is an Azure Active Directory premium feature.
@@ -132,7 +132,7 @@ If your environment is already federated and supports Azure device registration,
## Follow the Windows Hello for Business hybrid certificate trust deployment guide
1. [Overview](hello-hybrid-cert-trust.md)
-2. Prerequistes (*You are here*)
+2. Prerequisites (*You are here*)
3. [New Installation Baseline](hello-hybrid-cert-new-install.md)
4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md)
5. [Configure Windows Hello for Business settings](hello-hybrid-cert-whfb-settings.md)
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust.md
index 97b72c76a3..30efcbd805 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust.md
@@ -14,9 +14,9 @@ ms.date: 09/08/2017
# Hybrid Azure AD joined Certificate Trust Deployment
**Applies to**
-- Windows 10
-
->This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
+- Windows 10, version 1703 or later
+- Hybrid deployment
+- Certificate trust
Windows Hello for Business replaces username and password sign-in to Windows with strong user authentication based on asymmetric key pair. The following deployment guide provides the information needed to successfully deploy Windows Hello for Business in a hybrid certificate trust scenario.
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-provision.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-provision.md
index effbe6b03a..124a34248b 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-provision.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-provision.md
@@ -9,16 +9,16 @@ ms.pagetype: security, mobile
author: mikestephens-MS
ms.author: mstephen
ms.localizationpriority: medium
-ms.date: 03/26/2018
+ms.date: 08/19/2018
---
# Hybrid Windows Hello for Business Provisioning
**Applies to**
-- Windows 10
+- Windows 10, version 1703 or later
+- Hybrid deployment
+- Certificate trust
->This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
-
## Provisioning
The Windows Hello for Business provisioning begins immediately after the user has signed in, after the user profile is loaded, but before the user receives their desktop. Windows only launches the provisioning experience if all the prerequisite checks pass. You can determine the status of the prerequisite checks by viewing the **User Device Registration** in the **Event Viewer** under **Applications and Services Logs\Microsoft\Windows**.
@@ -45,7 +45,7 @@ The provisioning flow has all the information it needs to complete the Windows H
* A fresh, successful multi-factor authentication
* A validated PIN that meets the PIN complexity requirements
-The remainder of the provisioning includes Windows Hello for Business requesting an asymmetric key pair for the user, preferably from the TPM (or required if explicitly set through policy). Once the key pair is acquired, Windows communicates with Azure Active Directory to register the public key. AAD Connect syncrhonizes the user's key to the on-prem Active Directory.
+The remainder of the provisioning includes Windows Hello for Business requesting an asymmetric key pair for the user, preferably from the TPM (or required if explicitly set through policy). Once the key pair is acquired, Windows communicates with Azure Active Directory to register the public key. AAD Connect synchronizes the user's key to the on-premises Active Directory.
> [!IMPORTANT]
> The following is the enrollment behavior prior to Windows Server 2016 update [KB4088889 (14393.2155)](https://support.microsoft.com/en-us/help/4088889).
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-ad.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-ad.md
index 80b5408547..4395d9c432 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-ad.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-ad.md
@@ -9,20 +9,21 @@ ms.pagetype: security, mobile
ms.localizationpriority: medium
author: mikestephens-MS
ms.author: mstephen
-ms.date: 10/23/2017
+ms.date: 08/19/2018
---
# Configuring Windows Hello for Business: Active Directory
**Applies to**
-- Windows 10
+- Windows 10, version 1703 or later
+- Hybrid deployment
+- Certificate trust
->This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
The key synchronization process for the hybrid deployment of Windows Hello for Business needs the Windows Server 2016 Active Directory schema.
### Creating Security Groups
-Windows Hello for Business uses several security groups to simplify the deployment and managment.
+Windows Hello for Business uses several security groups to simplify the deployment and management.
> [!Important]
> If your environment has one or more Windows Server 2016 domain controllers in the domain to which you are deploying Windows Hello for Business, then skip the **Create the KeyCredentials Admins Security Group**. Domains that include Windows Server 2016 domain controllers use the KeyAdmins group, which is created during the installation of the first Windows Server 2016 domain controller.
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-adfs.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-adfs.md
index dd6f6d5b50..25208af1bd 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-adfs.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-adfs.md
@@ -9,18 +9,17 @@ ms.pagetype: security, mobile
ms.localizationpriority: medium
author: mikestephens-MS
ms.author: mstephen
-ms.date: 03/26/2018
+ms.date: 08/20/2018
---
# Configure Windows Hello for Business: Active Directory Federation Services
**Applies to**
-- Windows10
+- Windows10, version 1703 or later
+- Hybrid deployment
+- Certificate trust
## Federation Services
-
->This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
-
-The Windows Server 2016 Active Directory Fedeartion Server Certificate Registration Authority (AD FS RA) enrolls for an enrollment agent certificate. Once the registration authority verifies the certificate request, it signs the certificate request using its enrollment agent certificate and sends it to the certificate authority.
+The Windows Server 2016 Active Directory Federation Server Certificate Registration Authority (AD FS RA) enrolls for an enrollment agent certificate. Once the registration authority verifies the certificate request, it signs the certificate request using its enrollment agent certificate and sends it to the certificate authority.
The Windows Hello for Business Authentication certificate template is configured to only issue certificates to certificate requests that have been signed with an enrollment agent certificate.
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-dir-sync.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-dir-sync.md
index ce00462dc9..7464c27892 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-dir-sync.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-dir-sync.md
@@ -14,9 +14,10 @@ ms.date: 10/23/2017
# Configure Hybrid Windows Hello for Business: Directory Synchronization
**Applies to**
-- Windows 10
+- Windows 10, version 1703 or later
+- Hybrid deployment
+- Certificate trust
->This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
## Directory Synchronization
@@ -77,5 +78,5 @@ Sign-in a domain controller or management workstation with _Domain Admin_ equiva
2. [Prerequistes](hello-hybrid-cert-trust-prereqs.md)
3. [New Installation Baseline](hello-hybrid-cert-new-install.md)
4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md)
-5. Configure Windows Hello for Business settings: Directory Syncrhonization (*You are here*)
+5. Configure Windows Hello for Business settings: Directory Synchronization (*You are here*)
6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md)
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-pki.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-pki.md
index 1508af5827..f6a16d45b9 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-pki.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-pki.md
@@ -9,23 +9,24 @@ ms.pagetype: security, mobile
ms.localizationpriority: medium
author: mikestephens-MS
ms.author: mstephen
-ms.date: 11/08/2017
+ms.date: 08/19/2018
---
# Configure Hybrid Windows Hello for Business: Public Key Infrastructure
**Applies to**
-- Windows 10
+- Windows 10, version 1703 or later
+- Hybrid Deployment
+- Certificate Trust
->This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
-Windows Hello for Business deployments rely on certificates. Hybrid deployments uses publicly issued server authentication certifcates to validate the name of the server to which they are connecting and to encyrpt the data that flows them and the client computer.
+Windows Hello for Business deployments rely on certificates. Hybrid deployments uses publicly issued server authentication certificates to validate the name of the server to which they are connecting and to encrypt the data that flows them and the client computer.
-All deployments use enterprise issed certificates for domain controllers as a root of trust. Hybrid certificate trust deployments issue users sign-in certificate that enables them to authenticate using Windows Hello for Business credentials to non-Windows Server 2016 domain controllers. Additionally, hybrid certificate trust deployments issue certificate to registration authorites to provide defenese-in-depth security for issueing user authentication certificates.
+All deployments use enterprise issued certificates for domain controllers as a root of trust. Hybrid certificate trust deployments issue users sign-in certificate that enables them to authenticate using Windows Hello for Business credentials to non-Windows Server 2016 domain controllers. Additionally, hybrid certificate trust deployments issue certificate to registration authorities to provide defense-in-depth security for issuing user authentication certificates.
## Certifcate Templates
-This section has you configure certificate templates on your Windows Server 2012 or later issuing certificate authtority.
+This section has you configure certificate templates on your Windows Server 2012 or later issuing certificate authority.
### Domain Controller certificate template
@@ -42,7 +43,7 @@ Sign-in a certificate authority or management workstations with _Domain Admin_ e
1. Open the **Certificate Authority** management console.
2. Right-click **Certificate Templates** and click **Manage**.
3. In the **Certificate Template Console**, right-click the **Kerberos Authentication** template in the details pane and click **Duplicate Template**.
-4. On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Authority** list. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Recipient** list.
+4. On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2008 R2** from the **Certification Authority** list. Select **Windows 7.Server 2008 R2** from the **Certification Recipient** list.
5. On the **General** tab, type **Domain Controller Authentication (Kerberos)** in Template display name. Adjust the validity and renewal period to meet your enterprise's needs.
**Note**If you use different template names, you'll need to remember and substitute these names in different portions of the lab.
6. On the **Subject** tab, select the **Build from this Active Directory information** button if it is not already selected. Select **None** from the **Subject name format** list. Select **DNS name** from the **Include this information in alternate subject** list. Clear all other items.
@@ -55,7 +56,7 @@ Many domain controllers may have an existing domain controller certificate. The
The Kerberos Authentication certificate template is the most current certificate template designated for domain controllers and should be the one you deploy to all your domain controllers (2008 or later).
-The autoenrollment feature in Windows enables you to effortlessly replace these domain controller certificates. You can use the following configuration to replace older domain controller certificates with a new certificate using the Kerberos Authentication certificate template.
+The auto-enrollment feature in Windows enables you to effortlessly replace these domain controller certificates. You can use the following configuration to replace older domain controller certificates with a new certificate using the Kerberos Authentication certificate template.
Sign-in a certificate authority or management workstations with _Enterprise Admin_ equivalent credentials.
@@ -73,7 +74,7 @@ The certificate template is configured to supersede all the certificate template
### Enrollment Agent certificate template
-Active Directory Federation Server used for Windows Hello for Business certificate enrollment performs its own certificate lifecycle management. Once the registration authority is configured with the proper certificate template, the AD FS server attempts to enroll the certificate on the first certificate request or when the service first starts.
+Active Directory Federation Server used for Windows Hello for Business certificate enrollment performs its own certificate life-cycle management. Once the registration authority is configured with the proper certificate template, the AD FS server attempts to enroll the certificate on the first certificate request or when the service first starts.
Approximately 60 days prior to enrollment agent certificate's expiration, the AD FS service attempts to renew the certificate until it is successful. If the certificate fails to renew, and the certificate expires, the AD FS server will request a new enrollment agent certificate. You can view the AD FS event logs to determine the status of the enrollment agent certificate.
@@ -96,7 +97,7 @@ Sign-in a certificate authority or management workstations with _Domain Admin_ e
8. On the **Security** tab, click **Add**.
9. Click **Object Types**. Select the **Service Accounts** check box and click **OK**.
10. Type **adfssvc** in the **Enter the object names to select** text box and click **OK**.
-11. Click the **adfssvc** from the **Group or users names** list. In the **Permissions for adfssvc** section, In the **Permissions for adfssvc** section, select the **Allow** check box for the **Enroll** permission. Excluding the **adfssvc** user, clear the **Allow** check box for the **Enroll** and **Autoenroll** permissions for all other items in the **Group or users names** list if the check boxes are not already cleared. Click **OK**.
+11. Click the **adfssvc** from the **Group or users names** list. In the **Permissions for adfssvc** section, select the **Allow** check box for the **Enroll** permission. Excluding the **adfssvc** user, clear the **Allow** check box for the **Enroll** and **Autoenroll** permissions for all other items in the **Group or users names** list if the check boxes are not already cleared. Click **OK**.
12. Close the console.
#### Creating an Enrollment Agent certificate for typical Service Acconts
@@ -128,7 +129,7 @@ Sign-in a certificate authority or management workstations with _Domain Admin eq
**Note:** If you use different template names, you'll need to remember and substitute these names in different portions of the deployment.
6. On the **Cryptography** tab, select **Key Storage Provider** from the **Provider Category** list. Select **RSA** from the **Algorithm name** list. Type **2048** in the **Minimum key size** text box. Select **SHA256** from the **Request hash** list.
7. On the **Extensions** tab, verify the **Application Policies** extension includes **Smart Card Logon**.
-8. On the **Issuance Requirements** tab, select the T**his number of authorized signatures** check box. Type **1** in the text box.
+8. On the **Issuance Requirements** tab, select the **This number of authorized signatures** check box. Type **1** in the text box.
* Select **Application policy** from the **Policy type required in signature**. Select **Certificate Request Agent** from in the **Application policy** list. Select the **Valid existing certificate** option.
9. On the **Subject** tab, select the **Build from this Active Directory information** button if it is not already selected. Select **Fully distinguished name** from the **Subject name format** list if **Fully distinguished name** is not already selected. Select the **User Principal Name (UPN)** check box under **Include this information in alternative subject name**.
10. On the **Request Handling** tab, select the **Renew with same key** check box.
@@ -151,7 +152,18 @@ Publish Templates
The certificate authority may only issue certificates for certificate templates that are published to that certificate authority. If you have more than one certificate authority and you want that certificate authority to issue certificates based on a specific certificate template, then you must publish the certificate template to all certificate authorities that are expected to issue the certificate.
-### Unpublish Superseded Certificate Templates
+#### Publish Certificate Templates to the Certificate Authority
+
+Sign-in to the certificate authority or management workstations with an _Enterprise Admin_ equivalent credentials.
+1. Open the **Certificate Authority** management console.
+2. Expand the parent node from the navigation pane.
+3. Click **Certificate Templates** in the navigation pane.
+4. Right-click the **Certificate Templates** node. Click **New**, and click **Certificate Template** to issue.
+5. In the **Enable Certificates Templates** window, select the **Domain Controller Authentication (Kerberos)**, **WHFB Enrollment Agent** and **WHFB Authentication** templates you created in the previous steps. Click **OK** to publish the selected certificate templates to the certificate authority.
+6. Close the console.
+
+
+#### Unpublish Superseded Certificate Templates
The certificate authority only issues certificates based on published certificate templates. For defense in depth security, it is a good practice to unpublish certificate templates that the certificate authority is not configured to issue. This includes the pre-published certificate template from the role installation and any superseded certificate templates.
@@ -169,9 +181,9 @@ Sign-in to the certificate authority or management workstation with _Enterprise
> [!div class="checklist"]
> * Domain Controller certificate template
> * Configure superseded domain controller certificate templates
-> * Enrollment Agent certifcate template
+> * Enrollment Agent certificate template
> * Windows Hello for Business Authentication certificate template
-> * Mark the certifcate template as Windows Hello for Business sign-in template
+> * Mark the certificate template as Windows Hello for Business sign-in template
> * Publish Certificate templates to certificate authorities
> * Unpublish superseded certificate templates
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-policy.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-policy.md
index 933756d930..9728d0ac98 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-policy.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-policy.md
@@ -9,14 +9,15 @@ ms.pagetype: security, mobile
ms.localizationpriority: medium
author: mikestephens-MS
ms.author: mstephen
-ms.date: 11/08/2017
+ms.date: 08/19/2018
---
# Configure Hybrid Windows Hello for Business: Group Policy
**Applies to**
-- Windows 10
+- Windows 10, version 1703 or later
+- Hybrid deployment
+- Certificate trust
->This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
## Policy Configuration
@@ -25,7 +26,7 @@ Install the Remote Server Administration Tools for Windows 10 on a computer runn
Alternatively, you can create copy the .ADMX and .ADML files from a Windows 10 Creators Edition (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.
-Domain controllers of Windows Hello for Business deployments need one Group Policy setting, which enables automatic certificate enrollment for the newly create domain controller authentication certificate. This policy setting ensures domain controllers (new and existing) autoamtically request and renew the correct domain controller certifcate.
+Domain controllers of Windows Hello for Business deployments need one Group Policy setting, which enables automatic certificate enrollment for the newly create domain controller authentication certificate. This policy setting ensures domain controllers (new and existing) automatically request and renew the correct domain controller certificate.
Domain joined clients of hybrid certificate-based deployments of Windows Hello for Business needs three Group Policy settings:
* Enable Windows Hello for Business
@@ -145,7 +146,7 @@ The default configuration for Windows Hello for Business is to prefer hardware p
You can enable and deploy the **Use a hardware security device** Group Policy Setting to force Windows Hello for Business to only create hardware protected credentials. Users that sign-in from a computer incapable of creating a hardware protected credential do not enroll for Windows Hello for Business.
-Another policy setting becomes available when you enable the **Use a hardware security device** Group Policy setting that enables you to prevent Windows Hello for Business enrollment from using version 1.2 Trusted Platform Modules (TPM). Version 1.2 TPMs typically perform cryptographic operations slower than version 2.0 TPMs and are more unforgiven during anti-hammering and PIN lockout activities. Therefore, some organization may want not want slow sign-in performance and management overhead associated with version 1.2 TPMs. To prevent Windows Hello for Business from using version 1.2 TPMs, simply select the TPM 1.2 check box after you enable the Use a hardware security device Group Policy object.
+Another policy setting becomes available when you enable the **Use a hardware security device** Group Policy setting that enables you to prevent Windows Hello for Business enrollment from using version 1.2 Trusted Platform Modules (TPM). Version 1.2 TPMs typically perform cryptographic operations slower than version 2.0 TPMs and are more unforgiving during anti-hammering and PIN lockout activities. Therefore, some organization may want not want slow sign-in performance and management overhead associated with version 1.2 TPMs. To prevent Windows Hello for Business from using version 1.2 TPMs, simply select the TPM 1.2 check box after you enable the Use a hardware security device Group Policy object.
#### Use biometrics
@@ -171,7 +172,7 @@ Starting with Windows 10, version 1703, the PIN complexity Group Policy settings
## Add users to the Windows Hello for Business Users group
-Users must receive the Windows Hello for Business group policy settings and have the proper permission to enroll for the Wwindows Hello for Business Authentication certificate. You can provide users with these settings and permissions by adding the group used synchronize users to the Windows Hello for Business Users group. Users and groups who are not members of this group will not attempt to enroll for Windows Hello for Business.
+Users must receive the Windows Hello for Business group policy settings and have the proper permission to enroll for the Windows Hello for Business Authentication certificate. You can provide users with these settings and permissions by adding the group used synchronize users to the Windows Hello for Business Users group. Users and groups who are not members of this group will not attempt to enroll for Windows Hello for Business.
### Section Review
> [!div class="checklist"]
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings.md
index fac7f81257..f3f298b684 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings.md
@@ -9,14 +9,15 @@ ms.pagetype: security, mobile
ms.localizationpriority: medium
author: mikestephens-MS
ms.author: mstephen
-ms.date: 10/23/2017
+ms.date: 08/19/2018
---
# Configure Windows Hello for Business
**Applies to**
-- Windows 10
+- Windows 10, version 1703 or later
+- Hybrid deployment
+- Certificate trust
->This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
You're environment is federated and you are ready to configure your hybrid environment for Windows Hello for business using the certificate trust model.
> [!IMPORTANT]
@@ -28,7 +29,7 @@ The configuration for Windows Hello for Business is grouped in four categories.
* [Active Directory Federation Services](hello-hybrid-cert-whfb-settings-adfs.md)
* [Group Policy](hello-hybrid-cert-whfb-settings-policy.md)
-For the most efficent deployment, configure these technologies in order beginning with the Active Directory configuration
+For the most efficient deployment, configure these technologies in order beginning with the Active Directory configuration
> [!div class="step-by-step"]
[Configure Active Directory >](hello-hybrid-cert-whfb-settings-ad.md)
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-new-install.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-new-install.md
index f986fd3e0e..8ec23ffcaa 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-new-install.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-new-install.md
@@ -9,16 +9,17 @@ ms.pagetype: security, mobile
author: mikestephens-MS
ms.author: mstephen
ms.localizationpriority: medium
-ms.date: 03/26/2018
+ms.date: 08/19/2018
---
# Windows Hello for Business Key Trust New Installation
**Applies to**
-- Windows 10
+- Windows 10, version 1703 or later
+- Hybrid deployment
+- Key trust
->This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
-Windows Hello for Business involves configuring distributed technologies that may or may not exist in your current infrastructure. Hybrid key trust deployments of Windows Hello for Business rely on these technolgies
+Windows Hello for Business involves configuring distributed technologies that may or may not exist in your current infrastructure. Hybrid key trust deployments of Windows Hello for Business rely on these technologies
* [Active Directory](#active-directory)
* [Public Key Infrastructure](#public-key-infrastructure)
@@ -26,7 +27,7 @@ Windows Hello for Business involves configuring distributed technologies that ma
* [Active Directory Federation Services](#active-directory-federation-services)
-New installations are considerably more involved than existing implementations because you are building the entire infrastructure. Microsoft recommends you review the new installation baseline to validate your exsting envrionment has all the needed configurations to support your hybrid certificate trust Windows Hello for Business deployment. If your environment meets these needs, you can read the [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md) section to prepare your Windows Hello for Business deployment by configuring directory synchronization.
+New installations are considerably more involved than existing implementations because you are building the entire infrastructure. Microsoft recommends you review the new installation baseline to validate your existing environment has all the needed configurations to support your hybrid certificate trust Windows Hello for Business deployment. If your environment meets these needs, you can read the [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md) section to prepare your Windows Hello for Business deployment by configuring directory synchronization.
The new installation baseline begins with a basic Active Directory deployment and enterprise PKI.
@@ -142,8 +143,8 @@ Alternatively, you can configure Windows Server 2016 Active Directory Federation
## Follow the Windows Hello for Business hybrid key trust deployment guide
-1. [Overview](hello-hybrid-cert-trust.md)
-2. [Prerequistes](hello-hybrid-cert-trust-prereqs.md)
+1. [Overview](hello-hybrid-key-trust.md)
+2. [Prerequistes](hello-hybrid-key-trust-prereqs.md)
3. New Installation Baseline (*You are here*)
4. [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md)
5. [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md)
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-devreg.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-devreg.md
index 45f22f940d..c4ddccad00 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-devreg.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-devreg.md
@@ -9,15 +9,15 @@ ms.pagetype: security, mobile
author: mikestephens-MS
ms.author: mstephen
ms.localizationpriority: medium
-ms.date: 10/20/2017
+ms.date: 08/19/2018
---
# Configure Device Registration for Hybrid key trust Windows Hello for Business
**Applies to**
-- Windows 10
+- Windows 10, version 1703 or later
+- Hybrid deployment
+- Key trust
-
->This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
You are ready to configure device registration for your hybrid environment. Hybrid Windows Hello for Business deployment needs device registration to enable proper device authentication.
@@ -34,7 +34,7 @@ Begin configuring device registration to support Hybrid Windows Hello for Busine
To do this, follow the **Configure device settings** steps under [Setting up Azure AD Join in your organization](https://azure.microsoft.com/en-us/documentation/articles/active-directory-azureadjoin-setup/)
-Next, follow the guidance on the [How to configure hybrid Azure Active Directory joined devices](https://docs.microsoft.com/en-us/azure/active-directory/device-management-hybrid-azuread-joined-devices-setup) page. In the **Configuration steps** section, identify you configuration at the top of the table (either **Windows current and password hash sync** or **Windows current and federation**) and perform only the steps identified with a checkmark.
+Next, follow the guidance on the [How to configure hybrid Azure Active Directory joined devices](https://docs.microsoft.com/en-us/azure/active-directory/device-management-hybrid-azuread-joined-devices-setup) page. In the **Configuration steps** section, identify you configuration at the top of the table (either **Windows current and password hash sync** or **Windows current and federation**) and perform only the steps identified with a check mark.
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-dirsync.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-dirsync.md
index bf7954d10e..041c3f0a23 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-dirsync.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-dirsync.md
@@ -8,29 +8,34 @@ ms.sitesec: library
ms.pagetype: security, mobile
author: mikestephens-MS
ms.author: mstephen
-ms.localizationpriority: medium
-ms.date: 10/20/2017
+localizationpriority: high
+ms.date: 08/19/2018
---
# Configure Directory Synchronization for Hybrid key trust Windows Hello for Business
**Applies to**
-- Windows 10
+- Windows 10, version 1703 or later
+- Hybrid deployment
+- Key trust
->This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
-
-You are ready to configure directory synchronization for your hybrid environment. Hybrid Windows Hello for Business deployment needs both a cloud and an on-premises identity to authenticate and access resources in the cloud or on-premises.
+
+You are ready to configure directory synchronization for your hybrid environment. Hybrid Windows Hello for Business deployment needs both a cloud and an on-premises identity to authenticate and access resources in the cloud or on-premises.
## Deploy Azure AD Connect
-Next, you need to synchronizes the on-premises Active Directory with Azure Active Directory. To do this, first review the [Integrating on-prem directories with Azure Active Directory](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect) and [hardware and prerequisites](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-prerequisites) needed and then [download the software](https://go.microsoft.com/fwlink/?LinkId=615771).
+Next, you need to synchronizes the on-premises Active Directory with Azure Active Directory. To do this, first review the [Integrating on-prem directories with Azure Active Directory](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect) and [hardware and prerequisites](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-prerequisites) needed and then [download the software](http://go.microsoft.com/fwlink/?LinkId=615771).
-
+
+> [!NOTE]
+> If you installed Azure AD Connect prior to upgrading the schema, you will need to re-run the Azure AD Connect installation and refresh the on-premises AD schema to ensure the synchronization rule for msDS-KeyCredentialLink is configured.
+
+
## Follow the Windows Hello for Business hybrid key trust deployment guide
-1. [Overview](hello-hybrid-cert-trust.md)
-2. [Prerequistes](hello-hybrid-cert-trust-prereqs.md)
-3. [New Installation Baseline](hello-hybrid-cert-new-install.md)
+1. [Overview](hello-hybrid-key-trust.md)
+2. [Prerequistes](hello-hybrid-key-trust-prereqs.md)
+3. [New Installation Baseline](hello-hybrid-key-new-install.md)
4. Configure Directory Synchronization (*You are here*)
5. [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md)
6. [Configure Windows Hello for Business settings](hello-hybrid-key-whfb-settings.md)
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-prereqs.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-prereqs.md
index 59977cb224..00a4885e90 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-prereqs.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-prereqs.md
@@ -8,22 +8,22 @@ ms.sitesec: library
ms.pagetype: security, mobile
author: mikestephens-MS
ms.author: mstephen
-ms.localizationpriority: medium
-ms.date: 11/17/2017
+localizationpriority: high
+ms.date: 08/20/2018
---
# Hybrid Key trust Windows Hello for Business Prerequisites
**Applies to**
-- Windows 10
+- Windows 10, version 1703 or later
+- Hybrid deployment
+- Key trust
->This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
-
Hybrid environments are distributed systems that enable organizations to use on-premises and Azure-based identities and resources. Windows Hello for Business uses the existing distributed system as a foundation on which organizations can provide two-factor authentication that provides a single sign-in like experience to modern resources.
The distributed systems on which these technologies were built involved several pieces of on-premises and cloud infrastructure. High-level pieces of the infrastructure include:
* [Directories](#directories)
-* [Public Key Infrastructure](#public-key-infrastructure)
+* [Public Key Infrastucture](#public-key-infastructure)
* [Directory Synchronization](#directory-synchronization)
* [Federation](#federation)
* [MultiFactor Authetication](#multifactor-authentication)
@@ -58,7 +58,7 @@ The minimum required enterprise certificate authority that can be used with Wind
> [!IMPORTANT]
> For Azure AD joined device to authenticate to and use on-premises resources, ensure you:
-> * Install the root certificate authority certificate for your organization in the user's trusted root certificate store.
+> * Install the root certificate authority certificate for your organization in the user's trusted root certifcate store.
> * Publish your certificate revocation list to a location that is available to Azure AD joined devices, such as a web-based url.
### Section Review
@@ -91,15 +91,15 @@ You can deploy Windows Hello for Business key trust in non-federated and federat
## Multifactor Authentication ##
-Windows Hello for Business is a strong, two-factor credential the helps organizations reduce their dependency on passwords. The provisioning process lets a user enroll in Windows Hello for Business using their username and password as one factor, but needs a second factor of authentication.
+Windows Hello for Business is a strong, two-factor credential the helps organizations reduce their dependency on passwords. The provisioning process lets a user enroll in Windows Hello for Business using their user name and password as one factor, but needs a second factor of authentication.
-Hybrid Windows Hello for Business deployments can use Azure’s Multifactor Authentication service or they can use multifactor authentication provides by Windows Server 2012 R2 or later Active Directory Federation Services, which includes an adapter model that enables third parties to integrate their multifactor authentication into AD FS.
+Hybrid Windows Hello for Business deployments can use Azure’s Multi-factor Authentication service or they can use multi-factor authentication provides by Windows Server 2012 R2 or later Active Directory Federation Services, which includes an adapter model that enables third parties to integrate their multi-factor authentication into AD FS.
### Section Review
> [!div class="checklist"]
> * Azure MFA Service
> * Windows Server 2016 AD FS and Azure (optional, if federated)
-> * Windows Server 2016 AD FS and third-party MFA Adapter (optional, if federated)
+> * Windows Server 2016 AD FS and third party MFA Adapter (optional, if federated)
@@ -114,9 +114,9 @@ Organizations wanting to deploy hybrid key trust need their domain joined device
### Next Steps ###
-Follow the Windows Hello for Business hybrid key trust deployment guide. For proof-of-concepts, labs, and new installations, choose the **New Installation Baseline**.
+Follow the Windows Hello for Business hybrid key trust deployment guide. For proof-of-concepts, labs, and new installations, choose the **New Installation Basline**.
-For environments transitioning from on-premises to hybrid, start with **Configure Azure Directory Synchronization**.
+For environments transitioning from on-premises to hybrid, start with **Configure Azure Directory Syncrhonization**.
For federated and non-federated environments, start with **Configure Windows Hello for Business settings**.
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
index 397e878d3c..8fb2bf361a 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
@@ -9,14 +9,14 @@ ms.pagetype: security, mobile
author: mikestephens-MS
ms.author: mstephen
ms.localizationpriority: medium
-ms.date: 10/20/2017
+ms.date: 08/20/2018
---
# Hybrid Azure AD joined Key Trust Deployment
**Applies to**
-- Windows 10
-
->This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
+- Windows 10, version 1703 or later
+- Hybrid deployment
+- Key trust
Windows Hello for Business replaces username and password sign-in to Windows with strong user authentication based on asymmetric key pair. The following deployment guide provides the information needed to successfully deploy Windows Hello for Business in a hybrid key trust scenario.
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-provision.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-provision.md
index ce0710525a..fecb1059be 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-provision.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-provision.md
@@ -9,16 +9,16 @@ ms.pagetype: security, mobile
author: mikestephens-MS
ms.author: mstephen
ms.localizationpriority: medium
-ms.date: 10/20/2017
+ms.date: 08/20/2018
---
# Hybrid Windows Hello for Business Provisioning
**Applies to**
-- Windows 10
+- Windows 10, version 1703 or later
+- Hybrid deployment
+- Key trust
->This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
-
## Provisioning
The Windows Hello for Business provisioning begins immediately after the user has signed in, after the user profile is loaded, but before the user receives their desktop. Windows only launches the provisioning experience if all the prerequisite checks pass. You can determine the status of the prerequisite checks by viewing the **User Device Registration** in the **Event Viewer** under **Applications and Services Logs\Microsoft\Windows**.
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-ad.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-ad.md
index 8b9848f45c..c2821a19f1 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-ad.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-ad.md
@@ -9,21 +9,22 @@ ms.pagetype: security, mobile
ms.localizationpriority: medium
author: mikestephens-MS
ms.author: mstephen
-ms.date: 10/23/2017
+ms.date: 08/20/2018
---
# Configuring Hybrid key trust Windows Hello for Business: Active Directory
**Applies to**
-- Windows 10
+- Windows 10, version 1703 or later
+- Hybrid deployment
+- Key trust
->This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
Configure the appropriate security groups to efficiently deploy Windows Hello for Business to users.
### Creating Security Groups
-Windows Hello for Business uses a security group to simplify the deployment and managment.
+Windows Hello for Business uses a security group to simplify the deployment and management.
#### Create the Windows Hello for Business Users Security Group
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-dir-sync.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-dir-sync.md
index 2059a8d2ff..4679d66c11 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-dir-sync.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-dir-sync.md
@@ -9,14 +9,15 @@ ms.pagetype: security, mobile
ms.localizationpriority: medium
author: mikestephens-MS
ms.author: mstephen
-ms.date: 10/23/2017
+ms.date: 08/19/2018
---
# Configure Hybrid Windows Hello for Business: Directory Synchronization
**Applies to**
-- Windows 10
+- Windows 10, version 1703 or later
+- Hybrid deployment
+- Key trust
->This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
## Directory Syncrhonization
@@ -54,5 +55,5 @@ Sign-in a domain controller or management workstation with _Domain Admin_ equiva
3. [New Installation Baseline](hello-hybrid-key-new-install.md)
4. [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md)
5. [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md)
-6. Configure Windows Hello for Business settings: Directory Syncrhonization (*You are here*)
+6. Configure Windows Hello for Business settings: Directory Synchronization (*You are here*)
7. [Sign-in and Provision](hello-hybrid-key-whfb-provision.md)
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-pki.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-pki.md
index 7fa866d652..21befdf74e 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-pki.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-pki.md
@@ -9,15 +9,16 @@ ms.pagetype: security, mobile
ms.localizationpriority: medium
author: mikestephens-MS
ms.author: mstephen
-ms.date: 10/23/2017
+ms.date: 08/19/2018
---
# Configure Hybrid Windows Hello for Business: Public Key Infrastructure
**Applies to**
-- Windows 10
+- Windows 10, version 1703 or later
+- Hybrid Deployment
+- Key trust
->This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
Windows Hello for Business deployments rely on certificates. Hybrid deployments uses publicly issued server authentication certificates to validate the name of the server to which they are connecting and to encrypt the data that flows them and the client computer.
@@ -42,7 +43,7 @@ Sign-in a certificate authority or management workstations with _Domain Admin_ e
1. Open the **Certificate Authority** management console.
2. Right-click **Certificate Templates** and click **Manage**.
3. In the **Certificate Template Console**, right-click the **Kerberos Authentication** template in the details pane and click **Duplicate Template**.
-4. On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Authority** list. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Recipient** list.
+4. On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2008 R2** from the **Certification Authority** list. Select **Windows 7.Server 2008 R2** from the **Certification Recipient** list.
5. On the **General** tab, type **Domain Controller Authentication (Kerberos)** in Template display name. Adjust the validity and renewal period to meet your enterprise's needs.
**Note**If you use different template names, you'll need to remember and substitute these names in different portions of the lab.
6. On the **Subject** tab, select the **Build from this Active Directory information** button if it is not already selected. Select **None** from the **Subject name format** list. Select **DNS name** from the **Include this information in alternate subject** list. Clear all other items.
@@ -76,6 +77,17 @@ The certificate template is configured to supersede all the certificate template
The certificate authority may only issue certificates for certificate templates that are published to that certificate authority. If you have more than one certificate authority and you want that certificate authority to issue certificates based on a specific certificate template, then you must publish the certificate template to all certificate authorities that are expected to issue the certificate.
+Sign-in to the certificate authority or management workstations with an _enterprise administrator_ equivalent credentials.
+
+1. Open the **Certificate Authority** management console.
+2. Expand the parent node from the navigation pane.
+3. Click **Certificate Templates** in the navigation pane.
+4. Right-click the **Certificate Templates** node. Click **New**, and click **Certificate Template** to issue.
+5. In the **Enable Certificates Templates** window, select the **Domain Controller Authentication (Kerberos)** template you created in the previous steps. Click **OK** to publish the selected certificate templates to the certificate authority.
+6. If you published the **Domain Controller Authentication (Kerberos)** certificate template, then you should unpublish the certificate templates you included in the superseded templates list.
+ * To unpublish a certificate template, right-click the certificate template you want to unpublish in the details pane of the Certificate Authority console and select **Delete**. Click **Yes** to confirm the operation.
+7. Close the console.
+
### Unpublish Superseded Certificate Templates
The certificate authority only issues certificates based on published certificate templates. For defense in depth security, it is a good practice to unpublish certificate templates that the certificate authority is not configured to issue. This includes the pre-published certificate template from the role installation and any superseded certificate templates.
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-policy.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-policy.md
index 4ddb7eed9d..1a0b808710 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-policy.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-policy.md
@@ -6,17 +6,18 @@ ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security, mobile
-ms.localizationpriority: medium
+localizationpriority: high
author: mikestephens-MS
ms.author: mstephen
-ms.date: 10/23/2017
+ms.date: 08/20/2018
---
# Configure Hybrid Windows Hello for Business: Group Policy
**Applies to**
-- Windows 10
+- Windows 10, version 1703 or later
+- Hybrid deployment
+- Key trust
->This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
## Policy Configuration
@@ -36,7 +37,7 @@ Domain controllers automatically request a certificate from the *Domain Controll
To continue automatic enrollment and renewal of domain controller certificates that understand newer certificate template and superseded certificate template configurations, create and configure a Group Policy object for automatic certificate enrollment and link the Group Policy object to the Domain Controllers OU.
-#### Create a Domain Controller Automatic Certificate Enrollment Group Policy object
+#### Create a Domain Controller Automatic Certifiacte Enrollment Group Policy object
Sign-in a domain controller or management workstations with _Domain Admin_ equivalent credentials.
@@ -47,7 +48,7 @@ Sign-in a domain controller or management workstations with _Domain Admin_ equiv
5. Right-click the **Domain Controller Auto Certificate Enrollment** Group Policy object and click **Edit**.
6. In the navigation pane, expand **Policies** under **Computer Configuration**.
7. Expand **Windows Settings**, **Security Settings**, and click **Public Key Policies**.
-8. In the details pane, right-click **Certificate Services Client - Auto-Enrollment** and select **Properties**.
+8. In the details pane, right-click **Certificate Services Client � Auto-Enrollment** and select **Properties**.
9. Select **Enabled** from the **Configuration Model** list.
10. Select the **Renew expired certificates**, **update pending certificates**, and **remove revoked certificates** check box.
11. Select the **Update certificates that use certificate templates** check box.
@@ -58,7 +59,7 @@ Sign-in a domain controller or management workstations with _Domain Admin_ equiv
Sign-in a domain controller or management workstations with _Domain Admin_ equivalent credentials.
1. Start the **Group Policy Management Console** (gpmc.msc)
-2. In the navigation pane, expand the domain and expand the node that has your Active Directory domain name. Right-click the **Domain Controllers** organizational unit and click **Link an existing GPO**
+2. In the navigation pane, expand the domain and expand the node that has your Active Directory domain name. Right-click the **Domain Controllers** organizational unit and click **Link an existing GPO�**
3. In the **Select GPO** dialog box, select **Domain Controller Auto Certificate Enrollment** or the name of the domain controller certificate enrollment Group Policy object you previously created and click **OK**.
### Windows Hello for Business Group Policy
@@ -67,7 +68,7 @@ The Windows Hello for Business Group Policy object delivers the correct Group Po
#### Enable Windows Hello for Business
-The Enable Windows Hello for Business Group Policy setting is the configuration needed for Windows to determine if a user should attempt to enroll for Windows Hello for Business. A user will only attempt enrollment if this policy setting is configured to enabled.
+The Enable Windows Hello for Business Group Policy setting is the configuration needed for Windows to determine if a user should be attempt to enroll for Windows Hello for Business. A user will only attempt enrollment if this policy setting is configured to enabled.
You can configure the Enable Windows Hello for Business Group Policy setting for computer or users. Deploying this policy setting to computers results in ALL users that sign-in that computer to attempt a Windows Hello for Business enrollment. Deploying this policy setting to a user results in only that user attempting a Windows Hello for Business enrollment. Additionally, you can deploy the policy setting to a group of users so only those users attempt a Windows Hello for Business enrollment. If both user and computer policy settings are deployed, the user policy setting has precedence.
@@ -103,13 +104,13 @@ The application of the Windows Hello for Business Group Policy object uses secur
2. In the navigation pane, expand the domain and right-click the node that has your Active Directory domain name and click **Link an existing GPO**
3. In the **Select GPO** dialog box, select **Enable Windows Hello for Business** or the name of the Windows Hello for Business Group Policy object you previously created and click **OK**.
-Just to reassure, linking the **Windows Hello for Business** Group Policy object to the domain ensures the Group Policy object is in scope for all domain users. However, not all users will have the policy settings applied to them. Only users who are members of the Windows Hello for Business group receive the policy settings. All other users ignore the Group Policy object.
+Just to reassure, linking the **Windows Hello for Business** Group Policy object to the domain ensures the Group Policy object is in scope for all domain users. However, not all users will have the policy settings applied to them. Only users who are members of the Windows Hello for Business group receive the policy settings. All others users ignore the Group Policy object.
## Other Related Group Policy settings
### Windows Hello for Business
-There are other Windows Hello for Business policy settings you can configure to manage your Windows Hello for Business deployment. These policy settings are computer-based policy setting so they are applicable to any user that sign-in from a computer with these policy settings.
+There are other Windows Hello for Business policy settings you can configure to manage your Windows Hello for Business deployment. These policy settings are computer-based policy setting; so they are applicable to any user that sign-in from a computer with these policy settings.
#### Use a hardware security device
@@ -117,7 +118,7 @@ The default configuration for Windows Hello for Business is to prefer hardware p
You can enable and deploy the **Use a hardware security device** Group Policy Setting to force Windows Hello for Business to only create hardware protected credentials. Users that sign-in from a computer incapable of creating a hardware protected credential do not enroll for Windows Hello for Business.
-Another policy setting becomes available when you enable the **Use a hardware security device** Group Policy setting that enables you to prevent Windows Hello for Business enrollment from using version 1.2 Trusted Platform Modules (TPM). Version 1.2 TPMs typically perform cryptographic operations slower than version 2.0 TPMs and are more unforgiven during anti-hammering and PIN lockout activities. Therefore, some organization may not want slow sign-in performance and management overhead associated with version 1.2 TPMs. To prevent Windows Hello for Business from using version 1.2 TPMs, simply select the TPM 1.2 check box after you enable the Use a hardware security device Group Policy object.
+Another policy setting becomes available when you enable the **Use a hardware security device** Group Policy setting that enables you to prevent Windows Hello for Business enrollment from using version 1.2 Trusted Platform Modules (TPM). Version 1.2 TPMs typically perform cryptographic operations slower than version 2.0 TPMs and are more unforgiving during anti-hammering and PIN lockout activities. Therefore, some organization may want not want slow sign-in performance and management overhead associated with version 1.2 TPMs. To prevent Windows Hello for Business from using version 1.2 TPMs, simply select the TPM 1.2 check box after you enable the Use a hardware security device Group Policy object.
#### Use biometrics
@@ -144,7 +145,7 @@ Windows 10 provides eight PIN Complexity Group Policy settings that give you gra
## Add users to the Windows Hello for Business Users group
-Users must receive the Windows Hello for Business group policy settings and have the proper permission to provision Windows Hello for Business. You can provide users with these settings and permissions by adding the users or groups to the **Windows Hello for Business Users** group. Users and groups who are not members of this group will not attempt to enroll for Windows Hello for Business.
+Users must receive the Windows Hello for Business group policy settings and have the proper permission to provision Windows Hello for Business . You can provide users with these settings and permissions by adding the users or groups to the **Windows Hello for Business Users** group. Users and groups who are not members of this group will not attempt to enroll for Windows Hello for Business.
### Section Review
> [!div class="checklist"]
@@ -163,9 +164,9 @@ Users must receive the Windows Hello for Business group policy settings and have
## Follow the Windows Hello for Business hybrid key trust deployment guide
1. [Overview](hello-hybrid-cert-trust.md)
-2. [Prerequisites](hello-hybrid-key-trust-prereqs.md)
+2. [Prerequistes](hello-hybrid-key-trust-prereqs.md)
3. [New Installation Baseline](hello-hybrid-key-new-install.md)
4. [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md)
5. [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md)
6. Configure Windows Hello for Business policy settings (*You are here*)
-7. [Sign-in and Provision](hello-hybrid-key-whfb-provision.md)
+7. [Sign-in and Provision](hello-hybrid-key-whfb-provision.md)
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings.md
index 05697bb83f..c28c97dce0 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings.md
@@ -9,14 +9,15 @@ ms.pagetype: security, mobile
ms.localizationpriority: medium
author: mikestephens-MS
ms.author: mstephen
-ms.date: 10/23/2017
+ms.date: 08/19/2018
---
# Configure Hybrid Windows Hello for Business key trust settings
**Applies to**
-- Windows 10
+- Windows 10, version 1703 or later
+- Hybrid deployment
+- Key trust
->This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
You are ready to configure your hybrid key trust environment for Windows Hello for Business.
@@ -29,7 +30,7 @@ The configuration for Windows Hello for Business is grouped in four categories.
* [Public Key Infrastructure](hello-hybrid-key-whfb-settings-pki.md)
* [Group Policy](hello-hybrid-key-whfb-settings-policy.md)
-For the most efficent deployment, configure these technologies in order beginning with the Active Directory configuration
+For the most efficient deployment, configure these technologies in order beginning with the Active Directory configuration
> [!div class="step-by-step"]
[Configure Active Directory >](hello-hybrid-key-whfb-settings-ad.md)
diff --git a/windows/security/identity-protection/hello-for-business/hello-identity-verification.md b/windows/security/identity-protection/hello-for-business/hello-identity-verification.md
index 3a148d65c9..34a61661eb 100644
--- a/windows/security/identity-protection/hello-for-business/hello-identity-verification.md
+++ b/windows/security/identity-protection/hello-for-business/hello-identity-verification.md
@@ -9,8 +9,8 @@ ms.sitesec: library
ms.pagetype: security, mobile
author: mikestephens-MS
ms.author: mstephen
-ms.localizationpriority: medium
-ms.date: 03/26/2018
+localizationpriority: high
+ms.date: 05/05/2018
---
# Windows Hello for Business
@@ -34,7 +34,7 @@ Windows Hello addresses the following problems with passwords:
* Windows 10, version 1511 or later
* Microsoft Azure Account
* Azure Active Directory
-* Azure Multifactor authentication
+* Azure Multi-factor authentication
* Modern Management (Intune or supported third-party MDM), *optional*
* Azure AD Premium subscription - *optional*, needed for automatic MDM enrollment when the device joins Azure Active Directory
@@ -53,7 +53,7 @@ The table shows the minimum requirements for each deployment.
| Azure Account | Azure Account | Azure Account | Azure Account |
| Azure Active Directory | Azure Active Directory | Azure Active Directory | Azure Active Directory |
| Azure AD Connect | Azure AD Connect | Azure AD Connect | Azure AD Connect |
-| Azure AD Premium, optional | Azure AD Premium, needed for device writeback | Azure AD Premium, optional for automatic MDM enrollment | Azure AD Premium, optional for automatic MDM enrollment |
+| Azure AD Premium, optional | Azure AD Premium, needed for device write-back | Azure AD Premium, optional for automatic MDM enrollment | Azure AD Premium, optional for automatic MDM enrollment |
### On-premises Deployments
The table shows the minimum requirements for each deployment.
@@ -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, orAD FS with 3rd Party MFA Adapter | AD FS with Azure MFA Server, orAD 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]
-
-
-
-> [!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)
-
diff --git a/windows/security/identity-protection/hello-for-business/hello-key-trust-adfs.md b/windows/security/identity-protection/hello-for-business/hello-key-trust-adfs.md
index 03cf30c20c..125313997c 100644
--- a/windows/security/identity-protection/hello-for-business/hello-key-trust-adfs.md
+++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-adfs.md
@@ -9,16 +9,17 @@ ms.pagetype: security, mobile
author: mikestephens-MS
ms.author: mstephen
ms.localizationpriority: medium
-ms.date: 03/26/2018
+ms.date: 08/19/2018
---
# Prepare and Deploy Windows Server 2016 Active Directory Federation Services
**Applies to**
-- Windows 10
+- Windows 10, version 1703 or later
+- On-premises deployment
+- Key trust
-> This guide only applies to Windows 10, version 1703 or higher.
-Windows Hello for Business works exclusively with the Active Directory Federation Service role included with Windows Server 2016 and requires an additional server update. The on-prem key trust deployment uses Active Directory Federation Services roles for key registration and device registration.
+Windows Hello for Business works exclusively with the Active Directory Federation Service role included with Windows Server 2016 and requires an additional server update. The on-premises key trust deployment uses Active Directory Federation Services roles for key registration and device registration.
The following guidance describes deploying a new instance of Active Directory Federation Services 2016 using the Windows Information Database as the configuration database, which is ideal for environments with no more than 30 federation servers and no more than 100 relying party trusts.
@@ -59,7 +60,7 @@ Be sure to enroll or import the certificate into the AD FS server’s computer c
### Internal Server Authentication Certificate Enrollment
-Sign-in the federation server with domain admin equivalent credentials.
+Sign-in the federation server with domain administrator equivalent credentials.
1. Start the Local Computer **Certificate Manager** (certlm.msc).
2. Expand the **Personal** node in the navigation pane.
3. Right-click **Personal**. Select **All Tasks** and **Request New Certificate**.
@@ -134,7 +135,7 @@ Sign-in a domain controller or management workstation with _Domain Admin_ equiva
1. Open **Active Directory Users and Computers**.
2. Right-click the **Users** container, Click **New**. Click **User**.
3. In the **New Object – User** window, type **adfssvc** in the **Full name** text box. Type **adfssvc** in the **User logon name** text box. Click **Next**.
-4. Enter and confirm a password for the **adfssvc** user. Clear the **User must change password at next logon** checkbox.
+4. Enter and confirm a password for the **adfssvc** user. Clear the **User must change password at next logon** check box.
5. Click **Next** and then click **Finish**.
## Configure the Active Directory Federation Service Role
@@ -253,7 +254,7 @@ Sign-in the federation server with _Enterprise Admin_ equivalent credentials.
2. Click **Manage** and then click **Add Roles and Features**.
3. Click **Next** On the **Before you begin** page.
4. On the **Select installation type** page, select **Role-based or feature-based installation** and click **Next**.
-5. On the **Select destination server** page, chosoe **Select a server from the server pool**. Select the federation server from the **Server Pool** list. Click **Next**.
+5. On the **Select destination server** page, choose **Select a server from the server pool**. Select the federation server from the **Server Pool** list. Click **Next**.
6. On the **Select server roles** page, click **Next**.
7. Select **Network Load Balancing** on the **Select features** page.
8. Click **Install** to start the feature installation
@@ -287,7 +288,7 @@ Sign-in a node of the federation farm with _Admin_ equivalent credentials.
## Configure DNS for Device Registration
-Sign-in the domain controller or administrative workstation with Domain Admin equivalent credentials. You’ll need the Federation service name to complete this task. You can view the federation service name by clicking **Edit Federation Service Properties** from the **Action** pan of the **AD FS** management console, or by using `(Get-AdfsProperties).Hostname.` (PowerShell) on the AD FS server.
+Sign-in the domain controller or administrative workstation with domain administrator equivalent credentials. You’ll need the Federation service name to complete this task. You can view the federation service name by clicking **Edit Federation Service Properties** from the **Action** pan of the **AD FS** management console, or by using `(Get-AdfsProperties).Hostname.` (PowerShell) on the AD FS server.
1. Open the **DNS Management** console.
2. In the navigation pane, expand the domain controller name node and **Forward Lookup Zones**.
3. In the navigation pane, select the node that has the name of your internal Active Directory domain name.
diff --git a/windows/security/identity-protection/hello-for-business/hello-key-trust-deploy-mfa.md b/windows/security/identity-protection/hello-for-business/hello-key-trust-deploy-mfa.md
index cd5414603f..67a8061c4d 100644
--- a/windows/security/identity-protection/hello-for-business/hello-key-trust-deploy-mfa.md
+++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-deploy-mfa.md
@@ -9,14 +9,15 @@ ms.pagetype: security, mobile
author: mikestephens-MS
ms.author: mstephen
ms.localizationpriority: medium
-ms.date: 10/10/2017
+ms.date: 08/19/2018
---
# Configure or Deploy Multifactor Authentication Services
**Applies to**
-- Windows 10
+- Windows 10, version 1703 or later
+- On-premises deployment
+- Key trust
-> This guide only applies to Windows 10, version 1703 or higher.
On-premises deployments must use the On-premises Azure MFA Server using the AD FS adapter model Optionally, you can use a third-party MFA server that provides an AD FS Multifactor authentication adapter.
@@ -29,7 +30,7 @@ The Azure MFA Server and User Portal servers have several perquisites and must h
### Primary MFA Server
-The Azure MFA server uses a primary and secondary replication model for its configuration database. The primary Azure MFA server hosts the writeable partition of the configuration database. All secondary Azure MFA servers hosts read-only partitions of the configuration database. All production environment should deploy a minimum of two MFA Servers.
+The Azure MFA server uses a primary and secondary replication model for its configuration database. The primary Azure MFA server hosts the writable partition of the configuration database. All secondary Azure MFA servers hosts read-only partitions of the configuration database. All production environment should deploy a minimum of two MFA Servers.
For this documentation, the primary MFA uses the name **mf*a*** or **mfa.corp.contoso.com**. All secondary servers use the name **mfa*n*** or **mfa*n*.corp.contoso.com**, where *n* is the number of the deployed MFA server.
@@ -54,7 +55,7 @@ A server authentication certificate should appear in the computer’s Personal c
#### Install the Web Server Role
-The Azure MFA server does not require the Web Server role, however, User Portal and the optional Mobile App server communicate with the MFA server database using the MFA Web Services SDK. The MFA Web Services SDK uses the Web Server role.
+The Azure MFA server does not require the Web Server role, however, User Portal and the optional Mobile Application server communicate with the MFA server database using the MFA Web Services SDK. The MFA Web Services SDK uses the Web Server role.
To install the Web Server (IIS) role, please follow [Installing IIS 7 on Windows Server 2008 or Windows Server 2008 R2](https://docs.microsoft.com/iis/install/installing-iis-7/installing-iis-7-and-above-on-windows-server-2008-or-windows-server-2008-r2) or [Installing IIS 8.5 on Windows Server 2012 R2](https://docs.microsoft.com/iis/install/installing-iis-85/installing-iis-85-on-windows-server-2012-r2) depending on the host Operating System you're going to use.
@@ -89,7 +90,7 @@ Sign in the primary MFA server with _administrator_ equivalent credentials.
#### Configure the Web Service’s Security
-The Azure MFA Server service runs in the security context of the Local System. The MFA User Portal gets its user and configuration information from the Azure MFA server using the MFA Web Services. Access control to the information is gated by membership to the Phonefactor Admins security group. You need to configure the Web Service’s security to ensure the User Portal and the Mobile App servers can securely communicate to the Azure MFA Server. Also, all User Portal server administrators must be included in the Phonefactor Admins security group.
+The Azure MFA Server service runs in the security context of the Local System. The MFA User Portal gets its user and configuration information from the Azure MFA server using the MFA Web Services. Access control to the information is gated by membership to the Phonefactor Admins security group. You need to configure the Web Service’s security to ensure the User Portal and the Mobile Application servers can securely communicate to the Azure MFA Server. Also, all User Portal server administrators must be included in the Phonefactor Admins security group.
Sign in the domain controller with _domain administrator_ equivalent credentials.
@@ -160,7 +161,7 @@ A server authentication certificate should appear in the computer’s Personal c
#### Install the Web Server Role
-To do this, please follow the instructions mentioned in the previous [Install the Web Server Role](#install-the-web-server-role) section. However, do **not** install Security > Basic Authentication. The user portal server does not requiret this.
+To do this, please follow the instructions mentioned in the previous [Install the Web Server Role](#install-the-web-server-role) section. However, do **not** install Security > Basic Authentication. The user portal server does not require this.
#### Update the Server
@@ -172,7 +173,7 @@ To do this, please follow the instructions mentioned in the previous [Configure
#### Create WebServices SDK user account
-The User Portal and Mobile App web services need to communicate with the configuration database hosted on the primary MFA server. These services use a user account to communicate to authenticate to the primary MFA server. You can think of the WebServices SDK account as a service account used by other servers to access the WebServices SDK on the primary MFA server.
+The User Portal and Mobile Application web services need to communicate with the configuration database hosted on the primary MFA server. These services use a user account to communicate to authenticate to the primary MFA server. You can think of the WebServices SDK account as a service account used by other servers to access the WebServices SDK on the primary MFA server.
1. Open **Active Directory Users and Computers**.
2. In the navigation pane, expand the node with the organization’s Active Directory domain name. Right-click the **Users** container, select **New**, and select **User**.
@@ -234,12 +235,12 @@ Sign-in the primary MFA server with MFA _administrator_ equivalent credentials.
2. Click **Company Settings**.
3. On the **General** Tab, select **Fail Authentication** from the **When internet is not accessible** list.
4. In **User defaults**, select **Phone Call** or **Text Message**
- **Note:** You can use mobile app; however, the configuration is beyond the scope of this document. Read [Getting started the MFA Server Mobile App Web Service](https://docs.microsoft.com/azure/multi-factor-authentication/multi-factor-authentication-get-started-server-webservice) to configure and use mobile app multi-factor authentication or the Install User Portal topic in the Multi-Factor Server help.
+ **Note:** You can use mobile application; however, the configuration is beyond the scope of this document. Read [Getting started the MFA Server Mobile App Web Service](https://docs.microsoft.com/azure/multi-factor-authentication/multi-factor-authentication-get-started-server-webservice) to configure and use mobile application multi-factor authentication or the Install User Portal topic in the Multi-Factor Server help.
5. Select **Enable Global Services** if you want to allow Multi-Factor Authentications to be made to telephone numbers in rate zones that have an associated charge.
6. Clear the **User can change phone** check box to prevent users from changing their phone during the Multi-Factor Authentication call or in the User Portal. A consistent configuration is for users to change their phone numbers in Active Directory and let those changes synchronize to the multi-factor server using the Synchronization features in Directory Integration.
7. Select **Fail Authentication** from the **When user is disabled** list. Users should provision their account through the user portal.
8. Select the appropriate language from the **Phone call language**, **Text message language**, **Mobile app language**, and **OATH token language** lists.
-9. Under default PIN rules, Select the User can change PIN checkbox to enable users to change their PIN during multi-factor authentication and through the user portal.
+9. Under default PIN rules, Select the User can change PIN check box to enable users to change their PIN during multi-factor authentication and through the user portal.
10. Configure the minimum length for the PIN.
11. Select the **Prevent weak PINs** check box to reject weak PINs. A weak PIN is any PIN that could be easily guessed by a hacker: 3 sequential digits, 3 repeating digits, or any 4 digit subset of user phone number are not allowed. If you clear this box, then there are no restrictions on PIN format. For example: User tries to reset PIN to 1235 and is rejected because it's a weak PIN. User will be prompted to enter a valid PIN.
12. Select the **Expiration days** check box if you want to expire PINs. If enabled, provide a numeric value representing the number of days the PIN is valid.
@@ -255,9 +256,9 @@ Now that you have imported or synchronized with your Azure Multi-Factor Authenti
With the Azure Multi-Factor Authentication Server there are various ways to configure your users for using multi-factor authentication. For instance, if you know the users’ phone numbers or were able to import the phone numbers into the Azure Multi-Factor Authentication Server from their company’s directory, the email will let users know that they have been configured to use Azure Multi-Factor Authentication, provide some instructions on using Azure Multi-Factor Authentication and inform the user of the phone number they will receive their authentications on.
-The content of the email will vary depending on the method of authentication that has been set for the user (e.g. phone call, SMS, mobile app). For example, if the user is required to use a PIN when they authenticate, the email will tell them what their initial PIN has been set to. Users are usually required to change their PIN during their first authentication.
+The content of the email will vary depending on the method of authentication that has been set for the user (e.g. phone call, SMS, mobile application). For example, if the user is required to use a PIN when they authenticate, the email will tell them what their initial PIN has been set to. Users are usually required to change their PIN during their first authentication.
-If users’ phone numbers have not been configured or imported into the Azure Multi-Factor Authentication Server, or users are pre-configured to use the mobile app for authentication, you can send them an email that lets them know that they have been configured to use Azure Multi-Factor Authentication and it will direct them to complete their account enrollment through the Azure Multi-Factor Authentication User Portal. A hyperlink will be included that the user clicks on to access the User Portal. When the user clicks on the hyperlink, their web browser will open and take them to their company’s Azure Multi-Factor Authentication User Portal.
+If users’ phone numbers have not been configured or imported into the Azure Multi-Factor Authentication Server, or users are pre-configured to use the mobile application for authentication, you can send them an email that lets them know that they have been configured to use Azure Multi-Factor Authentication and it will direct them to complete their account enrollment through the Azure Multi-Factor Authentication User Portal. A hyperlink will be included that the user clicks on to access the User Portal. When the user clicks on the hyperlink, their web browser will open and take them to their company’s Azure Multi-Factor Authentication User Portal.
#### Settings
@@ -304,7 +305,7 @@ Sign in the primary MFA server with _MFA administrator_ equivalent credentials.
2. From the **Multi-Factor Authentication Server** window, click the **Directory Integration** icon.
3. Click the **Synchronization** tab.
4. Select **Use Active Directory**.
-5. Select **Include trusted domains** to have the Multi-Factor Authentication Server attempt to connect to domains trusted by the current domain, another domain in the forest, or domains involved in a forest trust. When not importing or synchronizing users from any of the trusted domains, clear the checkbox to improve performance.
+5. Select **Include trusted domains** to have the Multi-Factor Authentication Server attempt to connect to domains trusted by the current domain, another domain in the forest, or domains involved in a forest trust. When not importing or synchronizing users from any of the trusted domains, clear the check box to improve performance.
#### Synchronization
@@ -352,7 +353,7 @@ The Web Service SDK section allows the administrator to install the Multi-Factor
Remember the Web Services SDK is only need on the primary Multi-Factor to easily enable other servers access to the configuration information. The prerequisites section guided you through installing and configuring the items needed for the Web Services SDK, however the installer will validate the prerequisites and make suggest any corrective action needed.
-Please follow the instructions under [Install the web service SDK](https://docs.microsoft.com/en-us/azure/multi-factor-authentication/multi-factor-authentication-get-started-server-webservice#install-the-web-service-sdk) to intall the MFA Web Services SDK.
+Please follow the instructions under [Install the web service SDK](https://docs.microsoft.com/en-us/azure/multi-factor-authentication/multi-factor-authentication-get-started-server-webservice#install-the-web-service-sdk) to install the MFA Web Services SDK.
## Install Secondary MFA Servers
@@ -391,7 +392,7 @@ You previously configured the User Portal settings on the primary MFA server. T
Sign in the primary MFA server with _local administrator_ equivalent credentials.
1. Open Windows Explorer.
-2. Browse to the C:\Progam Files\MultiFactor Authentication Server folder.
+2. Browse to the C:\Program Files\MultiFactor Authentication Server folder.
3. Copy the **MultiFactorAuthenticationUserPortalSetup64.msi** file to a folder on the User Portal server.
### Configure Virtual Directory name
@@ -410,7 +411,7 @@ Sign in the User Portal server with _local administrator_ equivalent credentials
2. Locate the **USE_WEB_SERVICE_SDK** key and change the value from **false** to **true**.
3. Locate the **WEB_SERVICE_SDK_AUTHENTICATION_USERNAME** key and set the value to the username of the Web Service SDK account in the **PhoneFactor Admins** security group. Use a qualified username, like domain\username or machine\username.
4. Locate the **WEB_SERVICE_SDK_AUTHENTICATION_PASSWORD** key and set the value to the password of the Web Service SDK account in the **PhoneFactor Admins** security group.
-5. Locate the **pfup_pfwssdk_PfWsSdk** setting and change the value from **“http://localhost:4898/PfWsSdk.asmx”** to the URL of the Web Service SDK that is running on the Azure Multi-Factor Authentication Server (e.g. https://computer1.domain.local/MultiFactorAuthWebServiceSdk/PfWsSdk.asmx). Since SSL is used for this connection, refer to the Web Service SDK by server name, not IP address, since the SSL certificate was issued for the server name. If the server name does not resolve to an IP address from the internet-facing server, add an entry to the hosts file on that server to map the name of the Azure Multi-Factor Authentication Server to its IP address. Save the **web.config** file after changes have been made.
+5. Locate the **pfup_pfwssdk_PfWsSdk** setting and change the value from **“http://localhost:4898/PfWsSdk.asmx”** to the URL of the Web Service SDK that is running on the Azure Multi-Factor Authentication Server (e.g. https://computer1.domain.local/MultiFactorAuthWebServiceSdk/PfWsSdk.asmx). Since SSL is used for this connection, refer to the Web Service SDK by server name, not IP address, since the SSL certificate was issued for the server name. If the server name does not resolve to an IP address from the Internet-facing server, add an entry to the hosts file on that server to map the name of the Azure Multi-Factor Authentication Server to its IP address. Save the **web.config** file after changes have been made.
### Create a DNS entry for the User Portal web site
@@ -453,7 +454,7 @@ Sign in the primary MFA server with _MFA administrator_ equivalent credentials.
3. On the Settings tab, type the URL your users use to access the User Portal. The URL should begin with https, such as `https://mfaportal.corp.contoso.com/mfa`.
The Multi-Factor Authentication Server uses this information when sending emails to users.
4. Select Allow users to log in and Allow user enrollment check boxes.
-5. Select Allow users to select method. Select Phone call and select Text message (you can select Mobile app later once you have deployed the Mobile app web service). Select Automatically trigger user’s default method.
+5. Select Allow users to select method. Select Phone call and select Text message (you can select Mobile application later once you have deployed the Mobile application web service). Select Automatically trigger user’s default method.
6. Select Allow users to select language.
7. Select Use security questions for fallback and select 4 from the Questions to answer list.
@@ -495,7 +496,7 @@ Sign in the primary AD FS server with _local administrator_ equivalent credentia
2. Locate the **USE_WEB_SERVICE_SDK** key and change the value from **false** to **true**.
3. Locate the **WEB_SERVICE_SDK_AUTHENTICATION_USERNAME** key and set the value to the username of the Web Service SDK account in the **PhoneFactor Admins** security group. Use a qualified username, like domain\username or machine\username.
4. Locate the **WEB_SERVICE_SDK_AUTHENTICATION_PASSWORD** key and set the value to the password of the Web Service SDK account in the **PhoneFactor Admins** security group.
-5. Locate the **pfup_pfwssdk_PfWsSdk** setting and change the value from “http://localhost:4898/PfWsSdk.asmx” to the URL of the Web Service SDK that is running on the Azure Multi-Factor Authentication Server (e.g. https://computer1.domain.local/MultiFactorAuthWebServiceSdk/PfWsSdk.asmx). Since SSL is used for this connection, refer to the Web Service SDK by server name, not IP address, since the SSL certificate was issued for the server name. If the server name does not resolve to an IP address from the internet-facing server, add an entry to the hosts file on that server to map the name of the Azure Multi-Factor Authentication Server to its IP address. Save the **MultiFactorAuthenticationAdfsAdapter.config** file after changes have been made.
+5. Locate the **pfup_pfwssdk_PfWsSdk** setting and change the value from “http://localhost:4898/PfWsSdk.asmx” to the URL of the Web Service SDK that is running on the Azure Multi-Factor Authentication Server (e.g. https://computer1.domain.local/MultiFactorAuthWebServiceSdk/PfWsSdk.asmx). Since SSL is used for this connection, refer to the Web Service SDK by server name, not IP address, since the SSL certificate was issued for the server name. If the server name does not resolve to an IP address from the Internet-facing server, add an entry to the hosts file on that server to map the name of the Azure Multi-Factor Authentication Server to its IP address. Save the **MultiFactorAuthenticationAdfsAdapter.config** file after changes have been made.
### Edit the AD FS Adapter Windows PowerShell cmdlet
diff --git a/windows/security/identity-protection/hello-for-business/hello-key-trust-policy-settings.md b/windows/security/identity-protection/hello-for-business/hello-key-trust-policy-settings.md
index 69e6e36112..bbc808feae 100644
--- a/windows/security/identity-protection/hello-for-business/hello-key-trust-policy-settings.md
+++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-policy-settings.md
@@ -9,14 +9,15 @@ ms.pagetype: security, mobile
author: mikestephens-MS
ms.author: mstephen
ms.localizationpriority: medium
-ms.date: 10/10/2017
+ms.date: 08/19/2018
---
# Configure Windows Hello for Business Policy settings
**Applies to**
-- Windows 10
+- Windows 10, version 1703 or later
+- On-premises deployment
+- Key trust
-> This guide only applies to Windows 10, version 1703 or higher.
You need a Windows 10, version 1703 workstation to run the Group Policy Management Console, which provides the latest Windows Hello for Business and PIN Complexity Group Policy settings. 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 1703.
@@ -76,7 +77,7 @@ The default configuration for Windows Hello for Business is to prefer hardware p
You can enable and deploy the **Use a hardware security device** Group Policy Setting to force Windows Hello for Business to only create hardware protected credentials. Users that sign-in from a computer incapable of creating a hardware protected credential do not enroll for Windows Hello for Business.
-Another policy setting becomes available when you enable the **Use a hardware security device** Group Policy setting that enables you to prevent Windows Hello for Business enrollment from using version 1.2 Trusted Platform Modules (TPM). Version 1.2 TPMs typically perform cryptographic operations slower than version 2.0 TPMs and are more unforgiven during anti-hammering and PIN lockout activities. Therefore, some organization may want not want slow sign-in performance and management overhead associated with version 1.2 TPMs. To prevent Windows Hello for Business from using version 1.2 TPMs, simply select the TPM 1.2 check box after you enable the Use a hardware security device Group Policy object.
+Another policy setting becomes available when you enable the **Use a hardware security device** Group Policy setting that enables you to prevent Windows Hello for Business enrollment from using version 1.2 Trusted Platform Modules (TPM). Version 1.2 TPMs typically perform cryptographic operations slower than version 2.0 TPMs and are more unforgiving during anti-hammering and PIN lockout activities. Therefore, some organization may want not want slow sign-in performance and management overhead associated with version 1.2 TPMs. To prevent Windows Hello for Business from using version 1.2 TPMs, simply select the TPM 1.2 check box after you enable the Use a hardware security device Group Policy object.
### Use biometrics
@@ -105,7 +106,7 @@ In the Windows 10, version 1703, the PIN complexity Group Policy settings have m
Before you continue with the deployment, validate your deployment progress by reviewing the following items:
* Confirm you authored Group Policy settings using the latest ADMX/ADML files (from the Widows 10 Creators Editions)
* Confirm you configured the Enable Windows Hello for Business to the scope that matches your deployment (Computer vs. User)
-* Confirm you configure the Use Certificate enrollment for on-prem authentication policy setting.
+* Confirm you configure the Use Certificate enrollment for on-premises authentication policy setting.
* Confirm you configure automatic certificate enrollment to the scope that matches your deployment (Computer vs. User)
* Confirm you configured the proper security settings for the Group Policy object
* Removed the allow permission for Apply Group Policy for Domain Users (Domain Users must always have the read permissions)
diff --git a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-ad-prereq.md b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-ad-prereq.md
index da6751970c..9c5067319d 100644
--- a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-ad-prereq.md
+++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-ad-prereq.md
@@ -8,19 +8,21 @@ ms.sitesec: library
ms.pagetype: security, mobile
author: DaniHalfin
ms.localizationpriority: medium
-ms.author: daniha
-ms.date: 10/23/2017
+author: mikestephens-MS
+ms.author: mstephen
+ms.date: 08/19/2018
---
# Validate Active Directory prerequisites
**Applies to**
-- Windows 10
+- Windows 10, version 1703 or later
+- On-premises deployment
+- Key trust
-> This guide only applies to Windows 10, version 1703 or higher.
Key trust deployments need an adequate number of 2016 domain controllers to ensure successful user authentication with Windows Hello for Business. To learn more about domain controller planning for key trust deployments, read the [Windows Hello for Business planning guide](hello-planning-guide.md), the [Planning an adequate number of Windows Server 2016 Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) section.
-The key registration process for the On-prem deployment of Windows Hello for Business needs the Windows Server 2016 Active Directory schema. The key-trust model receives the schema extension when the first Windows Server 2016 domain controller is added to the forest. The minimum required domain functional and forest functional levels for Windows Hello for Business deployment is Windows Server 2008 R2.
+The key registration process for the On-premises deployment of Windows Hello for Business needs the Windows Server 2016 Active Directory schema. The key-trust model receives the schema extension when the first Windows Server 2016 domain controller is added to the forest. The minimum required domain functional and forest functional levels for Windows Hello for Business deployment is Windows Server 2008 R2.
## Create the Windows Hello for Business Users Security Global Group
diff --git a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-deploy-mfa.md b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-deploy-mfa.md
index 8980d9d210..f657b6ca14 100644
--- a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-deploy-mfa.md
+++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-deploy-mfa.md
@@ -9,20 +9,21 @@ ms.pagetype: security, mobile
author: mikestephens-MS
ms.author: mstephen
ms.localizationpriority: medium
-ms.date: 10/10/2017
+ms.date: 08/19/2018
---
# Validate and Deploy Multifactor Authentication Services (MFA)
**Applies to**
-- Windows 10
+- Windows 10, version 1703 or later
+- On-premises deployment
+- Key trust
-> This guide only applies to Windows 10, version 1703 or higher.
Windows Hello for Business requires all users perform an additional factor of authentication prior to creating and registering a Windows Hello for Business credential. Windows Hello for Business deployments use Azure Multi-Factor Authentication (Azure MFA) services for the secondary authentication. On-Premises deployments use Azure MFA server, an on-premises implementation that do not require synchronizing Active Directory credentials to Azure Active Directory.
Azure Multi-Factor Authentication is an easy to use, scalable, and reliable solution that provides a second method of authentication so your users are always protected.
* **Easy to Use** - Azure Multi-Factor Authentication is simple to set up and use. The extra protection that comes with Azure Multi-Factor Authentication allows users to manage their own devices. Best of all, in many instances it can be set up with just a few simple clicks.
-* **Scalable** - Azure Multi-Factor Authentication uses the power of the cloud and integrates with your on-premises AD and custom apps. This protection is even extended to your high-volume, mission-critical scenarios.
+* **Scalable** - Azure Multi-Factor Authentication uses the power of the cloud and integrates with your on-premises AD and custom applications. This protection is even extended to your high-volume, mission-critical scenarios.
* **Always Protected** - Azure Multi-Factor Authentication provides strong authentication using the highest industry standards.
* **Reliable** - We guarantee 99.9% availability of Azure Multi-Factor Authentication. The service is considered unavailable when it is unable to receive or process verification requests for the two-step verification.
diff --git a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-pki.md b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-pki.md
index 2d65964f36..764dacd461 100644
--- a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-pki.md
+++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-pki.md
@@ -8,15 +8,16 @@ ms.sitesec: library
ms.pagetype: security, mobile
author: mikestephens-MS
ms.author: mstephen
-ms.localizationpriority: medium
-ms.date: 10/10/2017
+localizationpriority: high
+ms.date: 08/19/2018
---
# Validate and Configure Public Key Infrastructure
**Applies to**
-- Windows 10
+- Windows 10, version 1703 or later
+- On-premises deployment
+- Key trust
-> This guide only applies to Windows 10, version 1703 or higher.
Windows Hello for Business must have a public key infrastructure regardless of the deployment or trust model. All trust models depend on the domain controllers having a certificate. The certificate serves as a root of trust for clients to ensure they are not communicating with a rogue domain controller.
@@ -60,7 +61,7 @@ Sign-in to a certificate authority or management workstations with _Domain Admin
1. Open the **Certificate Authority** management console.
2. Right-click **Certificate Templates** and click **Manage**.
3. In the **Certificate Template Console**, right-click the **Kerberos Authentication** template in the details pane and click **Duplicate Template**.
-4. On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Authority** list. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Recipient** list.
+4. On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2008 R2** from the **Certification Authority** list. Select **Windows 7.Server 2008 R2** from the **Certification Recipient** list.
5. On the **General** tab, type **Domain Controller Authentication (Kerberos)** in Template display name. Adjust the validity and renewal period to meet your enterprise’s needs.
**Note**If you use different template names, you’ll need to remember and substitute these names in different portions of the lab.
6. On the **Subject** tab, select the **Build from this Active Directory information** button if it is not already selected. Select **None** from the **Subject name format** list. Select **DNS name** from the **Include this information in alternate subject** list. Clear all other items.
diff --git a/windows/security/identity-protection/hello-for-business/hello-manage-in-organization.md b/windows/security/identity-protection/hello-for-business/hello-manage-in-organization.md
index 499d76b162..f367ae301e 100644
--- a/windows/security/identity-protection/hello-for-business/hello-manage-in-organization.md
+++ b/windows/security/identity-protection/hello-for-business/hello-manage-in-organization.md
@@ -17,7 +17,6 @@ ms.date: 10/18/2017
**Applies to**
- Windows 10
-- Windows 10 Mobile
You can create a Group Policy or mobile device management (MDM) policy that will implement Windows Hello on devices running Windows 10.
diff --git a/windows/security/identity-protection/hello-for-business/hello-overview.md b/windows/security/identity-protection/hello-for-business/hello-overview.md
index e37f8cbe0f..0d044aa31e 100644
--- 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,15 @@ ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security, mobile
-author: DaniHalfin
-ms.localizationpriority: medium
-ms.date: 07/27/2017
+author: mikestephens-MS
+ms.author: mstephen
+ms.localizationpriority: high
+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.
@@ -53,15 +53,14 @@ Windows stores biometric data that is used to implement Windows Hello securely o
- Windows Hello for Business, which is configured by Group Policy or mobile device management (MDM) policy, uses key-based or certificate-based authentication.
-- Currently Active Directory accounts using Windows Hello are not backed by key-based or certificate-based authentication. Support for key-based or certificate-based authentication is on the roadmap for a future release.
## Benefits of Windows Hello
Reports of identity theft and large-scale hacking are frequent headlines. Nobody wants to be notified that their user name and password have been exposed.
-You may wonder [how a PIN can help protect a device better than a password](hello-why-pin-is-better-than-password.md). Passwords are shared secrets; they are entered on a device and transmitted over the network to the server. An intercepted account name and password can be used by anyone. Because they're stored on the server, a server breach can reveal those stored credentials.
+You may wonder [how a PIN can help protect a device better than a password](hello-why-pin-is-better-than-password.md). Passwords are shared secrets; they are entered on a device and transmitted over the network to the server. An intercepted account name and password can be used by anyone, anywhere. Because they're stored on the server, a server breach can reveal those stored credentials.
-In Windows 10, Windows Hello replaces passwords. When the identity provider supports keys, the Windows Hello provisioning process creates a cryptographic key pair bound to the Trusted Platform Module (TPM), if a device has a TPM, or in software. Access to these keys and obtaining a signature to validate user possession of the private key is enabled only by the PIN or biometric gesture. The two-step verification that takes place during Windows Hello enrollment creates a trusted relationship between the identity provider and the user when the public portion of the public/private key pair is sent to an identity provider and associated with a user account. When a user enters the gesture on the device, the identity provider knows from the combination of Hello keys and gesture that this is a verified identity and provides an authentication token that allows Windows 10 to access resources and services.
+In Windows 10, Windows Hello replaces passwords. When the identity provider supports keys, the Windows Hello provisioning process creates a cryptographic key pair bound to the Trusted Platform Module (TPM), if a device has a TPM 2.0, or in software. Access to these keys and obtaining a signature to validate user possession of the private key is enabled only by the PIN or biometric gesture. The two-step verification that takes place during Windows Hello enrollment creates a trusted relationship between the identity provider and the user when the public portion of the public/private key pair is sent to an identity provider and associated with a user account. When a user enters the gesture on the device, the identity provider knows from the combination of Hello keys and gesture that this is a verified identity and provides an authentication token that allows Windows 10 to access resources and services.
>[!NOTE]
>Windows Hello as a convenience sign-in uses regular user name and password authentication, without the user entering the password.
@@ -79,8 +78,8 @@ Windows Hello helps protect user identities and user credentials. Because the us
- Windows Hello credentials are based on certificate or asymmetrical key pair. Windows Hello credentials can be bound to the device, and the token that is obtained using the credential is also bound to the device.
- Identity provider (such as Active Directory, Azure AD, or a Microsoft account) validates user identity and maps the Windows Hello public key to a user account during the registration step.
- Keys can be generated in hardware (TPM 1.2 or 2.0 for enterprises, and TPM 2.0 for consumers) or software, based on the policy.
-- Authentication is the two-factor authentication with the combination of a key or certificate tied to a device and something that the person knows (a PIN) or something that the person is (Windows Hello). The Windows Hello gesture does not roam between devices and is not shared with the server; it is stored locally on a device.
-- Private key never leaves a device when using TPM. The authenticating server has a public key that is mapped to the user account during the registration process.
+- Authentication is the two-factor authentication with the combination of a key or certificate tied to a device and something that the person knows (a PIN) or something that the person is (biometrics). The Windows Hello gesture does not roam between devices and is not shared with the server. Biometrics templates are stored locally on a device. The PIN is never stored or shared.
+- The private key never leaves a device when using TPM. The authenticating server has a public key that is mapped to the user account during the registration process.
- PIN entry and biometric gesture both trigger Windows 10 to use the private key to cryptographically sign data that is sent to the identity provider. The identity provider verifies the user's identity and authenticates the user.
- Personal (Microsoft account) and corporate (Active Directory or Azure AD) accounts use a single container for keys. All keys are separated by identity providers' domains to help ensure user privacy.
- Certificate private keys can be protected by the Windows Hello container and the Windows Hello gesture.
@@ -99,17 +98,12 @@ Windows Hello for Business can use either keys (hardware or software) or certifi
[Introduction to Windows Hello](https://go.microsoft.com/fwlink/p/?LinkId=786649), video presentation on Microsoft Virtual Academy
-[What's new in Active Directory Domain Services (AD DS) in Windows Server Technical Preview](https://go.microsoft.com/fwlink/p/?LinkId=708533)
-
[Windows Hello face authentication](https://go.microsoft.com/fwlink/p/?LinkId=626024)
-[Biometrics hardware guidelines](https://go.microsoft.com/fwlink/p/?LinkId=626995)
-
[Windows 10: Disrupting the Revolution of Cyber-Threats with Revolutionary Security!](https://go.microsoft.com/fwlink/p/?LinkId=533890)
[Windows 10: The End Game for Passwords and Credential Theft?](https://go.microsoft.com/fwlink/p/?LinkId=533891)
-[Authenticating identities without passwords through Windows Hello for Business](https://go.microsoft.com/fwlink/p/?LinkId=616778)
## Related topics
diff --git a/windows/security/identity-protection/hello-for-business/hello-planning-guide.md b/windows/security/identity-protection/hello-for-business/hello-planning-guide.md
index e13cabd2e5..b762cb48f0 100644
--- a/windows/security/identity-protection/hello-for-business/hello-planning-guide.md
+++ b/windows/security/identity-protection/hello-for-business/hello-planning-guide.md
@@ -8,8 +8,8 @@ ms.sitesec: library
ms.pagetype: security, mobile
author: mikestephens-MS
ms.author: mstephen
-ms.localizationpriority: medium
-ms.date: 03/26/2018
+localizationpriority: high
+ms.date: 08/19/2018
---
# Planning a Windows Hello for Business Deployment
@@ -73,7 +73,7 @@ A deployment's trust type defines how each Windows Hello for Business client aut
The key trust type does not require issuing authentication certificates to end users. Users authenticate using a hardware-bound key created during an in-box provisioning experience, which requires an adequate distribution of Windows Server 2016 domain controllers relative to your existing authentication and the number of users included in your Windows Hello for Business deployment. Read the [Planning an adequate number of Windows Server 2016 Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) to learn more.
-The certificate trust type issues authentication certificates to end users. Users authenticate using a certificate requested using a hardware-bound key created during the in-box provisioning experience. Unlike key trust, certificate trust does not require Windows Server 2016 domain controllers. Users can authentice using their certificate to any Windows Server 2008 R2 or later domain controller.
+The certificate trust type issues authentication certificates to end users. Users authenticate using a certificate requested using a hardware-bound key created during the in-box provisioning experience. Unlike key trust, certificate trust does not require Windows Server 2016 domain controllers. Users can authenticate using their certificate to any Windows Server 2008 R2 or later domain controller.
#### Device registration
@@ -85,9 +85,9 @@ The in-box Windows Hello for Business provisioning experience creates a hardware
#### Multifactor authentication
-The goal of Windows Hello for Business is to move organizations away from passwords by providing them a strong credential that provides easy two-factor authentication. The inbox provisioning experience accepts the user’s weak credentials (username and password) as the first factor authentication; however, the user must provide a second factor of authentication before Windows provisions a strong credential.
+The goal of Windows Hello for Business is to move organizations away from passwords by providing them a strong credential that provides easy two-factor authentication. The in-box provisioning experience accepts the user’s weak credentials (username and password) as the first factor authentication; however, the user must provide a second factor of authentication before Windows provisions a strong credential.
-Cloud only and hybrid deployments provide many choices for multifactor authentication. On-premises deployments must use a multifactor authentication that provides an AD FS multifactor adapter to be used in conjunction with the on-premises Windows Server 2016 AD FS server role. Organizations can use the on-premises Azure Multifactor Authentication server, or choose from several third parties (Read [Microsoft and third-party additional authentication methods](https://docs.microsoft.com/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs#microsoft-and-third-party-additional-authentication-methods) for more information).
+Cloud only and hybrid deployments provide many choices for multi-factor authentication. On-premises deployments must use a multi-factor authentication that provides an AD FS multi-factor adapter to be used in conjunction with the on-premises Windows Server 2016 AD FS server role. Organizations can use the on-premises Azure Multi-factor Authentication server, or choose from several third parties (Read [Microsoft and third-party additional authentication methods](https://docs.microsoft.com/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs#microsoft-and-third-party-additional-authentication-methods) for more information).
>[!NOTE]
> Azure Multi-Factor Authentication is available through:
>* Microsoft Enterprise Agreement
@@ -128,7 +128,7 @@ Hybrid and on-premises deployments include Active Directory as part of their inf
### Public Key Infrastructure
-The Windows Hello for Business deployment depends on an enterprise public key infrastructure as a trust anchor for authentication. Domain controllers for hybrid and on-prem deployments need a certificate in order for Windows 10 devices to trust the domain controller as legitimate. Deployments using the certificate trust type need an enterprise public key infrastructure and a certificate registration authority to issue authentication certificates to users. Hybrid deployments may need to issue VPN certificates to users to enable connectivity on-premises resources.
+The Windows Hello for Business deployment depends on an enterprise public key infrastructure as a trust anchor for authentication. Domain controllers for hybrid and on-premises deployments need a certificate in order for Windows 10 devices to trust the domain controller as legitimate. Deployments using the certificate trust type need an enterprise public key infrastructure and a certificate registration authority to issue authentication certificates to users. Hybrid deployments may need to issue VPN certificates to users to enable connectivity on-premises resources.
### Cloud
@@ -163,7 +163,7 @@ Choose a trust type that is best suited for your organizations. Remember, the t
One trust model is not more secure than the other. The major difference is based on the organization comfort with deploying Windows Server 2016 domain controllers and not enrolling users with end entity certificates (key-trust) against using existing domain controllers (Windows Server 2008R2 or later) and needing to enroll certificates for all their users (certificate trust).
-Because the certificate trust types issues certificates, there is more configuration and infrastructure needed to accomodate user certificate enrollment, which could also be a factor to consider in your decision. Additional infrastructure needed for certificate-trust deployements includes a certificate registration authority. Hybrid Azure AD joined devices managed by Group Policy need the Windows Server 2016 AD FS role to issue certificates. Hybrid Azure AD joined devices and Azure AD joined devices managed by Intune or a compatible MDM need the Windows Server NDES server role to issue certificates.
+Because the certificate trust types issues certificates, there is more configuration and infrastructure needed to accommodate user certificate enrollment, which could also be a factor to consider in your decision. Additional infrastructure needed for certificate-trust deployments includes a certificate registration authority. Hybrid Azure AD joined devices managed by Group Policy need the Windows Server 2016 AD FS role to issue certificates. Hybrid Azure AD joined devices and Azure AD joined devices managed by Intune or a compatible MDM need the Windows Server NDES server role to issue certificates.
If your organization wants to use the key trust type, write **key trust** in box **1b** on your planning worksheet. Write **Windows Server 2016** in box **4d**. Write **N/A** in box **5b**.
@@ -187,17 +187,17 @@ If box **1a** on your planning worksheet reads **on-premises**, write **AD FS**
### Directory Synchronization
-Windows Hello for Business is strong user authentication, which usually means there is an identity (a user or username) and a credential (typically a key pair). Some operations require writing or reading user data to or from the directory. For example, reading the user’s phone number to perform multifactor authentication during provisioning or writing the user’s public key.
+Windows Hello for Business is strong user authentication, which usually means there is an identity (a user or username) and a credential (typically a key pair). Some operations require writing or reading user data to or from the directory. For example, reading the user’s phone number to perform multi-factor authentication during provisioning or writing the user’s public key.
If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **1e**. User information is written directly to Azure Active Directory and there is not another directory with which the information must be synchronized.
If box **1a** on your planning worksheet reads **hybrid**, then write **Azure AD Connect** in box **1e** on your planning worksheet.
-If box **1a** on your planning worksheet reads **on-premises**, then write **Azure MFA Server**. This deployment exclusively uses Active Directory for user information with the exception of the multifactor authentication. The on-premises Azure MFA server synchronizes a subset of the user information, such as phone number, to provide multifactor authentication while the user’s credential remain on the on-premises network.
+If box **1a** on your planning worksheet reads **on-premises**, then write **Azure MFA Server**. This deployment exclusively uses Active Directory for user information with the exception of the multi-factor authentication. The on-premises Azure MFA server synchronizes a subset of the user information, such as phone number, to provide multi-factor authentication while the user’s credential remain on the on-premises network.
### Multifactor Authentication
-The goal of Windows Hello for Business is to move user authentication away from passwords to a strong, key-based user authentication. Passwords are weak credentials and cannot be trusted by themselves as an attacker with a stolen password could be attempting to enroll in Windows Hello for Business. To keep the transition from a weak to a strong credential secure, Windows Hello for Business relies on multifactor authentication during provisioning to have some assurances that the user identity provisioning a Windows Hello for Business credential is the proper identity.
+The goal of Windows Hello for Business is to move user authentication away from passwords to a strong, key-based user authentication. Passwords are weak credentials and cannot be trusted by themselves as an attacker with a stolen password could be attempting to enroll in Windows Hello for Business. To keep the transition from a weak to a strong credential secure, Windows Hello for Business relies on multi-factor authentication during provisioning to have some assurances that the user identity provisioning a Windows Hello for Business credential is the proper identity.
If box **1a** on your planning worksheet reads **cloud only**, then your only option is to use the Azure MFA cloud service. Write **Azure MFA** in box **1f** on your planning worksheet.
@@ -311,9 +311,9 @@ Windows Hello for Business does not require an Azure AD premium subscription. H
If box **1a** on your planning worksheet reads **on-premises**, write **No** in box **6c** on your planning worksheet.
-If box **1a** on your planning worksheet reads **hybrid** and box **1b** reads **key trust**, write **No** in box **6c** on your planning worksheet. You can deploy Windows Hello for Business using the free Azure Active Directory account (additional costs needed for multifactor authentication).
+If box **1a** on your planning worksheet reads **hybrid** and box **1b** reads **key trust**, write **No** in box **6c** on your planning worksheet. You can deploy Windows Hello for Business using the free Azure Active Directory account (additional costs needed for multi-factor authentication).
-If box **5b** on your planning worksheet reads **AD FS RA**, write **Yes** in box **6c** on your planning worksheet. Enrolling a certificate using the AD FS registration authority requires devices to authenticate to the AD FS server, which requires device writeback—an Azure AD Premium feature.
+If box **5b** on your planning worksheet reads **AD FS RA**, write **Yes** in box **6c** on your planning worksheet. Enrolling a certificate using the AD FS registration authority requires devices to authenticate to the AD FS server, which requires device write-back, an Azure AD Premium feature.
Modern managed devices do not require an Azure AD premium subscription. By forgoing the subscription, your users must manually enroll devices in the modern management software, such as Intune or a supported third-party MDM.
diff --git a/windows/security/identity-protection/hello-for-business/hello-prepare-people-to-use.md b/windows/security/identity-protection/hello-for-business/hello-prepare-people-to-use.md
index df783bb5d9..363636202f 100644
--- a/windows/security/identity-protection/hello-for-business/hello-prepare-people-to-use.md
+++ b/windows/security/identity-protection/hello-for-business/hello-prepare-people-to-use.md
@@ -7,17 +7,16 @@ ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
-author: DaniHalfin
+author: mikestephens-MS
+ms.author: mstephen
ms.localizationpriority: medium
-ms.author: daniha
-ms.date: 07/27/2017
+ms.date: 08/19/2018
---
# Prepare people to use Windows Hello
**Applies to**
- Windows 10
-- Windows 10 Mobile
When you set a policy to require Windows Hello for Business in the workplace, you will want to prepare people in your organization by explaining how to use Hello.
@@ -37,7 +36,7 @@ Next, they select a way to connect. Tell the people in your enterprise which opt
-They sign in, and are then asked to verify their identity. People have options to choose from, such as a text message, phone call, or authentication app. After verification, they create their PIN. The **Create a PIN** screen displays any complexity requirements that you have set, such as minimum length.
+They sign in, and are then asked to verify their identity. People have options to choose from a text message, phone call, or the authentication application. After verification, they create their PIN. The **Create a PIN** screen displays any complexity requirements that you have set, such as minimum length.
After Hello is set up, people use their PIN to unlock the device, and that will automatically log them on.
diff --git a/windows/security/identity-protection/hello-for-business/hello-videos.md b/windows/security/identity-protection/hello-for-business/hello-videos.md
new file mode 100644
index 0000000000..6c6251b3f1
--- /dev/null
+++ b/windows/security/identity-protection/hello-for-business/hello-videos.md
@@ -0,0 +1,46 @@
+---
+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: 08/19/2018
+---
+# Windows Hello for Business Videos
+
+**Applies to**
+- Windows 10
+
+## 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]
+
+
+
+> [!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 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.
\ No newline at end of file
diff --git a/windows/security/identity-protection/hello-for-business/hello-why-pin-is-better-than-password.md b/windows/security/identity-protection/hello-for-business/hello-why-pin-is-better-than-password.md
index d0cd963ed7..c7eae511cd 100644
--- a/windows/security/identity-protection/hello-for-business/hello-why-pin-is-better-than-password.md
+++ b/windows/security/identity-protection/hello-for-business/hello-why-pin-is-better-than-password.md
@@ -17,7 +17,6 @@ ms.date: 10/23/2017
**Applies to**
- Windows 10
-- Windows 10 Mobile
Windows Hello in Windows 10 enables users to sign in to their device using a PIN. How is a PIN different from (and better than) a password?
On the surface, a PIN looks much like a password. A PIN can be a set of numbers, but enterprise policy might allow complex PINs that include special characters and letters, both upper-case and lower-case. Something like **t758A!** could be an account password or a complex Hello PIN. It isn't the structure of a PIN (length, complexity) that makes it better than a password, it's how it works.
diff --git a/windows/security/identity-protection/hello-for-business/images/aadj/AADConnectSchema.png b/windows/security/identity-protection/hello-for-business/images/aadj/AADConnectSchema.png
new file mode 100644
index 0000000000..2a5658b1a9
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadj/AADConnectSchema.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadj/Certificate-CDP.png b/windows/security/identity-protection/hello-for-business/images/aadj/Certificate-CDP.png
new file mode 100644
index 0000000000..34a1cf932a
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadj/Certificate-CDP.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadj/IntuneWHFBPolicy-00.png b/windows/security/identity-protection/hello-for-business/images/aadj/IntuneWHFBPolicy-00.png
new file mode 100644
index 0000000000..88aaf424f0
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadj/IntuneWHFBPolicy-00.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadj/IntuneWHFBPolicy-01.png b/windows/security/identity-protection/hello-for-business/images/aadj/IntuneWHFBPolicy-01.png
new file mode 100644
index 0000000000..3d547d05fc
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadj/IntuneWHFBPolicy-01.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadj/cdp-disable-caching.png b/windows/security/identity-protection/hello-for-business/images/aadj/cdp-disable-caching.png
new file mode 100644
index 0000000000..bb66d1a699
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadj/cdp-disable-caching.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadj/cdp-extension-complete-http.png b/windows/security/identity-protection/hello-for-business/images/aadj/cdp-extension-complete-http.png
new file mode 100644
index 0000000000..2d4f57993d
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadj/cdp-extension-complete-http.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadj/cdp-extension-complete-unc.png b/windows/security/identity-protection/hello-for-business/images/aadj/cdp-extension-complete-unc.png
new file mode 100644
index 0000000000..edeb6d971e
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadj/cdp-extension-complete-unc.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadj/cdp-extension-new-location.png b/windows/security/identity-protection/hello-for-business/images/aadj/cdp-extension-new-location.png
new file mode 100644
index 0000000000..a56d495089
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadj/cdp-extension-new-location.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadj/cdp-ntfs-permissions.png b/windows/security/identity-protection/hello-for-business/images/aadj/cdp-ntfs-permissions.png
new file mode 100644
index 0000000000..79a72ae29f
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadj/cdp-ntfs-permissions.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadj/cdp-share-permissions.png b/windows/security/identity-protection/hello-for-business/images/aadj/cdp-share-permissions.png
new file mode 100644
index 0000000000..30da456ff0
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadj/cdp-share-permissions.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadj/cdp-sharing.png b/windows/security/identity-protection/hello-for-business/images/aadj/cdp-sharing.png
new file mode 100644
index 0000000000..4efa6708c6
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadj/cdp-sharing.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadj/certlm-cert-path-tab.png b/windows/security/identity-protection/hello-for-business/images/aadj/certlm-cert-path-tab.png
new file mode 100644
index 0000000000..9f19625b42
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadj/certlm-cert-path-tab.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadj/certlm-export-root-certificate.png b/windows/security/identity-protection/hello-for-business/images/aadj/certlm-export-root-certificate.png
new file mode 100644
index 0000000000..fa835f58dc
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadj/certlm-export-root-certificate.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadj/certlm-personal-store.png b/windows/security/identity-protection/hello-for-business/images/aadj/certlm-personal-store.png
new file mode 100644
index 0000000000..daa8efae51
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadj/certlm-personal-store.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadj/certlm-renew-with-new-key.png b/windows/security/identity-protection/hello-for-business/images/aadj/certlm-renew-with-new-key.png
new file mode 100644
index 0000000000..efad4471ca
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadj/certlm-renew-with-new-key.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadj/certlm-root-cert-details-tab.png b/windows/security/identity-protection/hello-for-business/images/aadj/certlm-root-cert-details-tab.png
new file mode 100644
index 0000000000..4f34de2e73
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadj/certlm-root-cert-details-tab.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadj/dc-cert-with-new-cdp.png b/windows/security/identity-protection/hello-for-business/images/aadj/dc-cert-with-new-cdp.png
new file mode 100644
index 0000000000..174ee56fd0
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadj/dc-cert-with-new-cdp.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadj/dns-new-host-dialog.png b/windows/security/identity-protection/hello-for-business/images/aadj/dns-new-host-dialog.png
new file mode 100644
index 0000000000..4076e6ad33
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadj/dns-new-host-dialog.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadj/dsregcmd.png b/windows/security/identity-protection/hello-for-business/images/aadj/dsregcmd.png
new file mode 100644
index 0000000000..cacbcf0737
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadj/dsregcmd.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadj/iis-add-virtual-directory.png b/windows/security/identity-protection/hello-for-business/images/aadj/iis-add-virtual-directory.png
new file mode 100644
index 0000000000..b33235ec14
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadj/iis-add-virtual-directory.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadj/iis-config-editor-allowDoubleEscaping.png b/windows/security/identity-protection/hello-for-business/images/aadj/iis-config-editor-allowDoubleEscaping.png
new file mode 100644
index 0000000000..20fbffbd85
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadj/iis-config-editor-allowDoubleEscaping.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadj/iis-config-editor-requestFiltering.png b/windows/security/identity-protection/hello-for-business/images/aadj/iis-config-editor-requestFiltering.png
new file mode 100644
index 0000000000..8c057c4d29
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadj/iis-config-editor-requestFiltering.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadj/intune-create-device-config-profile.png b/windows/security/identity-protection/hello-for-business/images/aadj/intune-create-device-config-profile.png
new file mode 100644
index 0000000000..caacf8a566
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadj/intune-create-device-config-profile.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadj/intune-create-trusted-certificate-profile.png b/windows/security/identity-protection/hello-for-business/images/aadj/intune-create-trusted-certificate-profile.png
new file mode 100644
index 0000000000..226f85eeb0
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadj/intune-create-trusted-certificate-profile.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadj/intune-device-config-enterprise-root-assignment.png b/windows/security/identity-protection/hello-for-business/images/aadj/intune-device-config-enterprise-root-assignment.png
new file mode 100644
index 0000000000..067c109808
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadj/intune-device-config-enterprise-root-assignment.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadj/publish-new-crl.png b/windows/security/identity-protection/hello-for-business/images/aadj/publish-new-crl.png
new file mode 100644
index 0000000000..b9176ebfc4
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadj/publish-new-crl.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadj/validate-cdp-using-browser.png b/windows/security/identity-protection/hello-for-business/images/aadj/validate-cdp-using-browser.png
new file mode 100644
index 0000000000..59ff4c01d2
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadj/validate-cdp-using-browser.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/AADConnectOnPremDN.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/AADConnectOnPremDN.png
new file mode 100644
index 0000000000..c2a4f36704
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/AADConnectOnPremDN.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/AzureADCreateWHFBCertGroup.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/AzureADCreateWHFBCertGroup.png
new file mode 100644
index 0000000000..c54b8061cd
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/AzureADCreateWHFBCertGroup.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/AzureAppProxyConnectorInstall-01.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/AzureAppProxyConnectorInstall-01.png
new file mode 100644
index 0000000000..1e8f3268a2
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/AzureAppProxyConnectorInstall-01.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/AzureAppProxyConnectorInstall-02.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/AzureAppProxyConnectorInstall-02.png
new file mode 100644
index 0000000000..23e573ba1a
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/AzureAppProxyConnectorInstall-02.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/AzureAppProxyConnectorInstall-03.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/AzureAppProxyConnectorInstall-03.png
new file mode 100644
index 0000000000..2482c97c25
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/AzureAppProxyConnectorInstall-03.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/AzureConsole-AppProxyConfig.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/AzureConsole-AppProxyConfig.png
new file mode 100644
index 0000000000..3a31bdd905
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/AzureConsole-AppProxyConfig.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/AzureConsole-ApplicationProxy-Connectors-Default.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/AzureConsole-ApplicationProxy-Connectors-Default.png
new file mode 100644
index 0000000000..336da91706
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/AzureConsole-ApplicationProxy-Connectors-Default.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/AzureConsole-ApplicationProxy-Connectors-Empty.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/AzureConsole-ApplicationProxy-Connectors-Empty.png
new file mode 100644
index 0000000000..9a78424978
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/AzureConsole-ApplicationProxy-Connectors-Empty.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/AzureConsole-ApplicationProxy-Connectors-NewConnectorGroup.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/AzureConsole-ApplicationProxy-Connectors-NewConnectorGroup.png
new file mode 100644
index 0000000000..c620c6593c
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/AzureConsole-ApplicationProxy-Connectors-NewConnectorGroup.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneCertConnectorConfig-01.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneCertConnectorConfig-01.png
new file mode 100644
index 0000000000..f2c38239f3
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneCertConnectorConfig-01.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneCertConnectorConfig-02.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneCertConnectorConfig-02.png
new file mode 100644
index 0000000000..74cea5f0b5
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneCertConnectorConfig-02.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneCertConnectorConfig-04.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneCertConnectorConfig-04.png
new file mode 100644
index 0000000000..e95fd1b9ba
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneCertConnectorConfig-04.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneCertConnectorInstall-01.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneCertConnectorInstall-01.png
new file mode 100644
index 0000000000..c973e43aec
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneCertConnectorInstall-01.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneCertConnectorInstall-03.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneCertConnectorInstall-03.png
new file mode 100644
index 0000000000..70aaa2db9d
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneCertConnectorInstall-03.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneCertConnectorInstall-05.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneCertConnectorInstall-05.png
new file mode 100644
index 0000000000..eadf1eb285
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneCertConnectorInstall-05.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneCertConnectorInstall-06.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneCertConnectorInstall-06.png
new file mode 100644
index 0000000000..56cced034f
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneCertConnectorInstall-06.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneCertConnectorInstall-07.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneCertConnectorInstall-07.png
new file mode 100644
index 0000000000..e4e4555942
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneCertConnectorInstall-07.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneConfigCertRevocation-02.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneConfigCertRevocation-02.png
new file mode 100644
index 0000000000..1f5512c1a5
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneConfigCertRevocation-02.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneDeviceConfigurationCertAuthority.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneDeviceConfigurationCertAuthority.png
new file mode 100644
index 0000000000..390bfecafd
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneDeviceConfigurationCertAuthority.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneDeviceConfigurationCreateProfile.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneDeviceConfigurationCreateProfile.png
new file mode 100644
index 0000000000..a136973f04
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneDeviceConfigurationCreateProfile.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneDownloadCertConnector.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneDownloadCertConnector.png
new file mode 100644
index 0000000000..c78baecd49
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneDownloadCertConnector.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneWHFBScepProfile-00.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneWHFBScepProfile-00.png
new file mode 100644
index 0000000000..96fe45bbcf
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneWHFBScepProfile-00.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneWHFBScepProfile-01.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneWHFBScepProfile-01.png
new file mode 100644
index 0000000000..004d3a3f25
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneWHFBScepProfile-01.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneWHFBScepProfile-03.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneWHFBScepProfile-03.png
new file mode 100644
index 0000000000..9d66d330fd
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneWHFBScepProfile-03.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneWHFBScepProfile-04.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneWHFBScepProfile-04.png
new file mode 100644
index 0000000000..dea61f116e
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneWHFBScepProfile-04.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneWHFBScepProfileAssignment.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneWHFBScepProfileAssignment.png
new file mode 100644
index 0000000000..831e12fe59
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/IntuneWHFBScepProfileAssignment.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/MicrosoftIntuneConsole.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/MicrosoftIntuneConsole.png
new file mode 100644
index 0000000000..21f4159d80
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/MicrosoftIntuneConsole.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/NDES-IIS-Bindings-Add-443.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/NDES-IIS-Bindings-Add-443.png
new file mode 100644
index 0000000000..00b75cbcd4
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/NDES-IIS-Bindings-Add-443.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/NDES-IIS-Bindings.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/NDES-IIS-Bindings.png
new file mode 100644
index 0000000000..89335a38fe
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/NDES-IIS-Bindings.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/NDES-IIS-Console.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/NDES-IIS-Console.png
new file mode 100644
index 0000000000..d1e5d924a5
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/NDES-IIS-Console.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/NDES-IIS-RequestFiltering.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/NDES-IIS-RequestFiltering.png
new file mode 100644
index 0000000000..100c33218b
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/NDES-IIS-RequestFiltering.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/NDES-https-website-test-01-show-Cert.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/NDES-https-website-test-01-show-Cert.png
new file mode 100644
index 0000000000..0e90f4ed40
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/NDES-https-website-test-01-show-Cert.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/NDES-https-website-test-01.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/NDES-https-website-test-01.png
new file mode 100644
index 0000000000..475313433f
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/NDES-https-website-test-01.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/NDES-https-website-test-after-Intune-Connector.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/NDES-https-website-test-after-Intune-Connector.png
new file mode 100644
index 0000000000..49c4dee983
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/NDES-https-website-test-after-Intune-Connector.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/NDESSvcDelegation-HOST-CA-SPN.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/NDESSvcDelegation-HOST-CA-SPN.png
new file mode 100644
index 0000000000..a97f9f579a
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/NDESSvcDelegation-HOST-CA-SPN.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/NDESSvcDelegation-HOST-NDES-SPN.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/NDESSvcDelegation-HOST-NDES-SPN.png
new file mode 100644
index 0000000000..a66dcb1d27
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/NDESSvcDelegation-HOST-NDES-SPN.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/NDESSvcDelegationTab.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/NDESSvcDelegationTab.png
new file mode 100644
index 0000000000..fe3e125013
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/NDESSvcDelegationTab.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/dotNet35sideByside.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/dotNet35sideByside.png
new file mode 100644
index 0000000000..9e17a4353a
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/dotNet35sideByside.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/ndes-TLS-Cert-Enroll-subjectNameWithExternalName.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/ndes-TLS-Cert-Enroll-subjectNameWithExternalName.png
new file mode 100644
index 0000000000..c7015d5153
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/ndes-TLS-Cert-Enroll-subjectNameWithExternalName.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/ndesConfig01.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/ndesConfig01.png
new file mode 100644
index 0000000000..d71124ff6b
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/ndesConfig01.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/ndesConfig02.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/ndesConfig02.png
new file mode 100644
index 0000000000..f2ee619ccc
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/ndesConfig02.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/ndesConfig03b.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/ndesConfig03b.png
new file mode 100644
index 0000000000..ac473ff1f1
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/ndesConfig03b.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/ndesConfig04.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/ndesConfig04.png
new file mode 100644
index 0000000000..42f44f1450
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/ndesConfig04.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/ndesConfig05.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/ndesConfig05.png
new file mode 100644
index 0000000000..2aaf619b44
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/ndesConfig05.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/ndesConfig06.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/ndesConfig06.png
new file mode 100644
index 0000000000..0ec08ecbc0
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/ndesConfig06.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/serverManager-ADCS-HTTP-Activation.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/serverManager-ADCS-HTTP-Activation.png
new file mode 100644
index 0000000000..e049986459
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/serverManager-ADCS-HTTP-Activation.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/serverManager-ADCS-NDES-Role-Checked.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/serverManager-ADCS-NDES-Role-Checked.png
new file mode 100644
index 0000000000..03a63b4da1
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/serverManager-ADCS-NDES-Role-Checked.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/serverManager-ADCS-Role.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/serverManager-ADCS-Role.png
new file mode 100644
index 0000000000..a4081da362
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/serverManager-ADCS-Role.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/serverManager-ADCS-WebServer-Role.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/serverManager-ADCS-WebServer-Role.png
new file mode 100644
index 0000000000..deaef2b720
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/serverManager-ADCS-WebServer-Role.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/serverManager-ADCS-add-Features.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/serverManager-ADCS-add-Features.png
new file mode 100644
index 0000000000..81b0b2f36a
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/serverManager-ADCS-add-Features.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/serverManager-Destination-Server-NDES.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/serverManager-Destination-Server-NDES.png
new file mode 100644
index 0000000000..cd64efd4f8
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/serverManager-Destination-Server-NDES.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/serverManager-Post-NDES-YellowActionFlag.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/serverManager-Post-NDES-YellowActionFlag.png
new file mode 100644
index 0000000000..e7016550bc
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/serverManager-Post-NDES-YellowActionFlag.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/aadjCert/setSPN-CommandPrompt.png b/windows/security/identity-protection/hello-for-business/images/aadjCert/setSPN-CommandPrompt.png
new file mode 100644
index 0000000000..fa38ebce96
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/aadjCert/setSPN-CommandPrompt.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/dc-chart1.png b/windows/security/identity-protection/hello-for-business/images/dc-chart1.png
deleted file mode 100644
index f5c8d3f2f3..0000000000
Binary files a/windows/security/identity-protection/hello-for-business/images/dc-chart1.png and /dev/null differ
diff --git a/windows/security/identity-protection/hello-for-business/images/dc-chart2.png b/windows/security/identity-protection/hello-for-business/images/dc-chart2.png
deleted file mode 100644
index ff99966521..0000000000
Binary files a/windows/security/identity-protection/hello-for-business/images/dc-chart2.png and /dev/null differ
diff --git a/windows/security/identity-protection/hello-for-business/images/dc-chart3.png b/windows/security/identity-protection/hello-for-business/images/dc-chart3.png
deleted file mode 100644
index bb0f940660..0000000000
Binary files a/windows/security/identity-protection/hello-for-business/images/dc-chart3.png and /dev/null differ
diff --git a/windows/security/identity-protection/hello-for-business/images/dc-chart4.png b/windows/security/identity-protection/hello-for-business/images/dc-chart4.png
deleted file mode 100644
index ecdab58907..0000000000
Binary files a/windows/security/identity-protection/hello-for-business/images/dc-chart4.png and /dev/null differ
diff --git a/windows/security/identity-protection/hello-for-business/images/dc-chart5.png b/windows/security/identity-protection/hello-for-business/images/dc-chart5.png
deleted file mode 100644
index 5671c2ecf7..0000000000
Binary files a/windows/security/identity-protection/hello-for-business/images/dc-chart5.png and /dev/null differ
diff --git a/windows/security/identity-protection/hello-for-business/images/four-steps-passwordless.png b/windows/security/identity-protection/hello-for-business/images/four-steps-passwordless.png
new file mode 100644
index 0000000000..8552a3ee2f
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/four-steps-passwordless.png differ
diff --git 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
new file mode 100644
index 0000000000..344be6aa22
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/auth-aadj-certtrust-kerb.png differ
diff --git 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
new file mode 100644
index 0000000000..751e2fbe99
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/auth-aadj-cloud.png differ
diff --git 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
new file mode 100644
index 0000000000..095ebc3417
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/auth-aadj-keytrust-kerb.png differ
diff --git 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
new file mode 100644
index 0000000000..905d36fa8f
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/auth-haadj-certtrust.png differ
diff --git 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
new file mode 100644
index 0000000000..7f82cda5ae
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/auth-haadj-keytrust.png differ
diff --git 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
new file mode 100644
index 0000000000..454fe3df0a
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/devreg-aadj-federated.png differ
diff --git 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
new file mode 100644
index 0000000000..7f9774389c
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/devreg-aadj-managed.png differ
diff --git 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
new file mode 100644
index 0000000000..df7973e2ca
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/devreg-hybrid-haadj-federated.png differ
diff --git 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
new file mode 100644
index 0000000000..eb3458bf76
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/devreg-hybrid-haadj-managed.png differ
diff --git 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
new file mode 100644
index 0000000000..dd7eee063e
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/prov-aadj-federated.png differ
diff --git 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
new file mode 100644
index 0000000000..3e67ac6b42
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/prov-aadj-managed.png differ
diff --git 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
new file mode 100644
index 0000000000..6011b3c66e
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/prov-haadj-certtrust-managed.png differ
diff --git 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
new file mode 100644
index 0000000000..b7f4927730
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/prov-haadj-instant-certtrust-federated.png differ
diff --git 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
new file mode 100644
index 0000000000..ac1752b75b
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/prov-haadj-instant-certtrust-managed.png differ
diff --git 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
new file mode 100644
index 0000000000..5bf7d96a34
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/prov-haadj-keytrust-managed.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/prov-onprem-certtrust.png b/windows/security/identity-protection/hello-for-business/images/howitworks/prov-onprem-certtrust.png
new file mode 100644
index 0000000000..6afa492270
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/prov-onprem-certtrust.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/prov-onprem-keytrust.png b/windows/security/identity-protection/hello-for-business/images/howitworks/prov-onprem-keytrust.png
new file mode 100644
index 0000000000..3e051918ce
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/prov-onprem-keytrust.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless/00-HideCredProv.png b/windows/security/identity-protection/hello-for-business/images/passwordless/00-HideCredProv.png
new file mode 100644
index 0000000000..fd9085fbd1
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/passwordless/00-HideCredProv.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless/00-SCRIL-dsa.png b/windows/security/identity-protection/hello-for-business/images/passwordless/00-SCRIL-dsa.png
new file mode 100644
index 0000000000..6b19520041
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/passwordless/00-SCRIL-dsa.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless/00-securityPolicy-2016.png b/windows/security/identity-protection/hello-for-business/images/passwordless/00-securityPolicy-2016.png
new file mode 100644
index 0000000000..1ec0fe5a29
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/passwordless/00-securityPolicy-2016.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless/00-securityPolicy.png b/windows/security/identity-protection/hello-for-business/images/passwordless/00-securityPolicy.png
new file mode 100644
index 0000000000..9731de1222
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/passwordless/00-securityPolicy.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless/00-updatedSecurityPolicyText.png b/windows/security/identity-protection/hello-for-business/images/passwordless/00-updatedSecurityPolicyText.png
new file mode 100644
index 0000000000..5935422718
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/passwordless/00-updatedSecurityPolicyText.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless/01-HideCredProv.png b/windows/security/identity-protection/hello-for-business/images/passwordless/01-HideCredProv.png
new file mode 100644
index 0000000000..21329d0ffa
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/passwordless/01-HideCredProv.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless/01-SCRIL-ADAC-2012.png b/windows/security/identity-protection/hello-for-business/images/passwordless/01-SCRIL-ADAC-2012.png
new file mode 100644
index 0000000000..9e3a5509a9
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/passwordless/01-SCRIL-ADAC-2012.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless/01-SCRIL-ADAC-2016.png b/windows/security/identity-protection/hello-for-business/images/passwordless/01-SCRIL-ADAC-2016.png
new file mode 100644
index 0000000000..b4e1575d05
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/passwordless/01-SCRIL-ADAC-2016.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless/02-Rotate-SCRIL-2016.png b/windows/security/identity-protection/hello-for-business/images/passwordless/02-Rotate-SCRIL-2016.png
new file mode 100644
index 0000000000..9b068a70a2
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/passwordless/02-Rotate-SCRIL-2016.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/plan/dc-chart1.png b/windows/security/identity-protection/hello-for-business/images/plan/dc-chart1.png
new file mode 100644
index 0000000000..8133c22b66
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/plan/dc-chart1.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/plan/dc-chart2.png b/windows/security/identity-protection/hello-for-business/images/plan/dc-chart2.png
new file mode 100644
index 0000000000..66f3d18bf2
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/plan/dc-chart2.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/plan/dc-chart3.png b/windows/security/identity-protection/hello-for-business/images/plan/dc-chart3.png
new file mode 100644
index 0000000000..c3e127c0c2
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/plan/dc-chart3.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/plan/dc-chart4.png b/windows/security/identity-protection/hello-for-business/images/plan/dc-chart4.png
new file mode 100644
index 0000000000..4559b432aa
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/plan/dc-chart4.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/plan/dc-chart5.png b/windows/security/identity-protection/hello-for-business/images/plan/dc-chart5.png
new file mode 100644
index 0000000000..b8e2bea022
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/plan/dc-chart5.png differ
diff --git a/windows/security/identity-protection/hello-for-business/images/rdpbio/RDPBioPolicySetting.png b/windows/security/identity-protection/hello-for-business/images/rdpbio/RDPBioPolicySetting.png
new file mode 100644
index 0000000000..06a2ab8543
Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/rdpbio/RDPBioPolicySetting.png differ
diff --git a/windows/security/identity-protection/hello-for-business/passwordless-strategy.md b/windows/security/identity-protection/hello-for-business/passwordless-strategy.md
new file mode 100644
index 0000000000..0836a4dfc0
--- /dev/null
+++ b/windows/security/identity-protection/hello-for-business/passwordless-strategy.md
@@ -0,0 +1,291 @@
+---
+title: Password-less Strategy
+description: Reducing Password Usage Surface
+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: 08/20/2018
+---
+# Password-less Strategy
+
+## Four steps to Password-less
+
+Over the past few years, Microsoft has continued their commitment to enabling a world without passwords. At Microsoft Ignite 2017, we shared our four-step approach to password-less.
+
+
+
+### 1. Develop a password replacement offering
+Before you move away from passwords, you need something to replace them. With Windows 10, Microsoft introduced Windows Hello for Business, a strong, hardware protected two-factor credential that enables single-sign on to Azure Active Directory and Active Directory.
+
+Deploying Windows Hello for Business is the first step towards password-less. With Windows Hello for Business deployed, it coexists with password nicely. Users are likely to useWindows Hello for Business because of its convenience, especially when combined with biometrics. However, some workflows and applications may still need passwords. This early stage is about implementing an alternative and getting users used to it.
+
+### 2. Reduce user-visible password surface area
+With Windows Hello for Business and passwords coexisting in your environment, the next step towards password-less is to reduce the password surface. The environment and workflows need to stop asking for passwords. The goal of this step is to achieve a state where the user knows they have a password, but they never user it. This state helps decondition users from providing a password any time a password prompt shows on their computer. This is a how passwords are phished. Users who rarely, it at all, use their password are unlikely to provide it. Password prompts are no longer the norm.
+
+### 3. Transition into a password-less deployment
+Once the user-visible password surface has been eliminated, your organization can begin to transition those users into a password-less world. A world where:
+ - the user never types their password
+ - the user never changes their password
+ - the user does not know their password
+
+In this world, the user signs in to Windows 10 using Windows Hello for Business and enjoys single sign-on to Azure and Active Directory resources. If the user is forced to authenticate, their authentication uses Windows Hello for Business.
+
+### 4. Eliminate passwords from the identity directory
+The final step of the password-less story is where passwords simply do not exist. At this step, identity directories no longer persist any form of the password. This is where Microsoft achieves the long-term security promise of a truly password-less environment.
+
+## Methodology
+The four steps to password-less provides a overall view of how Microsoft envisions the road to password-less. But the road to password-less is frequently traveled and derailed by many. The scope of work is vast and filled with many challenges and frustrations. Nearly everyone wants the instant gratification of password-less, but can easily become overwhelmed in any of the steps. You are not alone and Microsoft understands. While there are many ways to accomplish password-less, here is one recommendation based on several years of research, investigation, and customer conversations.
+
+### Prepare for the Journey
+The road to password-less is a journey. The duration of that journey varies from each organization. It is important for IT decision makers to understand the criteria that influences the length of the journey.
+
+The most intuitive answer is the size of the organization, and that would be correct. However, what exactly determines size. One way to break down the size of the organization is:
+- Number of departments
+- Organization or department hierarchy
+- Number and type of applications and services
+- Number of work personas
+
+- Organization's IT structure
+
+#### Number of departments
+The number of departments within an organization varies. Most organizations have a common set of departments such as executive leadership, human resources, accounting, sales, and marketing. Other organizations will have those departments and additional ones such research and development or support. Small organizations may not segment their departments this explicitly while larger ones may. Additionally, there may be sub-departments, and sub-departments of those sub-departments as well.
+
+You need to know all the departments within your organization and you need to know which departments use computers and which do not. It is fine if a department does not use computer (probably rare, but acceptable). This is one less department with which you need to concern yourself. Nevertheless, ensure this department is in your list and you have assessed it is not applicable for password-less.
+
+Your count of the departments must be thorough and accurate, as well as knowing the stakeholders for those departments that will you and your staff on the road to password-less. Realistically, many of us lose sight of our organization chart and how it grows or shrinks over time. This is why you need to inventory all of them. Also, do not forget to include external departments such as vendors or federated partners. If your organizations goes password-less, but partners continue to use passwords and then access your corporate resources, you should know about it and include them in your password-less strategy.
+
+#### Organization or department hierarchy
+Organization and department hierarchy is the management layers within the departments or the organization as a whole. How the device is used, what applications and how they are used most likely differ between each department, but also within the structure of the department. To determine the correct password-less strategy, you need to know these differences across your organization. An executive leader is likely to use their device differently than a member of middle management in the sales department. Both of those use cases are likely different than how an individual contributor in the customer service department uses their device.
+
+#### Number and type of applications and services
+The number of applications within an organization is simply astonishing and rarely is there one centralized list that is accurate. Applications and services are the most critical item in your password-less assessment. Applications and services take considerable effort to move to a different type of authentication. That is not to say changing policies and procedures is not a daunting task, but there is something to be said of updating a company's set of standard operating procedure and security policies compared to changing 100 lines (or more) of authentication code in the critical path of your internally developed CRM application.
+
+Capturing the number of applications used is easier once you have the departments, their hierarchy, and their stakeholders. In this approach, you should have an organized list of departments and the hierarchy in each. You can now associate the applications that are used by all levels within each department. You'll also want to document whether the application is internally developed or commercially available off-the-shelf (COTS). If the later, document the manufacture and the version. Also, do not forget web-based applications or services when inventorying applications.
+
+#### Number of work personas
+Work personas is where the three previous efforts converge. You know the departments, the organizational levels within each department, the numbers of applications used by each, respectively, and the type of application. From this you want to create a work persona.
+
+A work persona classifies a category of user, title or role (individual contributor, manager, middle manager, etc), within a specific department to a collection of applications used. There is a high possibility and probability that you will have many work personas. These work personas will become units of work an you will refer to them in documentation and in meetings. You need to give them a name.
+
+Give your personas easy and intuitive name like Abby Accounting, Mark Marketing, or Sue Sales. If the organization levels are common across departments then decide on a first name that represents the common levels in a department. For example, Abby could be the first name of an individual contributor in any given department, while the first name Sue could represent someone from middle management in any given department. Additionally, you can use suffixes such as (I, II, Senior, etc.) to further define departmental structure for a given persona.
+
+Ultimately, create a naming convention that does not require your stakeholders and partners to read through a long list of tables or that needs a secret decoder ring. Also, if possible, try to keep the references as names of people. After all, you are talking about a person, who is in that department, who uses that specific software.
+
+#### Organization's IT structure
+IT department structures can vary more than the organization. Some IT departments are centralized while others are decentralized. Also, the road to password-less will likely have you interacting with the client authentication team, the deployment team, the security team, the PKI team, the Active Directory team, the cloud team, and the list continues. Most of these teams will be your partner on your journey to password-less. Ensure there is a password-less stakeholder on each of these teams and that the effort is understood and funded.
+
+#### Assess your Organization
+You have a ton of information. You have created your work personas, you identified your stakeholders throughout the different IT groups. Now what?
+
+By now you can see why its a journey and not a weekend project. You need to investigate user-visible password surfaces for each of your work personas. Once you identified the password surfaces, you need to mitigate them. Resolving some password surfaces are simple-- meaning a solution already exists in the environment and its a matter of moving users to it. Resolution to some passwords surfaces may exist, but are not deployed in your environment. That resolution results in a project that must be planned, tested, and then deployed. That is likely to span multiple IT departments with multiple people, and potentially one or more distributed systems. Those types of projects take time and need dedicated cycles. This same sentiment is true with in-house software development. Even with agile development methodologies, changing the way someone authenticates to an application is critical. Without the proper planning and testing, it has the potential to severely impact productivity.
+
+How long does it take to reach password-less? The answer is "it depends". It depends on the organizational alignment of a password-less strategy. Top-down agreement that password-less is the organization's goal makes conversations much easier. Easier conversations means less time spent convincing people and more time spent moving forward toward the goal. Top-down agreement on password-less as a priority within the ranks of other on-going IT projects helps everyone understand how to prioritize existing projects. Agreeing on priorities should reduce and minimize manager and executive level escalations. After these organizational discussions, modern project management techniques are used to continue the password-less effort. The organization allocates resources based on the priority (after they agreed on the strategy). Those resources will:
+- work through the work personas
+- organize and deploy user acceptance testing
+- evaluate user acceptance testing results for user-visible password surfaces
+- work with stakeholders to create solutions that mitigate user-visible password surfaces
+- add the solution to the project backlog and prioritize against other projects
+- deploy solution
+- User acceptance testing to confirm the solution mitigates the user-visible password surface
+- Repeat as needed
+
+Your organization's journey to password-less may take some time to get there. Counting the number of work personas and the number of applications is probably a good indicator of the investment. Hopefully, your organization is growing, which means that the list of personas and the list of applications is unlikely to shrink. If the work to go password-less today is *n*, then it is likely that to go password-less tomorrow is *n x 2* or perhaps more, *n x n*. Do not let the size or duration of the project be a distraction. As you progress through each work persona, the actions and tasks will become more familiar for you and your stakeholders. Scope the project to sizable, realistic phases, pick the correct work personas, and soon you will see parts of your organization transition to password-less.
+
+### Where to start?
+What is the best guidance for kicking off the journey to password-less? You will want to show you management a proof of concept as soon as possible. Ideally, you want to show this at each step of your password-less journey. Keeping password-less top of mind and showing consistent progress keeps everyone focused.
+
+#### Work persona
+You begin with your work personas. These were part of your preparation process. They have a persona name, such as Abby Accounting II, or any other naming convention your organization defined. That work persona includes a list of all the applications that Abby uses to perform her assigned duties in the accounting department. To start, you need to pick a work persona. This is the targeted work persona you will enable to climb the password-less steps.
+
+> [!IMPORTANT]
+> Avoid using any work personas from your IT department. This is probably the worst way to start the password-less journey. IT roles are very difficult and time consuming. IT workers typically have multiple credentials, run a multitude of scripts and custom applications, and are the worst offenders of password usage. It is better to save these work personas for the middle or end of your journey.
+
+Review your collection of work personas. Early in your password-less journey, identify personas that have the fewest applications. These work personas could represent an entire department or two. These are the perfect work personas for your proof-of-concept or pilot.
+
+Most organizations host their proof of concept in a test lab or environment. To do that with password-less may be more challenging and take more time. To test in a lab, you must first duplicate the environment of the targeted persona. This could be a few days or several weeks depending on the complexity of targeted work persona.
+
+You will want to balance testing in a lab with providing results to management quickly. Continuing to show forward progress on your password-less journey is always good thing. If there are ways you can test in production with low or now risk, that may be advantageous to your time line.
+
+## The Process
+
+The journey to password-less is to take each work persona through each password-less step. In the begging, we encourage working with one persona at a time to ensure team members and stakeholders are familiar with the process. Once comfortable with the process, you can cover as many work personas in parallel as resources allow. The process looks something like
+
+1. Password-less replacement offering (Step 1)
+ 1. Identify test users that represent the targeted work persona.
+ 2. Deploy Windows Hello for Business to test users.
+ 3. Validate password and Windows Hello for Business work.
+2. Reduce User-visible Password Surface (Step 2)
+ 1. Survey test user workflow for password usage.
+ 2. Identify password usage and plan, develop, and deploy password mitigations.
+ 3. Repeat until all user password usage is mitigated.
+ 4. Remove password capabilities from the Windows.
+ 5. Validate **all** workflows do not need passwords.
+3. Transition into a password-less (Step 3)
+ 1. Awareness campaign and user education.
+ 2. Including remaining users that fit the work persona.
+ 3. Validate **all** users of the work personas do not need passwords.
+ 4. Configure user accounts to disallow password authentication.
+
+After successfully moving a work persona to password-less, you can prioritize the remaining work personas, and repeat the process.
+
+### Password-less replacement offering (Step 1)
+THe first step to password-less is providing an alternative to passwords. Windows 10 provides an affordable and easy in-box alternative to passwords, Windows Hello for Business, a strong, two-factor authentication to Azure Active Directory and Active Directory.
+
+#### Identify test users that represent the targeted work persona
+A successful transition to password-less heavily relies on user acceptance testing. It is impossible for you to know how every work persona goes about their day-to-day activities, or to accurately validate them. You need to enlist the help of users that fit the targeted work persona. You only need a few users from the targeted work persona. As you cycle through step 2, you may want to change a few of the users (or add a few) as part of your validation process.
+
+#### Deploy Windows Hello for Business to test users
+Next, you will want to plan your Windows Hello for Business deployment. Your test users will need an alternative way to sign-in during step 2 of the password-less journey. Use the [Windows Hello for Business Planning Guide](hello-planning-guide.md) to help learn which deployment is best for your environment. Next, use the [Windows Hello for Business deployment guides](hello-deployment-guide.md) to deploy Windows Hello for Business.
+
+With the Windows Hello for Business infrastructure in place, you can limit Windows Hello for Business enrollments to the targeted work personas. The great news is you will only need to deploy the infrastructure once. When other targeted work personas need to provision Windows Hello for Business, you can simply add them to a group. You will use the first work persona to validate your Windows Hello for Business deployment.
+
+> [!NOTE]
+> There are many different ways to connect a device to Azure. Deployments may vary based on how the device is joined to Azure Active Directory. Review your planning guide and deployment guide to ensure additional infrastructure is not needed for an additional Azure joined devices.
+
+#### Validate password and Windows Hello for Business work
+In this first step, passwords and Windows Hello for Business must coexist. You want to validate that while your targeted work personas can sign in and unlock using Windows Hello for Business, but they can also sign-in, unlock, and use passwords as needed. Reducing the user-visible password surface too soon can create frustration and confusion with your targeted user personas.
+
+### Reduce User-visible Password Surface (Step 2)
+Before you move to step 2, ensure you have:
+- selected your targeted work persona.
+- identified your test users that represented the targeted work persona.
+- deployed Windows Hello for Business to test users.
+- validated passwords and Windows Hello for Business both work for the test users.
+
+#### Survey test user workflow for password usage
+Now is the time to learn more about the targeted work persona. You have a list of applications they use, but you do not know what, why, when, and how frequently. This information is important as your further your progress through step 2.
+
+Test users create the workflows associated with the targeted work persona. Their initial goal is to do one simply task. Document password usage. This list is not a comprehensive one, but it gives you an idea of the type of information you want. The general idea is to learn about all the scenarios in which that work persona encounters a password. A good approach is:
+- What is the name of the application that asked for a password?.
+- Why do they use the application that asked for a password? (Example: is there more than one application that can do the same thing?).
+- What part of their workflow makes them use the application? Try to be as specific as possible (I use application x to issue credit card refunds for amounts over y.).
+- How frequently do you use this application in a given day? week?
+- Is the password you type into the application the same as the password you use to sign-in to Windows?
+
+Some organizations will empower their users to write this information while some may insist on having a member of the IT department shadow them. An objective viewer may notice a password prompt that the user overlooks simply because of muscle memory. As previously mentioned, this information is critical. You could miss one password prompt which could delay the transition to password-less.
+
+#### Identify password usage and plan, develop, and deploy password mitigations
+Your test users have provided you valuable information that describes the how, what, why and when they use a password. It is now time for your team to identify each of these password use cases and understand why the user must use a password.
+
+Create a master list of the scenarios. Each scenario should have a clear problem statement. Name the scenario with a one-sentence summary of the problem statement. Include in the scenario the results of your team's investigation as to why the user is prompted by a password. Include relevant, but accurate details. If its policy or procedure driven, then include the name and section of the policy that dictates why the workflow uses a password.
+
+Keep in mind your test users will not uncover all scenarios. Some scenarios you will need to force on your users because they low percentage scenarios. Remember to include scenarios like:
+- Provisioning a new brand new user without a password.
+- Users who forget the PIN or other remediation flows when the strong credential is unusable.
+
+Next, review your master list of scenarios. You can start with the workflows that are dictated by process or policy or, you can begin with workflows that need technical solutions-- whichever of the two is easier or quicker. This will certainly vary by organization.
+
+Start mitigating password usages based on the workflows of your targeted personas. Document the mitigation as a solution to your scenario. Don't worry about the implementation details for the solution. A overview of the changes needed to reduce the password usages is all you need. If there are technical changes needed either infrastructure or code changes-- the exact details will likely be included in the project documentation. However your organization tracks projects, create a new project in that system. Associate your scenario to that project and start the processes needed to get that project funded.
+
+Mitigating password usage with applications is one or the more challenging obstacle in the journey to password-less. If your organization develops the application, then you are in better shape the common-off-the-shelf software (COTS).
+
+The ideal mitigation for applications that prompt the user for a password is to enable those enable those applications to use an existing authenticated identity, such as Azure Active Directory or Active Directory. Work with the applications vendors to have them add support for Azure identities. For on-premises applications, have the application use Windows integrated authentication. The goal for your users should be a seamless single sign-on experience where each user authenticates once-- when they sign-in to Windows. Use this same strategy for applications that store their own identities in their own databases.
+
+Each scenario on your master list should now have a problem statement, an investigation as to why the password was used, and a mitigation plan on how to make the password usage go away. Armed with this data, one-by-one, close the gaps on user-visible passwords. Change policies and procedures as needed, make infrastructure changes where possible. Convert in-house applications to use federated identities or Windows integrated authentication. Work with third-party software vendors to update their software to support federated identities or Windows integrated authenticate.
+
+#### Repeat until all user password usage is mitigated
+Some or all of your mitigations are in place. You need to validate your solutions have solved their problem statements. This is where you rely on your test users. You want to keep a good portion of your first test users, but this is a good opportunity to replace a few or add a few. Survey test users workflow for password usage. If all goes well, you have closed most or all the gaps. A few are likely to remain. Evaluate your solutions and what went wrong, change your solution as needed until you reach a solution that removes your user's need to type a password. If your stuck, others might be too. Use the forums from various sources or your network of IT colleague to describe your problem and see how others are solving it. If your out of options, contact Microsoft for assistance.
+
+#### Remove password capabilities from the Windows
+You believe you have mitigates all the password usage for the targeted work persona. Now comes the true test-- configure Windows so the user cannot use a password.
+
+Windows provides two ways to prevent your users from using passwords. You can use an interactive logon security policy to only allow Windows Hello for Business sign-in and unlocks, or you can exclude the password credential provider.
+
+##### Security Policy
+You can use Group Policy to deploy an interactive logon security policy setting to the computer. This policy setting is found under **Computer Configuration > Policies > Windows Settings > Local Policy > Security Options**. The name of the policy setting depends on the version of the operating systems you use to configure Group Policy.
+
+
+**Windows Server 2016 and earlier**
+The policy name for these operating systems is **Interactive logon: Require smart card**.
+
+
+**Windows 10, version 1703 or later using Remote Server Administrator Tools**
+The policy name for these operating systems is **Interactive logon: Require Windows Hello for Business or smart card**.
+
+
+When you enables this security policy setting, Windows prevents users from signing in or unlocking with a password. The password credential provider remains visible to the user. If a user tries to use a password, Windows informs the user they must use Windows Hello for Business or a smart card.
+
+#### Excluding the password credential provider
+You can use Group Policy to deploy an administrative template policy settings to the computer. This policy settings is found under **Computer Configuration > Policies > Administrative Templates > Logon**
+
+
+The name of the policy setting is **Exclude credential providers**. The value to enter in the policy to hide the password credential provider is **60b78e88-ead8-445c-9cfd-0b87f74ea6cd**.
+
+
+Excluding the password credential provider hides the password credential provider from Windows and any application that attempts to load it. This prevents the user from entering a password using the credential provider. However, this does not prevent applications from creating their own password collection dialogs and prompting the user for a password using custom dialogs.
+
+#### Validate all workflows do not need passwords
+This is the big moment. You have identified password usage, developed solutions to mitigate password usage, and have removed or disabled password usage from Windows. In this configuration, your users will not be able to use a passwords. Users will be blocked is any of their workflows ask them for a password. Ideally, your test users should be able to complete all the work flows of the targeted work persona without any password usage. Do not forget those low percentage work flows, such as provisioning a new user or a user that forgot their PIN or cannot use their strong credential. Ensure those scenarios are validated as well.
+
+### Transition into a password-less deployment (Step 3)
+Congratulations! You are ready to transition one or more portions of your organization to a password-less deployment. You have validated the targeted work-persona is ready to go where the user no longer needs to know or use their password. You are just few steps away from declaring success.
+
+#### Awareness and user education
+In this last step, you are going to include the remaining users that fit the targeted work persona to the wonderful world of password-less. Before you do this, you want to invest in an awareness campaign.
+
+An awareness campaign is introduces the users to the new way of authenticating to their device, such as using Windows Hello for Business. The idea of the campaign is to positively promote the change to the users in advance. Explain the value and why your company is changing. The campaign should provide dates and encourage questions and feedback. This campaign can coincide user education, where you can show the users the changes and, if your environment allows, enable the users to try the experience out.
+
+#### Including remaining users that fit the work persona
+You have implemented the awareness campaign for the targeted users. These users are informed and ready to transition to password-less. Add the remaining users that match the targeted work persona to your deployment.
+
+#### Validate **all** users of the work personas do not need passwords.
+You have successfully transitioned all users for the targeted work persona to password-less. Monitor the users within the work persona to ensure they do not encounter any issues while working in a password-less environment.
+
+Track all reported issues. Set priority and severity to each reported issue and have your team triage the issues appropriately. As you triage issues, some things to consider are:
+- Is the reporting user performing a task outside the work persona?
+- Is the reported issue affecting the entire work persona, or only specific users?
+- Is the outage a result of a misconfiguration?
+- Is the outage a overlooked gap from step 2?
+
+Each organization's priority and severity will differ however most organizations consider work stoppages fairly significant. Your team should pre-define levels of priority and severity. With each of these levels, create service level agreements (SLAs) for each combination of severity and priority and hold everyone accountable to those agreements. Reactive planning enables people to spend more time on the issue and resolving it and less time on process.
+
+Resolve the issues per your service level agreements. Higher severity items may require returning some or all of the user's password surface. Clearly this is not the end goal but, do not let this slow your password-less momentum. Refer to how you reduced the user's password surface in step 2 and progress forward to a solution, deploying that solution and validating.
+
+#### Configure user accounts to disallow password authentication.
+You transitioned all the users for the targeted work persona to a password-less environment and you have successfully validated all their workflows. The last step to complete the password-less transition is to remove the user's knowledge of the password and prevent the authenticating authority from accepting passwords.
+
+You can change the user's password to random data and prevent domain controllers from allowing users to use passwords for interactive sign-ins using an account configuration on the user object.
+
+The account options on a user account includes an option -- **Smart card is required for interactive logon**, also known as (SCRIL).
+
+> [!NOTE]
+> Do not confuse the Interactive Logon security policy for SCRIL. Security policies are enforced on the client (locally). A user account configured for SCRIL is enforced at the domain controller.
+
+
+**SCRIL setting for a user on Active Directory Users and Computers.**
+
+When you configure an user account for SCRIL, Active Directory changes the affected user's password to a random 128 bits of data. Additionally, domain controllers hosting the user account do not allow the user to sign-in interactively with a password. Also, users will no longer be troubled with needing to change their password when it expires, because passwords for SCRIL users in domains with a Windows Server 2012 R2 or early domain functional level do not expire. The users is effectively password-less because:
+- the do not know their password.
+- their password is 128 random bits of data and is likely to include non-typable characters.
+- the user is not asked to change their password
+- domain controllers do not allow passwords for interactive authentication
+
+
+**SCRIL setting for a user in Active Directory Administrative Center on Windows Server 2012.**
+
+> [!NOTE]
+> Although a SCRIL user's password never expires in early domains, you can toggle the SCRIL configuration on a user account (clear the check box, save the settings, select the check box and save the settings) to generate a new random 128 bit password. However, you should consider upgrading the domain to Windows Server 2016 domain forest functional level and allow the domain controller to do this for you automatically.
+
+
+**SCRIL setting for a user in Active Directory Administrative Center on Windows Server 2016.**
+
+> [!NOTE]
+> Windows Hello for Business was formerly known as Microsoft Passport.
+
+##### Automatic password change for SCRIL configured users
+Domains configured for Windows Server 2016 domain functional level can further secure the unknown password for a SCRIL enabled users by configuring the domain to automatically change the password for SCRIL users.
+
+In this configuration, passwords for SCRIL configured users expired based on Active Directory password policy settings. When the SCRIL user authentication from a domain controller, the domain controller recognizes the password has expired, and automatically generates a new random 128 bit password for the user as part of the authentication. What is great about this feature is your users do not experience any change password notifications or experience any authentication outages.
+
+
+> [!NOTE]
+> Some components within Windows 10, such as Data Protection APIs and NTLM authentication, still need artifacts of a user possessing a password. This configuration provides interoperability with while reducing the usage surface while Microsoft continues to close the gaps to remove the password completely.
+
+## The Road Ahead
+The information presented here is just the beginning. We will update this guide with improved tool and methods and scenarios, like Azure AD joined and MDM managed environments, As we continue to invest in password-less, we would love to hear from you. Your feedback is important. Send us an email at [pwdless@microsoft.com](mailto:pwdless@microsoft.com?subject=Passwordless%20Feedback).
+
diff --git 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
new file mode 100644
index 0000000000..ec19abbc74
--- /dev/null
+++ 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.
+
+
+
+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)
diff --git a/windows/security/identity-protection/hello-for-business/toc.md b/windows/security/identity-protection/hello-for-business/toc.md
index ae838d1fcc..de55fa465e 100644
--- 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)
@@ -14,7 +20,7 @@
## [Windows Hello for Business Deployment Guide](hello-deployment-guide.md)
### [Hybrid Azure AD Joined Key Trust Deployment](hello-hybrid-key-trust.md)
-#### [Prerequistes](hello-hybrid-key-trust-prereqs.md)
+#### [Prerequisites](hello-hybrid-key-trust-prereqs.md)
#### [New Installation Baseline](hello-hybrid-key-new-install.md)
#### [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md)
#### [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md)
@@ -28,6 +34,10 @@
#### [Configure Windows Hello for Business policy settings](hello-hybrid-cert-whfb-settings.md)
#### [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md)
+### [Azure AD Join Single Sign-on Deployment Guides](hello-hybrid-aadj-sso.md)
+#### [Configure Azure AD joined devices for On-premises Single-Sign On using Windows Hello for Business](hello-hybrid-aadj-sso-base.md)
+#### [Using Certificates for AADJ On-premises Single-sign On](hello-hybrid-aadj-sso-cert.md)
+
### [On Premises Key Trust Deployment](hello-deployment-key-trust.md)
#### [Validate Active Directory prerequisites](hello-key-trust-validate-ad-prereq.md)
#### [Validate and Configure Public Key Infrastructure](hello-key-trust-validate-pki.md)
@@ -44,4 +54,9 @@
#### [Configure Windows Hello for Business Policy settings](hello-cert-trust-policy-settings.md)
## [Windows Hello for Business Features](hello-features.md)
-### [Multifactor Unlock](feature-multifactor-unlock.md)
\ No newline at end of file
+### [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)
+
+##[Password-less Strategy](passwordless-strategy.md)
\ No newline at end of file
diff --git a/windows/security/information-protection/bitlocker/bitlocker-management-for-enterprises.md b/windows/security/information-protection/bitlocker/bitlocker-management-for-enterprises.md
index 691e7ec1de..430fd8fbe7 100644
--- a/windows/security/information-protection/bitlocker/bitlocker-management-for-enterprises.md
+++ b/windows/security/information-protection/bitlocker/bitlocker-management-for-enterprises.md
@@ -8,7 +8,7 @@ ms.sitesec: library
ms.pagetype: security
ms.localizationpriority: medium
author: brianlic-msft
-ms.date: 07/27/2018
+ms.date: 09/17/2018
---
# BitLocker Management for Enterprises
@@ -21,7 +21,7 @@ Though much Windows BitLocker [documentation](bitlocker-overview.md) has been pu
Companies that image their own computers using Microsoft System Center 2012 Configuration Manager SP1 (SCCM) or later can use an existing task sequence to [pre-provision BitLocker](https://technet.microsoft.com/library/hh846237.aspx#BKMK_PreProvisionBitLocker) encryption while in Windows Preinstallation Environment (WinPE) and can then [enable protection](https://technet.microsoft.com/library/hh846237.aspx#BKMK_EnableBitLocker). This can help ensure that computers are encrypted from the start, even before users receive them. As part of the imaging process, a company could also decide to use SCCM to pre-set any desired [BitLocker Group Policy](https://technet.microsoft.com/library/ee706521(v=ws.10).aspx).
-Enterprises can use [Microsoft BitLocker Administration and Management (MBAM)](https://docs.microsoft.com/microsoft-desktop-optimization-pack/mbam-v25/) to manage client computers with BitLocker that are domain-joined on-premises until [mainstream support ends in July 2019](https://support.microsoft.com/en-us/lifecycle/search?alpha=Microsoft%20BitLocker%20Administration%20and%20Monitoring%202.5%20Service%20Pack%201) or they can receive extended support until July 2024. Thus, over the next few years, a good strategy for enterprises will be to plan and move to cloud-based management for BitLocker. Refer to the [PowerShell examples](#powershell-examples) to see how to store recovery keys in Azure Active Directory (Azure AD).
+Enterprises can use [Microsoft BitLocker Administration and Monitoring (MBAM)](https://docs.microsoft.com/microsoft-desktop-optimization-pack/mbam-v25/) to manage client computers with BitLocker that are domain-joined on-premises until [mainstream support ends in July 2019](https://support.microsoft.com/en-us/lifecycle/search?alpha=Microsoft%20BitLocker%20Administration%20and%20Monitoring%202.5%20Service%20Pack%201) or they can receive extended support until July 2024. Thus, over the next few years, a good strategy for enterprises will be to plan and move to cloud-based management for BitLocker. Refer to the [PowerShell examples](#powershell-examples) to see how to store recovery keys in Azure Active Directory (Azure AD).
## Managing devices joined to Azure Active Directory
diff --git a/windows/security/information-protection/index.md b/windows/security/information-protection/index.md
index 4da67275f3..5c7a8d5795 100644
--- a/windows/security/information-protection/index.md
+++ b/windows/security/information-protection/index.md
@@ -6,7 +6,7 @@ ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
-ms.date: 02/05/2018
+ms.date: 09/17/2018
---
# Information protection
@@ -16,4 +16,8 @@ Learn more about how to secure documents and other data across your organization
| Section | Description |
|-|-|
| [BitLocker](bitlocker/bitlocker-overview.md)| Provides information about BitLocker, which is a data protection feature that integrates with the operating system and addresses the threats of data theft or exposure from lost, stolen, or inappropriately decommissioned computers. |
+| [Encrypted Hard Drive](bitlocker/bitlocker-overview.md)| Encrypted Hard Drive uses the rapid encryption that is provided by BitLocker Drive Encryption to enhance data security and management. |
+| [Kernel DMA Protection for Thunderbolt™ 3](kernel-dma-protection-for-thunderbolt.md)| Kernel DMA Protection protects PCs against drive-by Direct Memory Access (DMA) attacks using PCI hot plug devices connected to Thunderbolt™ 3 ports. |
| [Protect your enterprise data using Windows Information Protection (WIP)](windows-information-protection/protect-enterprise-data-using-wip.md)|Provides info about how to create a Windows Information Protection policy that can help protect against potential corporate data leakage.|
+| [Secure the Windows 10 boot process](secure-the-windows-10-boot-process.md)| Windows 10 supports features to help prevent rootkits and bootkits from loading during the startup process. |
+| [Trusted Platform Module](tpm/trusted-platform-module-top-node.md)| Trusted Platform Module (TPM) technology is designed to provide hardware-based, security-related functions. A TPM chip is a secure crypto-processor that helps you with actions such as generating, storing, and limiting the use of cryptographic keys. |
diff --git a/windows/security/threat-protection/security-policy-settings/network-access-restrict-clients-allowed-to-make-remote-sam-calls.md b/windows/security/threat-protection/security-policy-settings/network-access-restrict-clients-allowed-to-make-remote-sam-calls.md
index 6b9f166e9f..1ad7ec6aeb 100644
--- a/windows/security/threat-protection/security-policy-settings/network-access-restrict-clients-allowed-to-make-remote-sam-calls.md
+++ b/windows/security/threat-protection/security-policy-settings/network-access-restrict-clients-allowed-to-make-remote-sam-calls.md
@@ -8,7 +8,7 @@ ms.pagetype: security
ms.localizationpriority: medium
ms.localizationpriority: medium
author: justinha
-ms.date: 07/27/2017
+ms.date: 09/17/2018
---
# Network access: Restrict clients allowed to make remote calls to SAM
@@ -130,7 +130,7 @@ Compare the security context attempting to remotely enumerate accounts with the
### Event Throttling
A busy server can flood event logs with events related to the remote enumeration access check. To prevent this, access-denied events are logged once every 15 minutes by default. The length of this period is controlled by the following registry value.
-|Registry Path|System\CurrentControlSet\Control\Lsa\
+|Registry Path|HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\ |
|---|---|
Setting |RestrictRemoteSamEventThrottlingWindow|
Data Type |DWORD|