diff --git a/windows/security/identity-protection/hello-for-business/hello-cert-trust-adfs.md b/windows/security/identity-protection/hello-for-business/hello-cert-trust-adfs.md index 378aa2deb3..c6f11370e1 100644 --- a/windows/security/identity-protection/hello-for-business/hello-cert-trust-adfs.md +++ b/windows/security/identity-protection/hello-for-business/hello-cert-trust-adfs.md @@ -9,7 +9,7 @@ ms.pagetype: security, mobile author: mikestephens-MS ms.author: mstephen localizationpriority: high -ms.date: 08/06/2018 +ms.date: 08/19/2018 --- # Prepare and Deploy Windows Server 2016 Active Directory Federation Services @@ -18,7 +18,7 @@ ms.date: 08/06/2018 > 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 +43,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) @@ -58,8 +58,8 @@ 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 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 +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 @@ -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. @@ -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 @@ -338,7 +338,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 +378,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 +412,7 @@ Sign-in a node of the federation farm with _Admin_ equivalent credentials. ## Configure DNS for Device Registration -Sign-in the domain controller or administrative workstation with Domain Admin equivalent credentials. You’ll need the Federation service name to complete this task. You can view the federation service name by clicking **Edit Federation Service Properties** from the **Action** pan of the **AD FS** management console, or by using `(Get-AdfsProperties).Hostname.` (PowerShell) on the AD FS server. +Sign-in the domain controller or administrative workstation with domain administrator equivalent credentials. You’ll need the Federation service name to complete this task. You can view the federation service name by clicking **Edit Federation Service Properties** from the **Action** pan of the **AD FS** management console, or by using `(Get-AdfsProperties).Hostname.` (PowerShell) on the AD FS server. 1. Open the **DNS Management** console. 2. In the navigation pane, expand the domain controller name node and **Forward Lookup Zones**. 3. In the navigation pane, select the node that has the name of your internal Active Directory domain name. diff --git a/windows/security/identity-protection/hello-for-business/hello-cert-trust-deploy-mfa.md b/windows/security/identity-protection/hello-for-business/hello-cert-trust-deploy-mfa.md index cad539f4e1..058ca43ce1 100644 --- a/windows/security/identity-protection/hello-for-business/hello-cert-trust-deploy-mfa.md +++ b/windows/security/identity-protection/hello-for-business/hello-cert-trust-deploy-mfa.md @@ -9,7 +9,7 @@ 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 @@ -29,7 +29,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 +54,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 +89,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 +160,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 +172,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 +234,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 +255,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 +304,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 +352,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 +391,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 +410,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 +453,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 +495,7 @@ Sign in the primary AD FS server with _local administrator_ equivalent credentia 2. Locate the **USE_WEB_SERVICE_SDK** key and change the value from **false** to **true**. 3. Locate the **WEB_SERVICE_SDK_AUTHENTICATION_USERNAME** key and set the value to the username of the Web Service SDK account in the **PhoneFactor Admins** security group. Use a qualified username, like domain\username or machine\username. 4. Locate the **WEB_SERVICE_SDK_AUTHENTICATION_PASSWORD** key and set the value to the password of the Web Service SDK account in the **PhoneFactor Admins** security group. -5. Locate the **pfup_pfwssdk_PfWsSdk** setting and change the value from “http://localhost:4898/PfWsSdk.asmx” to the URL of the Web Service SDK that is running on the Azure Multi-Factor Authentication Server (e.g. https://computer1.domain.local/MultiFactorAuthWebServiceSdk/PfWsSdk.asmx). Since SSL is used for this connection, refer to the Web Service SDK by server name, not IP address, since the SSL certificate was issued for the server name. If the server name does not resolve to an IP address from the internet-facing server, add an entry to the hosts file on that server to map the name of the Azure Multi-Factor Authentication Server to its IP address. Save the **MultiFactorAuthenticationAdfsAdapter.config** file after changes have been made. +5. Locate the **pfup_pfwssdk_PfWsSdk** setting and change the value from “http://localhost:4898/PfWsSdk.asmx” to the URL of the Web Service SDK that is running on the Azure Multi-Factor Authentication Server (e.g. https://computer1.domain.local/MultiFactorAuthWebServiceSdk/PfWsSdk.asmx). Since SSL is used for this connection, refer to the Web Service SDK by server name, not IP address, since the SSL certificate was issued for the server name. If the server name does not resolve to an IP address from the Internet-facing server, add an entry to the hosts file on that server to map the name of the Azure Multi-Factor Authentication Server to its IP address. Save the **MultiFactorAuthenticationAdfsAdapter.config** file after changes have been made. ### Edit the AD FS Adapter Windows PowerShell cmdlet diff --git a/windows/security/identity-protection/hello-for-business/hello-cert-trust-policy-settings.md b/windows/security/identity-protection/hello-for-business/hello-cert-trust-policy-settings.md index e15da1d342..bb2c1c1317 100644 --- a/windows/security/identity-protection/hello-for-business/hello-cert-trust-policy-settings.md +++ b/windows/security/identity-protection/hello-for-business/hello-cert-trust-policy-settings.md @@ -103,7 +103,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 +132,7 @@ In the Windows 10, version 1703, the PIN complexity Group Policy settings have m Before you continue with the deployment, validate your deployment progress by reviewing the following items: * Confirm you authored Group Policy settings using the latest ADMX/ADML files (from the Widows 10 Creators Editions) * Confirm you configured the Enable Windows Hello for Business to the scope that matches your deployment (Computer vs. User) -* Confirm you configure the Use Certificate enrollment for on-prem authentication policy setting. +* Confirm you configure the Use Certificate enrollment for on-premises authentication policy setting. * Confirm you configure automatic certificate enrollment to the scope that matches your deployment (Computer vs. User) * Confirm you configured the proper security settings for the Group Policy object * Removed the allow permission for Apply Group Policy for Domain Users (Domain Users must always have the read permissions) diff --git a/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-ad-prereq.md b/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-ad-prereq.md index 2fa60f6b13..8f3b9c0a2c 100644 --- a/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-ad-prereq.md +++ b/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-ad-prereq.md @@ -9,7 +9,7 @@ ms.pagetype: security, mobile author: DaniHalfin ms.localizationpriority: medium ms.author: daniha -ms.date: 07/27/2017 +ms.date: 08/19/2018 --- # Validate Active Directory prerequisites @@ -18,7 +18,7 @@ ms.date: 07/27/2017 > 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 **\:\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 +28,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 +36,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 +48,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 +61,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**. diff --git a/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-deploy-mfa.md b/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-deploy-mfa.md index 00290c9fef..156c35ce69 100644 --- a/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-deploy-mfa.md +++ b/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-deploy-mfa.md @@ -6,10 +6,11 @@ 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: 07/27/2017 +ms.date: 08/19/2018 --- # Validate and Deploy Multifactor Authentication Services (MFA) @@ -22,7 +23,7 @@ Windows Hello for Business requires all users perform multi-factor authenticatio Azure Multi-Factor Authentication is an easy to use, scalable, and reliable solution that provides a second method of authentication so your users are always protected. * **Easy to Use** - Azure Multi-Factor Authentication is simple to set up and use. The extra protection that comes with Azure Multi-Factor Authentication allows users to manage their own devices. Best of all, in many instances it can be set up with just a few simple clicks. -* **Scalable** - Azure Multi-Factor Authentication uses the power of the cloud and integrates with your on-premises AD and custom apps. This protection is even extended to your high-volume, mission-critical scenarios. +* **Scalable** - Azure Multi-Factor Authentication uses the power of the cloud and integrates with your on-premises AD and custom applications. This protection is even extended to your high-volume, mission-critical scenarios. * **Always Protected** - Azure Multi-Factor Authentication provides strong authentication using the highest industry standards. * **Reliable** - We guarantee 99.9% availability of Azure Multi-Factor Authentication. The service is considered unavailable when it is unable to receive or process verification requests for the two-step verification. diff --git a/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-pki.md b/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-pki.md index 49c8430f5f..934d2f8e0c 100644 --- a/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-pki.md +++ b/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-pki.md @@ -9,7 +9,7 @@ ms.pagetype: security, mobile author: mikestephens-MS ms.author: mstephen localizationpriority: high -ms.date: 05/05/2018 +ms.date: 08/19/2018 --- # Validate and Configure Public Key Infrastructure @@ -163,7 +163,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. diff --git a/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md b/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md index 84ebce7b0d..7ae1ab1d14 100644 --- a/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md +++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md @@ -8,7 +8,7 @@ ms.pagetype: security author: mikestephens-MS ms.author: mstephen localizationpriority: high -ms.date: 05/05/2018 +ms.date: 08/19/2018 --- # Windows Hello for Business and Authentication diff --git a/windows/security/identity-protection/hello-for-business/hello-how-it-works-device-registration.md b/windows/security/identity-protection/hello-for-business/hello-how-it-works-device-registration.md index c5fd398ddf..d2f8d995f9 100644 --- a/windows/security/identity-protection/hello-for-business/hello-how-it-works-device-registration.md +++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works-device-registration.md @@ -8,7 +8,7 @@ ms.pagetype: security author: mikestephens-MS ms.author: mstephen localizationpriority: high -ms.date: 05/05/2018 +ms.date: 08/19/2018 --- # Windows Hello for Business and Device Registration diff --git a/windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md b/windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md index c8ec8d5238..2251f953d0 100644 --- a/windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md +++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md @@ -8,7 +8,7 @@ ms.pagetype: security author: mikestephens-MS ms.author: mstephen localizationpriority: high -ms.date: 05/05/2018 +ms.date: 08/19/2018 --- # Windows Hello for Business Provisioning diff --git a/windows/security/identity-protection/hello-for-business/hello-how-it-works-tech-deep-dive.md b/windows/security/identity-protection/hello-for-business/hello-how-it-works-tech-deep-dive.md index e912294768..7297f63ac7 100644 --- a/windows/security/identity-protection/hello-for-business/hello-how-it-works-tech-deep-dive.md +++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works-tech-deep-dive.md @@ -9,7 +9,7 @@ ms.pagetype: security author: mikestephens-MS ms.author: mstephen localizationpriority: high -ms.date: 05/05/2018 +ms.date: 08/19/2018 --- # Technical Deep Dive diff --git a/windows/security/identity-protection/hello-for-business/hello-how-it-works-technology.md b/windows/security/identity-protection/hello-for-business/hello-how-it-works-technology.md index a6fb1710fc..016c10e1b5 100644 --- a/windows/security/identity-protection/hello-for-business/hello-how-it-works-technology.md +++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works-technology.md @@ -8,7 +8,7 @@ ms.pagetype: security author: mikestephens-MS ms.author: mstephen localizationpriority: high -ms.date: 05/05/2018 +ms.date: 08/19/2018 --- # Technology and Terms @@ -245,7 +245,7 @@ The storage root key (SRK) is also an asymmetric key pair (RSA with a minimum of [Return to Top](#Technology-and-Terms) ## Trust type -The trust type determines how a user authenticates to the Active Directory to access on-premises resources. There are two trust types, key trust and certificate trust. The hybrid and on-premises deployment models support both trust types. The trust type does not affect authentication to Auzre Active Directory. Windows Hello for Business authentication to Azure Active Directory always uses the key, not a certificate (excluding smart card authentication in a federated environment). +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) diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base.md index 6a696fae68..a24521bc5c 100644 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base.md +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base.md @@ -9,7 +9,7 @@ ms.pagetype: security, mobile author: mikestephens-MS ms.author: mstephen localizationpriority: high -ms.date: 05/05/2018 +ms.date: 08/19/2018 --- # Configure Azure AD joined devices for On-premises Single-Sign On using Windows Hello for Business diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md index d8c9d3b752..27f21330dc 100644 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md @@ -9,7 +9,7 @@ ms.pagetype: security, mobile author: mikestephens-MS ms.author: mstephen localizationpriority: high -ms.date: 08/06/2018 +ms.date: 08/19/2018 --- # Using Certificates for AADJ On-premises Single-sign On diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso.md index 592f77603c..9145280789 100644 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso.md +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso.md @@ -9,7 +9,7 @@ ms.pagetype: security, mobile author: mikestephens-MS ms.author: mstephen localizationpriority: high -ms.date: 05/05/2018 +ms.date: 08/19/2018 --- # Azure AD Join Single Sign-on Deployment Guides diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-new-install.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-new-install.md index 9ce7a7999e..1fa2a59b67 100644 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-new-install.md +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-new-install.md @@ -9,7 +9,7 @@ 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 @@ -18,15 +18,15 @@ ms.date: 10/20/2017 >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 +68,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 +91,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 ## -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 +## Multifactor Authentication Services +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. diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-devreg.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-devreg.md index b09e2f8ec6..4f795e5493 100644 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-devreg.md +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-devreg.md @@ -9,7 +9,7 @@ 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 @@ -58,7 +58,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 +68,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 **\:\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. @@ -111,7 +111,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 "" ` diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-prereqs.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-prereqs.md index ffcdd3cdc3..99e376399b 100644 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-prereqs.md +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-prereqs.md @@ -9,7 +9,7 @@ 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 @@ -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
## Device Registration ## -Organizations wanting to deploy hybrid certificate trust need thier domain joined devices to register to Azure Active Directory. Just as a computer has an identity in Active Directory, that same computer has an identity in the cloud. This ensures that only approved computers are used with that Azure Active Directory. Each computer registers its identity in Azure Active Directory. +Organizations wanting to deploy hybrid certificate trust need their domain joined devices to register to Azure Active Directory. Just as a computer has an identity in Active Directory, that same computer has an identity in the cloud. This ensures that only approved computers are used with that Azure Active Directory. Each computer registers its identity in Azure Active Directory. Hybrid certificate trust deployments need the device write back feature. Authentication to the Windows Server 2016 Active Directory Federation Services needs both the user and the computer to authenticate. Typically the users are synchronized, but not devices. This prevents AD FS from authenticating the computer and results in Windows Hello for Business certificate enrollment failures. For this reason, Windows Hello for Business deployments need device writeback, which is an Azure Active Directory premium feature. @@ -132,7 +132,7 @@ If your environment is already federated and supports Azure device registration, ## Follow the Windows Hello for Business hybrid certificate trust deployment guide 1. [Overview](hello-hybrid-cert-trust.md) -2. Prerequistes (*You are here*) +2. Prerequisites (*You are here*) 3. [New Installation Baseline](hello-hybrid-cert-new-install.md) 4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md) 5. [Configure Windows Hello for Business settings](hello-hybrid-cert-whfb-settings.md) diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-provision.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-provision.md index effbe6b03a..044564711e 100644 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-provision.md +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-provision.md @@ -9,7 +9,7 @@ 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 @@ -45,7 +45,7 @@ The provisioning flow has all the information it needs to complete the Windows H * A fresh, successful multi-factor authentication * A validated PIN that meets the PIN complexity requirements -The remainder of the provisioning includes Windows Hello for Business requesting an asymmetric key pair for the user, preferably from the TPM (or required if explicitly set through policy). Once the key pair is acquired, Windows communicates with Azure Active Directory to register the public key. AAD Connect syncrhonizes the user's key to the on-prem Active Directory. +The remainder of the provisioning includes Windows Hello for Business requesting an asymmetric key pair for the user, preferably from the TPM (or required if explicitly set through policy). Once the key pair is acquired, Windows communicates with Azure Active Directory to register the public key. AAD Connect synchronizes the user's key to the on-premises Active Directory. > [!IMPORTANT] > The following is the enrollment behavior prior to Windows Server 2016 update [KB4088889 (14393.2155)](https://support.microsoft.com/en-us/help/4088889). diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-ad.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-ad.md index 80b5408547..7273b0af95 100644 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-ad.md +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-ad.md @@ -9,7 +9,7 @@ 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 @@ -22,7 +22,7 @@ The key synchronization process for the hybrid deployment of Windows Hello for B ### Creating Security Groups -Windows Hello for Business uses several security groups to simplify the deployment and managment. +Windows Hello for Business uses several security groups to simplify the deployment and management. > [!Important] > If your environment has one or more Windows Server 2016 domain controllers in the domain to which you are deploying Windows Hello for Business, then skip the **Create the KeyCredentials Admins Security Group**. Domains that include Windows Server 2016 domain controllers use the KeyAdmins group, which is created during the installation of the first Windows Server 2016 domain controller. diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-policy.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-policy.md index 933756d930..142682b7cf 100644 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-policy.md +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-policy.md @@ -9,7 +9,7 @@ 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 @@ -25,7 +25,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 +145,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 +171,7 @@ Starting with Windows 10, version 1703, the PIN complexity Group Policy settings ## Add users to the Windows Hello for Business Users group -Users must receive the Windows Hello for Business group policy settings and have the proper permission to enroll for the Wwindows Hello for Business Authentication certificate. You can provide users with these settings and permissions by adding the group used synchronize users to the Windows Hello for Business Users group. Users and groups who are not members of this group will not attempt to enroll for Windows Hello for Business. +Users must receive the Windows Hello for Business group policy settings and have the proper permission to enroll for the Windows Hello for Business Authentication certificate. You can provide users with these settings and permissions by adding the group used synchronize users to the Windows Hello for Business Users group. Users and groups who are not members of this group will not attempt to enroll for Windows Hello for Business. ### Section Review > [!div class="checklist"] diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings.md index fac7f81257..b7090aa9d8 100644 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings.md +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings.md @@ -9,7 +9,7 @@ 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 @@ -28,7 +28,7 @@ The configuration for Windows Hello for Business is grouped in four categories. * [Active Directory Federation Services](hello-hybrid-cert-whfb-settings-adfs.md) * [Group Policy](hello-hybrid-cert-whfb-settings-policy.md) -For the most efficent deployment, configure these technologies in order beginning with the Active Directory configuration +For the most efficient deployment, configure these technologies in order beginning with the Active Directory configuration > [!div class="step-by-step"] [Configure Active Directory >](hello-hybrid-cert-whfb-settings-ad.md) diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-new-install.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-new-install.md index f986fd3e0e..c5f3cf6bee 100644 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-new-install.md +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-new-install.md @@ -9,7 +9,7 @@ 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 @@ -18,7 +18,7 @@ ms.date: 03/26/2018 >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 +26,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. diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-devreg.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-devreg.md index 45f22f940d..7a69aa6510 100644 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-devreg.md +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-devreg.md @@ -9,7 +9,7 @@ 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 @@ -34,7 +34,7 @@ Begin configuring device registration to support Hybrid Windows Hello for Busine To do this, follow the **Configure device settings** steps under [Setting up Azure AD Join in your organization](https://azure.microsoft.com/en-us/documentation/articles/active-directory-azureadjoin-setup/) -Next, follow the guidance on the [How to configure hybrid Azure Active Directory joined devices](https://docs.microsoft.com/en-us/azure/active-directory/device-management-hybrid-azuread-joined-devices-setup) page. In the **Configuration steps** section, identify you configuration at the top of the table (either **Windows current and password hash sync** or **Windows current and federation**) and perform only the steps identified with a checkmark. +Next, follow the guidance on the [How to configure hybrid Azure Active Directory joined devices](https://docs.microsoft.com/en-us/azure/active-directory/device-management-hybrid-azuread-joined-devices-setup) page. In the **Configuration steps** section, identify you configuration at the top of the table (either **Windows current and password hash sync** or **Windows current and federation**) and perform only the steps identified with a check mark.

diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-dir-sync.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-dir-sync.md index 2059a8d2ff..46cb0337c9 100644 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-dir-sync.md +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-dir-sync.md @@ -9,7 +9,7 @@ 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 @@ -54,5 +54,5 @@ Sign-in a domain controller or management workstation with _Domain Admin_ equiva 3. [New Installation Baseline](hello-hybrid-key-new-install.md) 4. [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md) 5. [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md) -6. Configure Windows Hello for Business settings: Directory Syncrhonization (*You are here*) +6. Configure Windows Hello for Business settings: Directory Synchronization (*You are here*) 7. [Sign-in and Provision](hello-hybrid-key-whfb-provision.md) diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings.md index 05697bb83f..49ac794f2d 100644 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings.md +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings.md @@ -9,7 +9,7 @@ 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 @@ -29,7 +29,7 @@ The configuration for Windows Hello for Business is grouped in four categories. * [Public Key Infrastructure](hello-hybrid-key-whfb-settings-pki.md) * [Group Policy](hello-hybrid-key-whfb-settings-policy.md) -For the most efficent deployment, configure these technologies in order beginning with the Active Directory configuration +For the most efficient deployment, configure these technologies in order beginning with the Active Directory configuration > [!div class="step-by-step"] [Configure Active Directory >](hello-hybrid-key-whfb-settings-ad.md) diff --git a/windows/security/identity-protection/hello-for-business/hello-key-trust-adfs.md b/windows/security/identity-protection/hello-for-business/hello-key-trust-adfs.md index 03cf30c20c..de527182d4 100644 --- a/windows/security/identity-protection/hello-for-business/hello-key-trust-adfs.md +++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-adfs.md @@ -9,7 +9,7 @@ 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 @@ -18,7 +18,7 @@ ms.date: 03/26/2018 > 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 +59,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 +134,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 +253,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 +287,7 @@ Sign-in a node of the federation farm with _Admin_ equivalent credentials. ## Configure DNS for Device Registration -Sign-in the domain controller or administrative workstation with Domain Admin equivalent credentials. You’ll need the Federation service name to complete this task. You can view the federation service name by clicking **Edit Federation Service Properties** from the **Action** pan of the **AD FS** management console, or by using `(Get-AdfsProperties).Hostname.` (PowerShell) on the AD FS server. +Sign-in the domain controller or administrative workstation with domain administrator equivalent credentials. You’ll need the Federation service name to complete this task. You can view the federation service name by clicking **Edit Federation Service Properties** from the **Action** pan of the **AD FS** management console, or by using `(Get-AdfsProperties).Hostname.` (PowerShell) on the AD FS server. 1. Open the **DNS Management** console. 2. In the navigation pane, expand the domain controller name node and **Forward Lookup Zones**. 3. In the navigation pane, select the node that has the name of your internal Active Directory domain name. diff --git a/windows/security/identity-protection/hello-for-business/hello-key-trust-deploy-mfa.md b/windows/security/identity-protection/hello-for-business/hello-key-trust-deploy-mfa.md index cd5414603f..adca684cc9 100644 --- a/windows/security/identity-protection/hello-for-business/hello-key-trust-deploy-mfa.md +++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-deploy-mfa.md @@ -9,7 +9,7 @@ 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 @@ -29,7 +29,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 +54,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 +89,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 +160,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 +172,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 +234,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 +255,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 +304,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 +352,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 +391,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 +410,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 +453,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 +495,7 @@ Sign in the primary AD FS server with _local administrator_ equivalent credentia 2. Locate the **USE_WEB_SERVICE_SDK** key and change the value from **false** to **true**. 3. Locate the **WEB_SERVICE_SDK_AUTHENTICATION_USERNAME** key and set the value to the username of the Web Service SDK account in the **PhoneFactor Admins** security group. Use a qualified username, like domain\username or machine\username. 4. Locate the **WEB_SERVICE_SDK_AUTHENTICATION_PASSWORD** key and set the value to the password of the Web Service SDK account in the **PhoneFactor Admins** security group. -5. Locate the **pfup_pfwssdk_PfWsSdk** setting and change the value from “http://localhost:4898/PfWsSdk.asmx” to the URL of the Web Service SDK that is running on the Azure Multi-Factor Authentication Server (e.g. https://computer1.domain.local/MultiFactorAuthWebServiceSdk/PfWsSdk.asmx). Since SSL is used for this connection, refer to the Web Service SDK by server name, not IP address, since the SSL certificate was issued for the server name. If the server name does not resolve to an IP address from the internet-facing server, add an entry to the hosts file on that server to map the name of the Azure Multi-Factor Authentication Server to its IP address. Save the **MultiFactorAuthenticationAdfsAdapter.config** file after changes have been made. +5. Locate the **pfup_pfwssdk_PfWsSdk** setting and change the value from “http://localhost:4898/PfWsSdk.asmx” to the URL of the Web Service SDK that is running on the Azure Multi-Factor Authentication Server (e.g. https://computer1.domain.local/MultiFactorAuthWebServiceSdk/PfWsSdk.asmx). Since SSL is used for this connection, refer to the Web Service SDK by server name, not IP address, since the SSL certificate was issued for the server name. If the server name does not resolve to an IP address from the Internet-facing server, add an entry to the hosts file on that server to map the name of the Azure Multi-Factor Authentication Server to its IP address. Save the **MultiFactorAuthenticationAdfsAdapter.config** file after changes have been made. ### Edit the AD FS Adapter Windows PowerShell cmdlet diff --git a/windows/security/identity-protection/hello-for-business/hello-key-trust-policy-settings.md b/windows/security/identity-protection/hello-for-business/hello-key-trust-policy-settings.md index 69e6e36112..5b622bf503 100644 --- a/windows/security/identity-protection/hello-for-business/hello-key-trust-policy-settings.md +++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-policy-settings.md @@ -9,7 +9,7 @@ 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 @@ -76,7 +76,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 +105,7 @@ In the Windows 10, version 1703, the PIN complexity Group Policy settings have m Before you continue with the deployment, validate your deployment progress by reviewing the following items: * Confirm you authored Group Policy settings using the latest ADMX/ADML files (from the Widows 10 Creators Editions) * Confirm you configured the Enable Windows Hello for Business to the scope that matches your deployment (Computer vs. User) -* Confirm you configure the Use Certificate enrollment for on-prem authentication policy setting. +* Confirm you configure the Use Certificate enrollment for on-premises authentication policy setting. * Confirm you configure automatic certificate enrollment to the scope that matches your deployment (Computer vs. User) * Confirm you configured the proper security settings for the Group Policy object * Removed the allow permission for Apply Group Policy for Domain Users (Domain Users must always have the read permissions) diff --git a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-ad-prereq.md b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-ad-prereq.md index da6751970c..383590e40d 100644 --- a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-ad-prereq.md +++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-ad-prereq.md @@ -8,8 +8,9 @@ ms.sitesec: library ms.pagetype: security, mobile author: DaniHalfin ms.localizationpriority: medium -ms.author: daniha -ms.date: 10/23/2017 +author: mikestephens-MS +ms.author: mstephen +ms.date: 08/19/2018 --- # Validate Active Directory prerequisites @@ -20,7 +21,7 @@ ms.date: 10/23/2017 Key trust deployments need an adequate number of 2016 domain controllers to ensure successful user authentication with Windows Hello for Business. To learn more about domain controller planning for key trust deployments, read the [Windows Hello for Business planning guide](hello-planning-guide.md), the [Planning an adequate number of Windows Server 2016 Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) section. -The key registration process for the On-prem deployment of Windows Hello for Business needs the Windows Server 2016 Active Directory schema. The key-trust model receives the schema extension when the first Windows Server 2016 domain controller is added to the forest. The minimum required domain functional and forest functional levels for Windows Hello for Business deployment is Windows Server 2008 R2. +The key registration process for the On-premises deployment of Windows Hello for Business needs the Windows Server 2016 Active Directory schema. The key-trust model receives the schema extension when the first Windows Server 2016 domain controller is added to the forest. The minimum required domain functional and forest functional levels for Windows Hello for Business deployment is Windows Server 2008 R2. ## Create the Windows Hello for Business Users Security Global Group diff --git a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-deploy-mfa.md b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-deploy-mfa.md index 8980d9d210..7e189412aa 100644 --- a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-deploy-mfa.md +++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-deploy-mfa.md @@ -9,7 +9,7 @@ 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) @@ -22,7 +22,7 @@ Windows Hello for Business requires all users perform an additional factor of au Azure Multi-Factor Authentication is an easy to use, scalable, and reliable solution that provides a second method of authentication so your users are always protected. * **Easy to Use** - Azure Multi-Factor Authentication is simple to set up and use. The extra protection that comes with Azure Multi-Factor Authentication allows users to manage their own devices. Best of all, in many instances it can be set up with just a few simple clicks. -* **Scalable** - Azure Multi-Factor Authentication uses the power of the cloud and integrates with your on-premises AD and custom apps. This protection is even extended to your high-volume, mission-critical scenarios. +* **Scalable** - Azure Multi-Factor Authentication uses the power of the cloud and integrates with your on-premises AD and custom applications. This protection is even extended to your high-volume, mission-critical scenarios. * **Always Protected** - Azure Multi-Factor Authentication provides strong authentication using the highest industry standards. * **Reliable** - We guarantee 99.9% availability of Azure Multi-Factor Authentication. The service is considered unavailable when it is unable to receive or process verification requests for the two-step verification. diff --git a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-pki.md b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-pki.md index de5dab6e76..5f3bd34161 100644 --- a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-pki.md +++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-pki.md @@ -9,7 +9,7 @@ ms.pagetype: security, mobile author: mikestephens-MS ms.author: mstephen localizationpriority: high -ms.date: 05/05/2018 +ms.date: 08/19/2018 --- # Validate and Configure Public Key Infrastructure diff --git a/windows/security/identity-protection/hello-for-business/hello-planning-guide.md b/windows/security/identity-protection/hello-for-business/hello-planning-guide.md index b474c7a882..b762cb48f0 100644 --- a/windows/security/identity-protection/hello-for-business/hello-planning-guide.md +++ b/windows/security/identity-protection/hello-for-business/hello-planning-guide.md @@ -9,7 +9,7 @@ ms.pagetype: security, mobile author: mikestephens-MS ms.author: mstephen localizationpriority: high -ms.date: 05/05/2018 +ms.date: 08/19/2018 --- # Planning a Windows Hello for Business Deployment @@ -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 diff --git a/windows/security/identity-protection/hello-for-business/hello-prepare-people-to-use.md b/windows/security/identity-protection/hello-for-business/hello-prepare-people-to-use.md index 3d085cb306..363636202f 100644 --- a/windows/security/identity-protection/hello-for-business/hello-prepare-people-to-use.md +++ b/windows/security/identity-protection/hello-for-business/hello-prepare-people-to-use.md @@ -7,10 +7,10 @@ ms.prod: w10 ms.mktglfcycl: deploy ms.sitesec: library ms.pagetype: security -author: DaniHalfin +author: mikestephens-MS +ms.author: mstephen ms.localizationpriority: medium -ms.author: daniha -ms.date: 07/27/2017 +ms.date: 08/19/2018 --- # Prepare people to use Windows Hello @@ -36,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. diff --git a/windows/security/identity-protection/hello-for-business/hello-videos.md b/windows/security/identity-protection/hello-for-business/hello-videos.md index 19004441bd..6c6251b3f1 100644 --- a/windows/security/identity-protection/hello-for-business/hello-videos.md +++ b/windows/security/identity-protection/hello-for-business/hello-videos.md @@ -9,7 +9,7 @@ ms.pagetype: security, mobile author: mikestephens-MS ms.author: mstephen localizationpriority: high -ms.date: 05/05/2018 +ms.date: 08/19/2018 --- # Windows Hello for Business Videos