Merge branch 'master' into App-v-revision

windows/configuration/customize-and-export-start-layout.md

@@ -10,7 +10,7 @@ author: jdeckerms
 ms.author: jdecker
 ms.topic: article
 ms.localizationpriority: medium
-ms.date: 10/16/2017
+ms.date: 09/18/2018
 ---
 
 # Customize and export Start layout
@@ -132,6 +132,8 @@ When you have the Start layout that you want your users to see, use the [Export-
     </tbody>
     </table>
 
+3. (Optional) Edit the .xml file to add [a taskbar configuration](configure-windows-10-taskbar.md) or to [modify the exported layout](start-layout-xml-desktop.md). When you make changes to the exported layout, be aware that [the order of the elements in the .xml file are critical.](start-layout-xml-desktop.md#required-order)
+
 >[!IMPORTANT]
 >If the Start layout that you export contains tiles for desktop (Win32) apps or .url links, **Export-StartLayout** will use **DesktopApplicationLinkPath** in the resulting file. Use a text or XML editor to change **DesktopApplicationLinkPath** to **DesktopApplicationID**. See [Specify Start tiles](start-layout-xml-desktop.md#specify-start-tiles) for details on using the app ID in place of the link path. 
 

windows/deployment/update/windows-analytics-azure-portal.md

@@ -5,7 +5,7 @@ keywords: Device Health, oms, Azure, portal, operations management suite, add, m
 ms.prod: w10
 ms.mktglfcycl: deploy
 ms.sitesec: library
-ms.date: 08/21/2018
+ms.date: 09/12/2018
 ms.pagetype: deploy
 author: jaimeo
 ms.author: jaimeo
@@ -35,7 +35,7 @@ To check the Log Analytics workspaces you can access, select **Log Analytics**.
 
 If you do not see your workspace in this view, you do not have access to the underlying Azure subscription. To view and assign permissions for a workspace, select its name and then, in the flyout that opens, select **Access control (IAM)**. You can view and assign permissions for a subscription similarly by selecting the subscription name and selecting **Access control (IAM)**.
 
-Both the workspace and Azure subscription require at least "read" permissions. To make changes (for example, to set app importantance in Upgrade Readiness), both the subscription and workspace require "contributor" permissions. You can view your current role and make changes in other roles by using the **Access control (IAM)** tab in Azure.
+The Azure subscription requires at least "Log Analytics Reader" permission. Making changes (for example, to set app importance in Upgrade Readiness) requires "Log Analytics Contributor" permission. You can view your current role and make changes in other roles by using the Access control (IAM) tab in Azure. These permissions will be inherited by Azure Log Analytics.
 
 When permissions are configured, you can select the workspace and then select **Workspace summary** to see information similar to what was shown in the OMS overview page.
 

windows/privacy/diagnostic-data-viewer-overview.md

@@ -31,7 +31,9 @@ Before you can use this tool, you must turn on data viewing in the **Settings**
 **To turn on data viewing**
 1. Go to **Start**, select **Settings** > **Privacy** > **Diagnostics & feedback**.
 
-2. Under **Diagnostic data**, turn on the **If data viewing is enabled, you can see your diagnostics data** option.<p>![Location to turn on data viewing](images/ddv-data-viewing.png)
+2. Under **Diagnostic data**, turn on the **If data viewing is enabled, you can see your diagnostics data** option.
+
+    ![Location to turn on data viewing](images/ddv-data-viewing.png)
 
 ### 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.<p>![Location to turn on the Diagnostic Data Viewer](images/ddv-settings-launch.png)<p>-OR-<p> Go to **Start** and search for _Diagnostic Data Viewer_.
+2. Under **Diagnostic data**, select the **Diagnostic Data Viewer** button.
+
+    ![Location to turn on the Diagnostic Data Viewer](images/ddv-settings-launch.png)<br><br>-OR-<br><br>
+    
+    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,15 +58,31 @@ 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.<p> 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.<p>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.<p>Selecting a check box lets you filter between the diagnostic event categories.
+     ![View your diagnostic events](images/ddv-event-view.png)
 
-- **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.<p>To signify your contribution, you’ll see this icon (![Icon to review the device-level sampling](images/ddv-device-sample.png)) 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 (![Icon to review the event-level sampling](images/ddv-event-sample.png)). 
+- **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. 
 
-- **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.<p>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)**.
+    Selecting an event opens the detailed JSON view, with the matching text highlighted.
+
+- **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.
+    
+     ![Filter your diagnostic event categories](images/ddv-event-view-filter.png)
+
+- **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 (![Icon to review the device-level sampling](images/ddv-device-sample.png)) 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 (![Icon to review the event-level sampling](images/ddv-event-sample.png)). 
+
+- **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.
+
+ 	![Send event feedback](images/ddv-event-feedback.png)
+
+    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.
@@ -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.<p>![Location to turn off data viewing](images/ddv-settings-off.png)
+2. Under **Diagnostic data**, turn off the **If data viewing is enabled, you can see your diagnostics data** option.
+
+    ![Location to turn off data viewing](images/ddv-settings-off.png)
 
 ## 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**.<p>-OR-<p>Go to **Start** and search for _Problem Reports_.<p>The **Review problem reports** tool opens, showing you your Windows Error Reporting reports, along with a status about whether it was sent to Microsoft.<p>![View problem reports tool with report statuses](images/ddv-problem-reports-screen.png)
+1. Go to **Start**, select **Control Panel** > **All Control Panel Items** > **Security and Maintenance** > **Problem Reports**.<br><br>-OR-<br><br>
+	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.
+
+    ![View problem reports tool with report statuses](images/ddv-problem-reports-screen.png)

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.<br>
+You represent signal rules in XML.  Each signal rule has an starting and ending **rule** element that contains the **schemaVersion** attribute and value.  The current supported schema version is 1.0.<br>
 **Example**
 ```
 <rule schemaVersion="1.0">
@@ -89,9 +93,10 @@ Each rule element has a **signal** element.  All signal elements have a **type**
 |Attribute|Value|
 |---------|-----|
 | type| "bluetooth" or "ipConfig" (Windows 10, version 1709)| 
+| type| "wifi" (Windows 10, version 1803)
 
 #### Bluetooth
-You define the bluetooth signal with additional attribute in the signal elment. The bluetooth configuration does not use any other elements. You can end the signal element with short ending tag "\/>".
+You define the bluetooth signal with additional attribute in the signal element. The bluetooth configuration does not use any other elements. You can end the signal element with short ending tag "\/>".
 
 |Attribute|Value|Required|
 |---------|-----|--------|
@@ -188,13 +193,61 @@ The IPv6 DNS server represented in Internet standard hexadecimal encoding. An IP
 <ipv6DnsServer>21DA:00D3:0000:2F3B:02AA:00FF:FE28:9C5A%2</ipv6DnsServer>
 ```
 ##### dnsSuffix
-The fully qualified domain name of your 
+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.<br>
-s 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.<br>
 **Example**
 ```
 <dnsSuffix>corp.contoso.com</dnsSuffix>
 ```
 
+#### Wi-Fi
+
+**Applies to:**
+-   Windows 10, version 1803
+
+You define Wi-Fi signals using one or more wifi elements.  Each element has a string value.  Wifi elements do not have attributes or nested elements.
+
+#### SSID
+Contains the service set identifier (SSID) of a wireless network.  The SSID is the name of the wireless network.  The SSID element is required.<br>
+```
+<ssid>corpnetwifi</ssid>
+```
+
+#### BSSID
+Contains the basic service set identifier (BSSID) of a wireless access point.  the BSSID is the mac address of the wireless access point.  The BSSID element is optional.<br>
+**Example**
+```
+<bssid>12-ab-34-ff-e5-46</bssid>
+```
+
+#### Security
+Contains the type of security the client uses when connecting to the wireless network.  The security element is required and must contain one of the following values:<br>
+
+|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**
+```
+<security>WPA2-Enterprise</security> 
+```
+#### TrustedRootCA
+Contains the thumbprint of the trusted root certificate of the wireless network. This may be any valid trusted root certificate. The value is represented as hexadecimal string where each byte in the string is separated by a single space.  This element is optional.<br>
+**Example**
+```
+<trustedRootCA>a2 91 34 aa 22 3a a2 3a 4a 78 a2 aa 75 a2 34 2a 3a 11 4a aa</trustedRootCA>
+```
+#### Sig_quality
+Contains numeric value ranging from 0 to 100 to represent the wireless network's signal strength needed to be considered a trusted signal.<br>
+**Example**
+```
+<sig_quality>80</sig_quality>
+```
+ 
 ### Sample Trusted Signal Congfigurations
 
 These examples are wrapped for readability.  Once properly formatted, the entire XML contents must be a single line.
@@ -240,7 +293,19 @@ This example configures the same as example 2 using compounding And elements.  T
 </and>
 </rule>
 ```
-
+#### Example 4 
+This example configures Wi-Fi as a trusted signal (Windows 10, version 1803)
+```
+<rule version="1.0"> 
+  <signal type="wifi"> 
+    <ssid>contoso</ssid> 
+    <bssid>12-ab-34-ff-e5-46</bssid> 
+    <security>WPA2-Enterprise</security> 
+    <trustedRootCA>a2 91 34 aa 22 3a a2 3a 4a 78 a2 aa 75 a2 34 2a 3a 11 4a aa</trustedRootCA> 
+    <sig_quality>80</sig_quality> 
+  </signal> 
+</rule> 
+```
 
 ## Deploying Multifactor Unlock
 
@@ -249,7 +314,7 @@ This example configures the same as example 2 using compounding And elements.  T
 
 ### How to configure Multifactor Unlock policy settings
 
-You need a Windows 10, version 1709 workstation to run the Group Policy Management Console, which provides the latest Windows Hello for Business  Group Policy settings, which includes muiltifactor unlock. To run the Group Policy Management Console, you need to install the Remote Server Administration Tools for Windows 10. You can download these tools from the [Microsoft Download Center](https://www.microsoft.com/en-us/download/details.aspx?id=45520). Install the Remote Server Administration Tools for Windows 10 on a computer running Windows 10, version 1709.
+You need a Windows 10, version 1709 workstation to run the Group Policy Management Console, which provides the latest Windows Hello for Business  Group Policy settings, which includes multi-factor unlock. To run the Group Policy Management Console, you need to install the Remote Server Administration Tools for Windows 10. You can download these tools from the [Microsoft Download Center](https://www.microsoft.com/en-us/download/details.aspx?id=45520). Install the Remote Server Administration Tools for Windows 10 on a computer running Windows 10, version 1709.
 
 Alternatively, you can create copy the .ADMX and .ADML files from a Windows 10, version 1703 to their respective language folder on a Windows Server or you can create a Group Policy Central Store and copy them their respective language folder. See [How to create and manage the Central Store for Group Policy Administrative Templates in Windows](https://support.microsoft.com/help/3087759/how-to-create-and-manage-the-central-store-for-group-policy-administrative-templates-in-windows) for more information.
 
@@ -278,7 +343,7 @@ The Group Policy object contains the policy settings needed to trigger Windows H
 11. Click **Ok** to close the **Group Policy Management Editor**. Use the **Group Policy Management Console** to deploy the newly created Group Policy object to your organization's computers.
 
  ## Troubleshooting
-Mulitfactor unlock writes events to event log under **Application and Services Logs\Microsoft\Windows\HelloForBusiness** with the category name **Device Unlock**.
+Multi-factor unlock writes events to event log under **Application and Services Logs\Microsoft\Windows\HelloForBusiness** with the category name **Device Unlock**.
 
 ### Events
 

windows/security/identity-protection/hello-for-business/hello-adequate-domain-controllers.md

@@ -9,15 +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
 ---
 # Planning an adequate number of Windows Server 2016 Domain Controllers for Windows Hello for Business deployments
 
 **Applies to**
--   Windows 10
+-   Windows 10, version 1702 or later
-
+-   Hybrid or On-Premises deployment
-
+-   Key trust
->This section only applies to Hybrid and On-premises key trust deployments.
 
 ## How many is adequate
 
@@ -29,23 +28,23 @@ Determining an adequate number of Windows Server 2016 domain controllers is impo
  
 Consider a controlled environment where there are 1000 client computers and the authentication load of these 1000 client computers is evenly distributed across 10 domain controllers in the environment.  The Kerberos AS requests load would look something like the following.
 
-![dc-chart1](images/dc-chart1.png)
+![dc-chart1](images/plan/dc-chart1.png)
 
 The environment changes.  The first change includes DC1 upgraded to Windows Server 2016 to support Windows Hello for Business key-trust authentication. Next, 100 clients enroll for Windows Hello for Business using the public key trust deployment.   Given all other factors stay constant, the authentication would now look like the following.
 
-![dc-chart2](images/dc-chart2.png)
+![dc-chart2](images/plan/dc-chart2.png)
 
 The Windows Server 2016 domain controller is handling 100 percent of all public key trust authentication.  However, it is also handling 10 percent of the password authentication. Why?  This behavior occurs because domain controllers 2- 10 only support password and certificate trust authentication; only a Windows Server 2016 domain controller supports authentication public key trust authentication.  The Windows Server 2016 domain controller understands how to authenticate password and certificate trust authentication and will continue to share the load of authenticating those clients.  Because DC1 can handle all forms of authentication, it will be bear more of the authentication load, and easily become overloaded.  What if another Windows Server 2016 domain controller is added, but without deploying Windows Hello for Business to anymore clients.
 
-![dc-chart3](images/dc-chart3.png)
+![dc-chart3](images/plan/dc-chart3.png)
 
 Upgrading another Windows Server 2016 domain controller distributes the public key trust authentication across two domain controllers--each supporting 50 percent of the load.  But it doesn't change the distribution of password and certificate trust authentication.  Both Windows Server 2016 domain controllers still share 10 percent of this load. Now look at the scenario when half of the domain controllers are upgraded to Windows Server 2016, but the number of WHFB clients remains the same.
 
-![dc-chart4](images/dc-chart4.png)
+![dc-chart4](images/plan/dc-chart4.png)
 
 Domain controllers 1 through 5 now share the public key trust authentication load where each domain controller handles 20 percent of the public key trust load but they each still handle 10 percent of the password and certificate trust authentication.  These domain controllers still have a heavier load than domain controllers 6 through 10; however, the load is adequately distributed.  Now look the scenario when half of the client computers are upgraded to Windows Hello for Business using a key-trust deployment.
 
-![dc-chart5](images/dc-chart5.png)
+![dc-chart5](images/plan/dc-chart5.png)
 
 You'll notice the distribution did not change.  Each Windows Server 2016 domain controller handles 20 percent of the public key trust authentication.  However, increasing the volume of authentication (by increasing the number of clients) increases the amount of work that is represented by the same 20 percent.  In the previous example, 20 percent of public key trust authentication equated to a volume of 20 authentications per domain controller capable of public key trust authentication.  However, with upgraded clients, that same 20 percent represents a volume 100 public key trust authentications per public key trust capable domain controller.  Also, the distribution of non-public key trust authentication remained at 10 percent, but the volume of password and certificate trust authentication decreased across the older domain controllers.
 

windows/security/identity-protection/hello-for-business/hello-and-password-changes.md

@@ -15,7 +15,6 @@ ms.date: 07/27/2017
 
 **Applies to**
 -   Windows 10
--   Windows 10 Mobile
 
 When you set up Windows Hello, the PIN or biometric gesture that you use is specific to that device. You can set up Hello for the same account on multiple devices. If the PIN or biometric is configured as part of Windows Hello for Business, changing the account password will not impact sign-in or unlock with these gestures since it uses a key or certificate. However, if Windows Hello for Business is not deployed and the password for that account changes, you must provide the new password on each device to continue to use Hello.
 

windows/security/identity-protection/hello-for-business/hello-biometrics-in-enterprise.md

@@ -7,15 +7,15 @@ ms.prod: w10
 ms.mktglfcycl: explore
 ms.sitesec: library
 ms.pagetype: security
-author: DaniHalfin
+author: mikestephens-MS
+ms.author: mstephen
 ms.localizationpriority: medium
-ms.author: daniha
+ms.date: 08/19/2018
-ms.date: 07/27/2017
 ---
 
 # Windows Hello biometrics in the enterprise
-**Applies to:**
 
+**Applies to:**
 -   Windows 10
 
 Windows Hello is the biometric authentication feature that helps strengthen authentication and helps to guard against potential spoofing through fingerprint matching and facial recognition.
@@ -82,7 +82,6 @@ To allow facial recognition, you must have devices with integrated special infra
 - [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)
-- [PassportforWork CSP](https://go.microsoft.com/fwlink/p/?LinkId=708219)
 
  
 

windows/security/identity-protection/hello-for-business/hello-cert-trust-adfs.md

@@ -8,17 +8,18 @@ ms.sitesec: library
 ms.pagetype: security, mobile
 author: mikestephens-MS
 ms.author: mstephen
-ms.localizationpriority: medium
+localizationpriority: high
-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
+-   Certificate 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 certificate trust deployment uses Active Directory Federation Services roles for key registration, device registration, and as a certificate registration authority.
+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 certificate trust deployment uses Active Directory Federation Services roles for key registration, device registration, and as a certificate registration authority.
 
 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.
 
@@ -43,7 +44,7 @@ Sign-in the federation server with _local admin_ equivalent credentials.
 
 ## Enroll for a TLS Server Authentication Certificate
 
-Windows Hello for Business on-prem deployments require a federation server for device registration, key registration, and authentication certificate enrollment.  Typically, a federation service is an edge facing role.  However, the federation services and instance used with the on-prem deployment of Windows Hello for Business does not need Internet connectivity.  
+Windows Hello for Business on-premises deployments require a federation server for device registration, key registration, and authentication certificate enrollment.  Typically, a federation service is an edge facing role.  However, the federation services and instance used with the on-premises deployment of Windows Hello for Business does not need Internet connectivity.  
 
 The AD FS role needs a server authentication certificate for the federation services, but you can use a certificate issued by your enterprise (internal) certificate authority.  The server authentication certificate should have the following names included in the certificate if you are requesting an individual certificate for each node in the federation farm:
 * Subject Name: The internal FQDN of the federation server (the name of the computer running AD FS)
@@ -57,9 +58,9 @@ It’s recommended that you mark the private key as exportable so that the same
 
 Be sure to enroll or import the certificate into the AD FS server’s computer certificate store.  Also, ensure all nodes in the farm have the proper TLS server authentication certificate.
 
-### Internal Server Authentication Certificate Enrollment
+### Internal Web Server Authentication Certificate Enrollment
+Sign-in the federation server with domain administrator equivalent credentials.
 
-Sign-in the federation server with domain admin 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**.
@@ -135,7 +136,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
@@ -147,11 +148,11 @@ Sign-in a domain controller or management workstation with _Domain Admin_ equiva
 
 Use the following procedures to configure AD FS when your environment uses **Windows Server 2012 or later Domain Controllers**.  If you are not using Windows Server 2012 or later Domain Controllers, follow the procedures under the [Configure the Active Directory Federation Service Role (Windows Server 2008 or 2008R2 Domain Controllers)](#windows-server-2008-or-2008R2-domain-controllers) section.
 
-Sign-in the federation server with _Domain Admin_ equivalent credentials. These procedures assume you are configuring the first federation server in a federation server farm.
+Sign-in the federation server with _domain administrator_ equivalent credentials. These procedures assume you are configuring the first federation server in a federation server farm.
+
 1. Start **Server Manager**.
 2. Click the notification flag in the upper right corner. Click **Configure federation services on this server**.
-   ![Example of pop-up notification as described above](images/hello-adfs-configure-2012r2.png)
+![Example of pop-up notification as described above](images/hello-adfs-configure-2012r2.png)
-
 3. On the **Welcome** page, click **Create the first federation server farm** and click **Next**.
 4. Click **Next** on the **Connect to Active Directory Domain Services** page.
 5. On the **Specify Service Properties** page, select the recently enrolled or imported certificate from the **SSL Certificate** list.  The certificate is likely named after your federation service, such as *fs.corp.contoso.com* or *fs.contoso.com*.
@@ -167,18 +168,17 @@ Sign-in the federation server with _Domain Admin_ equivalent credentials. These
 
 Use the following procedures to configure AD FS when your environment uses **Windows Server 2008 or 2008 R2 Domain Controllers**.  If you are not using Windows Server 2008 or 2008 R2 Domain Controllers, follow the procedures under the [Configure the Active Directory Federation Service Role (Windows Server 2012 or later Domain Controllers)](#windows-server-2012-or-later-domain-controllers) section.
 
-Sign-in the federation server with _Domain Admin_ equivalent credentials.  These instructions assume you are configuring the first federation server in a federation server farm.
+Sign-in the federation server with _domain administrator_ equivalent credentials.  These instructions assume you are configuring the first federation server in a federation server farm.
+
 1. Start **Server Manager**.
 2. Click the notification flag in the upper right corner.  Click **Configure federation services on this server**.
-    ![Example of pop-up notification as described above](images/hello-adfs-configure-2012r2.png)
+![Example of pop-up notification as described above](images/hello-adfs-configure-2012r2.png)
-
 3. On the **Welcome** page, click **Create the first federation server farm** and click **Next**.
 4. Click **Next** on the **Connect to Active Directory Domain Services** page.
 5. On the **Specify Service Properties** page, select the recently enrolled or imported certificate from the **SSL Certificate** list. The certificate is likely named after your federation service, such as fs.corp.mstepdemo.net or fs.mstepdemo.net.
 6. Select the federation service name from the **Federation Service Name** list.
 7. Type the Federation Service Display Name in the text box. This is the name users see when signing in. Click **Next**.
-8. On the **Specify Service Account** page, Select **Use an existing domain user account or group Managed Service Account** and click **Select**.   
+8. On the **Specify Service Account** page, Select **Use an existing domain user account or group Managed Service Account** and click **Select**.  In the **Select User or Service Account** dialog box, type the name of the previously created AD FS service account (example adfssvc) and click **OK**. Type the password for the AD FS service account and click **Next**.
-    * In the **Select User or Service Account** dialog box, type the name of the previously created AD FS service account (example adfssvc) and click **OK**. Type the password for the AD FS service account and click **Next**.
 9. On the **Specify Configuration Database** page, select **Create a database on this server using Windows Internal Database** and click **Next**.
 10. On the **Review Options** page, click **Next**.
 11. On the **Pre-requisite Checks** page, click **Configure**.
@@ -188,7 +188,7 @@ Sign-in the federation server with _Domain Admin_ equivalent credentials.  These
 
 ### Add the AD FS Service account to the KeyCredential Admin group and the Windows Hello for Business Users group
 
-The KeyCredential Admins global group provides the AD FS service with the permissions needed to perform key registration.  The Windows Hello for Business group provides the AD FS service with the permissions needed to enroll a Windows Hello for Business authentication certificate on behalf of the provisioning user.
+The **KeyCredential Administrators** global group provides the AD FS service with the permissions needed to perform key registration.  The Windows Hello for Business group provides the AD FS service with the permissions needed to enroll a Windows Hello for Business authentication certificate on behalf of the provisioning user.
 
 Sign-in a domain controller or management workstation with _Domain Admin_ equivalent credentials.
 1. Open **Active Directory Users and Computers**.
@@ -205,7 +205,7 @@ Sign-in a domain controller or management workstation with _Domain Admin_ equiva
 
 ### Configure Permissions for Key Registration
 
-Key Registration stores the Windows Hello for Business public key in Active Directory.  In on-prem deployments, the Windows Server 2016 AD FS server registers the public key with the on-premises Active Directory.
+Key Registration stores the Windows Hello for Business public key in Active Directory.  With on-premises deployments, the Windows Server 2016 AD FS server registers the public key with the on-premises Active Directory.
 
 The key-trust model needs Windows Server 2016 domain controllers, which configures the key registration permissions automatically; however, the certificate-trust model does not and requires you to add the permissions manually. 
 
@@ -217,7 +217,7 @@ Sign-in a domain controller or management workstations with _Domain Admin_ equiv
 5. The **Select User, Computer, Service Account, or Group** dialog box appears. In the **Enter the object name to select** text box, type **KeyCredential Admins**.  Click **OK**.
 6. In the **Applies to** list box, select **Descendant User objects**.
 7. Using the scroll bar, scroll to the bottom of the page and click **Clear all**.
-8. In the **Properties** section, select **Read msDS-KeyCredentialLink** and **Write msDS-KeyCredentialLink**.
+8. In the **Properties** section, select **Read msDS-KeyCredentialLink** and **Write msDS-KeyCrendentialLink**.
 9. Click **OK** three times to complete the task. 
 
 ## Configure the Device Registration Service
@@ -251,7 +251,7 @@ Before you continue with the deployment, validate your deployment progress by re
 
 ## Prepare and Deploy AD FS Registration Authority
 
-A registration authority is a trusted authority that validates certificate request.  Once it validates the request, it presents the request to the certificate authority for issuance.  The certificate authority issues the certificate, returns it to the registration authority, which returns the certificate to the requesting user.  The Windows Hello for Business on-prem certificate-based deployment uses the Active Directory Federation Server (AD FS) as the certificate registration authority.
+A registration authority is a trusted authority that validates certificate request.  Once it validates the request, it presents the request to the certificate authority for issuance.  The certificate authority issues the certificate, returns it to the registration authority, which returns the certificate to the requesting user.  The Windows Hello for Business on-premises certificate-based deployment uses the Active Directory Federation Server (AD FS) as the certificate registration authority.
 
 ### Configure Registration Authority template
 
@@ -263,15 +263,16 @@ The registration authority template you configure depends on the AD FS service c
 >Follow the procedures below based on the domain controllers deployed in your environment. If the domain controller is not listed below, then it is not supported for Windows Hello for Business.
 
 #### Windows 2012 or later domain controllers
+Sign-in a certificate authority or management workstations with _domain administrator_ equivalent credentials.
 
-Sign-in a certificate authority or management workstations with _Domain Admin_ equivalent credentials.
 1. Open the **Certificate Authority Management** console.
 2. Right-click **Certificate Templates** and click **Manage**.
 3. In the **Certificate Template Console**, right click on the **Exchange Enrollment Agent (Offline request)** template 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.
 5. On the **General** tab, type **WHFB Enrollment Agent** in **Template display name**.  Adjust the validity and renewal period to meet your enterprise’s needs.
 6. On the **Subject** tab, select the **Supply in the request** button if it is not already selected.
-    **Note:** The preceding step is very important.  Group Managed Service Accounts (GMSA) do not support the Build from this Active Directory information option and will result in the AD FS server failing to enroll the enrollment agent certificate.  You must configure the certificate template with Supply in the request to ensure that AD FS servers can perform the automatic enrollment and renewal of the enrollment agent certificate.
+> [!NOTE]
+> The preceding step is very important.  Group Managed Service Accounts (GMSA) do not support the Build from this Active Directory information option and will result in the AD FS server failing to enroll the enrollment agent certificate.  You must configure the certificate template with Supply in the request to ensure that AD FS servers can perform the automatic enrollment and renewal of the enrollment agent certificate.
 
 7. 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.
 8. On the **Security** tab, click **Add**.
@@ -298,7 +299,7 @@ Sign-in a certificate authority or management workstations with _Domain Admin_ e
 
 During Windows Hello for Business provisioning, the Windows 10, version 1703 client requests an authentication certificate from the Active Directory Federation Service, which requests the authentication certificate on behalf of the user.  This task configures the Windows Hello for Business authentication certificate template.  You use the name of the certificate template when configuring.
 
-Sign-in a certificate authority or management workstations with _Domain Admin equivalent_ credentials.
+Sign-in a certificate authority or management workstations with _domain administrator equivalent_ credentials.
 1. Open the **Certificate Authority** management console.
 2. Right-click **Certificate Templates** and click **Manage**.
 3. Right-click the **Smartcard Logon** template and choose **Duplicate Template**.
@@ -318,7 +319,7 @@ Sign-in a certificate authority or management workstations with _Domain Admin eq
 
 #### Mark the template as the Windows Hello Sign-in template 
 
-Sign-in to an **AD FS Windows Server 2016** computer with _Enterprise Admin_ equivalent credentials.
+Sign-in to an **AD FS Windows Server 2016** computer with _enterprise administrator_ equivalent credentials.
 1. Open an elevated command prompt.
 2. Run `certutil –dsTemplate WHFBAuthentication msPKI-Private-Key-Flag +CTPRIVATEKEY_FLAG_HELLO_LOGON_KEY`
 
@@ -338,7 +339,7 @@ Sign-in a certificate authority or management workstations with _Enterprise Admi
 
 ### Configure the Registration Authority
 
-Sign-in the AD FS server with Domain Admin equivalent credentials. 
+Sign-in the AD FS server with domain administrator equivalent credentials. 
 
 1.	Open a **Windows PowerShell** prompt.
 2.	Type the following command   
@@ -378,7 +379,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   
@@ -412,7 +413,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.

windows/security/identity-protection/hello-for-business/hello-cert-trust-deploy-mfa.md

@@ -9,14 +9,15 @@ ms.pagetype: security, mobile
 author: mikestephens-MS
 ms.author: mstephen
 ms.localizationpriority: medium
-ms.date: 03/5/2018
+ms.date: 08/19/2018
 ---
 # Configure or Deploy Multifactor Authentication Services
 
 **Applies to**
--   Windows 10
+-   Windows 10, version 1703 or later
+-   On-premises deployment
+-   Certificate 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 prerequisites and must
 
 ### 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 the 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
 

windows/security/identity-protection/hello-for-business/hello-cert-trust-policy-settings.md

@@ -6,17 +6,18 @@ ms.prod: w10
 ms.mktglfcycl: deploy
 ms.sitesec: library
 ms.pagetype: security, mobile
-author: DaniHalfin
 ms.localizationpriority: medium
-ms.author: daniha
+author: mikestephens-MS
-ms.date: 07/27/2017
+ms.author: mstephen
+ms.date: 08/20/2018
 ---
 # Configure Windows Hello for Business Policy settings
 
 **Applies to**
--   Windows 10
+-   Windows 10, version 1703 or later
+-   On-premises deployment
+-   Certificate 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.
@@ -103,7 +104,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
 
@@ -132,7 +133,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)

windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-ad-prereq.md

@@ -6,19 +6,20 @@ ms.prod: w10
 ms.mktglfcycl: deploy
 ms.sitesec: library
 ms.pagetype: security, mobile
-author: DaniHalfin
 ms.localizationpriority: medium
-ms.author: daniha
+author: mikestephens-MS
-ms.date: 07/27/2017
+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
+-   Certificate trust
 
-> This guide only applies to Windows 10, version 1703 or higher.
 
-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 certificate trust model requires manually updating the current schema to the Windows Server 2016 schema. If you already have a Windows Server 2016 domain controller in your forest, you can skip the next step.
+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 certificate trust model requires manually updating the current schema to the Windows Server 2016 schema. If you already have a Windows Server 2016 domain controller in your forest, you can skip the next step.
 
 Manually updating Active Directory uses the command-line utility **adprep.exe** located at **\<drive>:\support\adprep** on the Windows Server 2016 DVD or ISO.  Before running adprep.exe, you must identify the domain controller hosting the schema master role.
 
@@ -28,7 +29,7 @@ To locate the schema master role holder, open and command prompt and type:
 
 ```Netdom query fsmo | findstr -i “schema”```
 
-![Netdom example output](images\hello-cmd-netdom.png)
+![Netdom example output](images/hello-cmd-netdom.png)
 
 The command should return the name of the domain controller where you need to adprep.exe.  Update the schema locally on the domain controller hosting the Schema master role.
 
@@ -36,7 +37,7 @@ The command should return the name of the domain controller where you need to ad
 
 Windows Hello for Business uses asymmetric keys as user credentials (rather than passwords).  During enrollment, the public key is registered in an attribute on the user object in Active Directory.  The schema update adds this new attribute to Active Directory.  
 
-Sign-in to the domain controller hosting the schema master operational role using Enterprise Admin equivalent credentials.
+Sign-in to the domain controller hosting the schema master operational role using enterprise administrator equivalent credentials.
 
 1.	Open an elevated command prompt.
 2.	Type ```cd /d x:\support\adprep``` where *x* is the drive letter of the DVD or mounted ISO.
@@ -48,7 +49,7 @@ Sign-in to the domain controller hosting the schema master operational role usin
 
 The Windows Server 2016 Active Directory Federation Services (AD FS) role registers the public key on the user object during provisioning.  You assign write and read permission to this group to the Active Directory attribute to ensure the AD FS service can add and remove keys are part of its normal workflow.
 
-Sign-in a domain controller or management workstation with Domain Admin equivalent credentials.
+Sign-in a domain controller or management workstation with domain administrator equivalent credentials.
 
 1.	Open **Active Directory Users and Computers**.
 2.	Click **View** and click **Advance Features**.
@@ -61,7 +62,7 @@ Sign-in a domain controller or management workstation with Domain Admin equivale
 
 The Windows Hello for Business Users group is used to make it easy to deploy Windows Hello for Business in phases.  You assign Group Policy and Certificate template permissions to this group to simplify the deployment by simply adding the users to the group.  This provides them the proper permissions to provision Windows Hello for Business and to enroll in the Windows Hello for Business authentication certificate.
 
-Sign-in a domain controller or management workstation with Domain Admin equivalent credentials.
+Sign-in a domain controller or management workstation with domain administrator equivalent credentials.
 
 1.	Open **Active Directory Users and Computers**.
 2.	Click **View** and click **Advanced Features**.

windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-deploy-mfa.md

@@ -6,23 +6,24 @@ ms.prod: w10
 ms.mktglfcycl: deploy
 ms.sitesec: library
 ms.pagetype: security, mobile
-author: DaniHalfin
+author: mikestephens-MS
+ms.author: mstephen
 ms.localizationpriority: medium
-ms.author: daniha
+ms.date: 08/19/2018
-ms.date: 07/27/2017
 ---
 # Validate and Deploy Multifactor Authentication Services (MFA)
 
 **Applies to**
--   Windows 10
+-   Windows 10, version 1703 or later
+-   On-premises deployment
+-   Certificate trust
 
-> This guide only applies to Windows 10, version 1703 or higher.
 
 Windows Hello for Business requires all users perform multi-factor 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.
 

windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-pki.md

@@ -6,17 +6,18 @@ ms.prod: w10
 ms.mktglfcycl: deploy
 ms.sitesec: library
 ms.pagetype: security, mobile
-author: DaniHalfin
+author: mikestephens-MS
-ms.localizationpriority: medium
+ms.author: mstephen
-ms.author: daniha
+localizationpriority: high
-ms.date: 09/01/2017
+ms.date: 08/19/2018
 ---
 # Validate and Configure Public Key Infrastructure
 
 **Applies to**
--   Windows 10
+-   Windows 10, version 1703 or later
+-   On-premises deployment
+-   Certificate 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.  The certificate trust model extends certificate issuance to client computers.  During Windows Hello for Business provisioning, the user receives a sign-in certificate.
 
@@ -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.
@@ -120,7 +121,8 @@ Sign-in to the certificate authority or management workstation with _Enterprise
 
 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 Admin_ equivalent credentials.
+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.
@@ -128,7 +130,6 @@ Sign-in to the certificate authority or management workstations with an _Enterpr
 5. In the **Enable Certificates Templates** window, select the **Domain Controller Authentication (Kerberos)**, and **Internal Web Server** templates 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.
 
 ### Configure Domain Controllers for Automatic Certificate Enrollment
@@ -163,7 +164,7 @@ You want to confirm your domain controllers enroll the correct certificates and
 
 #### Use the Event Logs
 
-Windows Server 2012 and later include Certificate Lifecycle events to determine the lifecycles of certificates for both users and computers.  Using the Event Viewer, navigate to the CertificateServices-Lifecycles-System event log under Application and Services/Microsoft/Windows.
+Windows Server 2012 and later include Certificate Lifecycle events to determine the lifecycles of certificates for both users and computers.  Using the Event Viewer, navigate to the **CertificateServices-Lifecycles-System** event log under **Application and Services/Microsoft/Windows**.
 
 Look for an event indicating a new certificate enrollment (autoenrollment).  The details of the event include the certificate template on which the certificate was issued.  The name of the certificate template used to issue the certificate should match the certificate template name included in the event.  The certificate thumbprint and EKUs for the certificate are also included in the event.  The EKU needed for proper Windows Hello for Business authentication is Kerberos Authentication, in addition to other EKUs provide by the certificate template. 
 

windows/security/identity-protection/hello-for-business/hello-deployment-cert-trust.md

@@ -6,17 +6,18 @@ ms.prod: w10
 ms.mktglfcycl: deploy
 ms.sitesec: library
 ms.pagetype: security, mobile
-author: DaniHalfin
 ms.localizationpriority: medium
-ms.author: daniha
+author: mikestephens-MS
-ms.date: 07/27/2017
+ms.author: mstephen
+ms.date: 08/19/2018
 ---
 # On Premises Certificate Trust Deployment
 
 **Applies to**
--   Windows 10
+-   Windows 10, version 1703 or later
+-   On-premises deployment
+-   Certificate trust
 
-> This guide only applies to Windows 10, version 1703 or higher.
 
 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 an existing environment.  
 

windows/security/identity-protection/hello-for-business/hello-deployment-guide.md

@@ -9,15 +9,13 @@ ms.pagetype: security, mobile
 author: mikestephens-MS
 ms.author: mstephen
 ms.localizationpriority: medium
-ms.date: 11/08/2017
+ms.date: 08/29/2018
 ---
 # Windows Hello for Business Deployment Guide
 
 **Applies to**
--   Windows 10
+-   Windows 10, version 1703 or later
--   Windows 10 Mobile
 
-> This guide only applies to Windows 10, version 1703 or higher.
 
 Windows Hello for Business is the springboard to a world without passwords. It replaces username and password sign-in to Windows with strong user authentication based on an asymmetric key pair.
 
@@ -50,10 +48,11 @@ The trust model determines how you want users to authenticate to the on-premises
 * The certificate trust model also supports enterprises which are not ready to deploy Windows Server 2016 Domain Controllers.
 
 Following are the various deployment guides included in this topic:
-* [Hybrid Key Trust Deployment](hello-hybrid-key-trust.md)
+- [Hybrid Azure AD Joined Key Trust Deployment](hello-hybrid-key-trust.md)
-* [Hybrid Certificate Trust Deployment](hello-hybrid-cert-trust.md)
+- [Hybrid Azure AD Joined Certificate Trust Deployment](hello-hybrid-cert-trust.md)
-* [On Premises Key Trust Deployment](hello-deployment-key-trust.md)
+- [Azure AD Join Single Sign-on Deployment Guides](hello-hybrid-aadj-sso.md)
-* [On Premises Certificate Trust Deployment](hello-deployment-cert-trust.md)
+- [On Premises Key Trust Deployment](hello-deployment-key-trust.md)
+- [On Premises Certificate Trust Deployment](hello-deployment-cert-trust.md)
 
 
 ## Provisioning

windows/security/identity-protection/hello-for-business/hello-deployment-key-trust.md

@@ -9,18 +9,19 @@ ms.pagetype: security, mobile
 author: mikestephens-MS
 ms.author: mstephen
 ms.localizationpriority: medium
-ms.date: 10/23/2017
+ms.date: 08/20/2018
 ---
 # On Premises Key Trust Deployment
 
 **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 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 an existing environment.  
 
-Below, you can find all the infromation you need to deploy Windows Hello for Business in a key trust model in your on-premises environment:
+Below, you can find all the information you need to deploy Windows Hello for Business in a key trust model in your on-premises environment:
 1. [Validate Active Directory prerequisites](hello-key-trust-validate-ad-prereq.md)
 2. [Validate and Configure Public Key Infrastructure](hello-key-trust-validate-pki.md)
 3. [Prepare and Deploy Windows Server 2016 Active Directory Federation Services](hello-key-trust-adfs.md)

windows/security/identity-protection/hello-for-business/hello-errors-during-pin-creation.md

@@ -10,14 +10,13 @@ ms.pagetype: security
 author: DaniHalfin
 ms.localizationpriority: medium
 ms.author: daniha
-ms.date: 07/27/2017
+ms.date: 05/05/2018
 ---
 
 # Windows Hello errors during PIN creation
 
 **Applies to**
 -   Windows 10
--   Windows 10 Mobile
 
 When you set up Windows Hello in Windows 10, you may get an error during the **Create a PIN** step. This topic lists some of the error codes with recommendations for mitigating the problem. If you get an error code that is not listed here, contact Microsoft Support.
 

windows/security/identity-protection/hello-for-business/hello-event-300.md

@@ -17,7 +17,7 @@ ms.date: 07/27/2017
 
 **Applies to**
 -   Windows 10
--   Windows 10 Mobile
+
 
 This event is created when Windows Hello for Business is successfully created and registered with Azure Active Directory (Azure AD). Applications or services can trigger actions on this event. For example, a certificate provisioning service can listen to this event and trigger a certificate request.
 

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

@@ -0,0 +1,157 @@
+---
+title: Windows Hello for Business Frequently Asked Questions
+description: Windows Hello for Business FAQ 
+keywords: identity, PIN, biometric, Hello, passport
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security, mobile
+author: mikestephens-MS
+ms.author: mstephen
+localizationpriority: high
+ms.date: 08/19/2018
+---
+# Windows Hello for Business Frequently Ask Questions
+
+**Applies to**
+-   Windows 10
+
+## What about virtual smart cards?
+Windows Hello for Business is the modern, two-factor credential for Windows 10.  Microsoft will be deprecating virtual smart cards in the future but not date at this time.  Customers using Windows 10 and virtual smart cards should move to Windows Hello for Business.  Microsoft will publish the date early to ensure customers have adequate lead time to move to Windows Hello for Business.  Microsoft recommends new Windows 10 deployments to use Windows Hello for Business. Virtual smart card remain supported for Windows 7 and Windows 8.
+
+## What about convenience PIN?
+Microsoft is committed to its vision of a <u>world without passwords.</u> We recognize the *convenience* provided by convenience PIN, but it stills uses a password for authentication.  Microsoft recommends customers using Windows 10 and convenience PINs should move to Windows Hello for Business.  New Windows 10 deployments should deploy Windows Hello for Business and not convenience PINs.  Microsoft will be deprecating convenience PINs in the future and will publish the date early to ensure customers have adequate lead time to deploy Windows Hello for Business. 
+
+## Can I deploy Windows Hello for Business using System Center Configuration Manager?
+Windows Hello for Business deployments using System Center Configuration Manager need to move to the hybrid deployment model that uses Active Directory Federation Services. Deployments using System Center Configuration Manager will no long be supported after November 2018.
+
+## How many users can enroll for Windows Hello for Business on a single Windows 10 computer?
+The maximum number of supported enrollments on a single Windows 10 computer is 10.  That enables 10 users to each enroll their face and up to 10 fingerprints.  While we support 10 enrollments, we will strongly encourage the use of Windows Hello security keys for the shared computer scenario when they become available.
+
+## How can PIN be more secure than a Password?
+When using Windows Hello for Business, the PIN is not a symmetric key where is the password is a symmetric key.  With passwords, there is a server that has some representation of the password.  With Windows Hello for Business, the PIN is user provided entropy used to load the private key in the TPM.  The server does not have a copy of the PIN.  For that matter, the Windows client does not have a copy of the current PIN either.  The user must provide the entropy, the TPM protected key, and the TPM that generated that key to successfully have access to the private key.
+
+The statement "PIN is stronger than Password" is not directed at the strength of the entropy used by the PIN.  It is about the difference of providing entropy vs continuing the use of a symmetric key (the password).  The TPM has anti-hammering features which thwart brute-force PIN attacks (an attackers continuous attempt to try all combination of PINs).  Some organizations may worry about shoulder surfing.  For those organizations, rather than increased the complexity of the PIN, implement the [Multifactor Unlock](feature-multifactor-unlock.md) feature.
+
+## Why is the Key Admins group missing, I have Windows Server 2016 domain controller(s)?
+The **Key Admins** and **Enterprise Key Admins** groups are created when you install the first Windows Server 2016 domain controller into a domain. Domain controllers running previous versions of Windows Server cannot translate the security identifier (SID) to a name.  To resolve this, transfer the PDC emulator domain role to a domain controller running Windows Server 2016.
+
+## Can I use convenience PIN with Azure AD?
+No. If you want to use PIN or biometrics with Azure Active Directory identities on Azure AD registered, Azure AD joined, or hybrid Azure AD joined devices, then you must deploy Windows Hello for Business.
+
+## Can I use an external camera when my laptop is closed or docked?
+No. Windows 10 currently only supports one Windows Hello for Business camera and does not fluidly switch to an external camera when the computer is docked with the lid closed.  The product group is aware of this and is investigating this topic further.
+
+## What is the password-less strategy?
+Watch Principal Program Manager Karanbir Singh's Ignite 2017 presentation **Microsoft's guide for going password-less**
+
+[Microsoft's password-less strategy](hello-videos.md#microsofts-passwordless-strategy)
+
+## What is the user experience for Windows Hello for Business?
+The user experience for Windows Hello for Business occurs after user sign-in, after you deploy Windows Hello for Business policy settings to your environment.
+
+[Windows Hello for Business user enrollment experience](hello-videos.md#windows-hello-for-business-user-enrollment-experience)
+
+## What happens when my user forgets their PIN?
+If the user can sign-in with a password, they can reset their PIN by clicking the "I forgot my PIN" link in settings.  Beginning with the Fall Creators Update, users can reset their PIN above the lock screen by clicking the "I forgot my PIN" link on the PIN credential provider.
+
+[Windows Hello for Business forgotten PIN user experience](hello-videos.md#windows-hello-for-business-forgotten-pin-user-experience)
+
+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.
+
+## What URLs do I need to allow for a hybrid deployment?
+Communicating with Azure Active Directory uses the following URLs:
+- enterpriseregistration.windows.net
+- login.microsoftonline.com
+- login.windows.net
+
+If your environment uses Microsoft Intune, you need these additional URLs:
+- enrollment.manage-beta.microsoft.com
+- enrollment.manage.microsoft.com
+- portal.manage-beta.microsoft.com
+- portal.manage.microsoft.com
+
+## What is the difference between non-destructive and destructive PIN Reset?
+Windows Hello for Business has two types of PIN reset: non-destructive and destructive.  Organizations running Windows 10 Enterprise and Azure Active Directory can take advantage of the Microsoft PIN Reset service.  Once on-boarded to a tenant and deployed to computers, users who have forgotten their PINs can authenticate to Azure, provided a second factor of authentication, and reset their PIN without re-provisioning a new Windows Hello for Business enrollment. This is a non-destructive PIN reset because the user does not delete the current credential and obtain a new one.  Read [PIN Reset](hello-features.md#pin-reset) from our [Windows Hello for Business Features](hello-features.md) page for more information.
+
+Organizations that have the on-premises deployment of Windows Hello for Business, or those not using Windows 10 Enterprise can use destructive PIN reset.  with destructive PIN reset, users that have forgotten their PIN can authenticate using their password, perform a second factor of authentication to re-provision their Windows Hello for Business credential. Re-provisioning deletes the old credential and requests a new credential and certificate.  On-premises deployments need network connectivity to their domain controllers, Active Directory Federation Services, and their issuing certificate authority to perform a destructive PIN reset. Also, for hybrid deployments, destructive PIN reset is only supported with the certificate trust model and the latest updates to Active Directory Federation Services.
+
+## Which is better or more secure: Key trust or Certificate trust?
+The trust models of your deployment determine how you authenticate to Active Directory (on-premises). Both key trust and certificate trust use the same hardware backed, two-factor credential. The difference between the two trust types are:
+- Required domain controllers 
+- Issuing end entity certificates
+
+The **key trust** model authenticates to Active Directory using a raw key.  Windows Server 2016 domain controllers enables this authentication.  Key trust authenticate does not require an enterprise issued certificate, therefore you do not need to issue certificates to your end users (domain controller certificates are still needed).
+The **certificate trust** model authenticates to Active Directory using a certificate.  Because this authentication uses a certificate, domain controllers running previous versions of Windows Server can authenticate the user. Therefore, you need to issue certificates to your end users, but you do not need Windows Server 2016 domain controllers.  The certificate used in certificate trust uses the TPM protected private key to request a certificate from your enterprise's issuing certificate authority. 
+
+## 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
+
+## What attributes are synchronized by Azure AD Connect with Windows Hello for Business?
+Review [Azure AD Connect sync: Attributes synchronized to Azure Active Directory](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized) for a list of attributes that are sync based on scenarios.  The base scenarios that include Windows Hello for Business are [Windows 10](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized#windows-10) scenario and the [Device writeback](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized#device-writeback) scenario. Your environment may include additional attributes.
+
+## 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".
+
+## What are the biometric requirements for Windows Hello for Business?
+Read [Windows Hello biometric requirements](https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/windows-hello-biometric-requirements) for more information.
+
+## Can I use PIN and biometrics to unlock my device?
+Starting in Windows 10, version 1709, you can use multi-factor unlock to require the user to provide an additional factor to unlock the device.  Authentication remains two-factor, but another factor is required before Windows allows the user to reach the desktop.  Read more about [multifactor unlock](feature-multifactor-unlock.md).
+
+## What is the difference between Windows Hello and Windows Hello for Business?
+Windows Hello represents the biometric framework provided in Windows 10.  Windows Hello enables users to use biometrics to sign into their devices by securely storing their user name and password and releasing it for authentication when the user successfully identifies themselves using biometrics.  Windows Hello for Business uses asymmetric keys protected by the device's security module that requires a user gesture (PIN or biometrics) to authenticate.
+
+## Why can I not enroll biometrics for my local built-in Administrator?
+Windows 10 does not allow the local administrator to enroll biometric gestures(face or fingerprint).
+
+## I have extended Active Directory to Azure Active Directory.  Can I use the on-premises deployment model?
+No. If your organization is federated or using on-line services, such as Azure AD Connect, 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, version 1709, Windows Hello for Business used as a smart card (smart card emulation that is enabled by default) provides the same user experience of default smart card PIN caching.  Each process requesting a private key operation will prompt the user for the PIN on first use.  Subsequent private key operations will not prompt the user for the PIN.  
+
+The smart card emulation feature of Windows Hello for Business verifies the PIN and then discards the PIN in exchange for a ticket.  The process does not receive the PIN, but rather the ticket that grants them private key operations.  Windows 10 does not provide any Group Policy settings to adjust this caching.
+
+## Can I disable the PIN while using Windows Hello for Business?
+No. The movement away from passwords is accomplished by gradually reducing the use of the password.  In the occurrence where you cannot authenticate with biometrics, you need a fall back mechanism that is not a password.  The PIN is the fall back mechanism.  Disabling or hiding the PIN credential provider disabled the use of biometrics.
+
+## How keys are protected?
+Wherever possible, Windows Hello for Business takes advantage of trusted platform module (TPM) 2.0 hardware to generate and protect keys. However, Windows Hello and Windows Hello for Business does not require a TPM. Administrators can choose to allow key operations in software  
+
+Whenever possible, Microsoft strongly recommends the use of TPM hardware. The TPM protects against a variety of known and potential attacks, including PIN brute-force attacks. The TPM provides an additional layer of protection after an account lockout, too. When the TPM has locked the key material, the user will have to reset the PIN (which means he or she will have to use MFA to re-authenticate to the IDP before the IDP allows him or her to re-register).
+
+## Can Windows Hello for Business work in air gapped environments?
+Yes.  You can use the on-premises Windows Hello for Business deployment and combine it with a third-party MFA provider that does not require Internet connectivity to achieve an air-gapped Windows Hello for Business deployment.
+
+## Can I use third-party authentication providers with Windows Hello for Business?
+Yes, if you are federated hybrid deployment, you can use any third-party that provides an Active Directory Federation Services (AD FS) multi-factor authentication adapter.  A list of third-party MFA adapters can be found [here](https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs#microsoft-and-third-party-additional-authentication-methods).
+
+## 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 meta-data that enable the discovery of the issuer of access tokens and give additional information about provider capabilities. |
+
+## Does Windows Hello for Business work with Mac and Linux clients?
+Windows Hello for Business is a feature of Windows 10. At this time, Microsoft is not developing clients for other platforms.  However, Microsoft is open to third parties who are interested in moving these platforms away from passwords.  Interested third parties can get more information by emailing [whfbfeedback@microsoft.com](mailto:whfbfeedback@microsoft.com?subject=collaboration)
+

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

@@ -9,18 +9,21 @@ ms.sitesec: library
 ms.pagetype: security, mobile
 author: mikestephens-MS
 ms.author: mstephen
-ms.localizationpriority: medium
+localizationpriority: high
-ms.date: 3/5/2018
+ms.date: 05/05/2018
 ---
 # Windows Hello for Business Features
 
+**Applies to:**
+-   Windows 10
+
 Consider these additional features you can use after your organization deploys Windows Hello for Business. 
 
-* [Conditional access](#conditional-access)
+- [Conditional access](#conditional-access)
-* [Dynamic lock](#dynamic-lock)
+- [Dynamic lock](#dynamic-lock)
-* [PIN reset](#pin-reset)
+- [PIN reset](#pin-reset)
-* [Privileged credentials](#privileged-credentials)
+- [Dual Enrollment](#dual-enrollment)
-
+- [Remote Desktop with Biometrics](#remote-desktop-with-biometrics)
 
 ## Conditional access 
 
@@ -29,21 +32,20 @@ Consider these additional features you can use after your organization deploys W
 * Hybrid Windows Hello for Business deployment 
 
 
-In a mobile-first, cloud-first world, Azure Active Directory enables single sign-on to devices, apps, and services from anywhere. With the proliferation of devices (including BYOD), work off corporate networks, and 3rd party SaaS apps, IT professionals are faced with two opposing goals:+  
+In a mobile-first, cloud-first world, Azure Active Directory enables single sign-on to devices, applications, and services from anywhere. With the proliferation of devices (including BYOD), work off corporate networks, and 3rd party SaaS applications, IT professionals are faced with two opposing goals:+  
 * Empower the end users to be productive wherever and whenever
 * Protect the corporate assets at any time
  
-To improve productivity, Azure Active Directory provides your users with a broad range of options to access your corporate assets. With application access management, Azure Active Directory enables you to ensure that only the right people can access your applications. What if you want to have more control over how the right people are accessing your resources under certain conditions? What if you even have conditions under which you want to block access to certain apps even for the right people? For example, it might be OK for you if the right people are accessing certain apps from a trusted network; however, you might not want them to access these apps from a network you don't trust. You can address these questions using conditional access.
+To improve productivity, Azure Active Directory provides your users with a broad range of options to access your corporate assets. With application access management, Azure Active Directory enables you to ensure that only the right people can access your applications. What if you want to have more control over how the right people are accessing your resources under certain conditions? What if you even have conditions under which you want to block access to certain applications even for the right people? For example, it might be OK for you if the right people are accessing certain applications from a trusted network; however, you might not want them to access these applications from a network you don't trust. You can address these questions using conditional access.
 
 Read [Conditional access in Azure Active Directory](https://docs.microsoft.com/en-us/azure/active-directory/active-directory-conditional-access-azure-portal) to learn more about Conditional Access.  Afterwards, read [Getting started with conditional access in Azure Active Directory](https://docs.microsoft.com/en-us/azure/active-directory/active-directory-conditional-access-azure-portal-get-started) to start deploying Conditional access.
 
-
 ## Dynamic lock
 
 **Requirements:**
 * Windows 10, version 1703
 
-Dynamic lock enables you to configure Windows 10 devices to automatically lock when bluetooth paired device signal falls below the maximum Recieved Signal Stregnth Indicator (RSSI) value.  You configure the dynamic lock policy using Group Policy.  You can locate the policy setting at **Computer Configuration\Administrative Templates\Windows Components\Windows Hello for Busines**.  The name of the policy is **Configure dynamic lock factors**.
+Dynamic lock enables you to configure Windows 10 devices to automatically lock when Bluetooth paired device signal falls below the maximum Received Signal Strength Indicator (RSSI) value.  You configure the dynamic lock policy using Group Policy.  You can locate the policy setting at **Computer Configuration\Administrative Templates\Windows Components\Windows Hello for Business**.  The name of the policy is **Configure dynamic lock factors**.
 
 The Group Policy Editor, when the policy is enabled, creates a default signal rule policy with the following value:
 
@@ -78,54 +80,78 @@ RSSI measurements are relative and lower as the bluetooth signals between the tw
 
 ## PIN reset
 
+**Applies to:**
+-   Windows 10, version 1709 or later
+
+
 ### Hybrid Deployments
 
 **Requirements:**
-* Azure Active Directory
+- Azure Active Directory
-* Hybrid Windows Hello for Business deployment
+- Hybrid Windows Hello for Business deployment
-* Modern Management - Microsoft Intune, or compatible mobile device management (MDM)
+- Azure AD registered, Azure AD joined, and Hybrid Azure AD joined
-* Remote reset - Windows 10, version 1703
+- Windows 10, version 1709 or later, **Enterprise Edition**
-* Reset above Lock - Windows 10, version 1709
  
-The Microsoft PIN reset services enables you to help users who have forgotten their PIN.  Using Microsoft Intune or a compatible MDM, you can configure Windows 10 devices to securely use the Microsoft PIN reset service that enables you to remotely push a PIN reset or enables users to reset their forgotten PIN above the lock screen without requiring reenrollment.
+The Microsoft PIN reset services enables you to help users who have forgotten their PIN.  Using Group Policy, Microsoft Intune or a compatible MDM, you can configure Windows 10 devices to securely use the Microsoft PIN reset service that enables users to reset their forgotten PIN through settings or above the lock screen without requiring re-enrollment.
+
+>[!IMPORTANT]
+> The Microsoft PIN Reset service only works with Windows 10, version 1709 or later **Enterprise Edition**.  The feature does not work with the **Pro** edition.]
 
 #### Onboarding the Microsoft PIN reset service to your Intune tenant
 
-Before you can remotely reset PINs, you must onboard the Microsoft PIN reset service to your Intune or MDM tenant, and configure devices you manage. Follow these instructions to get that set up:
+Before you can remotely reset PINs, you must on-board the Microsoft PIN reset service to your Azure Active Directory tenant, and configure devices you manage. 
 
-#### Connect Intune with the PIN reset service
+#### Connect Azure Active Directory with the PIN reset service
 
-1. Visit [Microsoft PIN Reset Service Integration website](https://login.windows.net/common/oauth2/authorize?response_type=code&client_id=b8456c59-1230-44c7-a4a2-99b085333e84&resource=https%3A%2F%2Fgraph.windows.net&redirect_uri=https%3A%2F%2Fcred.microsoft.com&state=e9191523-6c2f-4f1d-a4f9-c36f26f89df0&prompt=admin_consent), and sign in using the tenant administrator account you use to manage your Intune tenant.
+1. Visit [Microsoft PIN Reset Service Integration website](https://login.windows.net/common/oauth2/authorize?response_type=code&client_id=b8456c59-1230-44c7-a4a2-99b085333e84&resource=https%3A%2F%2Fgraph.windows.net&redirect_uri=https%3A%2F%2Fcred.microsoft.com&state=e9191523-6c2f-4f1d-a4f9-c36f26f89df0&prompt=admin_consent), and sign in using the tenant administrator account you use to manage your Azure Active Directory tenant.
 2. After you log in, click **Accept** to give consent for the PIN reset service to access your account.<br>
+![PIN reset service application in Azure](images/pinreset/pin-reset-service-home-screen.png)<br>
+3. In the Azure portal, you can verify that the Microsoft PIN reset service is integrated from the **Enterprise applications**, **All applications** blade.<br>
 ![PIN reset service permissions page](images/pinreset/pin-reset-service-application.png)
-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:<br>
-![PIN reset service application in Azure](images/pinreset/pin-reset-service-home-screen.png)
-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.
+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.</br>
+```
+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 <b>*tenant ID*</b> 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.
  
-Set the value for this CSP to **True**.
+##### 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. 
-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.
+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 from settings - Windows 10, version 1703, Professional
-* Reset above Lock - Windows 10, version 1709
+* 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.</br>
+```dsacls "CN=AdminSDHolder,CN=System,**DC=domain,DC=com**" /g "**[domainName\keyAdminGroup]**":RPWP,msDS-KeyCredentialLink```</br>
+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:</br>
+```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.
+
+![WHFB Certificate GP Setting](images/rdpbio/rdpbiopolicysetting.png)
+
+> [!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)

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.<br>
+Azure Active Directory joined devices authenticate to Azure during sign-in and can optional authenticate to Active Directory.  Hybrid Azure Active Directory joined devices authenticate to Active Directory during sign-in, and authenticate to Azure Active Directory in the background.<br>
+
+[Azure AD join authentication to Azure Active Directory](#Azure-AD-join-authentication-to-Azure-Active-Directory)<br>
+[Azure AD join authentication to Active Direcotry using a Key](#Azure-AD-join-authentication-to-Active-Direcotry-using-a-Key)<br>
+[Azure AD join authentication to Active Directory using a Certificate](#Azure-AD-join-authentication-to-Active-Directory-using-a-Certificate)<br>
+[Hybrid Azure AD join authentication using a Key](#Hybrid-Azure-AD-join-authentication-using-a-Key)<br>
+[Hybrid Azure AD join authentication using a Certificate](#Hybrid-Azure-AD-join-authentication-using-a-Certificate)<br>
+
+
+## Azure AD join authentication to Azure Active Directory
+![Azure AD join authentication to Azure Active Directory](images/howitworks/auth-aadj-cloud.png)
+
+| Phase  | Description  |
+| :----: | :----------- |
+|A | Authentication begins when the users dismisses the lock screen, which triggers winlogon to show the Windows Hello for Business credential provider.  The user provides their Windows Hello gesture (PIN or biometrics).  The credential provider packages these credentials and returns them to winlogon.  Winlogon passes the collected credentials to lsass. Lsass passes the collected credentials to the Cloud Authentication security support provider, referred to as the Cloud AP provider.| 
+|B | The Cloud AP provider requests a nonce from Azure Active Directory.  Azure AD returns a nonce. The Cloud AP provider signs the nonce using the user's private key and returns the signed nonce to the Azure Active Directory.|
+|C | Azure Active Directory validates the signed nonce using the user's securely registered public key against the nonce signature.  After validating the signature, Azure AD then validates the returned signed nonce. After validating the nonce, Azure AD creates a PRT with session key that is encrypted to the device's transport key and returns it to the Cloud AP provider.|
+|D | The Cloud AP provider receives the encrypted PRT with session key.  Using the device's private transport key, the Cloud AP provider decrypt the session key and protects the session key using the device's TPM.|
+|E | The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT, and informs winlogon of the success authentication.  Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.| 
+
+[Return to top](#Windows-Hello-for-Business-and-Authentication)
+## Azure AD join authentication to Active Directory using a Key
+![Azure AD join authentication to Active Direotory using a Key](images/howitworks/auth-aadj-keytrust-kerb.png)
+
+
+| Phase  | Description  |
+| :----: | :----------- |
+|A | Authentication to Active Directory from a Azure AD joined device begins with the user first attempts to use a resource that needs Kerberos authentication.  The Kerberos security support provider, hosted in lsass, uses metadata from the Windows Hello for Business key to get a hint of the user's domain.  Using the hint, the provider uses the DClocator service to locate a 2016 domain controller. After the provider locates an active 2016 domain controller, the provider uses the private key to sign the Kerberos pre-authentication data.|
+|B | The Kerberos provider sends the signed pre-authentication data and its public key (in the form of a self-signed certificate) to the Key Distribution Center (KDC) service running on the 2016 domain controller in the form of a KERB_AS_REQ.<br>The 2016 domain controller determines the certificate is a self-signed certificate.  It retrieves the public key from the certificate included in the KERB_AS_REQ and searches for the public key in Active Directory.  It validates the UPN for authentication request matches the UPN registered in Active Directory and validates the signed pre-authentication data using the public key from Active Directory.  On success, the KDC returns a TGT to the client with its certificate in a KERB_AS_REP.|
+|C | The Kerberos provider ensures it can trust the response from the domain controller. First, it ensures the KDC certificate chains to a root certificate that is trusted by the device.  Next, it ensures the certificate is within its validity period and that it has not be revoked.  The Kerberos provider then verifies the certificate has the KDC Authentication present and that the subject alternate name listed in the KDC's certificate matches the domain name to which the user is authenticating. After passing this criteria, Kerberos returns the TGT to lsass, where it is cached and used for subsequent service ticket requests.|
+
+
+[Return to top](#Windows-Hello-for-Business-and-Authentication)
+## Azure AD join authentication to Active Directory using a Certificate
+![Azure AD join authentication to Active Directory using a Certificate](images/howitworks/auth-aadj-certtrust-kerb.png)
+
+| Phase  | Description  |
+| :----: | :----------- |
+|A | Authentication to Active Directory from a Azure AD joined device begins with the user first attempts to use a resource that needs Kerberos authentication.  The Kerberos security support provider, hosted in lsass, uses information from the certificate to get a hint of the user's domain. Kerberos can use the distinguished name of the user found in the subject of the certificate, or it can use the user principal name of the user found in the subject alternate name of the certificate.  Using the hint, the provider uses the DClocator service to locate a domain controller. After the provider locates an active domain controller, the provider use the private key to sign the Kerberos pre-authentication data.|
+|B | The Kerberos provider sends the signed pre-authentication data and  user's certificate, which includes the public key, to the Key Distribution Center (KDC) service running on the domain controller in the form of a KERB_AS_REQ.<br>The domain controller determines the certificate is not self-signed certificate.  The domain controller ensures the certificate chains to trusted root certificate, is within its validity period, can be used for authentication, and has not been revoked.  It retrieves the public key and UPN from the certificate included in the KERB_AS_REQ and searches for the UPN in Active Directory.  It validates the signed pre-authentication data using the public key from the certificate.  On success, the KDC returns a TGT to the client with its certificate in a KERB_AS_REP.|
+|C | The Kerberos provider ensures it can trust the response from the domain controller. First, it ensures the KDC certificate chains to a root certificate that is trusted by the device.  Next, it ensures the certificate is within its validity period and that it has not be revoked.  The Kerberos provider then verifies the certificate has the KDC Authentication present and that the subject alternate name listed in the KDC's certificate matches the domain name to which the user is authenticating. After passing this criteria, Kerberos returns the TGT to lsass, where it is cached and used for subsequent service ticket requests.|
+
+[Return to top](#Windows-Hello-for-Business-and-Authentication)
+## Hybrid Azure AD join authentication using a Key
+![Hybrid Azure AD join authentication using a Key](images/howitworks/auth-haadj-keytrust.png)
+
+| Phase  | Description  |
+| :----: | :----------- |
+|A | Authentication begins when the users dismisses the lock screen, which triggers winlogon to show the Windows Hello for Business credential provider.  The user provides their Windows Hello gesture (PIN or biometrics).  The credential provider packages these credentials and returns them to winlogon.  Winlogon passes the collected credentials to lsass. Lsass passes the collected credentials to the Kerberos security support provider.  The Kerberos provider gets domain hints from the domain joined workstation to locate a domain controller for the user.|
+|B | The Kerberos provider sends the signed pre-authentication data and the user's public key (in the form of a self-signed certificate) to the Key Distribution Center (KDC) service running on the 2016 domain controller in the form of a KERB_AS_REQ.<br>The 2016 domain controller determines the certificate is a self-signed certificate.  It retrieves the public key from the certificate included in the KERB_AS_REQ and searches for the public key in Active Directory.  It validates the UPN for authentication request matches the UPN registered in Active Directory and validates the signed pre-authentication data using the public key from Active Directory.  On success, the KDC returns a TGT to the client with its certificate in a KERB_AS_REP.| 
+|C | The Kerberos provider ensures it can trust the response from the domain controller. First, it ensures the KDC certificate chains to a root certificate that is trusted by the device.  Next, it ensures the certificate is within its validity period and that it has not be revoked.  The Kerberos provider then verifies the certificate has the KDC Authentication present and that the subject alternate name listed in the KDC's certificate matches the domain name to which the user is authenticating. 
+|D | After passing this criteria, Kerberos returns the TGT to lsass, where it is cached and used for subsequent service ticket requests.|
+|E | Lsass informs winlogon of the success authentication.  Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.|
+|F | While Windows loads the user's desktop, lsass passes the collected credentials to the Cloud Authentication security support provider, referred to as the Cloud AP provider.  The Cloud AP provider requests a nonce from Azure Active Directory.  Azure AD returns a nonce.|
+|G |  The Cloud AP provider signs the nonce using the user's private key and returns the signed nonce to the Azure Active Directory.  Azure Active Directory validates the signed nonce using the user's securely registered public key against the nonce signature.  After validating the signature, Azure AD then validates the returned signed nonce. After validating the nonce, Azure AD creates a PRT with session key that is encrypted to the device's transport key and returns it to the Cloud AP provider.<br>The Cloud AP provider receives the encrypted PRT with session key.  Using the device's private transport key, the Cloud AP provider decrypt the session key and protects the session key using the device's TPM.<br>The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT.|
+
+[Return to top](#Windows-Hello-for-Business-and-Authentication)
+## Hybrid Azure AD join authentication using a Certificate
+![Hybrid Azure AD join authentication using a Certificate](images/howitworks/auth-haadj-certtrust.png)
+
+| Phase  | Description  |
+| :----: | :----------- |
+|A | Authentication begins when the users dismisses the lock screen, which triggers winlogon to show the Windows Hello for Business credential provider.  The user provides their Windows Hello gesture (PIN or biometrics).  The credential provider packages these credentials and returns them to winlogon.  Winlogon passes the collected credentials to lsass. Lsass passes the collected credentials to the Kerberos security support provider.  The Kerberos provider gets domain hints from the domain joined workstation to locate a domain controller for the user.|
+|B | The Kerberos provider sends the signed pre-authentication data and  user's certificate, which includes the public key, to the Key Distribution Center (KDC) service running on the domain controller in the form of a KERB_AS_REQ.<br>The domain controller determines the certificate is not self-signed certificate.  The domain controller ensures the certificate chains to trusted root certificate, is within its validity period, can be used for authentication, and has not been revoked.  It retrieves the public key and UPN from the certificate included in the KERB_AS_REQ and searches for the UPN in Active Directory.  It validates the signed pre-authentication data using the public key from the certificate.  On success, the KDC returns a TGT to the client with its certificate in a KERB_AS_REP.| 
+|C | The Kerberos provider ensures it can trust the response from the domain controller. First, it ensures the KDC certificate chains to a root certificate that is trusted by the device.  Next, it ensures the certificate is within its validity period and that it has not be revoked.  The Kerberos provider then verifies the certificate has the KDC Authentication present and that the subject alternate name listed in the KDC's certificate matches the domain name to which the user is authenticating. 
+|D | After passing this criteria, Kerberos returns the TGT to lsass, where it is cached and used for subsequent service ticket requests.|
+|E | Lsass informs winlogon of the success authentication.  Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.|
+|F | While Windows loads the user's desktop, lsass passes the collected credentials to the Cloud Authentication security support provider, referred to as the Cloud AP provider.  The Cloud AP provider requests a nonce from Azure Active Directory.  Azure AD returns a nonce.|
+|G |  The Cloud AP provider signs the nonce using the user's private key and returns the signed nonce to the Azure Active Directory.  Azure Active Directory validates the signed nonce using the user's securely registered public key against the nonce signature.  After validating the signature, Azure AD then validates the returned signed nonce. After validating the nonce, Azure AD creates a PRT with session key that is encrypted to the device's transport key and returns it to the Cloud AP provider.<br>The Cloud AP provider receives the encrypted PRT with session key.  Using the device's private transport key, the Cloud AP provider decrypt the session key and protects the session key using the device's TPM.<br>The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT.|
+
+[Return to top](#Windows-Hello-for-Business-and-Authentication)
+
+

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)<br>
+[Azure AD joined in Federated environments](#Azure-AD-joined-in-Federated-environments)<br>
+[Hybrid Azure AD joined in Managed environments](#HybridAzure-AD-joined-in-Managed-environments)<br>
+[Hybrid Azure AD joined in Federated environments](#Hybrid-Azure-AD-joined-in-Federated-environments)<br>
+
+
+
+
+## Azure AD joined in Managed environments
+![Azure AD joined in Managed environments](images/howitworks/devreg-aadj-managed.png)
+
+| Phase  | Description  |
+| :----: | :----------- |
+|A | The most common way Azure AD joined devices register with Azure is during the out-of-box-experience (OOBE) where it loads the Azure AD join web application in the Cloud Experience Host (CXH) application.  The application sends a GET request to the Azure OpenID configuration endpoint to discover authorization endpoints.  Azure returns the OpenID configuration, which includes the authorization endpoints, to application as JSON document.|
+|B | The application builds a sign-in request for the authorization end point and collects user credentials.|
+|C |  After the user 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).<br>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
+![Azure AD joined in Managed environments](images/howitworks/devreg-aadj-federated.png)
+
+| Phase  | Description  |
+| :----: | :----------- |
+|A | The most common way Azure AD joined devices register with Azure is during the out-of-box-experience (OOBE) where it loads the Azure AD join web application in the Cloud Experience Host (CXH) application.  The application sends a GET request to the Azure OpenID configuration endpoint to discover authorization endpoints.  Azure returns the OpenID configuration, which includes the authorization endpoints, to application as JSON document.|
+|B | The application builds a sign-in request for the authorization end point and collects user credentials.|
+|C |  After the user 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).<br>The application redirects to the AuthURL value (on-premises STS sign-in page) in the returned JSON realm object.  The application collects credentials through the STS web page.|
+|D | The application POST the credential to the on-premises STS, which may require additional factors of authentication.  The on-premises STS authenticates the user and returns a token.   The application POSTs the token to Azure Active Directory for authentication.  Azure Active Directory validates the token and returns an ID token with claims.|
+|E | The application looks for MDM terms of use (the mdm_tou_url claim). If present, the application retrieves the terms of use from the claim's value, present the contents to the user, and waits for the user to accept the terms of use.  This step is 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
+![Hybrid Azure AD joined in Managed environments](images/howitworks/devreg-hybrid-haadj-managed.png)
+
+| Phase  | Description  |
+| :----: | :----------- |
+| A | The user signs in to a domain joined Windows 10 computers using domain credentials.  This can be 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
+![Hybrid Azure AD joined in Managed environments](images/howitworks/devreg-hybrid-haadj-federated.png)
+
+| Phase  | Description  |
+| :----: | :----------- |
+| A | The user signs in to a domain joined Windows 10 computers using domain credentials.  This can be 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)

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)<br>
+[Azure AD joined provisioning in a Federated environment](#Azure-AD-joined-provisioning-in-a-Federated-environment)<br>
+[Hybrid Azure AD joined provisioning in a Key Trust deployment](#Hybrid-Azure-AD-joined-provisioning-in-a-Key-Trust-deployment)<br>
+[Hybrid Azure AD joined provisioning in a Certificate Trust deployment](#Hybrid-Azure-AD-joined-provisioning-in-a-Certificate-Trust-deployment)<br>
+[Hybrid Azure AD joined provisioning in a synchronous Certificate Trust deployment](#Hybrid-Azure-AD-joined-provisioning-in-a-synchronous-Certificate-Trust-deployment)<br>
+[Domain joined provisioning in an On-premises Key Trust deployment](#Domain-joined-provisioning-in-an-Onpremises-Key-Trust-deployment)<br>
+[Domain joined provisioning in an On-premises Certificate Trust deployment](#Domain-joined-provisioning-in-an-Onpremises-Certificate-Trust-deployment)<br>
+
+
+
+## Azure AD joined provisioning in a Managed environment
+![Azure AD joined provisioning in a Managed environment](images/howitworks/prov-aadj-managed.png)
+
+| Phase  | Description  |
+| :----: | :----------- |
+| A|The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.<br>Users must provide two factors of authentication.  In this phase, the user has already provided one factor of authentication, typically user name and password.  Azure MFA services provides the second factor of authentication.  If the user has performed Azure MFA within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they are not prompted for MFA because the current MFA remains valid.<br>Azure Active Directory validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
+|B | After receiving a ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor.  If the application detects a biometric sensor, it gives the user the choice to enroll biometrics.  After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics).  The user provides and confirms their PIN.  Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data.  This is the user key (ukpub/ukpriv).|
+|C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration.  Azure DRS validates the MFA claim remains current.  On successful validation, Azure DRS locates the user's object in Azure Active Directory, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Azure Active Directory returns a key ID to the application which signals the end of user provisioning and the application exits.|
+
+
+[Return to top](#Windows-Hello-for-Business-Provisioning)
+## Azure AD joined provisioning in a Federated environment
+![Azure AD joined provisioning in a Managed environment](images/howitworks/prov-aadj-federated.png)
+
+| Phase  | Description  |
+| :----: | :----------- |
+| A|The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.<br>  In a federated environment, the plug-in sends the token request to the on-premises STS, such as Active Directory Federation Services.  The on-premises STS authenticates the user and determines if the user should perform another factor of authentication.<br>Users must provide two factors of authentication.  In this phase, the user has already provided one factor of authentication, typically user name and password.  Azure MFA services provides the second factor of authentication.  If the user has performed Azure MFA within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they are not prompted for MFA because the current MFA remains valid.<br> The on-premises STS server issues a enterprise token on successful MFA.  The application sends the token to Azure Active Directory.<br>Azure Active Directory validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
+|B | After receiving a ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor.  If the application detects a biometric sensor, it gives the user the choice to enroll biometrics.  After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics).  The user provides and confirms their PIN.  Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data.  This is the user key (ukpub/ukpriv).|
+|C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration.  Azure DRS validates MFA claim remains current.  On successful validation, Azure DRS locates the user's object in Azure Active Directory, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Azure Active Directory returns key ID to the application which signals the end of user provisioning and the application exits.|
+
+[Return to top](#Windows-Hello-for-Business-Provisioning)
+## Hybrid Azure AD joined provisioning in a Key Trust deployment in a Managed envrionment
+![Hybrid Azure AD joined provisioning in a Key Trust deployment in a Managed ennvironment](images/howitworks/prov-haadj-keytrust-managed.png)
+
+| Phase  | Description  |
+| :----: | :----------- |
+| A|The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.<br>Users must provide two factors of authentication.  In this phase, the user has already provided one factor of authentication, typically user name and password.  Azure MFA services provides the second factor of authentication.  If the user has performed Azure MFA within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they are not prompted for MFA because the current MFA remains valid.<br>Azure Active Directory validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
+|B | After receiving a ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor.  If the application detects a biometric sensor, it gives the user the choice to enroll biometrics.  After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics).  The user provides and confirms their PIN.  Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data.  This is the user key (ukpub/ukpriv).|
+|C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration.  Azure DRS validates the MFA claim remains current.  On successful validation, Azure DRS locates the user's object in Azure Active Directory, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Azure Active Directory returns a key ID to the application which signals the end of user provisioning and the application exits.|
+|D | Azure AD Connect requests updates on its next synchronization cycle.  Azure Active Directory sends the user's public key that was securely registered through provisioning.  AAD Connect receives the public key and writes it to user's msDS-KeyCredentialLink attribute in Active Directory.|
+> [!IMPORTANT]
+> The newly provisionied user will not be able to sign in using Windows Hello for Business until Azure AD Connect successfully synchronizes the public key to the on-premises Active Directory.
+
+
+
+
+[Return to top](#Windows-Hello-for-Business-Provisioning)
+## Hybrid Azure AD joined provisioning in a Certificate Trust deployment in a Managed environment
+![Hybrid Azure AD joined provisioning in a Certificate Trust deployment in a Managed environment](images/howitworks/prov-haadj-certtrust-managed.png)
+
+| Phase  | Description  |
+| :----: | :----------- |
+| A|The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.<br>Users must provide two factors of authentication.  In this phase, the user has already provided one factor of authentication, typically user name and password.  Azure MFA services provides the second factor of authentication.  If the user has performed Azure MFA within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they are not prompted for MFA because the current MFA remains valid.<br>Azure Active Directory validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
+|B | After receiving a ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor.  If the application detects a biometric sensor, it gives the user the choice to enroll biometrics.  After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics).  The user provides and confirms their PIN.  Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data.  This is the user key (ukpub/ukpriv).|
+|C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration.  Azure DRS validates the MFA claim remains current.  On successful validation, Azure DRS locates the user's object in Azure Active Directory, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Azure Active Directory returns a key ID to the application, which represents the end of user key registration.|
+|D | The certificate request portion of provisioning begins after the application receives a successful response from key registration.  The application creates a PKCS#10 certificate request.  The key used in the certificate request is the same key that was securely provisioned.<br> The application sends the certificate request, which includes the public key, to the certificate registration authority hosted on the Active Directory Federation Services (AD FS) farm.<br>  After receiving the certificate request, the certificate registration authority queries Active Directory for the msDS-KeyCredentailsLink for a list of registered public keys.|
+|E | The registration authority validates the public key in the certificate request matches a registered key for the user.<br>  If the public key in the certificate is not found in the list of registered public keys, certificate enrollment is deferred until Phase F completes.  The application is informed of the deferment and exits to the user's desktop.  The automatic certificate enrollment client triggers the Azure AD Web Account Manager plug-in to retry the certificate enrollment at 24, 85, 145, 205, 265, and 480 minutes after phase C successfully completes.  The user must remain signed in for automatic certificate enrollment to trigger certificate enrollment.  If the user signs out, automatic certificate enrollment is triggered approximately 30 minutes after the user's next sign in.<br> After validating the public key, the registration authority signs the certificate request using its enrollment agent certificate.|
+|G |The registration authority sends the certificate request to the enterprise issuing certificate authority. The certificate authority validates the certificate request is signed by a valid enrollment agent and, on success, issues a certificate and returns it to the registration authority that then returns the certificate to the application.|
+|H | The application receives the newly issued certificate and installs the it into the Personal store of the user.  This signals the end of provisioning.|    
+|F | Azure AD Connect requests updates on its next synchronization cycle.  Azure Active Directory sends the user's public key that was securely registered through provisioning.  AAD Connect receives the public key and writes it to user's msDS-KeyCredentialLink attribute in Active Directory.|
+> [!IMPORTANT]
+> The newly provisionied user will not be able to sign in using Windows Hello for Business until Azure AD Connect successfully synchronizes the public key to the on-premises Active Directory.
+
+
+[Return to top](#Windows-Hello-for-Business-Provisioning)
+## Hybrid Azure AD joined provisioning in a synchronous Certificate Trust deployment in a Managed environmnet
+![Hybrid Azure AD joined provisioning in a synchronous Certificate Trust deployment in a Managed environment](images/howitworks/prov-haadj-instant-certtrust-managed.png)
+
+| Phase  | Description  |
+| :----: | :----------- |
+| A|The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.<br>Users must provide two factors of authentication.  In this phase, the user has already provided one factor of authentication, typically user name and password.  Azure MFA services provides the second factor of authentication.  If the user has performed Azure MFA within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they are not prompted for MFA because the current MFA remains valid.<br>Azure Active Directory validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
+|B | After receiving a ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor.  If the application detects a biometric sensor, it gives the user the choice to enroll biometrics.  After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics).  The user provides and confirms their PIN.  Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data.  This is the user key (ukpub/ukpriv).|
+|C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration.  Azure DRS validates the MFA claim remains current.  On successful validation, Azure DRS locates the user's object in Azure Active Directory, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Azure Active Directory returns a key ID and a key receipt to the application, which represents the end of user key registration.|
+|D | The certificate request portion of provisioning begins after the application receives a successful response from key registration.  The application creates a PKCS#10 certificate request.  The key used in the certificate request is the same key that was securely provisioned.<br> The application sends the key receipt and certificate request, which includes the public key, to the certificate registration authority hosted on the Active Directory Federation Services (AD FS) farm.<br>  After receiving the certificate request, the certificate registration authority queries Active Directory for the msDS-KeyCredentailsLink for a list of registered public keys.|
+|E | The registration authority validates the public key in the certificate request matches a registered key for the user.<br>  If the public key in the certificate is not found in the list of registered public keys, it then validates the key receipt to confirm the key was securely registered with Azure.<br>After validating the key receipt or public key, the registration authority signs the certificate request using its enrollment agent certificate.|
+|F |The registration authority sends the certificate request to the enterprise issuing certificate authority. The certificate authority validates the certificate request is signed by a valid enrollment agent and, on success, issues a certificate and returns it to the registration authority that then returns the certificate to the application.|
+|G | The application receives the newly issued certificate and installs the it into the Personal store of the user.  This signals the end of provisioning.|    
+> [!IMPORTANT]
+> Synchronous certificate enrollment does not depend on Azure AD Connect to syncrhonize the user's public key to issue the Windows Hello for Business authentication certificate.  Users can sign-in using the certificate immediately after provisioning completes.  Azure AD Connect continues to synchronize the public key to Active Directory, but is not show in this flow.
+
+
+[Return to top](#Windows-Hello-for-Business-Provisioning)
+## Hybrid Azure AD joined provisioning in a synchronous Certificate Trust deployment in a Federated environment
+![Hybrid Azure AD joined provisioning in a synchronous Certificate Trust deployment in a Fedeerated environment](images/howitworks/prov-haadj-instant-certtrust-federated.png)
+
+| Phase  | Description  |
+| :----: | :----------- |
+| A|The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.<br>  In a federated environment, the plug-in sends the token request to the on-premises STS, such as Active Directory Federation Services.  The on-premises STS authenticates the user and determines if the user should perform another factor of authentication.<br>Users must provide two factors of authentication.  In this phase, the user has already provided one factor of authentication, typically user name and password.  Azure MFA services (or a third party MFA service) provides the second factor of authentication.<br> The on-premises STS server issues a enterprise token on successful MFA.  The application sends the token to Azure Active Directory.<br>Azure Active Directory validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
+|B | After receiving a ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor.  If the application detects a biometric sensor, it gives the user the choice to enroll biometrics.  After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics).  The user provides and confirms their PIN.  Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data.  This is the user key (ukpub/ukpriv).|
+|C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration.  Azure DRS validates the MFA claim remains current.  On successful validation, Azure DRS locates the user's object in Azure Active Directory, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Azure Active Directory returns a key ID and a key receipt to the application, which represents the end of user key registration.|
+|D | The certificate request portion of provisioning begins after the application receives a successful response from key registration.  The application creates a PKCS#10 certificate request.  The key used in the certificate request is the same key that was securely provisioned.<br> The application sends the key receipt and certificate request, which includes the public key, to the certificate registration authority hosted on the Active Directory Federation Services (AD FS) farm.<br>  After receiving the certificate request, the certificate registration authority queries Active Directory for the msDS-KeyCredentailsLink for a list of registered public keys.|
+|E | The registration authority validates the public key in the certificate request matches a registered key for the user.<br>  If the public key in the certificate is not found in the list of registered public keys, it then validates the key receipt to confirm the key was securely registered with Azure.<br>After validating the key receipt or public key, the registration authority signs the certificate request using its enrollment agent certificate.|
+|F |The registration authority sends the certificate request to the enterprise issuing certificate authority. The certificate authority validates the certificate request is signed by a valid enrollment agent and, on success, issues a certificate and returns it to the registration authority that then returns the certificate to the application.|
+|G | The application receives the newly issued certificate and installs the it into the Personal store of the user.  This signals the end of provisioning.| 
+> [!IMPORTANT]
+> Synchronous certificate enrollment does not depend on Azure AD Connect to syncrhonize the user's public key to issue the Windows Hello for Business authentication certificate.  Users can sign-in using the certificate immediately after provisioning completes.  Azure AD Connect continues to synchronize the public key to Active Directory, but is not show in this flow.
+
+[Return to top](#Windows-Hello-for-Business-Provisioning)
+## Domain joined provisioning in an On-premises Key Trust deployment
+![Domain joined provisioning in an On-premises Key Trust deployment](images/howitworks/prov-onprem-keytrust.png)
+
+| Phase  | Description  |
+| :----: | :----------- |
+|A| The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Enterprise Device Registration Service (EDRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.<br>  In an on-premises deployment, the plug-in sends the token request to the on-premises STS, such as Active Directory Federation Services.  The on-premises STS authenticates the user and determines if the user should perform another factor of authentication.<br>Users must provide two factors of authentication.  In this phase, the user has already provided one factor of authentication, typically user name and password.  Azure MFA server (or a third party MFA service) provides the second factor of authentication.<br> The on-premises STS server issues a enterprise DRS token on successful MFA.|
+| B| After receiving a EDRS access token, the application detects if the device has a Windows Hello biometric compatible sensor.  If the application detects a biometric sensor, it gives the user the choice to enroll biometrics.  After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics).  The user provides and confirms their PIN.  Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data.  This is the user key (ukpub/ukpriv).|
+|C | The application sends the EDRS token, ukpub, attestation data, and device information to the Enterprise DRS for user key registration.  Enterprise DRS validates the MFA claim remains current.  On successful validation, the Enterprise DRS locates the user's object in Active Directory, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. The Enterprise DRS returns a key ID to the application, which represents the end of user key registration.|
+
+
+[Return to top](#Windows-Hello-for-Business-Provisioning)
+## Domain joined provisioning in an On-premises Certificate Trust deployment
+![Domain joined provisioning in an On-premises Certificate Trust deployment](images/howitworks/prov-onprem-certtrust.png)
+
+| Phase  | Description  |
+| :----: | :----------- |
+|A| The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Enterprise Device Registration Service (EDRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.<br>  In an on-premises deployment, the plug-in sends the token request to the on-premises STS, such as Active Directory Federation Services.  The on-premises STS authenticates the user and determines if the user should perform another factor of authentication.<br>Users must provide two factors of authentication.  In this phase, the user has already provided one factor of authentication, typically user name and password.  Azure MFA server (or a third party MFA service) provides the second factor of authentication.<br> The on-premises STS server issues a enterprise DRS token on successful MFA.|
+| B| After receiving a EDRS access token, the application detects if the device has a Windows Hello biometric compatible sensor.  If the application detects a biometric sensor, it gives the user the choice to enroll biometrics.  After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics).  The user provides and confirms their PIN.  Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data.  This is the user key (ukpub/ukpriv).|
+|C | The application sends the EDRS token, ukpub, attestation data, and device information to the Enterprise DRS for user key registration.  Enterprise DRS validates the MFA claim remains current.  On successful validation, the Enterprise DRS locates the user's object in Active Directory, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. The Enterprise DRS returns a key ID to the application, which represents the end of user key registration.|
+|D | The certificate request portion of provisioning begins after the application receives a successful response from key registration.  The application creates a PKCS#10 certificate request.  The key used in the certificate request is the same key that was securely provisioned.<br> The application sends the certificate request, which includes the public key, to the certificate registration authority hosted on the Active Directory Federation Services (AD FS) farm.<br>  After receiving the certificate request, the certificate registration authority queries Active Directory for the msDS-KeyCredentailsLink for a list of registered public keys.|
+|E | The registration authority validates the public key in the certificate request matches a registered key for the user.<br>  After validating the  public key, the registration authority signs the certificate request using its enrollment agent certificate.|
+|F |The registration authority sends the certificate request to the enterprise issuing certificate authority. The certificate authority validates the certificate request is signed by a valid enrollment agent and, on success, issues a certificate and returns it to the registration authority that then returns the certificate to the application.|
+|G | The application receives the newly issued certificate and installs the it into the Personal store of the user.  This signals the end of provisioning.|
+
+[Return to top](#Windows-Hello-for-Business-Provisioning)

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.<br>
+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.<br>
+For cloud and hybrid deployments, the identity provider is Azure Active Directory and the user registers their key with the Azure Device Registration Service (ADRS).  For on-premises deployments, the identity provider is Active Directory Federation Services (AD FS), and the user registers their key with the enterprise device registration service hosted on the federation servers.<br>
+Provision can occur automatically through the out-of-box-experience (OOBE) on Azure Active Directory joined devices, or on hybrid Azure Active Directory joined devices where the user or device is influenced by Windows Hello for Business policy settings.  Users can start provisioning through **Add PIN** from Windows Settings.  Watch the [Windows Hello for Business enrollment experience](hello-videos.md#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)

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)
+<hr>
+
+## Attestation Identity Keys
+Because the endorsement certificate is unique for each device and does not change, the usage of it may present privacy concerns because it's theoretically possible to track a specific device. To avoid this privacy problem, Windows 10 issues a derived attestation anchor based on the endorsement certificate. This intermediate key, which can be attested to an endorsement key, is the Attestation Identity Key (AIK) and the corresponding certificate is called the AIK certificate. This AIK certificate is issued by a Microsoft cloud service.
+
+> [!NOTE]
+> The AIK certificate must be provisioned in conjunction with a third-party service like the Microsoft Cloud CA service. After it is provisioned, the AIK private key can be used to report platform configuration. Windows 10 creates a signature over the platform log state (and a monotonic counter value) at each boot by using the AIK.
+> The AIK is an asymmetric (public/private) key pair that is used as a substitute for the EK as an identity for the TPM for privacy purposes. The private portion of an AIK is never revealed or used outside the TPM and can only be used inside the TPM for a limited set of operations. Furthermore, it can only be used for signing, and only for limited, TPM-defined operations.
+
+Windows 10 creates AIKs protected by the TPM, if available, that are 2048-bit RSA signing keys. Microsoft hosts a cloud service called Microsoft Cloud CA to establish cryptographically that it is communicating with a real TPM and that the TPM possesses the presented AIK. After the Microsoft 
+Cloud CA service has established these facts, it will issue an AIK certificate to the Windows 10 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.<br>
+
+Windows 10 leverages security characteristics of a TPM for measuring boot integrity sequence (and based on that, unlocking automatically BitLocker protected drives), for protecting credentials or for health attestation.
+
+A TPM implements controls that meet the specification described by the Trusted Computing Group (TCG). At the time of this writing, there are two versions of TPM specification produced by TCG that are not compatible with each other:
+- The first TPM specification, version 1.2, was published in February 2005 by the TCG and standardized under ISO / IEC 11889 standard.
+- The latest TPM specification, referred to as TPM 2.0, was released in April 2014 and has been approved by the ISO/IEC Joint Technical Committee (JTC) as ISO/IEC 11889:2015.
+
+Windows 10 uses the TPM for cryptographic calculations as part of health attestation and to protect the keys for BitLocker, Windows Hello, virtual smart cards, and other public key certificates. For more information, see [TPM requirements in Windows 10](https://go.microsoft.com/fwlink/p/?LinkId=733948).
+
+Windows 10 recognizes versions 1.2 and 2.0 TPM specifications produced by the TCG. For the most recent and modern security features, Windows 10 supports only TPM 2.0. 
+
+TPM 2.0 provides a major revision to the capabilities over TPM 1.2:
+
+- Update 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)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+    

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

@@ -1,114 +1,32 @@
 ---
-title: How Windows Hello for Business works (Windows 10)
+title: How Windows Hello for Business works
 description: Explains registration, authentication, key material, and infrastructure for Windows Hello for Business.
 ms.prod: w10
 ms.mktglfcycl: deploy
 ms.sitesec: library
 ms.pagetype: security
-author: DaniHalfin
+author: mikestephens-MS
-ms.localizationpriority: medium
+ms.author: mstephen
-ms.author: daniha
+localizationpriority: high
-ms.date: 10/16/2017
+ms.date: 05/05/2018
 ---
 # How Windows Hello for Business works
 
 **Applies to**
--   Windows 10
+-   Windows 10
--   Windows 10 Mobile
-
-Windows Hello for Business requires a registered device. When the device is set up, its user can use the device to authenticate to services. This topic explains how device registration works, what happens when a user requests authentication, how key material is stored and processed, and which servers and infrastructure components are involved in different parts of this process.
-
-## Register a new user or device
-
-A goal of device registration is to allow a user to open a brand-new device, securely join an organizational network to download and manage organizational data, and create a new Windows Hello gesture to secure the device. Microsoft refers to the process of setting up a device for use with Windows Hello as registration.
- 
-> [!NOTE]
->This is separate from the organizational configuration required to use Windows Hello with Active Directory or Azure Active Directory (Azure AD); that configuration information is in [Manage Windows Hello for Business in your organization](hello-manage-in-organization.md). Organizational configuration must be completed before users can begin to register.  
-
- The registration process works like this: 
- 
-1. The user configures an account on the device. This account can be a local account on the device, a domain account stored in the on-premises Active Directory domain, a Microsoft account, or an Azure AD account. For a new device, this step may be as simple as signing in with a Microsoft account. Signing in with a Microsoft account on a Windows 10 device automatically sets up Windows Hello on the device; users don’t have to do anything extra to enable it. 
-2. To sign in using that account, the user has to enter the existing credentials for it. The identity provider (IDP) that “owns” the account receives the credentials and authenticates the user. This IDP authentication may include the use of an existing second authentication factor, or proof. For example, a user who registers a new device by using an Azure AD account will have to provide an SMS-based proof that Azure AD sends. 
-3. When the user has provided the proof to the IDP, the user enables PIN authentication. The PIN will be associated with this particular credential. When the user sets the PIN, it becomes usable immediately 
-
-The PIN chosen is associated with the combination of the active account and that specific device. The PIN must comply with whatever length and complexity policy the account administrator has configured; this policy is enforced on the device side. Other registration scenarios that Windows Hello supports are:
-
-- A user who upgrades from the Windows 8.1 operating system will sign in by using the existing enterprise password. That triggers a second authentication factor from the IDP side (if required); after receiving and returning a proof, such as a text message or voice code, the IDP authenticates the user to the upgraded Windows 10 device, and the user can set his or her PIN.
-- A user who typically uses a smart card to sign in will be prompted to set up a PIN the first time he or she signs in to a Windows 10 device the user has not previously signed in to.
-- A user who typically uses a virtual smart card to sign in will be prompted to set up a PIN the first time he or she signs in to a Windows 10 device the user has not previously signed in to.
-
-When the user has completed this process, Windows Hello generates a new public–private key pair on the device. The TPM generates and protects this private key; if the device doesn’t have a TPM, the private key is encrypted and stored in software. This initial key is referred to as the protector key. It’s associated only with a single gesture; in other words, if a user registers a PIN, a fingerprint, and a face on the same device, each of those gestures will have a unique protector key. Each unique gesture generates a unique protector key. The protector key securely wraps the authentication key. The container has only one authentication key, but there can be multiple copies of that key wrapped with different unique protector keys. Windows Hello also generates an administrative key that the user or administrator can use to reset credentials, when necessary. In addition to the protector key, TPM-enabled devices generate a block of data that contains attestations from the TPM.
-
-At this point, the user has a PIN gesture defined on the device and an associated protector key for that PIN gesture. That means he or she is able to securely sign in to the device with the PIN and thus that he or she can establish a trusted session with the device to add support for a biometric gesture as an alternative for the PIN. When you add a biometric gesture, it follows the same basic sequence: the user authenticates to the system by using his or her PIN, and then registers the new biometric (“smile for the camera!”), after which Windows generates a unique key pair and stores it securely. Future sign-ins can then use either the PIN or the registered biometric gestures.
-
-## What’s a container?
-
-You’ll often hear the term *container* used in reference to mobile device management (MDM) solutions. Windows Hello uses the term, too, but in a slightly different way. Container in this context is shorthand for a logical grouping of key material or data. Windows 10 Hello uses a single container that holds user key material for personal accounts, including key material associated with the user’s Microsoft account or with other consumer identity providers, and credentials associated with a workplace or school account.
-
-The container holds enterprise credentials only on devices that have been registered with an organization; it contains key material for the enterprise IDP, such as on-premises Active Directory or Azure AD. 
-
-It’s important to keep in mind that there are no physical containers on disk, in the registry, or elsewhere. Containers are logical units used to group related items. The keys, certificates, and credentials Windows Hello stores are protected without the creation of actual containers or folders.
-
-The container actually contains a set of keys, some of which are used to protect other keys. The following image shows an example: the protector key is used to encrypt the authentication key, and the authentication key is used to encrypt the individual keys stored in the container.
- 
-![Each logical container holds one or more sets of keys](images/passport-fig3-logicalcontainer.png)
-
-Containers can contain several types of key material:
-
-- An authentication key, which is always an asymmetric public–private key pair. This key pair is generated during registration. It must be unlocked each time it’s accessed, by using either the user’s PIN or a previously generated biometric gesture. The authentication key exists until the user resets the PIN, at which time a new key will be generated. When the new key is generated, all the key material that the old key previously protected must be decrypted and re-encrypted using the new key.
-- Virtual smart card keys are generated when a virtual smart card is generated and stored securely in the container. They’re available whenever the user’s container is unlocked.
-- The IDP key. These keys can be either symmetric or asymmetric, depending on which IDP you use. A single container may contain zero or more IDP keys, with some restrictions (for example, the enterprise container can contain zero or one IDP keys). IDP keys are stored in the container. For certificate-based Windows Hello for Work, when the container is unlocked, applications that require access to the IDP key or key pair can request access. IDP keys are used to sign or encrypt authentication requests or tokens sent from this device to the IDP. IDP keys are typically long-lived but could have a shorter lifetime than the authentication key. Microsoft accounts, Active Directory accounts, and Azure AD accounts all require the use of asymmetric key pairs. The device generates public and private keys, registers the public key with the IDP (which stores it for later verification), and securely stores the private key. For enterprises, the IDP keys can be generated in two ways:
-    - The IDP key pair can be associated with an enterprise Certificate Authority (CA) through the Windows Network Device Enrollment Service (NDES), described more fully in [Network Device Enrollment Service Guidance](https://technet.microsoft.com/library/hh831498.aspx). In this case, Windows Hello requests a new certificate with the same key as the certificate from the existing PKI. This option lets organizations that have an existing PKI continue to use it where appropriate. Given that many applications, such as popular virtual private network systems, require the use of certificates, when you deploy Windows Hello in this mode, it allows a faster transition away from user passwords while still preserving certificate-based functionality. This option also allows the enterprise to store additional certificates in the protected container.
-    - The IDP can generate the IDP key pair directly, which allows quick, lower-overhead deployment of Windows Hello in environments that don’t have or need a PKI.
-    
-## How keys are protected
-
-Any time key material is generated, it must be protected against attack. The most robust way to do this is through specialized hardware. There’s a long history of using hardware security modules (HSMs) to generate, store, and process keys for security-critical applications. Smart cards are a special type of HSM, as are devices that are compliant with the Trusted Computing Group TPM standard. Wherever possible, the Windows Hello for Work implementation takes advantage of onboard TPM hardware to generate and protect keys. However, Windows Hello and Windows Hello for Work do not require an onboard TPM. Administrators can choose to allow key operations in software, in which case any user who has (or can escalate to) administrative rights on the device can use the IDP keys to sign requests. As an alternative, in some scenarios, devices that don’t have a TPM can be remotely authenticated by using a device that does have a TPM, in which case all the sensitive operations are performed with the TPM and no key material is exposed.
-
-Whenever possible, Microsoft recommends the use of TPM hardware. The TPM protects against a variety of known and potential attacks, including PIN brute-force attacks. The TPM provides an additional layer of protection after an account lockout, too. When the TPM has locked the key material, the user will have to reset the PIN (which means he or she will have to use MFA to reauthenticate to the IDP before the IDP allows him or her to re-register). Resetting the PIN means that all keys and certificates encrypted with the old key material will be removed.
-
-
-## Authentication
-
-When a user wants to access protected key material, the authentication process begins with the user entering a PIN or biometric gesture to unlock the device, a process sometimes called releasing the key. Think of it like using a physical key to unlock a door: before you can unlock the door, you need to remove the key from your pocket or purse. The user's PIN unlocks the protector key for the container on the device. When that container is unlocked, applications (and thus the user) can use whatever IDP keys reside inside the container.
-
-These keys are used to sign requests that are sent to the IDP, requesting access to specified resources. It’s important to understand that although the keys are unlocked, applications cannot use them at will. Applications can use specific APIs to request operations that require key material for particular actions (for example, decrypt an email message or sign in to a website). Access through these APIs doesn’t require explicit validation through a user gesture, and the key material isn’t exposed to the requesting application. Rather, the application asks for authentication, encryption, or decryption, and the Windows Hello layer handles the actual work and returns the results. Where appropriate, an application can request a forced authentication even on an unlocked device. Windows prompts the user to reenter the PIN or perform an authentication gesture, which adds an extra level of protection for sensitive data or actions. For example, you can configure the Microsoft Store to require reauthentication any time a user purchases an application, even though the same account and PIN or gesture were already used to unlock the device.
-
-For example, the authentication process for Azure Active Directory works like this:
-
-1.	The client sends an empty authentication request to the IDP. (This is merely for the handshake process.)
-2.	The IDP returns a challenge, known as a nonce.
-3.	The device signs the nonce with the appropriate private key.
-4.	The device returns the original nonce, the signed nonce, and the ID of the key used to sign the nonce.
-5.	The IDP fetches the public key that the key ID specified, uses it to verify the signature on the nonce, and verifies that the nonce the device returned matches the original.
-6.	If all the checks in step 5 succeed, the IDP returns two data items: a symmetric key, which is encrypted with the device’s public key, and a security token, which is encrypted with the symmetric key.
-7.	The device uses its private key to decrypt the symmetric key, and then uses that symmetric key to decrypt the token.
-8.	The device makes a normal authentication request for the original resource, presenting the token from the IDP as its proof of authentication.
-
-When the IDP validates the signature, it is verifying that the request came from the specified user and device. The private key specific to the device signs the nonce, which allows the IDP to determine the identity of the requesting user and device so that it can apply policies for content access based on user, device type, or both together. For example, an IDP could allow access to one set of resources only from mobile devices and a different set from desktop devices.
-
-
-## The infrastructure
-
-Windows Hello depends on having compatible IDPs available to it. As of this writing, that means you have four deployment possibilities: 
-
-- Use an existing Windows-based PKI centered around Active Directory Certificate Services. This option requires additional infrastructure, including a way to issue certificates to users. You can use NDES to register devices directly, or Microsoft Intune where it’s available to manage mobile device participation in Windows Hello. 
-- The normal discovery mechanism that clients use to find domain controllers and global catalogs relies on Domain Name System (DNS) SRV records, but those records don’t contain version data. Windows 10 computers will query DNS for SRV records to find all available Active Directory servers, and then query each server to identify those that can act as Windows Hello IDPs. The number of authentication requests your users generate, where your users are located, and the design of your network all drive the number of Windows Server 2016 domain controllers required. 
-- Azure AD can act as an IDP either by itself or alongside an on-premises AD DS forest. Organizations that use Azure AD can register devices directly without having to join them to a local domain by using the capabilities the Azure AD Device Registration service provides. In addition to the IDP, Windows Hello requires an MDM system. This system can be the cloud-based Intune if you use Azure AD, or an on-premises System Center Configuration Manager deployment that meets the system requirements described in the Deployment requirements section of this document.
-
-
-
-
-
-
-
-
-
-
 
+Windows Hello for Business is a modern, two-factor credential that is the more secure alternative to passwords.  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
 

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 AD Connect Schema Refresh](images/aadj/aadconnectschema.png)
+
+### 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.
+![dsregcmd outpout](images/aadj/dsregcmd.png)
+
+### 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.  
+
+![Domain Controller Certificate with LDAP CDP](images/aadj/Certificate-CDP.png)
+
+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**.
+![Add Virtual Directory](images/aadj/iis-add-virtual-directory.png) 
+> [!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**.
+![IIS Configuration Editor requestFiltering](images/aadj/iis-config-editor-requestFiltering.png)   
+In the list of named value-pairs in the content pane, configure **allowDoubleEscapting** to **True**.  Click **Apply** in the actions pane.
+![IIS Configuration Editor double escaping](images/aadj/iis-config-editor-allowDoubleEscaping.png)
+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**.
+![Create DNS host record](images/aadj/dns-new-host-dialog.png)
+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**.
+![cdp sharing](images/aadj/cdp-sharing.png)
+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**.
+![CDP Share Permissions](images/aadj/cdp-share-permissions.png)
+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**.
+![CDP disable caching](images/aadj/cdp-disable-caching.png)
+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**.
+![CDP NTFS Permissions](images/aadj/cdp-ntfs-permissions.png)
+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). 
+![CDP New Location dialog box](images/aadj/cdp-extension-new-location.png)
+5. Select **\<CaName>** from the **Variable** list and click **Insert**.  Select **\<CRLNameSuffix>** from the **Variable** list and click **Insert**.  Select **\<DeltaCRLAllowed>** from the **Variable** list and click **Insert**.
+6. Type **.crl** at the end of the text in **Location**. Click **OK**.
+7. Select the CDP you just created.
+![CDP complete http](images/aadj/cdp-extension-complete-http.png)
+8. Select **Include in CRLs.  Clients use this to find Delta CRL locations**.
+9. Select **Include in the CDP extension of issued certificates**.
+10. Click **Apply** save your selections.  Click **No** when ask to restart the service.
+
+> [!NOTE]
+> Optionally, you can remove unused CRL distribution points and publishing locations.
+
+#### Configure the CRL publishing location
+
+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 the computer and share name you create for your CRL distribution point in [Configure the CDP file share](#configure-the-cdp-file-share).  For example, **\\\app\cdp$\** (do not forget the trailing backwards slash).
+5. Select **\<CaName>** from the **Variable** list and click **Insert**.  Select **\<CRLNameSuffix>** from the **Variable** list and click **Insert**.  Select **\<DeltaCRLAllowed>** from the **Variable** list and click **Insert**.
+6. Type **.crl** at the end of the text in **Location**. Click **OK**.
+7. Select the CDP you just created.
+![CDP publishing location](images/aadj/cdp-extension-complete-unc.png)
+8. Select **Publish CRLs to this location**.
+9. Select **Publish Delta CRLs to this location**.
+10. Click **Apply** save your selections.  Click **Yes** when ask to restart the service.  Click **OK** to close the properties dialog box.
+
+### Publish a new CRL
+
+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 **Revoked Certificates**, hover over **All Tasks**, and click **Publish**
+![Publish a New CRL](images/aadj/publish-new-crl.png)
+3. In the **Publish CRL** dialog box, select **New CRL** and click **OK**.
+
+#### Validate CDP Publishing
+
+Validate your new CRL distribution point is working. 
+
+1. Open a web browser.  Navigate to **http://crl.[yourdomain].com/cdp**.  You should see two files created from publishing your new CRL.
+![Validate the new CRL](images/aadj/validate-cdp-using-browser.png)
+
+### Reissue domain controller certificates
+
+With the CA properly configured with a valid HTTP-based CRL distribution point, you need to reissue certificates to domain controllers as the old certificate does not have the updated CRL distribution point. 
+
+1. Sign-in a domain controller using administrative credentials.
+2. Open the **Run** dialog box.  Type **certlm.msc** to open the **Certificate Manager** for the local computer.
+3. In the navigation pane, expand **Personal**.  Click **Certificates**.  In the details pane, select the existing domain controller certificate includes **KDC Authentication** in the list of **Intended Purposes**.
+![Certificate Manager Personal store](images/aadj/certlm-personal-store.png)
+4. Right-click the selected certificate.  Hover over **All Tasks** and then select **Renew Certificate with New Key...**.  In the **Certificate Enrollment** wizard, click **Next**.
+![Renew with New key](images/aadj/certlm-renew-with-new-key.png) 
+5. In the **Request Certificates** page of the wizard, verify the selected certificate has the correct certificate template and ensure the status is available.  Click **Enroll**.
+6. After the enrollment completes, click **Finish** to close the wizard. 
+7. Repeat this procedure on all your domain controllers.
+
+> [!NOTE]
+> You can configure domain controllers to automatically enroll and renew their certificates.  Automatic certificate enrollment helps prevent authentication outages due to expired certificates.  Refer to the [Windows Hello Deployment Guides](https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-deployment-guide) to learn how to deploy automatic certificate enrollment for domain controllers. 
+
+> [!IMPORTANT]
+> If you are not using automatic certificate enrollment, create a calendar reminder to alert you two months before the certificate expiration date. Send the reminder to multiple people in the organization to ensure more than one or two people know when these certificates expire.
+
+#### Validate CDP in the new certificate
+
+1. Sign-in a domain controller using administrative credentials.
+2. Open the **Run** dialog box.  Type **certlm.msc** to open the **Certificate Manager** for the local computer.
+3. In the navigation pane, expand **Personal**.  Click **Certificates**.  In the details pane, double-click the existing domain controller certificate includes **KDC Authentication** in the list of **Intended Purposes**.
+4. Click the **Details** tab.  Scroll down the list until **CRL Distribution Points** is visible in the **Field** column of the list.  Select **CRL Distribution Point**.
+5. Review the information below the list of fields to confirm the new URL for the CRL distribution point is present in the certificate.  Click **OK**.</br>
+![New Certificate with updated CDP](images/aadj/dc-cert-with-new-cdp.png)
+
+
+## Configure and Assign a Trusted Certificate Device Configuration Profile
+
+Your domain controllers have new certificate that include the new CRL distribution point.  Next, you need your enterprise root certificate so you can deploy it to Azure AD joined devices.  Deploying the enterprise root certificates to the device, ensures the device trusts any certificates issued by the certificate authority.  Without the certificate, Azure AD joined devices do not trust domain controller certificates and authentication fails. 
+
+Steps you will perform include:
+- [Export Enterprise Root certificate](#export-enterprise-root-certificate)
+- [Create and Assign a Trust Certificate Device Configuration Profile](#create-and-assign-a-trust-certificate-device-configuration-profile)
+
+### Export Enterprise Root certificate
+
+1. Sign-in a domain controller using administrative credentials.
+2. Open the **Run** dialog box.  Type **certlm.msc** to open the **Certificate Manager** for the local computer.
+3. In the navigation pane, expand **Personal**.  Click **Certificates**.  In the details pane, double-click the existing domain controller certificate includes **KDC Authentication** in the list of **Intended Purposes**.
+4. Click the **Certification Path** tab.  In the **Certifcation path** view, select the top most node and click **View Certificate**.
+![Certificate Path](images/aadj/certlm-cert-path-tab.png)
+5. In the new **Certificate** dialog box, click the **Details** tab. Click **Copy to File**.
+![Details tab and copy to file](images/aadj/certlm-root-cert-details-tab.png)
+6. In the **Certificate Export Wizard**, click **Next**.  
+7. On the **Export File Format** page of the wizard, click **Next**.  
+8. On the **File to Export** page in the wizard, type the name and location of the root certificate and click **Next**. Click **Finish** and then click **OK** to close the success dialog box.
+![Export root certificate](images/aadj/certlm-export-root-certificate.png)
+9. Click **OK**  two times to return to the **Certificate Manager** for the local computer.  Close the **Certificate Manager**.
+
+### Create and Assign a Trust Certificate Device Configuration Profile
+
+A **Trusted Certificate** device configuration profile is how you deploy trusted certificates to Azure AD joined devices.
+
+1. Sign-in to the [Microsoft Azure Portal](https://portal.azure.com) and select **Microsoft Intune**.
+2. Click **Device configuration**.  In the **Device Configuration** blade, click **Create profile**.
+![Intune Create Profile](images/aadj/intune-create-device-config-profile.png)
+3. In the **Create profle** blade, type **Enterprise Root Certificate** in **Name**.  Provide a description.  Select **Windows 10 and later** from the **Platform** list.  Select **Trusted certificate** from the **Profile type** list.  Click **Configure**.
+4. In the **Trusted Certificate** blade, use the folder icon to browse for the location of the enterprise root certificate file you created in step 8 of [Export Enterprise Root certificate](#export-enterprise-root-certificate).  Click **OK**.  Click **Create**.
+![Intune Trusted Certificate Profile](images/aadj/intune-create-trusted-certificate-profile.png)
+5. In the **Enterprise Root Certificate** blade, click **Assignmnets**.  In the **Include** tab, select **All Devices** from the **Assign to** list.  Click **Save**.
+![Intune Profile assignment](images/aadj/intune-device-config-enterprise-root-assignment.png)
+6. Sign out of the Microsoft Azure Portal.
+
+## Configure Windows Hello for Business Device Enrollment
+
+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. Click **device enrollment**.
+4. Click **Windows enrollment**
+5. Under **Windows enrollment**, click **Windows Hello for Business**.
+![Create Intune Windows Hello for Business Policy](images/aadj/IntuneWHFBPolicy-00.png)
+6. Under **Priority**, click **Default**. 
+7. Under **All users and all devices**, click **Settings**.
+8. Select **Enabled** from the **Configure Windows Hello for Business** list.
+9. Select **Required** next to **Use a Trusted Platform Module (TPM)**.  By default, Windows Hello for Business prefers TPM 2.0 or falls backs to software. Choosing **Required** forces Windows Hello for Business to only use TPM 2.0 or TPM 1.2 and does not allow fall back to software based keys.
+10. Type the desired **Minimum PIN length** and **Maximum PIN length**.
+> [!IMPORTANT]
+> The default minimum PIN length for Windows Hello for Business on Windows 10 is 6.  Microsoft Intune defaults the minimum PIN length to 4, which reduces the security of the user's PIN.  If you do not have a desired PIN length, set the minimum PIN length to 6.
+
+![Intune Windows Hello for Business policy settings](images/aadj/IntuneWHFBPolicy-01.png)
+
+11. Select the appropriate configuration for the following settings.
+  * **Lowercase letters in PIN**
+  * **Uppercase letters in PIN**
+  * **Special characters in PIN**
+  * **PIN expiration (days)**
+  * **Remember PIN history**
+> [!NOTE]
+> The Windows Hello for Business PIN is not a symmetric key (a password).  A copy of the current PIN is not stored locally or on a server like in the case of passwords.  Making the PIN as complex and changed frequently as a password increases the likelihood of forgotten PINs.  Additionally, enabling PIN history is the only scenario that requires Windows 10 to store older PIN combinations (protected to the current PIN). Windows Hello for Business combined with a TPM provides anti-hammering functionality that prevents brute force attacks of the user's PIN.  If you are concerned with user-to-user shoulder surfacing, rather that forcing complex PIN that change frequently, consider using the [Multifactor Unlock](feature-multifactor-unlock.md) feature.
+
+12. Select **Yes** next to **Allow biometric authentication** if you want to allow users to use biometrics (fingerprint and/or facial recognition) to unlock the device.  To further secure the use of biometrics, select **Yes** to **Use enhanced anti-spoofing, when available**.
+13. Select **No** to **Allow phone sign-in**.  This feature has been deprecated.
+14. Click **Save**
+15. Sign-out of the Azure portal.
+
+## Section Review
+> [!div class="checklist"]
+> * Configure Internet Information Services to host CRL distribution point
+> * Prepare a file share to host the certificate revocation list
+> * Configure the new CRL distribution point in the issuing certificate authority
+> * Publish CRL
+> * Reissue domain controller certificates
+> * Export Enterprise Root certificate
+> * Create and Assign a Trust Certificate Device Configuration Profile
+> * Configure Windows Hello for Business Device Enrollment
+
+If you plan on using certificates for on-premises single-sign on, perform the additional steps in [Using Certificates for On-premises Single-sign On](hello-hybrid-aadj-sso-cert.md). 
+ 
+
+
+

windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md

@@ -0,0 +1,689 @@
+---
+title: Using Certificates for AADJ On-premises Single-sign On single sign-on
+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
+---
+# Using Certificates for AADJ On-premises Single-sign On
+
+**Applies to**
+- Windows 10
+- Azure Active Directory joined
+- Hybrid Deployment
+- Certificate trust
+
+If you plan to use certificates for on-premises single-sign on, then follow these **additional** steps to configure the environment to enroll Windows Hello for Business certificates for Azure AD joined devices.
+
+> [!IMPORTANT]
+> Ensure you have performed the configurations in [Azure AD joined devices for On-premises Single-Sign On](hello-hybrid-aadj-sso-base.md) before you continue. 
+
+Steps you will perform include:
+- [Prepare Azure AD Connect](#prepare-azure-ad-connect)
+- [Prepare the Network Device Enrollment Services Service Account](#prepare-the-network-device-enrollment-services-ndes-service-account)
+- [Prepare Active Directory Certificate Services](#prepare-active-directory-certificate-authority)
+- [Install the Network Device Enrollment Services Role](#install-and-configure-the-ndes-role)
+- [Configure Network Device Enrollment Services to work with Microsoft Intune](#configure-network-device-enrollment-services-to-work-with-microsoft-intune)
+- [Download, Install and Configure the Intune Certificate Connector](#download-install-and-configure-the-intune-certificate-connector)
+- [Create and Assign a Simple Certificate Enrollment Protocol (SCEP) Certificate Profile](#create-and-assign-a-simple-certificate-enrollment-protocol-scep-certificate-profile)
+
+## Requirements
+You need to install and configure additional infrastructure to provide Azure AD joined devices with on-premises single-sign on.
+
+- An existing Windows Server 2012 R2 or later Enterprise Certificate Authority
+- A Windows Server 2012 R2 domain joined server that hosts the Network Device Enrollment Services role
+
+### High Availaibilty
+The Network Device Enrollment Services (NDES) server role acts as a certificate registration authority.  Certificate registration servers enroll certificates on behalf of the user.  Users request certificates from the NDES service rather than directly from the issuing certificate authority. 
+
+The architecture of the NDES server prevents it from being clustered or load balanced for high availability.  To provide high availability, you need to install more than one identically configured NDES servers and use Microsoft Intune to load balance then (in round-robin fashion).
+
+The Network Device Enrollment Service (NDES) server role can issue up to three unique certificate templates.  The server role accomplishes this by mapping the purpose of the certificate request to a configured certificate template.  The certificate request purpose has three options:
+
+- Signature
+- Encryption
+- Signature and Encryption
+
+If you need to deploy more than three types of certificates to the Azure AD joined device, you need additional NDES servers.  Alternatively, consider consolidating certificates templates to reduce the number of certificate templates.
+
+### Network Requirements
+All communication occurs securely over port 443. 
+
+## Prepare Azure AD Connect
+Successful authentication to on-premises resources using a certificate requires the certificate to provide a hint about the on-premises domain.  The hint can be the user's Active Directory distinguished name as the subject of the certificate, or the hint can be the user's user principal name where the suffix matches the Active Directory domain name.
+
+Most environments change the user principal name suffix to match the organization's external domain name (or vanity domain), which prevents the user principal name as a hint to locate a domain controller.  Therefore, the certificate needs the user's on-premises distinguished name in the subject to properly locate a domain controller.
+
+To include the on-premises distinguished name in the certificate's subject, Azure AD Connect must replicate the Active Directory **distinguishedName** attribute to the Azure Active Directory **onPremisesDistinguishedName** attribute.  Azure AD Connect version 1.1.819 includes the proper synchronization rules need to for these attributes. 
+
+### Verify AAD Connect version
+Sign-in to computer running Azure AD Connect with access equivalent to _local administrator_.
+
+1. Open **Syncrhonization Services** from the **Azure AD Connect** folder.
+2. In the **Syncrhonization Service Manager**, click **Help** and then click **About**.
+3. If the version number is not **1.1.819** or later, then upgrade Azure AD Connect to the latest version.
+
+### Verify the onPremisesDistinguishedName attribute is synchronized
+The easiest way to verify the onPremisesDistingushedNamne attribute is synchronized is to use Azure AD Graph Explorer.
+
+1. Open a web browser and navigate to https://graphexplorer.azurewebsites.net/
+2. Click **Login** and provide Azure credentials
+3. In the Azure AD Graph Explorer URL, type **https://graph.windows.net/myorganization/users/[userid], where **[userid]** is the user principal name of user in Azure Active Directory.  Click **Go**
+4. In the returned results, review the JSON data for the **onPremisesDistinguishedName** attribute.  Ensure the attribute has a value and the value is accurate for the given user.
+![Azure AD Connect On-Prem DN Attribute](images/aadjcert/aadconnectonpremdn.png)
+
+## Prepare the Network Device Enrollment Services (NDES) Service Account
+
+### Create the NDES Servers global security group
+The deployment uses the **NDES Servers** security group to assign the NDES service the proper user right assignments.
+
+Sign-in to a domain controller or management workstation with access equivalent to _domain administrator_.
+
+1.	Open **Active Directory Users and Computers**.
+2.	Expand the domain node from the navigation pane.
+3.	Right-click the **Users** container. Hover over **New** and click **Group**.
+4.	Type **NDES Servers** in the **Group Name** text box.
+5.	Click **OK**.
+
+### Add the NDES server to the NDES Servers global security group
+Sign-in to a domain controller or management workstation with access equivalent to _domain administrator_.
+
+1.	Open **Active Directory Users and Computers**.
+2.  Expand the domain node from the navigation pane.
+3.  Click **Computers** from the navigation pane. Right-click the name of the NDES server that will host the NDES server role.  Click **Add to a group...**.
+4. Type **NDES Servers** in **Enter the object names to select**.  Click **OK**.  Click **OK** on the **Active Directory Domain Services** success dialog.
+
+> [!NOTE]
+> For high-availabilty, you should have more than one NDES server to service Windows Hello for Business certificate requests.  You should add additional Windows Hello for Business NDES servers to this group to ensure they receive the proper configuration.
+
+### Create the NDES Service Account
+The Network Device Enrollment Services (NDES) role runs under a service account. Typically, it is preferential to run services using a Group Managed Service Account (GMSA).  While the NDES role can be configured to run using a GMSA, the Intune Certificate Connector was not designed nor tested using a GMSA and is considered an unsupported configuration.  The deployment uses a normal services account.
+
+Sign-in to a domain controller or management workstation with access equivalent to _domain administrator_.
+
+1. In the navigation pane, expand the node that has your domain name.  Select **Users**.
+2. Right-click the **Users** container. Hover over **New** and then select **User**.  Type **NDESSvc** in  **Full Name** and **User logon name**. Click **Next**.
+3. Type a secure password in **Password**.  Confirm the secure password in **Confirm Password**.  Clear **User must change password at next logon**.  Click **Next**.
+4. Click **Finish**.
+
+> [!IMPORTANT]
+> Configuring the service's account password to **Password never expires** may be more convenient, but it presents a security risk.  Normal service account passwords should expire in accordance with the organizations user password expiration policy.  Create a reminder to change the service account's password two weeks before it will expire.  Share the reminder with others that are allowed to change the password to ensure the password is changed before it expires. 
+
+### Create the NDES Service User Rights Group Policy object
+The Group Policy object ensures the NDES Service account has the proper user right assign all the NDES servers in the **NDES Servers** group.  As you add new NDES servers to your environment and this group, the service account automatically receives the proper user rights through Group Policy.
+
+Sign-in a domain controller or management workstations with _Domain Admin_ equivalent credentials.
+
+1. Start the **Group Policy Management Console** (gpmc.msc)
+2. Expand the domain and select the **Group Policy Object** node in the navigation pane.
+3. Right-click **Group Policy object** and select **New**.
+4. Type **NDES Service Rights** in the name box and click **OK**.
+5. In the content pane, right-click the **NDES Service Rights** Group Policy object and click **Edit**.
+6. In the navigation pane, expand **Policies** under **Computer Configuration**.
+7. Expand **Windows Settings > Security Settings > Local Policies**. Select **User Rights Assignments**.
+8. In the content pane, double-click **Allow log on locally**. Select **Define these policy settings**. and click **OK**.  Click **Add User or Group...**.  In the **Add User or Group** dialog box, click **Browse**.  In the **Select Users, Computers, Service Accounts, or Groups** dialog box, type **Administrators;Backup Operators;DOMAINNAME\NDESSvc;Users** where **DOMAINNAME** is the NetBios name of the domain (Example CONTOSO\NDESSvc) in **User and group names**.  Click **OK** twice.
+9. In the content pane, double-click **Log on as a batch job**. Select **Define these policy settings**. and click **OK**.  Click **Add User or Group...**.  In the **Add User or Group** dialog box, click **Browse**.  In the **Select Users, Computers, Service Accounts, or Groups** dialog box, type **Administrators;Backup Operators;DOMAINNAME\NDESSvc;Performance Log Users** where **DOMAINNAME** is the NetBios name of the domain (Example CONTOSO\NDESSvc) in **User and group names**.  Click **OK** twice.
+10. In the content pane, double-click **Log on as a batch job**. Select **Define these policy settings**. and click **OK**.  Click **Add User or Group...**.  In the **Add User or Group** dialog box, click **Browse**.  In the **Select Users, Computers, Service Accounts, or Groups** dialog box, type **NT SERVICE\ALL SERVICES;DOMAINNAME\NDESSvc** where **DOMAINNAME** is the NetBios name of the domain (Example CONTOSO\NDESSvc) in **User and group names**.  Click **OK** three times.
+11. Close the **Group Policy Management Editor**. 
+
+### Configure security for the NDES Service User Rights Group Policy object
+The best way to deploy the **NDES Service User Rights** Group Policy object is to use security group filtering. This enables you to easily manage the computers that  receive the Group Policy settings by adding them to a group. 
+
+Sign-in to a domain controller or management workstation with access equivalent to _domain administrator_.
+
+1. Start the **Group Policy Management Console** (gpmc.msc)
+2. Expand the domain and select the **Group Policy Object** node in the navigation pane.
+3. Double-click the **NDES Service User Rights** Group Policy object.
+4. In the **Security Filtering** section of the content pane, click **Add**.  Type **NDES Servers** or the name of the security group you previously created and click **OK**.
+5. Click the **Delegation** tab. Select **Authenticated Users** and click **Advanced**.
+6. In the **Group or User names** list, select **Authenticated Users**.  In the **Permissions for Authenticated Users** list, clear the **Allow** check box for the **Apply Group Policy** permission. Click **OK**.
+
+### Deploy the NDES Service User Rights Group Policy object
+The application of the **NDES Service User Rights** Group Policy object uses security group filtering.  This enables you to link the Group Policy object at the domain, ensuring the Group Policy object is within scope to all computers. However, the security group filtering ensures only computers included in the **NDES Servers** global security group receive and apply the Group Policy object, which results in providing the **NDESSvc** service account with the proper user rights.
+
+Sign-in to a domain controller or management workstation with access equivalent to _domain administrator_.
+
+1. Start the **Group Policy Management Console** (gpmc.msc)
+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 **NDES Service User Rights** or the name of the Group Policy object you previously created and click **OK**.
+
+> [!IMPORTANT]
+> Linking the **NDES Service User Rights** Group Policy object to the domain ensures the Group Policy object is in scope for all computers. However, not all computers will have the policy settings applied to them. Only computers that are members of the **NDES Servers** global security group receive the policy settings. All others computers ignore the Group Policy object. 
+
+## Prepare Active Directory Certificate Authority
+You must prepare the public key infrastructure and the issuing certificate authority to support issuing certificates using Microsoft Intune and the Network Devices Enrollment Services (NDES) server role.  In this task, you will
+
+- Configure the certificate authority to let Intune provide validity periods
+- Create an NDES-Intune Authentication Certificate template
+- Create an Azure AD joined Windows Hello for Business authentication certificate template
+- Publish certificate templates
+
+### Configure the certificate authority to let Intune provide validity periods
+When deploying certificates using Microsoft Intune, you have the option of providing the validity period in the SCEP certificate profile rather than relying on the validity period in the certificate template.  If you need to issue the same certificate with different validity periods, it may be advantageous to use the SCEP profile, given the limited number of certificates a single NDES server can issue.
+
+> [!NOTE]
+> Skip this step if you do not want to enable Microsoft Intune to specify the validity period of the certificate.  Without this configuiration, the certificate request uses the validity period configured in the certificate template.
+
+Sign-in to the issuing certificate authority with access equivalent to _local administrator_.
+
+1. Open and elevated command prompt.  Type the command
+```
+certutil -setreg Policy\EditFlags +EDITF_ATTRIBUTEENDDATE
+```
+2. Restart the **Active Directory Certificate Services** service. 
+
+### Create an NDES-Intune authentication certificate template
+NDES uses a server authentication certificate to authenticate the server endpoint, which encrypts the communication between it and the connecting client.  The Intune Certificate Connector uses a client authentication certificate template to authenticate to the certificate registration point. 
+
+Sign-in to the issuing certificate authority or management workstations with _Domain Admin_ equivalent credentials.
+
+1.  Open the **Certificate Authority** management console.
+2.	Right-click **Certificate Templates** and click **Manage**.
+3.	In the **Certificate Template Console**, right-click the **Computer** template in the details pane and click **Duplicate Template**.
+4.	On the **General** tab, type **NDES-Intune Authentication** 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.
+5.  On the **Subject** tab, select **Supply in the request**.
+6.  On the **Cryptography** tab, validate the **Minimum key size** is **2048**.
+7.  On the **Security** tab, click **Add**. 
+8.  Type **NDES server** in the **Enter the object names to select** text box and click **OK**.
+9.  Select **NDES server** from the **Group or users names** list. In the **Permissions for** section, select the **Allow** check box for the **Enroll** permission. 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**.
+10.	 Click on the **Apply** to save changes and close the console. 
+
+### Create an Azure AD joined Windows Hello for Business authentication certificate template
+During Windows Hello for Business provisioning,  Windows 10 requests an authentication certificate from the Microsoft Intune, which requests the authentication certificate on behalf of the user.  This task configures the Windows Hello for Business authentication certificate template.  You use the name of the certificate template when configuring the NDES Server.
+
+Sign-in a certificate authority or management workstations with _Domain Admin equivalent_ credentials.
+
+1. Open the **Certificate Authority** management console.
+2. Right-click **Certificate Templates** and click **Manage**.
+3. Right-click the **Smartcard Logon** template and choose **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.
+5. On the **General** tab, type **AADJ WHFB Authentication** 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 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 **Subject** tab, select **Supply in the request**.
+9.	On the **Request Handling** tab, select **Signature and encryption** from the **Purpose** list.  Select the **Renew with same key** check box. Select **Enroll subject without requiring any user input**.
+10.	On the **Security** tab, click **Add**. Type **NDESSvc** in the **Enter the object names to select** text box and click **OK**.
+12.	Select  **NDESSvc** from the **Group or users names** list. In the **Permissions for NDES Servers** section, select the **Allow** check box for the **Read**, **Enroll**. Clear the **Allow** check box for the **Enroll** and **Autoenroll** permissions for all other entries in the **Group or users names** section if the check boxes are not already cleared. Click **OK**. 
+13.	Close the console.
+
+### Publish certificate 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.
+
+> [!Important]
+> Ensure you publish the **AADJ WHFB Authentication** certificate templates to the certificate authority that Microsoft Intune uses by way of the NDES servers. The NDES configuration asks you to choose a certificate authority from which it requests certificates.  You need to publish that cerificate templates to that issuing certificate authority.  The **NDES-Intune Authentication** certificate is directly enrolled and can be published to any 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 **NDES-Intune Authentication** and **AADJ 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.
+
+## Install and Configure the NDES Role
+This section includes the following topics:
+* Install the Network Device Enrollment Service Role
+* Configure the NDES service account
+* Configure the NDES role and Certificate Templates
+* Create a Web Application Proxy for the Internal NDES URL.
+* Enroll for an NDES-Intune Authentication Certificate
+* Configure the Web Server Certificate for NDES
+* Verify the configuration
+
+### Install the Network Device Enrollment Services Role
+Install the Network Device Enrollment Service role on a computer other than the issuing certificate authority.
+
+Sign-in to the certificate authority or management workstations with an _Enterprise Admin_ equivalent credentials.
+
+1. Open **Server Manager** on the NDES server.
+2. Click **Manage**.  Click **Add Roles and Features**. 
+3. In the **Add Roles and Features Wizard**, on the **Before you begin** page, click **Next**.  Select **Role-based or feature-based installation** on the **Select installation type** page.  Click **Next**.  Click **Select a server from the server pool**.  Select the local server from the **Server Pool** list.  Click **Next**.
+![Server Manager destination server](images/aadjCert/servermanager-destination-server-ndes.png)
+4. On the **Select server roles** page, select **Active Directory Certificate Services** from the **Roles** list.  
+![Server Manager AD CS Role](images/aadjCert/servermanager-adcs-role.png)
+Click **Add Features** on the **Add Roles and Feature Wizard** dialog box.  Click **Next**.
+![Server Manager Add Features](images/aadjcert/serverManager-adcs-add-features.png)
+5. On the **Features** page, expand **.NET Framework 3.5 Features**.  Select **HTTP Activation**.  Click **Add Features** on the **Add Roles and Feature Wizard** dialog box.  Expand **.NET Framework 4.5 Features**.  Expand **WCF Services**.  Select **HTTP Activation**.  Click **Add Features** on the **Add Roles and Feature Wizard** dialog box.  Click **Next**.
+![Server Manager Feature HTTP Activation](images/aadjcert/servermanager-adcs-http-activation.png)
+6. On the **Select role services** page, clear the **Certificate Authority** check box. Select the **Network Device Enrollment Service**.  Click **Add Features** on the **Add Roles and Features Wizard** dialog box. Click **Next**.
+![Server Manager ADCS NDES Role](images/aadjcert/servermanager-adcs-ndes-role-checked.png)
+7. Click **Next** on the **Web Server Role (IIS)** page.
+8. On the **Select role services** page for the Web Serve role, Select the following additional services if they are not already selected and then click **Next**.
+  * **Web Server > Security > Request Filtering**
+  * **Web Server > Application Development > ASP.NET 3.5**.
+  * **Web Server > Application Development > ASP.NET 4.5**.   .
+  * **Management Tools > IIS 6 Management Compatibility > IIS 6 Metabase Compatibility**
+  * **Management Tools > IIS 6 Management Compatibility > IIS 6 WMI Compatibility**
+![Server Manager Web Server Role](images/aadjcert/servermanager-adcs-webserver-role.png)
+9. Click **Install**. When the installation completes, continue with the next procedure.  **Do not click Close**.
+> [!Important]
+> The .NET Framework 3.5 is not included in the typical installation.  If the server is connected to the Internet, the installation attempts to get the files using Windows Update.  If the server is not connected to the Internet, you need to **Specify an alternate source path** such as \<driveLetter>:\\Sources\SxS\
+![.NET Side by Side](images/aadjcert/dotNet35sidebyside.png)
+
+### Configure the NDES service account
+This task adds the NDES service account to the local IIS_USRS group.  The task also configures the NDES service account for Kerberos authentication and delegation
+
+#### Add the NDES service account to the IIS_USRS group
+Sign-in the NDES server with access equivalent to _local administrator_.
+
+1. Start the **Local Users and Groups** management console (lusrmgr.msc).
+2. Select **Groups** from the navigation pane. Double-click the IIS_IUSRS group.
+3. In the **IIS_IUSRS Properties** dialog box, click **Add**.  Type **NDESSvc** or the name of your NDES service account.  Click **Check Names** to verify the name and then click **OK**. Click **OK** to close the properties dialog box.
+4. Close the management console.
+
+#### Register a Service Principal Name on the NDES Service account
+Sign-in the NDES server with a access equivalent to _Domain Admins_.
+
+1. Open an elevated command prompt.
+2. Type the following command to register the service principal name<br>
+```setspn -s http/[FqdnOfNdesServer] [DomainName\\NdesServiceAccount]```<br>
+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.<br>
+```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.
+
+![Set SPN command prompt](images/aadjcert/setspn-commandprompt.png)
+
+#### 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.
+![NDES Delegation Tab](images/aadjcert/ndessvcdelegationtab.png)
+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**.
+![NDES Service delegation to NDES host](images/aadjcert/ndessvcdelegation-host-ndes-spn.png)
+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.
+![NDES Service delegation complete](images/aadjcert/ndessvcdelegation-host-ca-spn.png)
+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. 
+
+![Server Manager Post-Install Yellow flag](images/aadjcert/servermanager-post-ndes-yellowactionflag.png)
+
+1. Click the **Configure Active Directory Certificate Services on the destination server** link.
+2. On the **Credentials** page, click **Next**.
+![NDES Installation Credentials](images/aadjcert/ndesconfig01.png)
+3. On the **Role Services** page, select **Network Device Enrollment Service** and then click **Next**
+![NDES Role Services](images/aadjcert/ndesconfig02.png)
+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**.
+![NDES Service Account for NDES](images/aadjcert/ndesconfig03b.png)
+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**.
+![NDES CA selection](images/aadjcert/ndesconfig04.png)
+6. On the **RA Information**, click **Next**.
+7. On the **Cryptography for NDES** page, click **Next**.
+8. Review the **Confirmation** page.  Click **Configure**.
+![NDES Confirmation](images/aadjcert/ndesconfig05.png)
+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<br>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<br>
+```reg add HKLM\Software\Microsoft\Cryptography\MSCEP /v [registryValueName] /t REG_SZ /d [certificateTemplateName]```<br>
+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:<br>
+```reg add HKLM\Software\Microsoft\Cryptography\MSCEP /v SignatureTemplate /t REG_SZ /d AADJWHFBAuthentication```<br>
+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.
+![Azure Application Proxy Connectors](images/aadjcert/azureconsole-applicationproxy-connectors-empty.png)
+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**.
+![Azure Application Proxy Connector](images/aadjcert/azureappproxyconnectorinstall-01.png)
+8. Sign-in to Microsoft Azure with access equivalent to **Global Administrator**.
+![Azure Application Proxy Connector](images/aadjcert/azureappproxyconnectorinstall-02.png)
+9. When the installation completes. Read the information regarding outbound proxy servers.  Click **Close**.
+![Azure Application Proxy Connector](images/aadjcert/azureappproxyconnectorinstall-03.png)
+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**.
+![Azure Application Proxy Connector groups](images/aadjcert/azureconsole-applicationproxy-connectors-default.png)
+4. Click **New Connector Group**. Under **Name**, type **NDES WHFB Connectors**.
+![Azure Application New Connector Group](images/aadjcert/azureconsole-applicationproxy-connectors-newconnectorgroup.png)
+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).
+![Azure NDES Application Proxy Configuration](images/aadjcert/azureconsole-appproxyconfig.png)
+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   
+    ![Example of Certificate Properties Subject Tab - This is what shows when you click the above link](images/aadjcert/ndes-TLS-Cert-Enroll-subjectNameWithExternalName.png)
+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**. 
+![NDES IIS Console](images/aadjcert/ndes-iis-console.png)
+3. Click **Bindings...*** under **Actions**.  Click **Add**.
+![NDES IIS Console](images/aadjcert/ndes-iis-bindings.png)
+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**.
+![NDES IIS Console](images/aadjcert/ndes-iis-bindings-add-443.png)
+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.
+
+![NDES IIS Console](images/aadjcert/ndes-https-website-test-01.png)
+
+Confirm the web site uses the server authentication certificate. 
+![NDES IIS Console](images/aadjcert/ndes-https-website-test-01-show-cert.png)
+
+
+## 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.
+![Intune NDES Request filtering](images/aadjcert/NDES-IIS-RequestFiltering.png)
+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 <br>
+```reg add HKLM\CurrentControlSet\Services\HTTP\Parameters /v MaxFieldLength /t REG_DWORD /d 65534``` <br>
+```reg add HKLM\CurrentControlSet\Services\HTTP\Parameters /v MaxRequestBytes /t REG_DWORD /d 65534```<br>
+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**.
+![Microsoft Intune Console](images/aadjcert/microsoftintuneconsole.png)
+3. Select **Device Configuration**, and then select **Certificate Authority**.
+![Intune Certificate Authority](images/aadjcert/intunedeviceconfigurationcertauthority.png)
+4. Click **Add**, and then click **Download the certificate connector software** under the **Steps to install connector for SCEP** section.
+![Intune Download Certificate connector](images/aadjcert/intunedownloadcertconnector.png)
+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**. 
+![Intune Connector Install 01](images/aadjcert/intunecertconnectorinstall-01.png)
+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**.
+![Intune Connector Install 03](images/aadjcert/intunecertconnectorinstall-03.png)
+7. On the **Client certificate for Microsoft Intune** page, Click **Select**.  Select the certificate previously enrolled for the NDES server. Click **Next**. 
+![Intune Connector Install 05](images/aadjcert/intunecertconnectorinstall-05.png)
+> [!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**.
+![Intune Connector Install 06](images/aadjcert/intunecertconnectorinstall-06.png)
+> [!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. 
+![Intune Connector install 07](images/aadjcert/intunecertconnectorinstall-07.png)
+
+### 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 **\<install_Path>\NDESConnectorUI\NDESConnectorUI.exe**.
+
+2. If your organization uses a proxy server and the proxy is needed for the NDES server to access the Internet, select **Use proxy server**, and then enter the proxy server name, port, and credentials to connect.  Click **Apply**
+![Intune Certificate Connector Configuration 01](images/aadjcert/intunecertconnectorconfig-01.png)
+
+3. Click **Sign-in**.  Type credentials for your Intune administrator, or tenant administrator that has the **Global Administrator** directory role.
+![Intune Certificate Connector Configuration 02](images/aadjcert/intunecertconnectorconfig-02.png)
+> [!IMPORTANT]
+> The user account must have a valid Intune licenese asssigned.  If the user account does not have a valid Intune license, the sign-in fails.
+
+4. Optionally, you can configure the NDES Connector for certificate revocation. If you want to do this, continue to the next task. Otherwise, Click **Close**, restart the **Intune Connector Service** and the **World Wide Web Publishing Service**, and skip the next task. 
+
+
+### Configure the NDES Connector for certificate revocation (**Optional**)
+Optionally (not required), you can configure the Intune connector for certificate revocation when a device is wiped, unenrolled, or when the certificate profile falls out of scope for the targeted user (users is removed, deleted, or the profile is deleted).
+
+#### Enabling the NDES Service account for revocation
+Sign-in the certificate authority used by the NDES Connector with access equivalent to _domain administrator_.
+
+1. Start the **Certification Authority** management console.
+2. In the navigation pane, right-click the name of the certificate authority and select **Properties**.
+3. Click the **Security** tab.  Click **Add**. In **Enter the object names to select** box, type **NDESSvc** (or the name you gave the NDES Service account).  Click *Check Names*. Click **OK**.  Select the NDES Service account from the **Group or user names** list. Select **Allow** for the **Issue and Manage Certificates** permission.  Click **OK**.
+![Configure Intune certificate revocation 02](images/aadjcert/intuneconfigcertrevocation-02.png)
+4. Close the **Certification Authority**
+
+#### Enable the NDES Connector for certificate revocation
+Sign-in the NDES server with access equivalent to _domain administrator_.
+
+1. Open the **NDES Connector** user interface (**\<install_Path>\NDESConnectorUI\NDESConnectorUI.exe**).
+2. Click the **Advanced** tab.  Select **Specify a different account username and password**.  TYpe the NDES service account username and password.  Click **Apply**.  Click **OK** to close the confirmation dialog box.  Click **Close**.
+![Intune Connector cert revocation configuration 04](images/aadjcert/intunecertconnectorconfig-04.png)
+3. Restart the **Intune Connector Service** and the **World Wide Web Publishing Service**.
+
+### Test the NDES Connector
+Sign-in the NDES server with access equivalent to _domain admin_.
+
+1. Open a command prompt.
+2. Type the following command to confirm the NDES Connector's last connection time is current.</br>
+```reg query hklm\software\Micosoft\MicrosoftIntune\NDESConnector\ConnectionStatus```</br>
+3. Close the command prompt.
+4. Open **Internet Explorer**.
+5. In the navigation bar, type</br>
+```https://[fqdnHostName]/certsrv/mscep/mscep.dll```</br>
+where **[fqdnHostName]** is the fully qualified internal DNS host name of the NDES server.</br>
+A web page showing a 403 error (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.
+![NDES web site test after Intune Certificate Connector](images/aadjcert/ndes-https-website-test-after-intune-connector.png)
+6. Using **Server Manager**, enable **Internet Explorer Enhanced Security Configuration**.
+
+## Create and Assign a Simple Certificate Enrollment Protocol (SCEP) Certificate Profile
+
+### Create an AADJ WHFB Certificate Users 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. Click **Groups**.  Click **New group**.
+4. Select **Security** from the **Group type** list.
+5. Under **Group Name**, type the name of the group.  For example, **AADJ WHFB Certificate Users**.
+6. Provide a **Group description**, if applicable.
+7. Select **Assigned** from the **Membership type** list.
+![Azure AD new group creation](images/aadjcert/azureadcreatewhfbcertgroup.png)
+8. Click **Members**.  Use the  **Select members** pane to add members to this group. When finished click **Select**.
+9. Click **Create**.
+
+### Create a SCEP Certificte Profile
+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 click **Profiles**.
+4. Select **Create Profile**.
+![Intune Device Configuration Create Profile](images/aadjcert/intunedeviceconfigurationcreateprofile.png)
+5. Next to **Name**, type **WHFB Certificate Enrollment**.
+6. Next to **Description**, provide a description meaningful for your environment.
+7. Select **Windows 10 and later** from the **Platform** list.
+8. Select **SCEP certificate** from the **Profile** list.
+![WHFB Scep Profile Blade](images/aadjcert/intunewhfbscepprofile-00.png)
+9. The **SCEP Certificate** blade should open. Configure **Certificate validity period** to match your organization.
+> [!IMPORTANT]
+    > Remember that you need to configure your certificate authority to allow Microsoft Intune to configure certificate validity.
+
+10. Select **Enroll to Windows Hello for Business, otherwise fail (Windows 10 and later)** from the **Key storage provider (KSP)** list.
+11. Select **Custom** from the **Subject name format** list.
+12. Next to **Custom**, type **CN={{OnPrem_Distinguished_Name}}** to make the on-premises distinguished name the subject of the issued certificate.
+13. Refer to the "Configure Certificate Templates on NDES" task for how you configured the **AADJ WHFB Authentication** certificate template in the registry. Select the appropriate combination of key usages from the **Key Usages** list that map to configured NDES template in the registry. In this example, the **AADJ WHFB Authentication** certificate template was added to the **SignatureTemplate** registry value name.  The **Key usage** that maps to that registry value name is **Digital Signature**.
+14. Select a previously configured **Trusted certificate** profile that matches the root certificate of the issuing certificate authority.
+![WHFB SCEP certificate profile Trusted Certificate selection](images/aadjcert/intunewhfbscepprofile-01.png)
+15. Under **Extended key usage**, type **Smart Card Logon** under **Name. Type **1.3.6.1.4.1.311.20.2.2** under **Object identifier**.  Click **Add**.
+16. Type a percentage (without the percent sign) next to **Renewal Threshold** to determine when the certificate should attempt to renew. The recommended value is **20**.
+![WHFB SCEP certificate Profile EKUs](images/aadjcert/intunewhfbscepprofile-03.png)
+17. Under **SCEP Server URLs**, type the fully qualified external name of the Azure AD Application proxy you configured. Append to the name **/certsrv/mscep/mscep.dll**.  For example, https://ndes-mtephendemo.msappproxy.net/certsrv/mscep/mscep.dll.  Click **Add**.  Repeat this step for each additional NDES Azure AD Application Proxy you configured to issue Windows Hello for Business certificates. Microsoft Intune round-robin load balances requests amongst the URLs listed in the SCEP certificate profile.
+18. Click **OK**.
+19. Click **Create**.
+
+### Assign Group to the WHFB Certificate Enrollment Certificate Profile
+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 click **Profiles**.
+4. Click **WHFB Certificate Enrollment**.
+![WHFB Scep Profile landing](images/aadjcert/intunewhfbscepprofile-04.png)
+5. Click **Assignments**.
+6. In the **Assignments** pane, Click **Include**.  Select **Selected Groups** from the **Assign to** list.  Click **Select groups to include**.
+![WHFB SCEP Profile Assignment](images/aadjcert/intunewhfbscepprofileassignment.png)
+7. Select the **AADJ WHFB Certificate Users** group. Click **Select**.
+8. Click **Save**.
+
+You have successfully completed the configuration.  Add users that need to enroll a Windows Hello for Business authentication certificate to the **AADJ WHFB Certificate Users** group.  This group, combined with the device enrollment Windows Hello for Business configuration prompts the user to enroll for Windows Hello for Business and enroll a certificate that can be used to authentication to on-premises resources.
+
+## Section Review
+> [!div class="checklist"]
+> * Requirements
+> * Prepare Azure AD Connect
+> * Prepare the Network Device Enrollment Services (NDES) Service Acccount
+> * Prepare Active Directory Certificate Authority
+> * Install and Configure the NDES Role
+> * Configure Network Device Enrollment Services to work with Microsoft Intune
+> * Download, Install, and Configure the Intune Certificate Connector
+> * Create and Assign a Simple Certificate Enrollment Protocol (SCEP Certificate Profile)

windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso.md

@@ -0,0 +1,45 @@
+---
+title: Azure AD Join Single Sign-on Deployment Guides
+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
+---
+# Azure AD Join Single Sign-on Deployment Guides
+
+**Applies to**
+-   Windows 10
+-   Azure Active Directory joined
+-   Hybrid deployment
+
+Windows Hello for Business combined with Azure Active Directory joined devices makes it easy for users to securely access cloud-based resources using a strong, two-factor credential.  Some resources may remain on-premises as enterprises transition resources to the cloud and Azure AD joined devices may need to access these resources.  With additional configurations to your current hybrid deployment, you can provide single sign-on to your on-premises resources for Azure Active Directory joined devices using Windows Hello for Business, using a key or a certificate.
+ 
+## Key vs. Certificate
+
+Enterprises can use either a key or a certificate to provide single-sign on for on-premises resources.  Both types of authentication provide the same security; one is not more secure than the other.  
+
+When using a key, the on-premises environment needs 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.
+
+When using a certificate, the on-premises environment can use Windows Server 2008 R2 and later domain controllers, which removes the Windows Server 2016 domain controller requirement.  However, single-sign on using a key requires additional infrastructure to issue a certificate when the user enrolls for Windows Hello for Business.  Azure AD joined devices enroll certificates using Microsoft Intune or a compatible Mobile Device Management (MDM).  Microsoft Intune and Windows Hello for Business use the Network Device Enrollment Services (NDES) role and support Microsoft Intune connector.
+
+To deploy single sign-on for Azure AD joined devices using keys, read and follow [Configure Azure AD joined devices for On-premises Single-Sign On using Windows Hello for Business](hello-hybrid-aadj-sso-base.md).
+To deploy single sign-on for Azure AD joined devices using, read and follow [Configure Azure AD joined devices for On-premises Single-Sign On using Windows Hello for Business](hello-hybrid-aadj-sso-base.md) and then [Using Certificates for AADJ On-premises Single-sign On](hello-hybrid-aadj-sso-cert.md).
+
+## Related topics
+
+- [Windows Hello for Business](hello-identity-verification.md)
+- [How Windows Hello for Business works](hello-how-it-works.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 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/security/identity-protection/hello-for-business/hello-hybrid-cert-new-install.md

@@ -9,24 +9,25 @@ ms.pagetype: security, mobile
 author: mikestephens-MS
 ms.author: mstephen
 ms.localizationpriority: medium
-ms.date: 10/20/2017
+ms.date: 08/19/2018
 ---
 # Windows Hello for Business Certificate Trust New Installation
 
 **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 involves configuring distributed technologies that may or may not exist in your current infrastructure.  Hybrid certificate 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 certificate trust deployments of Windows Hello for Business rely on these technologies
 
 * [Active Directory](#active-directory)
 * [Public Key Infrastructure](#public-key-infrastructure)
 * [Azure Active Directory](#azure-active-directory)
-* [Active Directory Federation Services](#active-directory-federation-services)
+* [Multi-factor Authentication Services](#multi-factor-authentication-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 Azure Device Registration](hello-hybrid-cert-trust-devreg.md) section to prepare your Windows Hello for Business deployment by configuring Azure device registration.
+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 Azure Device Registration](hello-hybrid-cert-trust-devreg.md) section to prepare your Windows Hello for Business deployment by configuring Azure device registration.
 
 The new installation baseline begins with a basic Active Directory deployment and enterprise PKI.  This document expects you have Active Directory deployed using Windows Server 2008 R2 or later domain controllers.
 
@@ -68,7 +69,7 @@ Sign-in using _Enterprise Admin_ equivalent credentials on Windows Server 2012 o
     Install-AdcsCertificateAuthority
     ```   
     
-## Configure a Production Public Key Infrastructure
+### Configure a Production Public Key Infrastructure
 
 If you do have an existing public key infrastructure, please review [Certification Authority Guidance](https://technet.microsoft.com/library/hh831574.aspx) from Microsoft TechNet to properly design your infrastructure.   Then, consult the [Test Lab Guide: Deploying an AD CS Two-Tier PKI Hierarchy](https://technet.microsoft.com/library/hh831348.aspx) for instructions on how to configure your public key infrastructure using the information from your design session.
 
@@ -91,8 +92,8 @@ The next step of the deployment is to follow the [Creating an Azure AD tenant](h
 > * Create an Azure Active Directory Tenant.
 > * Purchase the appropriate Azure Active Directory subscription or licenses, if necessary.
    
-## Multifactor Authentication Services ##
+## Multifactor Authentication Services
-Windows Hello for Business uses multifactor authentication during provisioning and during user initiated PIN reset scenarios, such as when a user forgets their PIN.  There are two preferred multifactor authentication configurations with hybrid deployments—Azure MFA and AD FS using Azure MFA
+Windows Hello for Business uses multi-factor authentication during provisioning and during user initiated PIN reset scenarios, such as when a user forgets their PIN.  There are two preferred multi-factor authentication configurations with hybrid deployments—Azure MFA and AD FS using Azure MFA
 
 Review the [What is Azure Multi-Factor Authentication](https://docs.microsoft.com/en-us/azure/multi-factor-authentication/multi-factor-authentication) topic to familiarize yourself its purpose and how it works.
 

windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-devreg.md

@@ -9,14 +9,15 @@ ms.pagetype: security, mobile
 author: mikestephens-MS
 ms.author: mstephen
 ms.localizationpriority: medium
-ms.date: 03/26/2018
+ms.date: 08/18/2018
 ---
 # Configure Device Registration for Hybrid 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 device registration for your hybrid environment. Hybrid Windows Hello for Business deployment needs device registration and device write-back to enable proper device authentication.  
   
@@ -58,7 +59,7 @@ To locate the schema master role holder, open and command prompt and type:
 
 ```Netdom query fsmo | findstr -i schema```
 
-![Netdom example output](images\hello-cmd-netdom.png)
+![Netdom example output](images/hello-cmd-netdom.png)
 
 The command should return the name of the domain controller where you need to adprep.exe.  Update the schema locally on the domain controller hosting the Schema master role.
 
@@ -68,7 +69,7 @@ Windows Hello for Business uses asymmetric keys as user credentials (rather than
 
 Manually updating Active Directory uses the command-line utility **adprep.exe** located at **\<drive>:\support\adprep** on the Windows Server 2016 DVD or ISO.  Before running adprep.exe, you must identify the domain controller hosting the schema master role.
 
-Sign-in to the domain controller hosting the schema master operational role using Enterprise Admin equivalent credentials.
+Sign-in to the domain controller hosting the schema master operational role using enterprise administrator equivalent credentials.
 
 1.	Open an elevated command prompt.
 2.	Type ```cd /d x:\support\adprep``` where *x* is the drive letter of the DVD or mounted ISO.
@@ -95,7 +96,7 @@ Federation server proxies are computers that run AD FS software that have been c
 Use the [Setting of a Federation Proxy](https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/checklist--setting-up-a-federation-server-proxy) checklist to configure AD FS proxy servers in your environment.
 
 ### 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).
 
 When you are ready to install, follow the **Configuring federation with AD FS** section of [Custom installation of Azure AD Connect](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-get-started-custom).  Select the **Federation with AD FS** option on the **User sign-in** page.  At the **AD FS Farm** page, select the use an existing option and click **Next**.  
 
@@ -111,7 +112,7 @@ If your AD FS farm is not already configured for Device Authentication (you can
 
 ![Device Registration](images/hybridct/device2.png)
   
-2.  On your AD FS primary server, ensure you are logged in as AD DS user with Enterprise Admin (EA ) privileges and open an elevated Windows PowerShell prompt.  Then, run the following commands:
+2.  On your AD FS primary server, ensure you are logged in as AD DS user with enterprise administrator privileges and open an elevated Windows PowerShell prompt.  Then, run the following commands:  
     
     `Import-module activedirectory`  
 	`PS C:\> Initialize-ADDeviceRegistration -ServiceAccountName "<your service account>" ` 

windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-prereqs.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 Prerequisites
 
 **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.
-
 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:
@@ -32,7 +32,7 @@ The distributed systems on which these technologies were built involved several
 ## Directories ##
 Hybrid Windows Hello for Business needs two directories: on-premises Active Directory and a cloud Azure Active Directory.  The minimum required domain controller, domain functional level, and forest functional level for Windows Hello for Business deployment is Windows Server 2008 R2.
 
-A hybrid Windows Hello for Busines deployment needs an Azure Active Directory subscription.  Different deployment configurations are supported by different Azure subscriptions.  The hybrid-certificate trust deployment needs an Azure Active Directory premium subscription because it uses the device write-back synchronization feature.  Other deployments, such as the hybrid key-trust deployment, may not require Azure Active Directory premium subscription.
+A hybrid Windows Hello for Business deployment needs an Azure Active Directory subscription.  Different deployment configurations are supported by different Azure subscriptions.  The hybrid-certificate trust deployment needs an Azure Active Directory premium subscription because it uses the device write-back synchronization feature.  Other deployments, such as the hybrid key-trust deployment, may not require Azure Active Directory premium subscription.
 
 Windows Hello for Business can be deployed in any environment with Windows Server 2008 R2 or later domain controllers.  Azure device registration and Windows Hello for Business require the Windows Server 2016 Active Directory schema.
  
@@ -103,7 +103,7 @@ Hybrid Windows Hello for Business deployments can use Azure’s Multifactor Auth
 <br>
 
 ## 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)

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
+-   Windows 10, version 1703 or later
-
+-   Hybrid deployment
->This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
+-   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.

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).

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.

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
-
+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. 
->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 Hello for Business Authentication certificate template is configured to only issue certificates to certificate requests that have been signed with an enrollment agent certificate.
 

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)

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
 

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"]

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)

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
 <hr>
 
 ## Follow the Windows Hello for Business hybrid key trust deployment guide
-1. [Overview](hello-hybrid-cert-trust.md)
+1. [Overview](hello-hybrid-key-trust.md)
-2. [Prerequistes](hello-hybrid-cert-trust-prereqs.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)

windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-devreg.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/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.   
 
 > [!NOTE]
@@ -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.
 
 
 <br><br>

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
+localizationpriority: high
-ms.date: 10/20/2017
+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.    
 
 ## 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).
 
-<br><br>
+
+> [!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.
+
+<br>
 
 <hr>
 
 ## Follow the Windows Hello for Business hybrid key trust deployment guide
-1. [Overview](hello-hybrid-cert-trust.md)
+1. [Overview](hello-hybrid-key-trust.md)
-2. [Prerequistes](hello-hybrid-cert-trust-prereqs.md)
+2. [Prerequistes](hello-hybrid-key-trust-prereqs.md)
-3. [New Installation Baseline](hello-hybrid-cert-new-install.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)

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
+localizationpriority: high
-ms.date: 11/17/2017
+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
 <br>
 
 ## 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)
 
 <br>
 
@@ -114,9 +114,9 @@ Organizations wanting to deploy hybrid key trust need their domain joined device
 <br>
 
 ### 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**.
 

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
+-   Windows 10, version 1703 or later
-
+-   Hybrid deployment
->This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
+-   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.

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**.
 

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
 

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)

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.

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 <EFBFBD> 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<EFBFBD>**
 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,7 +164,7 @@ 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)

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)

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
+localizationpriority: high
-ms.date: 03/26/2018
+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, or</br>AD FS with 3rd Party MFA Adapter | AD FS with Azure MFA Server, or</br>AD FS with 3rd Party MFA Adapter |
 | Azure Account, optional for Azure MFA billing | Azure Account, optional for Azure MFA billing |
-
-## Frequently Asked Questions
-
-### Can I deploy Windows Hello for Business using System Center Configuration Manager?
-Windows Hello for Business deployments using System Center Configuration Manager need to move to the hybrid deployment model that uses Active Directory Federation Services. Deployments using System Center Configuration Manager will no long be supported after November 2018.
-
-### What is the password-less strategy?
-
-Watch Senior Program Manager Karanbir Singh's Ignite 2017 presentation **Microsoft's guide for going password-less**
-
-> [!VIDEO https://www.youtube.com/embed/mXJS615IGLM]
-
-### What is the user experience for Windows Hello for Business?
-The user experience for Windows Hello for Business occurs after user sign-in, after you deploy Windows Hello for Business policy settings to your environment.
-
-> [!VIDEO https://www.youtube.com/embed/FJqHPTZTpNM]
- 
-</br>
-
-> [!VIDEO https://www.youtube.com/embed/etXJsZb8Fso]
-
-
-
-
-### What happens when my user forgets their PIN?
-
-If the user can sign-in with a password, they can reset their PIN by clicking the "I forgot my PIN" link in settings.  Beginning with the Fall Creators Update, users can reset their PIN above the lock screen by clicking the "I forgot my PIN" link on the PIN credential provider.
-
-> [!VIDEO https://www.youtube.com/embed/KcVTq8lTlkI]
-
-For on-premises deployments, devices must be well connected to their on-premises network (domain controllers and/or certificate authority) to reset their PINs.  Hybrid customers can onboard their Azure tenant to use the Windows Hello for Business PIN reset service to reset their PINs without access to their corporate network.
-
-### Do I need Windows Server 2016 domain controllers?
-There are many deployment options from which to choose. Some of those options require an adequate number of Windows Server 2016 domain controllers in the site where you have deployed Windows Hello for Business. There are other deployment options that use existing Windows Server 2008 R2 or later domain controllers. Choose the deployment option that best suits your environment
-
-### Is Windows Hello for Business multifactor authentication?
-Windows Hello for Business is two-factor authentication based the observed authentication factors of: something you have, something you know, and something part of you.  Windows Hello for Business incorporates two of these factors: something you have (the user's private key protected by the device's security module) and something you know (your PIN). With the proper hardware, you can enhance the user experience by introducing biometrics. Using biometrics, you can replace the "something you know" authentication factor with the "something that is part of you" factor, with the assurances that users can fall back to the "something you know factor".
-
-### Can I use PIN and biometrics to unlock my device?
-Starting in Windows 10, version 1709, you can use multifactor unlock to require the user to provide an additional factor to unlock the device.  Authentication remains two-factor, but another factor is required before Windows allows the user to reach the desktop.  Read more about [multifactor unlock](https://docs.microsoft.com/en-us/windows/access-protection/hello-for-business/hello-features#multifactor-unlock) in [Windows Hello for Business Features](#hello-features.md)
-
-### What is the difference between Windows Hello and Windows Hello for Business
-Windows Hello represents the biometric framework provided in Windows 10.  Windows Hello enables users to use biometrics to sign into their devices by securely storing their username and password and releasing it for authentication when the user successfully identifies themselves using biometrics.  Windows Hello for Business uses asymmetric keys protected by the device's security module that requires a user gesture (PIN or biometrics) to authenticate.
-
-### I have extended Active Directory to Azure Active Directory.  Can I use the on-prem deployment model?
-No. If your organization is federated or using online services, such as Office 365 or OneDrive, then you must use a hybrid deployment model.  On-premises deployments are exclusive to organization who need more time before moving to the cloud and exclusively use Active Directory.
-
-### Does Windows Hello for Business prevent the use of simple PINs?
-Yes. Our simple PIN algorithm looks for and disallows any PIN that has a constant delta from one digit to the next.  This prevents repeating numbers, sequential numbers and simple patterns.
-So, for example:
-* 1111 has a constant delta of 0, so it is not allowed
-* 1234 has a constant delta of 1, so it is not allowed
-* 1357 has a constant delta of 2, so it is not allowed
-* 9630 has a constant delta of -3, so it is not allowed
-* 1231 does not have a constant delta, so it is okay
-* 1593 does not have a constant delta, so it is okay
-
-This algorithm does not apply to alphanumeric PINs.
-
-### How does PIN caching work with Windows Hello for Business?
-Windows Hello for Business provides a PIN caching user experience using a ticketing system. Rather than caching a PIN, processes cache a ticket they can use to request private key operations.  Azure AD and Active Directory sign-in keys are cached under lock.  This means the keys remain available for use without prompting as long as the user is interactively signed-in.  Microsoft Account sign-in keys are considered transactional keys, which means the user is always prompted when accessing the key.  
-
-Beginning with Windows 10, Fall Creators Update, Windows Hello for Business used as a smart card (smart card emulation that is enabled by default) provides the same user experience of default smart card PIN caching.  Each process requesting a private key operation will prompt the user for the PIN on first use.  Subsequent private key operations will not prompt the user for the PIN.  
-
-The smart card emulation feature of Windows Hello for Business verifies the PIN and then discards the PIN in exchange for a ticket.  The process does not receive the PIN, but rather the ticket that grants them private key operations.  Windows 10 does not provide any Group Policy settings to adjust this caching.
-
-### Can I disable the PIN while using Windows Hello for Business?
-No. The movement away from passwords is accomplished by gradually reducing the use of the password.  In the occurence where you cannot authenticate with biometrics, you need a fall back mechansim that is not a password.  The PIN is the fall back mechansim.  Disabling or hiding the PIN credential provider disabled the use of biometrics.
-
-### Does Windows Hello for Business work with third party federation servers?
-Windows Hello for Business can work with any third-party federation servers that support the protocols used during provisioning experience.  Interested third-parties can inquiry at [whfbfeedback@microsoft.com](mailto:whfbfeedback@microsoft.com?subject=collaboration)
-
-| Protocol | Description |
-| :---: | :--- |
-| [[MS-KPP]: Key Provisioning Protocol](https://msdn.microsoft.com/en-us/library/mt739755.aspx) | Specifies the Key Provisioning Protocol, which defines a mechanism for a client to register a set of cryptographic keys on a user and device pair. |
-| [[MS-OAPX]: OAuth 2.0 Protocol Extensions](https://msdn.microsoft.com/en-us/library/dn392779.aspx)| Specifies the OAuth 2.0 Protocol Extensions, which are used to extend the OAuth 2.0 Authorization Framework. These extensions enable authorization features such as resource specification, request identifiers, and login hints. |  
-| [[MS-OAPXBC]: OAuth 2.0 Protocol Extensions for Broker Clients](https://msdn.microsoft.com/en-us/library/mt590278.aspx) | Specifies the OAuth 2.0 Protocol Extensions for Broker Clients, extensions to RFC6749 (The OAuth 2.0 Authorization Framework) that allow a broker client to obtain access tokens on behalf of calling clients. |
-| [[MS-OIDCE]: OpenID Connect 1.0 Protocol Extensions](https://msdn.microsoft.com/en-us/library/mt766592.aspx) | Specifies the OpenID Connect 1.0 Protocol Extensions. These extensions define additional claims to carry information about the end user, including the user principal name, a locally unique identifier, a time for password expiration, and a URL for password change. These extensions also define additional provider metadata that enable the discovery of the issuer of access tokens and give additional information about provider capabilities. |
-
-### Does Windows Hello for Business work with Mac and Linux clients?
-Windows Hello for Business is a feature of Windows 10. At this time, Microsoft is not developing clients for other platforms.  However, Microsoft is open to third parties who are interested in moving these platforms away from passwords.  Interested third parties can inqury at [whfbfeedback@microsoft.com](mailto:whfbfeedback@microsoft.com?subject=collaboration)
-

windows/security/identity-protection/hello-for-business/hello-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.

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
 

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)

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
+author: mikestephens-MS
-ms.date: 10/23/2017
+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
 

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.
 

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
+localizationpriority: high
-ms.date: 10/10/2017
+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.

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.
 

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
+author: mikestephens-MS
-ms.localizationpriority: medium
+ms.author: mstephen
-ms.date: 07/27/2017
+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.
+-   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.
--   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.
+-   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
 

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
+localizationpriority: high
-ms.date: 03/26/2018
+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.
 

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: 08/19/2018
-ms.date: 07/27/2017
 ---
 
 # 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
 
 ![choose how you'll connect](images/connect.png)
 
-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.
 

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]
+ 
+</br>
+
+> [!VIDEO https://www.youtube.com/embed/etXJsZb8Fso]
+
+## Windows Hello for Business forgotten PIN user experience
+
+If the user can sign-in with a password, they can reset their PIN by clicking the "I forgot my PIN" link in settings.  Beginning with the Fall Creators Update, users can reset their PIN above the lock screen by clicking the "I forgot my PIN" link on the PIN credential provider.
+
+> [!VIDEO https://www.youtube.com/embed/KcVTq8lTlkI]
+
+For on-premises deployments, devices must be well connected to their on-premises network (domain controllers and/or certificate authority) to reset their PINs.  Hybrid customers can 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.

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.