deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-05-12 13:27:23 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Revert "Merged PR 2233: Merge master to live"

Browse Source
This commit is contained in:
Brian Lich 2017-07-13 23:12:16 +00:00
parent 99232da578
commit 8707890d30
35 changed files with 8 additions and 1603 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
microsoft-365/index.md
View File

@ -1 +0,0 @@
# Placeholder

39
windows/access-protection/hello-for-business/hello-deployment-key-trust.md
View File

@ -1,39 +0,0 @@
---
title: Windows Hello for Business Deployment Guide - On Premises Key Trust Deployment
description: A guide to an On Premises, Key trust Windows Hello for Business deployment
keywords: identity, PIN, biometric, Hello, passport
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security, mobile
author: DaniHalfin
localizationpriority: high
---
# On Premises Key Trust Deployment
**Applies to**
- Windows 10
- Windows 10 Mobile
> This guide only applies to Windows 10, version 1703 or higher.
Windows Hello for Business replaces username and password sign-in to Windows with strong user authentication based on asymmetric key pair. The following deployment guide provides the information needed to successfully deploy Windows Hello for Business in an existing environment.
Below, you can find all the infromation you will need to deploy Windows Hello for Business in a Certificate Trust Model in your on-premises environment:
1. [Validate Active Directory prerequisites](hello-key-trust-validate-ad-prereq.md)
2. [Validate and Configure Public Key Infrastructure](hello-key-trust-validate-pki.md)
3. [Prepare and Deploy Windows Server 2016 Active Directory Federation Services](hello-key-trust-adfs.md)
4. [Validate and Deploy Multifactor Authentication Services (MFA)](hello-key-trust-validate-deploy-mfa.md)
5. [Configure Windows Hello for Business Policy settings](hello-key-trust-policy-settings.md)

512
windows/access-protection/hello-for-business/hello-key-trust-adfs.md
View File

@ -1,512 +0,0 @@
---
title: Prepare and Deploy Windows Server 2016 Active Directory Federation Services (Windows Hello for Business)
description: How toPrepare and Deploy Windows Server 2016 Active Directory Federation Services for Windows Hello for Business
keywords: identity, PIN, biometric, Hello, passport
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security, mobile
author: DaniHalfin
localizationpriority: high
---
# Prepare and Deploy Windows Server 2016 Active Directory Federation Services
**Applies to**
- Windows 10
- Windows 10 Mobile
> 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.
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.
If your environment exceeds either of these factors or needs to provide SAML artifact resolution, token replay detection, or needs Active Directory Federation Services to operate in a federated provider role, then your deployment needs to use a SQL for your configuration database. To deploy the Active Directory Federation Services using SQL as its configuration database, please review the [Deploying a Federation Server Farm](https://docs.microsoft.com/windows-server/identity/ad-fs/deployment/deploying-a-federation-server-farm) checklist.
If your environment has an existing instance of Active Directory Federation Services, then you’ll need to upgrade all nodes in the farm to Windows Server 2016 along with the Windows Server 2016 update. If your environment uses Windows Internal Database (WID) for the configuration database, please read [Upgrading to AD FS in Windows Server 2016 using a WID database](https://docs.microsoft.com/windows-server/identity/ad-fs/deployment/upgrading-to-ad-fs-in-windows-server-2016) to upgrade your environment. If your environment uses SQL for the configuration database, please read [Upgrading to AD FS in Windows Server 2016 with SQL Server](https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/upgrading-to-ad-fs-in-windows-server-2016-sql) to upgrade your environment.
Ensure you apply the Windows Server 2016 Update to all nodes in the farm after you have successfully completed the upgrade.
A new Active Directory Federation Services farm should have a minimum of two federation servers for proper load balancing, which can be accomplished with an external networking peripherals, or with using the Network Load Balancing Role included in Windows Server.
Prepare the Active Directory Federation Services deployment by installing and updating two Windows Server 2016 Servers. Ensure the update listed below is applied to each server before continuing.
## Update Windows Server 2016
Sign-in the federation server with _local admin_ equivalent credentials.
1. Ensure Windows Server 2016 is current by running **Windows Update** from **Settings**. Continue this process until no further updates are needed. If you’re not using Windows Update for updates, please advise the [Windows Server 2016 update history page](https://support.microsoft.com/help/4000825/windows-10-windows-server-2016-update-history) to make sure you have the latest updates available installed.
2. Ensure the latest server updates to the federation server includes those referenced in following article https://aka.ms/whfbadfs1703.
>[!IMPORTANT]
>The above referenced updates are mandatory for Windows Hello for Business all on-premises deployment and hybrid certificate trust deployments for domain joined computers.
## 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.
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)
* Subject Alternate Name: Your federation service name, such as *fs.corp.contoso.com* (or an appropriate wildcard entry such as *.corp.contoso.com)
You configure your federation service name when you configure the AD FS role. You can choose any name, but that name must be different than the name of the server or host. For example, you can name the host server **adfs** and the federation service **fs**. The FQDN of the host is adfs.corp.contoso.com and the FQDN of the federation service is fs.corp.contoso.com.
You can; however, issue one certificate for all hosts in the farm. If you chose this option, then leave the subject name blank, and include all the names in the subject alternate name when creating the certificate request. All names should include the FQDN of each host in the farm and the federation service name.
It’s recommended that you mark the private key as exportable so that the same certificate can be deployed across each federation server and web application proxy within your AD FS farm. Note that the certificate must be trusted (chain to a trusted root CA). Once you have successfully requested and enrolled the server authentication certificate on one node, you can export the certificate and private key to a PFX file using the Certificate Manager console. You can then import the certificate on the remaining nodes in the AD FS farm.
Be sure to enroll or import the certificate into the AD FS server’s computer certificate store. Also, ensure all nodes in the farm have the proper TLS server authentication certificate.
### Internal Server Authentication Certificate Enrollment
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**.
4. Click **Next** on the **Before You Begin** page.
5. Click **Next** on the **Select Certificate Enrollment Policy** page.
6. On the **Request Certificates** page, Select the **Internal Web Server** check box.
7. Click the **More information is required to enroll for this certificate. Click here to configure settings** link
![Example of Certificate Properties Subject Tab - This is what shows when you click the above link](images/hello-internal-web-server-cert.png)
8. Under **Subject name**, select **Common Name** from the **Type** list. Type the FQDN of the computer hosting the Active Directory Federation Services role and then click **Add**. Under **Alternative name**, select **DNS** from the **Type** list. Type the FQDN of the name you will use for your federation services (fs.corp.contoso.com). The name you use here MUST match the name you use when configuring the Active Directory Federation Services server role. Click **Add**. Click **OK** when finished.
9. Click **Enroll**.
A server authentication certificate should appear in the computer’s Personal certificate store.
## Deploy the Active Directory Federation Service Role
The Active Directory Federation Service (AD FS) role provides the following services to support Windows Hello for Business on-premises deployments.
* Device registration
* Key registration
* Certificate registration authority (certificate trust deployments)
>[!IMPORTANT]
> Finish the entire AD FS configuration on the first server in the farm before adding the second server to the AD FS farm. Once complete, the second server receives the configuration through the shared configuration database when it is added the AD FS farm.
Windows Hello for Business depends on proper device registration. For on-premises deployments, Windows Server 2016 AD FS handles device registration.
Sign-in the federation server with _Enterprise Admin_ equivalent credentials.
1. Start **Server Manager**. Click **Local Server** in the navigation pane.
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, 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, select **Active Directory Federation Services**. Click **Next**.
7. Click **Next** on the **Select features** page.
8. Click **Next** on the **Active Directory Federation Service** page.
9. Click **Install** to start the role installation.
## Review
Before you continue with the deployment, validate your deployment progress by reviewing the following items:
* Confirm the AD FS farm uses the correct database configuration.
* Confirm the AD FS farm has an adequate number of nodes and is properly load balanced for the anticipated load.
* Confirm **all** AD FS servers in the farm have the latest updates.
* Confirm all AD FS servers have a valid server authentication certificate
* The subject of the certificate is the common name (FQDN) of the host or a wildcard name.
* The alternate name of the certificate contains a wildcard or the FQDN of the federation service
## Device Registration Service Account Prerequisite
The service account used for the device registration server depends on the domain controllers in the environment.
>[!NOTE]
>Follow the procedures below based on the domain controllers deployed in your environment. If the domain controller is not listed below, then it is not supported for Windows Hello for Business.
### Windows Server 2012 or later Domain Controllers
Windows Server 2012 or later domain controllers support Group Managed Service Accounts—the preferred way to deploy service accounts for services that support them. Group Managed Service Accounts, or GMSA have security advantages over normal user accounts because Windows handles password management. This means the password is long, complex, and changes periodically. The best part of GMSA is all this happens automatically. AD FS supports GMSA and should be configured using them for additional defense in depth security.
GSMA uses the Microsoft Key Distribution Service that is located on Windows Server 2012 or later domain controllers. Windows uses the Microsoft Key Distribution Service to protect secrets stored and used by the GSMA. Before you can create a GSMA, you must first create a root key for the service. You can skip this if your environment already uses GSMA.
#### Create KDS Root Key
Sign-in a domain controller with _Enterprise Admin_ equivalent credentials.
1. Start an elevated Windows PowerShell console.
2. Type `Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)`
### Windows Server 2008 or 2008 R2 Domain Controllers
Windows Server 2008 and 2008 R2 domain controllers do not host the Microsoft Key Distribution Service, nor do they support Group Managed Service Accounts. Therefore, you must use create a normal user account as a service account where you are responsible for changing the password on a regular basis.
#### Create an AD FS Service Account
Sign-in a domain controller or management workstation with _Domain Admin_ equivalent credentials.
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.
5. Click **Next** and then click **Finish**.
## Configure the Active Directory Federation Service Role
>[!IMPORTANT]
>Follow the procedures below based on the domain controllers deployed in your environment. If the domain controller is not listed below, then it is not supported for Windows Hello for Business.
### Windows Server 2012 or later Domain Controllers
Use the following procedures to configure AD FS when your environment uses **Windows Server 2012 or later Domain Controllers**. If you are not using Windows Server 2012 or later Domain Controllers, follow the procedures under the [Configure the Active Directory Federation Service Role (Windows Server 2008 or 2008R2 Domain Controllers)](#windows-server-2008-or-2008R2-domain-controllers) section.
Sign-in the federation server with _Domain Admin_ equivalent credentials. These procedures assume you are configuring the first federation server in a federation server farm.
1. Start **Server Manager**.
2. Click the notification flag in the upper right corner. Click **Configure federation services on this server**.
![Example of pop-up notification as described above](images/hello-adfs-configure-2012r2.png)
3. On the **Welcome** page, click **Create the first federation server farm** and click **Next**.
4. Click **Next** on the **Connect to Active Directory Domain Services** page.
5. On the **Specify Service Properties** page, select the recently enrolled or imported certificate from the **SSL Certificate** list. The certificate is likely named after your federation service, such as *fs.corp.contoso.com* or *fs.contoso.com*.
6. Select the federation service name from the **Federation Service Name** list.
7. Type the Federation Service Display Name in the text box. This is the name users see when signing in. Click **Next**.
8. On the **Specify Service Account** page, select **Create a Group Managed Service Account**. In the **Account Name** box, type **adfssvc**.
9. On the **Specify Configuration Database** page, select **Create a database on this server using Windows Internal Database** and click **Next**.
10. On the **Review Options** page, click **Next**.
11. On the **Pre-requisite Checks** page, click **Configure**.
12. When the process completes, click **Close**.
### Windows Server 2008 or 2008 R2 Domain Controllers
Use the following procedures to configure AD FS when your environment uses **Windows Server 2008 or 2008 R2 Domain Controllers**. If you are not using Windows Server 2008 or 2008 R2 Domain Controllers, follow the procedures under the [Configure the Active Directory Federation Service Role (Windows Server 2012 or later Domain Controllers)](#windows-server-2012-or-later-domain-controllers) section.
Sign-in the federation server with _Domain Admin_ equivalent credentials. These instructions assume you are configuring the first federation server in a federation server farm.
1. Start **Server Manager**.
2. Click the notification flag in the upper right corner. Click **Configure federation services on this server**.
![Example of pop-up notification as described above](images/hello-adfs-configure-2012r2.png)
3. On the **Welcome** page, click **Create the first federation server farm** and click **Next**.
4. Click **Next** on the **Connect to Active Directory Domain Services** page.
5. On the **Specify Service Properties** page, select the recently enrolled or imported certificate from the **SSL Certificate** list. The certificate is likely named after your federation service, such as fs.corp.mstepdemo.net or fs.mstepdemo.net.
6. Select the federation service name from the **Federation Service Name** list.
7. Type the Federation Service Display Name in the text box. This is the name users see when signing in. Click **Next**.
8. On the **Specify Service Account** page, Select **Use an existing domain user account or group Managed Service Account** and click **Select**.
* In the **Select User or Service Account** dialog box, type the name of the previously created AD FS service account (example adfssvc) and click **OK**. Type the password for the AD FS service account and click **Next**.
9. On the **Specify Configuration Database** page, select **Create a database on this server using Windows Internal Database** and click **Next**.
10. On the **Review Options** page, click **Next**.
11. On the **Pre-requisite Checks** page, click **Configure**.
12. When the process completes, click **Close**.
13. Do not restart the AD FS server. You will do this later.
### 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.
Sign-in a domain controller or management workstation with _Domain Admin_ equivalent credentials.
1. Open **Active Directory Users and Computers**.
2. Click the **Users** container in the navigation pane.
3. Right-click **KeyCredential Admins** in the details pane and click **Properties**.
4. Click the **Members** tab and click **Add…**
5. In the **Enter the object names to select** text box, type **adfssvc**. Click **OK**.
6. Click **OK** to return to **Active Directory Users and Computers**.
7. Right-click **Windows Hello for Business Users** group
8. Click the **Members** tab and click **Add…**
9. In the **Enter the object names to select** text box, type **adfssvc**. Click **OK**.
10. Click **OK** to return to **Active Directory Users and Computers**.
11. Change to server hosting the AD FS role and restart it.
### 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.
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.
Sign-in a domain controller or management workstations with _Domain Admin_ equivalent credentials.
1. Open **Active Directory Users and Computers**.
2. Right-click your domain name from the navigation pane and click **Properties**.
3. Click **Security** (if the Security tab is missing, turn on Advanced Features from the View menu).
4. Click **Advanced**. Click **Add**. Click **Select a principal**.
5. The **Select User, Computer, Service Account, or Group** dialog box appears. In the **Enter the object name to select** text box, type **KeyCredential Admins**. Click **OK**.
6. In the **Applies to** list box, select **Descendant User objects**.
7. Using the scroll bar, scroll to the bottom of the page and click **Clear all**.
8. In the **Properties** section, select **Read msDS-KeyCredentialLink** and **Write msDS-KeyCrendentialLink**.
9. Click **OK** three times to complete the task.
## Configure the Device Registration Service
Sign-in the federation server with _Enterprise Admin_ equivalent credentials. These instructions assume you are configuring the first federation server in a federation server farm.
1. Open the **AD FS management** console.
2. In the navigation pane, expand **Service**. Click **Device Registration**.
3. In the details pane, click **Configure Device Registration**.
4. In the **Configure Device Registration** dialog, click **OK**.
## Review
Before you continue with the deployment, validate your deployment progress by reviewing the following items:
* Confirm you followed the correct procedures based on the domain controllers used in your deployment
* Windows Server 2012 or Windows Server 2012 R2
* Windows Server 2008 or Windows Server 2008 R2
* Confirm you have the correct service account based on your domain controller version.
* Confirm you properly installed the AD FS role on your Windows Server 2016 based on the proper sizing of your federation, the number of relying parties, and database needs.
* Confirm you used a certificate with the correct names as the server authentication certificate
* Record the expiration date of the certificate and set a renewal reminder at least six weeks before it expires that includes the:
* Certificate serial number
* Certificate thumbprint
* Common name of the certificate
* Subject alternate name of the certificate
* Name of the physical host server
* The issued date
* The expiration date
* Issuing CA Vendor (if a third-party certificate)
* Confirm you granted the AD FS service allow read and write permissions to the ms-DSKeyCredentialLink Active Directory attribute.
* Confirm you enabled the Device Registration service.
## 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.
### Configure Registration Authority template
The certificate registration authority enrolls for an enrollment agent certificate. Once the registration authority verifies the certificate request, it signs the certificate request using its enrollment agent certificate and sends it to the certificate authority. The Windows Hello for Business Authentication certificate template is configured to only issue certificates to certificate requests that have been signed with an enrollment agent certificate. The certificate authority only issues a certificate for that template if the registration authority signs the certificate request.
The registration authority template you configure depends on the AD FS service configuration, which depends on the domain controllers the environment uses for authentication.
>[!IMPORTANT]
>Follow the procedures below based on the domain controllers deployed in your environment. If the domain controller is not listed below, then it is not supported for Windows Hello for Business.
#### Windows 2012 or later domain controllers
Sign-in a certificate authority or management workstations with _Domain Admin_ equivalent credentials.
1. Open the **Certificate Authority Management** console.
2. Right-click **Certificate Templates** and click **Manage**.
3. In the **Certificate Template Console**, right click on the **Exchange Enrollment Agent (Offline request)** template details pane and click **Duplicate Template**.
4. On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Authority** list. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Recipient** list.
5. On the **General** tab, type **WHFB Enrollment Agent** in **Template display name**. Adjust the validity and renewal period to meet your enterprise’s needs.
6. On the **Subject** tab, select the **Supply in the request** button if it is not already selected.
**Note:** The preceding step is very important. Group Managed Service Accounts (GMSA) do not support the Build from this Active Directory information option and will result in the AD FS server failing to enroll the enrollment agent certificate. You must configure the certificate template with Supply in the request to ensure that AD FS servers can perform the automatic enrollment and renewal of the enrollment agent certificate.
7. On the **Cryptography** tab, select **Key Storage Provider** from the **Provider Category** list. Select **RSA** from the **Algorithm name** list. Type **2048** in the **Minimum key size** text box. Select **SHA256** from the **Request hash** list.
8. On the **Security** tab, click **Add**.
9. Click **Object Types**. Select the **Service Accounts** check box and click **OK**.
10. Type **adfssvc** in the **Enter the object names to select** text box and click **OK**.
11. Click the **adfssvc** from the **Group or users names** list. In the **Permissions for adfssvc** section, In the **Permissions for adfssvc** section, select the **Allow** check box for the **Enroll** permission. Excluding the **adfssvc** user, clear the **Allow** check box for the **Enroll** and **Autoenroll** permissions for all other items in the **Group or users names** list if the check boxes are not already cleared. Click **OK**.
12. Close the console.
#### Windows 2008 or 2008R2 domain controllers
Sign-in a certificate authority or management workstations with _Domain Admin_ equivalent credentials.
1. Open the **Certificate Authority** management console.
2. Right-click **Certificate Templates** and click **Manage**.
3. In the **Certificate Template** console, right-click the **Exchange Enrollment Agent** template in the details pane and click **Duplicate Template**.
4. On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Authority** list. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Recipient** list.
5. On the **General** tab, type **WHFB Enrollment Agent** in **Template display name**. Adjust the validity and renewal period to meet your enterprise’s needs.
6. On the **Subject** tab, select the **Build from this Active Directory information** button if it is not already selected. Select **Fully distinguished name** from the **Subject name format** list if **Fully distinguished name** is not already selected. Select the **User Principal Name (UPN)** check box under **Include this information in alternative subject name**.
7. On the **Cryptography** tab, select **Key Storage Provider** from the **Provider Category** list. Select **RSA** from the **Algorithm name** list. Type **2048** in the **Minimum key size** text box. Select **SHA256** from the **Request hash** list.
8. On the **Security** tab, click **Add**. Type **adfssvc** in the **Enter the object names to select text box** and click **OK**.
9. Click the **adfssvc** from the **Group or users names** list. In the **Permissions for adfssvc** section, select the **Allow** check box for the **Enroll** permission. Excluding the **adfssvc** user, clear the **Allow** check boxes for the **Enroll** and **Autoenroll** permissions for all other items in the **Group or users names** list if the check boxes are not already cleared. Click **OK**.
10. Close the console.
### Configure the Windows Hello for Business Authentication Certificate template
During Windows Hello for Business provisioning, the Windows 10, version 1703 client requests an authentication certificate from the Active Directory Federation Service, which requests the authentication certificate on behalf of the user. This task configures the Windows Hello for Business authentication certificate template. You use the name of the certificate template when configuring.
Sign-in a certificate authority or management workstations with _Domain Admin equivalent_ credentials.
1. Open the **Certificate Authority** management console.
2. Right-click **Certificate Templates** and click **Manage**.
3. Right-click the **Smartcard Logon** template and choose **Duplicate Template**.
4. On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Authority** list. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Recipient** list.
5. On the **General** tab, type **WHFB Authentication** in **Template display name**. Adjust the validity and renewal period to meet your enterprise’s needs.
**Note:** If you use different template names, you’ll need to remember and substitute these names in different portions of the deployment.
6. On the **Cryptography** tab, select **Key Storage Provider** from the **Provider Category** list. Select **RSA** from the **Algorithm name** list. Type **2048** in the **Minimum key size** text box. Select **SHA256** from the **Request hash** list.
7. On the **Extensions** tab, verify the **Application Policies** extension includes **Smart Card Logon**.
8. On the **Issuance Requirements** tab, select the T**his number of authorized signatures** check box. Type **1** in the text box.
* Select **Application policy** from the **Policy type required in signature**. Select **Certificate Request Agent** from in the **Application policy** list. Select the **Valid existing certificate** option.
9. On the **Subject** tab, select the **Build from this Active Directory information** button if it is not already selected. Select **Fully distinguished name** from the **Subject name format** list if **Fully distinguished name** is not already selected. Select the **User Principal Name (UPN)** check box under **Include this information in alternative subject name**.
10. On the **Request Handling** tab, select the **Renew with same key** check box.
11. On the **Security** tab, click **Add**. Type **Window Hello for Business Users** in the **Enter the object names to select** text box and click **OK**.
12. Click the **Windows Hello for Business Users** from the **Group or users names** list. In the **Permissions for Windows Hello for Business Users** section, select the **Allow** check box for the **Enroll** permission. Excluding the **Windows Hello for Business Users** group, clear the **Allow** check box for the **Enroll** and **Autoenroll** permissions for all other entries in the **Group or users names** section if the check boxes are not already cleared. Click **OK**.
13. If you previously issued Windows Hello for Business sign-in certificates using Configuration Manger and are switching to an AD FS registration authority, then on the **Superseded Templates** tab, add the previously used **Windows Hello for Business Authentication** template(s), so they will be superseded by this template for the users that have Enroll permission for this template.
14. Click on the **Apply** to save changes and close the console.
#### Mark the template as the Windows Hello Sign-in template
Sign-in to an **AD FS Windows Server 2016** computer with _Enterprise Admin_ equivalent credentials.
1. Open an elevated command prompt.
2. Run `certutil –dsTemplate WHFBAuthentication msPKI-Private-Key-Flag +CTPRIVATEKEY_FLAG_HELLO_LOGON_KEY`
>[!NOTE]
>If you gave your Windows Hello for Business Authentication certificate template a different name, then replace **WHFBAuthentication** in the above command with the name of your certificate template. It’s important that you use the template name rather than the template display name. You can view the template name on the **General** tab of the certificate template using the Certificate Template management console (certtmpl.msc). Or, you can view the template name using the **Get-CATemplate** ADCS Administration Windows PowerShell cmdlet on our Windows Server 2012 or later certificate authority.
### Publish Enrollment Agent and Windows Hello For Business Authentication templates to the Certificate Authority
Sign-in a certificate authority or management workstations with _Enterprise Admin_ equivalent credentials.
1. Open the **Certificate Authority** management console.
2. Expand the parent node from the navigation pane.
3. Click **Certificate Templates** in the navigation pane.
4. Right-click the **Certificate Templates** node. Click **New**, and click **Certificate Template to issue**.
5. In the **Enable Certificates Templates** window, select the **WHFB Enrollment Agent** template you created in the previous steps. Click **OK** to publish the selected certificate templates to the certificate authority.
6. Publish the **WHFB Authentication** certificate template using step 5.
7. Close the console.
### Configure the Registration Authority
Sign-in the AD FS server with Domain Admin equivalent credentials.
1. Open a **Windows PowerShell** prompt.
2. Type the following command
```PowerShell
Set-AdfsCertificateAuthority -EnrollmentAgent -EnrollmentAgentCertificateTemplate WHFBEnrollmentAgent -WindowsHelloCertificateTemplate WHFBAuthentication
```
The `Set-AdfsCertificateAuthority` cmdlet should show the following warning:
>WARNING: PS0343: Issuing Windows Hello certificates requires enabling a permitted strong authentication provider, but no usable providers are currently configured. These authentication providers are not supported for Windows Hello certificates: CertificateAuthentication,MicrosoftPassportAuthentication. Windows Hello certificates will not be issued until a permitted strong authentication provider is configured.
This warning indicates that you have not configured multi-factor authentication in AD FS and until it is configured, the AD FS server will not issue Windows Hello certificates. Windows 10, version 1703 clients check this configuration during prerequisite checks. If detected, the prerequisite check will not succeed and the user will not provision Windows Hello for Business on sign-in.
>[!NOTE]
> If you gave your Windows Hello for Business Enrollment Agent and Windows Hello for Business Authentication certificate templates different names, then replace **WHFBEnrollmentAgent** and WHFBAuthentication in the above command with the name of your certificate templates. It’s important that you use the template name rather than the template display name. You can view the template name on the **General** tab of the certificate template using the **Certificate Template** management console (certtmpl.msc). Or, you can view the template name using the **Get-CATemplate** ADCS Administration Windows PowerShell cmdlet on a Windows Server 2012 or later certificate authority.
### Enrollment Agent Certificate Enrollment
Active Directory Federation Server used for Windows Hello for Business certificate enrollment perform their own certificate lifecycle management. Once the registration authority is configured with the proper certificate template, the AD FS server attempts to enroll the certificate on the first certificate request or when the service first starts.
Approximately 60 days prior to enrollment agent certificate’s expiration, the AD FS service attempts to renew the certificate until it is successful. If the certificate fails to renew, and the certificate expires, the AD FS server will request a new enrollment agent certificate. You can view the AD FS event logs to determine the status of the enrollment agent certificate.
## Additional Federation Servers
Organizations should deploy more than one federation server in their federation farm for high-availability. You should have a minimum of two federation services in your AD FS farm, however most organizations are likely to have more. This largely depends on the number of devices and users using the services provided by the AD FS farm.
### Server Authentication Certificate
Each server you add to the AD FS farm must have a proper server authentication certificate. Refer to the [Enroll for a TLS Server Authentication Certificate](#enroll-for-a-tls-server-authentication-certificate) section of this document to determine the requirements for your server authentication certificate. As previously stated, AD FS servers used exclusively for on-premises deployments of Windows Hello for Business can use enterprise server authentication certificates rather than server authentication certificates issued by public certificate authorities.
### Install Additional Servers
Adding federation servers to the existing AD FS farm begins with ensuring the server are fully patched, to include Windows Server 2016 Update needed to support Windows Hello for Business deployments (https://aka.ms/whfbadfs1703). Next, install the Active Directory Federation Service role on the additional servers and then configure the server as an additional server in an existing farm.
## Load Balance AD FS Federation Servers
Many environments load balance using hardware devices. Environments without hardware load-balancing capabilities can take advantage the network load-balancing feature included in Windows Server to load balance the AD FS servers in the federation farm. Install the Windows Network Load Balancing feature on all nodes participating in the AD FS farm that should be load balanced.
### Install Network Load Balancing Feature on AD FS Servers
Sign-in the federation server with _Enterprise Admin_ equivalent credentials.
1. Start **Server Manager**. Click **Local Server** in the navigation pane.
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**.
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
![Feature selection screen with NLB selected](images/hello-nlb-feature-install.png)
### Configure Network Load Balancing for AD FS
Before you can load balance all the nodes in the AD FS farm, you must first create a new load balance cluster. Once you have created the cluster, then you can add new nodes to that cluster.
Sign-in a node of the federation farm with _Admin_ equivalent credentials.
1. Open **Network Load Balancing Manager** from **Administrative Tools**.
![NLB Manager user interface](images/hello-nlb-manager.png)
2. Right-click **Network Load Balancing Clusters**, and then click **New Cluster**.
3. To connect to the host that is to be a part of the new cluster, in the **Host** text box, type the name of the host, and then click **Connect**.
![NLB Manager - Connect to new Cluster screen](images/hello-nlb-connect.png)
4. Select the interface that you want to use with the cluster, and then click **Next**. (The interface hosts the virtual IP address and receives the client traffic to load balance.)
5. In **Host Parameters**, select a value in **Priority (Unique host identifier)**. This parameter specifies a unique ID for each host. The host with the lowest numerical priority among the current members of the cluster handles all of the cluster's network traffic that is not covered by a port rule. Click **Next**.
6. In **Cluster IP Addresses**, click **Add** and type the cluster IP address that is shared by every host in the cluster. NLB adds this IP address to the TCP/IP stack on the selected interface of all hosts that are chosen to be part of the cluster. Click **Next**.
![NLB Manager - Add IP to New Cluster screen](images/hello-nlb-add-ip.png)
7. In **Cluster Parameters**, select values in **IP Address** and **Subnet mask** (for IPv6 addresses, a subnet mask value is not needed). Type the full Internet name that users will use to access this NLB cluster.
![NLB Manager - Cluster IP Configuration screen](images/hello-nlb-cluster-ip-config.png)
8. In **Cluster operation mode**, click **Unicast** to specify that a unicast media access control (MAC) address should be used for cluster operations. In unicast mode, the MAC address of the cluster is assigned to the network adapter of the computer, and the built-in MAC address of the network adapter is not used. We recommend that you accept the unicast default settings. Click **Next**.
9. In Port Rules, click Edit to modify the default port rules to use port 443.
![NLB Manager - Add\Edit Port Rule screen](images/hello-nlb-cluster-port-rule.png)
### Additional AD FS Servers
1. To add more hosts to the cluster, right-click the new cluster, and then click **Add Host to Cluster**.
2. Configure the host parameters (including host priority, dedicated IP addresses, and load weight) for the additional hosts by following the same instructions that you used to configure the initial host. Because you are adding hosts to an already configured cluster, all the cluster-wide parameters remain the same.
![NLB Manager - Cluster with nodes](images/hello-nlb-cluster.png)
## 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.
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.
4. In the navigation pane, right-click the domain name node and click **New Host (A or AAAA)**.
5. In the **name** box, type the name of the federation service. In the **IP address** box, type the IP address of your federation server. Click **Add Host**.
6. Close the DNS Management console
## Configure the Intranet Zone to include the federation service
The Windows Hello provisioning presents web pages from the federation service. Configuring the intranet zone to include the federation service enables the user to authenticate to the federation service using integrated authentication. Without this setting, the connection to the federation service during Windows Hello provisioning prompts the user for authentication.
### Create an Intranet Zone Group Policy
Sign-in the domain controller or administrative workstation with _Domain Admin_ equivalent credentials
1. Start the **Group Policy Management Console** (gpmc.msc)
2. Expand the domain and select the **Group Policy Object** node in the navigation pane.
3. Right-click **Group Policy object** and select **New**
4. Type **Intranet Zone Settings** in the name box and click **OK**.
5. In the content pane, right-click the **Intranet Zone Settings** Group Policy object and click **Edit**.
6. In the navigation pane, expand **Policies** under **Computer Configuration**.
7. Expand **Administrative Templates > Windows Component > Internet Explorer > Internet Control Panel**, and select **Security Page**.
8. In the content pane, double-click **Site to Zone Assignment List**. Click **Enable**.
9. Click **Show**. In the **Value Name** column, type the url of the federation service beginning with https. In the **Value** column, type the number **1**. Click OK twice, then close the Group Policy Management Editor.
### Deploy the Intranet Zone Group Policy object
1. Start the **Group Policy Management Console** (gpmc.msc)
2. In the navigation pane, expand the domain and right-click the node that has your Active Directory domain name and click **Link an existing GPO…**
3. In the **Select GPO** dialog box, select **Intranet Zone Settings** or the name of the Windows Hello for Business Group Policy object you previously created and click **OK**.
## Review
Before you continue with the deployment, validate your deployment progress by reviewing the following items:
* Confirm you configured the correct enrollment agent certificate template based on the type of AD FS service account.
* Confirm only the AD FS service account has the allow enroll permission for the enrollment agent certificate template.
* Consider using an HSM to protect the enrollment agent certificate; however, understand the frequency and quantity of signature operations the enrollment agent server makes and understand the impact it has on overall performance.
* Confirm you properly configured the Windows Hello for Business authentication certificate template—to include:
* Issuance requirements of an authorized signature from a certificate request agent.
* The certificate template was properly marked as a Windows Hello for Business certificate template using certutil.exe
* The Windows Hello for Business Users group, or equivalent has the allow enroll and allow auto enroll permissions
* Confirm all certificate templates were properly published to the appropriate issuing certificate authorities.
* Confirm the AD FS service account has the allow enroll permission for the Windows Hello Business authentication certificate template.
* Confirm the AD FS certificate registration authority is properly configured using the `Get-AdfsCertificateAuthority` Windows PowerShell cmdlet.
* Confirm you restarted the AD FS service.
* Confirm you properly configured load-balancing (hardware or software).
* Confirm you created a DNS A Record for the federation service and the IP address used is the load-balanced IP address
* Confirm you created and deployed the Intranet Zone settings to prevent double authentication to the federation server.
## Validating your work
You need to verify the AD FS service has properly enrolled for an enrollment agent certificate template. You can verify this is a variety ways, depending on if your service account is a normal user account or if the service account is a group managed service account.
### Event Logs
Use the event logs on the AD FS service to confirm the service account enrolled for an enrollment agent certificate. First, look for the AD FS event ID 443 that confirms certificate enrollment cycle has finished. Once confirmed the AD FS certificate enrollment cycle completed review the CertificateLifecycle-User event log. In this event log, look for event ID 1006, which indicates a new certificate was installed. Details of the event log should show
* The account name under which the certificate was enrolled.
* The action, which should read enroll.
* The thumbprint of the certificate
* The certificate template used to issue the certificate.
### Normal Service Account
When using a normal service account, use the Microsoft Management Console (mmc.exe) and load the Certificate Manager snap-in for the service account and verify.
### Group Managed Service Account
You cannot use the Certificate Manager to view enrolled certificates for group managed service accounts. Use the event log information to confirm the AD FS service account enrolled a certificate. Use certutil.exe to view the details of the certificate now shown in the event log.
Group managed service accounts use user profiles to store user information, which included enrolled certificates. On the AD FS server, use a command prompt and navigate to `%systemdrive%\users\<adfsGMSA_name>\appdata\roaming\Microsoft\systemcertificates\my\certificates` .
Each file in this folder represents a certificate in the service account’s Personal store (You may need to use DIR /A to view the files in the folder). Match the thumbprint of the certificate from the event log to one of the files in this folder. That file is the certificate. Use the `Certutil -q <certificateThumbprintFileName>` to view the basic information about the certificate.
For detailed information about the certificate, use `Certutil -q -v <certificateThumbprintFileName>` .
## Follow the Windows Hello for Business on premises certificate trust deployment guide
1. [Validate Active Directory prerequisites](hello-cert-trust-validate-ad-prereq.md)
2. [Validate and Configure Public Key Infrastructure](hello-cert-trust-validate-pki.md)
3. Prepare and Deploy Windows Server 2016 Active Directory Federation Services (*You are here*)
4. [Validate and Deploy Multifactor Authentication Services (MFA)](hello-cert-trust-validate-deploy-mfa.md)
5. [Configure Windows Hello for Business Policy settings](hello-cert-trust-policy-settings.md)

542
windows/access-protection/hello-for-business/hello-key-trust-deploy-mfa.md
View File

@ -1,542 +0,0 @@
---
title: Configure or Deploy Multifactor Authentication Services (Windows Hello for Business)
description: How to Configure or Deploy Multifactor Authentication Services for Windows Hello for Business
keywords: identity, PIN, biometric, Hello, passport
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security, mobile
author: DaniHalfin
localizationpriority: high
---
# Configure or Deploy Multifactor Authentication Services
**Applies to**
- Windows 10
- Windows 10 Mobile
> This guide only applies to Windows 10, version 1703 or higher.
On-premises deployments must use the On-premises Azure MFA Server using the AD FS adapter model Optionally, you can use a third-party MFA server that provides an AD FS Multifactor authentication adapter.
>[!TIP]
>Please make sure you've read [Validate and Deploy Multifactor Authentication Services (MFA)](hello-cert-trust-validate-deploy-mfa.md) before proceeding any further.
## Prerequisites
The Azure MFA Server and User Portal servers have several perquisites and must have connectivity to the Internet.
### 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.
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.
The primary MFA server is also responsible for synchronizing from Active Directory. Therefore, the primary MFA server should be domain joined and fully patched.
#### Enroll for Server Authentication
The communication between the primary MFA server, secondary MFA servers, User Portal servers, and the client is protected using TLS, which needs a server authentication certificate.
Sign-in the primary MFA 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**.
4. Click **Next** on the **Before You Begin** page.
5. Click **Next** on the **Select Certificate Enrollment Policy** page.
6. On the **Request Certificates** page, Select the **Internal Web Server** check box.
7. Click the **More information is required to enroll for this certificate. Click here to configure settings** link.
8. Under **Subject name**, select **Common Name** from the **Type** list. Type the FQDN of the primary MFA server and then click **Add** (mfa.corp.contoso.com). Click **Add**. Click **OK** when finished.
9. Click **Enroll**.
A server authentication certificate should appear in the computer’s Personal certificate store.
#### 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.
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.
The following services are required:
* Common Parameters > Default Document.
* Common Parameters > Directory Browsing.
* Common Parameters > HTTP Errors.
* Common Parameters > Static Content.
* Health and Diagnostics > HTTP Logging.
* Performance > Static Content Compression.
* Security > Request Filtering.
* Security > Basic Authentication.
* Management Tools > IIS Management Console.
* Management Tools > IIS 6 Management Compatibility.
* Application Development > ASP.NET 4.5.
#### Update the Server
Update the server using Windows Update until the server has no required or optional updates as the Azure MFA Server software may require one or more of these updates for the installation and software to correctly work. These procedures install additional components that may need to be updated.
#### Configure the IIS Server’s Certificate
The TLS protocol protects all the communication to and from the MFA server. To enable this protection, you must configure the default web site to use the previously enrolled server authentication certificate.
Sign in the primary MFA server with _administrator_ equivalent credentials.
1. From **Administrators**, Start the **Internet Information Services (IIS) Manager** console
2. In the navigation pane, expand the node with the same name as the local computer. Expand **Settings** and select **Default Web Site**.
3. In the **Actions** pane, click **Bindings**.
4. In the **Site Bindings** dialog, Click **Add**.
5. In the **Add Site Binding** dialog, select **https** from the **Type** list. In the **SSL certificate** list, select the certificate with the name that matches the FQDN of the computer.
6. Click **OK**. Click **Close**. From the **Action** pane, click **Restart**.
#### 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.
Sign in the domain controller with _domain administrator_ equivalent credentials.
##### Create Phonefactor Admin group
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 **Group**.
3. In the **New Object – Group** dialog box, type **Phonefactor Admins** in Group name.
4. Click **OK**.
##### Add accounts to the Phonefactor Admins group
1. Open **Active Directory Users and Computers**.
2. In the navigation pane, expand the node with the organization’s Active Directory domain name. Select Users. In the content pane. Right-click the **Phonefactors Admin** security group and select **Properties**.
3. Click the **Members** tab.
4. Click **Add**. Click **Object Types..** In the **Object Types** dialog box, select **Computers** and click **OK**. Enter the following user and/or computers accounts in the **Enter the object names to select** box and then click **OK**.
* The computer account for the primary MFA Server
* Group or user account that will manage the User Portal server.
#### Review
Before you continue with the deployment, validate your deployment progress by reviewing the following items:
* Confirm the hosts of the MFA service has enrolled a server authentication certificate with the proper names.
* Record the expiration date of the certificate and set a renewal reminder at least six weeks before it expires that includes the:
* Certificate serial number
* Certificate thumbprint
* Common name of the certificate
* Subject alternate name of the certificate
* Name of the physical host server
* The issued date
* The expiration date
* Issuing CA Vendor (if a third-party certificate)
* Confirm the Web Services Role was installed with the correct configuration (including Basic Authentication, ASP.NET 4.5, etc).
* Confirm the host has all the available updates from Windows Update.
* Confirm you bound the server authentication certificate to the IIS web site.
* Confirm you created the Phonefactor Admins group.
* Confirm you added the computer account hosting the MFA service to the Phonefactor Admins group and any user account who are responsible for administrating the MFA server or User Portal.
### User Portal Server
The User Portal is an IIS Internet Information Server web site that allows users to enroll in Multi-Factor Authentication and maintain their accounts. A user may change their phone number, change their PIN, or bypass Multi-Factor Authentication during their next sign on. Users will log in to the User Portal using their normal username and password and will either complete a Multi-Factor Authentication call or answer security questions to complete their authentication. If user enrollment is allowed, a user will configure their phone number and PIN the first time they log in to the User Portal. User Portal Administrators may be set up and granted permission to add new users and update existing users.
The User Portal web site uses the user database that is synchronized across the MFA Servers, which enables a design to support multiple web servers for the User Portal and those servers can support internal and external customers. While the user portal web site can be installed directly on the MFA server, it is recommended to install the User Portal on a server separate from the MFA Server to protect the MFA user database, as a layered, defense-in-depth security design.
#### Enroll for Server Authentication
Internal and external users use the User Portal to manage their multifactor authentication settings. To protect this communication, you need to enroll all User Portal servers with a server authentication certificate. You can use an enterprise certificate to protect communication to internal User Portal servers.
For external User Portal servers, it is typical to request a server authentication certificate from a public certificate authority. Contact a public certificate authority for more information on requesting a certificate for public use. Follow the procedures below to enroll an enterprise certificate on your User Portal server.
Sign-in the User Portal 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**.
4. Click **Next** on the **Before You Begin** page.
5. Click **Next** on the **Select Certificate Enrollment Policy** page.
6. On the **Request Certificates** page, Select the **Internal Web Server** check box.
7. Click the **More information is required to enroll for this certificate. Click here to configure settings** link.
8. Under **Subject name**, select **Common Name** from the **Type** list. Type the FQDN of the primary MFA server and then click **Add** (app1.corp.contoso.com).
9. Under **Alternative name**, select **DNS** from the **Type** list. Type the FQDN of the name you will use for your User Portal service (mfaweb.corp.contoso.com).
10. Click **Add**. Click **OK** when finished.
11. Click **Enroll**.
A server authentication certificate should appear in the computer’s Personal certificate store.
#### 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.
#### Update the Server
Update the server using Windows Update until the server has no required or optional updates as the Azure MFA Server software may require one or more of these updates for the installation and software to correctly work. These procedures install additional components that may need to be updated.
#### Configure the IIS Server’s Certificate
To do this, please follow the instructions mentioned in the previous [Configure the IIS Server’s Certificate](#configure-the-iis-server’s-certificate) section.
#### 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.
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**.
3. In the **New Object – User** dialog box, type **PFWSDK_<computerName>** in the **First name** and **User logon name** boxes, where *<computer>* is the name of the primary MFA server running the Web Services SDK. Click **Next**.
4. Type a strong password and confirm it in the respective boxes. Clear **User must change password at next logon**. Click **Next**. Click **Finish** to create the user account.
#### Add the MFA SDK user account to the Phonefactor Admins group
Adding the WebServices SDK user account to the Phonefactor Admins group provides the user account with the proper authorization needed to access the configuration data on the primary MFA server using the WebServices SDK.
1. Open **Active Directory Users and Computers**.
2. In the navigation pane, expand the node with the organization’s Active Directory domain name. Select **Users**. In the content pane. Right-click the **Phonefactors Admin** security group and select Properties.
3. Click the Members tab.
4. Click **Add**. Click **Object Types..** Type the PFWSDK_<computerName> user name in the **Enter the object names to select** box and then click **OK**.
* The computer account for the primary MFA Server
* The Webservices SDK user account
* Group or user account that will manage the User Portal server.
#### Review
Before you continue with the deployment, validate your deployment progress by reviewing the following items:
* Confirm the hosts of the user portal are properly configure for load balancing and high-availability.
* Confirm the hosts of the user portal have enrolled a server authentication certificate with the proper names.
* Record the expiration date of the certificate and set a renewal reminder at least six weeks before it expires that includes the:
* Certificate serial number
* Certificate thumbprint
* Common name of the certificate
* Subject alternate name of the certificate
* Name of the physical host server
* The issued date
* The expiration date
* Issuing CA Vendor (if a third-party certificate)
* Confirm the Web Server Role was properly configured on all servers.
* Confirm all the hosts have the latest updates from Windows Update.
* Confirm you created the web service SDK domain account and the account is a member of the Phonefactor Admins group.
## Installing Primary Azure MFA Server
When you install Azure Multi-Factor Authentication Server, you have the following options:
1. Install Azure Multi-Factor Authentication Server locally on the same server as AD FS
2. Install the Azure Multi-Factor Authentication adapter locally on the AD FS server, and then install Multi-Factor Authentication Server on a different computer (preferred deployment for production environments)
See [Configure Azure Multi-Factor Authentication Server to work with AD FS in Windows Server](https://docs.microsoft.com/azure/multi-factor-authentication/multi-factor-authentication-get-started-adfs-w2k12) to view detailed installation and configuration options.
Sign-in the federation server with _Domain Admin_ equivalent credentials and follow [To install and configure the Azure Multi-Factor Authentication server](https://docs.microsoft.com/azure/multi-factor-authentication/multi-factor-authentication-get-started-server#to-install-and-configure-the-azure-multi-factor-authentication-server) for an express setup with the configuration wizard. You can re-run the authentication wizard by selecting it from the Tools menu on the server.
>[!IMPORTANT]
>Only follow the above mention article to install Azure MFA Server. Once it is intstalled, continue configuration using this article.
### Configuring Company Settings
You need to configure the MFA server with the default settings it applies to each user account when it is imported or synchronized from Active Directory.
Sign-in the primary MFA server with MFA _administrator_ equivalent credentials.
1. Start the **Multi-Factor Server** application
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.
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.
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.
13. Select the **PIN history** check box if you want to remember previously used PINs for the user. PIN History stores old PINs for each user. Users are not allowed to reset their PIN to any value stored in their PIN History. When cleared, no PIN History is stored. The default value is 5 and range is 1 to 10.
![Azure MFA Server Company settings configured](images/hello-mfa-company-settings.png)
### Configuring Email Settings and Content
If you are deploying in a lab or proof-of-concept, then you have the option of skipping this step. In a production environment, ideally, you’ll want to setup the Azure Multifactor Authentication Server and its user portal web interface prior to sending the email. The email gives your users time to visit the user portal and configure the multi-factor settings.
Now that you have imported or synchronized with your Azure Multi-Factor Authentication server, it is advised that you send your users an email that informs them that they have been enrolled in multi-factor authentication.
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.
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.
#### Settings
By clicking the email icon on the left you can setup the settings for sending these emails. This is where you can enter the SMTP information of your mail server and it allows you to send a blanket wide email by adding a check to the Send mails to users check box.
#### Content
On the Email Content tab, you will see all of the various email templates that are available to choose from. So, depending on how you have configured your users to use multi-factor authentication, you can choose the template that best suits you.
##### Edit the Content Settings
The Azure MFA server does not send emails, even when configured to do so, until you configured the sender information for each email template listed in the Content tab.
Sign-in the primary MFA server with MFA _administrator_ equivalent credentials.
1. Open the **Multi-Factor Authentication Server** console.
2. Click **Email** from the list of icons and click the **Email Content** tab.
3. Select an email template from the list of templates. Click **Edit**.
4. In the **Edit Email** dialog, in the **From** text box, type the email address of the person or group that should appear to have sent the email.
![Edit email dialog within content settings](images/hello-mfa-content-edit-email.png)
5. Optionally, customize other options in the email template.
6. When finished editing the template, Click **Apply**.
7. Click **Next** to move to the next email in the list. Repeat steps 4 and 6 to edit the changes.
8. Click **Close** when you are done editing the email templates.
### Configuring Directory Integration Settings and Synchronization
Synchronization keeps the Multi-Factor Authentication user database synchronized with the users in Active Directory or another LDAP Lightweight Directory Access Protocol directory. The process is similar to Importing Users from Active Directory, but periodically polls for Active Directory user and security group changes to process. It also provides for disabling or removing users removed from a container or security group and removing users deleted from Active Directory.
It is important to use a different group memberships for synchronizing users from Active Directory and for enabling Windows Hello for Business. Keeping the group memberships separated enables you to synchronize users and configure MFA options without immediately deploying Windows Hello for Business to that user. This deployment approach provides the maximum flexibility, which gives users the ability to configure their settings before they provision Windows Hello for Business. To start provisioning, simply add the group used for synchronization to the Windows Hello for Business Users group (or equivalent if you use custom names).
#### MultiFactorAuthAdSync Service
The MultiFactorAuthAdSync service is a Windows service that performs the periodic polling of Active Directory. It is installed in a Stopped state and is started by the MultiFactorAuth service when configured to run. If you have a multi-server Multi-Factor Authentication configuration, the MultiFactorAuthAdSync may only be run on a single server.
The MultiFactorAuthAdSync service uses the DirSync LDAP server extension provided by Microsoft to efficiently poll for changes. This DirSync control caller must have the "directory get changes" right and DS-Replication-Get-Changes extended control access right. By default, these rights are assigned to the Administrator and LocalSystem accounts on domain controllers. The MultiFactorAuthAdSync service is configured to run as LocalSystem by default. Therefore, it is simplest to run the service on a domain controller. The service can run as an account with lesser permissions if you configure it to always perform a full synchronization. This is less efficient, but requires less account privileges.
#### Settings
Configuring the directory synchronization between Active Directory and the Azure MFA server is easy.
Sign in the primary MFA server with _MFA administrator_ equivalent credentials.
1. Open the **Multi-Factor Authentication Server** console.
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.
#### Synchronization
The MFA server uses synchronization items to synchronize users from Active Directory to the MFA server database. Synchronization items enables you to synchronize a collection of users based security groups or Active Directory containers.
You can configure synchronization items based on different criteria and filters. For the purpose of configuring Windows Hello for Business, you need to create a synchronization item based membership of the Windows Hello for Business user group. This ensures the same users who receive Windows Hello for Business policy settings are the same users synchronized to the MFA server (and are the same users with permission to enroll in the certificate). This significantly simplifies deployment and troubleshooting.
See [Directory integration between Azure MFA Server and Active Directory](https://docs.microsoft.com/azure/multi-factor-authentication/multi-factor-authentication-get-started-server-dirint) for more details.
##### To add a synchronization item
Sign in the primary MFA server with _MFA administrator_ equivalent credentials.
1. Open the **Multi-Factor Authentication Server** console.
2. From the **Multi-Factor Authentication Server** window, click the **Directory Integration** icon.
3. Select the **Synchronization** tab.
4. On the **Synchronization** tab, click **Add**.
![Azure MFA Server - add synchronization item screen](images/hello-mfa-sync-item.png)
5. In the **Add Synchronization Item** dialog, select **Security Groups** from the **View** list.
6. Select the group you are using for replication from the list of groups
7. Select **Selected Security Groups – Recursive** or, select **Security Group** from the **Import** list if you do not plan to nest groups.
8. Select **Add new users and Update existing users**.
9. Select **Disable/Remove users no longer a member** and select **Disable** from the list.
10. Select the attributes appropriate for your environment for **Import phone** and **Backup**.
11. Select **Enabled** and select **Only New Users with Phone Number** from the list.
12. Select **Send email** and select **New and Updated Users**.
##### Configure synchronization item defaults
1. When creating a new or editing a synchronization item from the Multi-Factor Authentication Server, select the **Method Defaults** tab.
2. Select the default second factor authentication method. For example, if the second factor of authentication is a text message, select **Text message**. Select if the direction of text message authentication and if the authentication should use a one-time password or one-time password and PIN (Ensure users are configured to create a PIN if the default second factor of communication requires a PIN).
##### Configure synchronization language defaults
1. When creating a new or editing a synchronization item from the Multi-Factor Authentication Server, select the **Language Defaults** tab.
2. Select the appropriate default language for these groups of users synchronized by these synchronization item.
3. If creating a new synchronization item, click **Add** to save the item. If editing an existing synchronization item, click **Apply** and then click **Close**.
>[!TIP]
>For more information on these settings and the behaviors they control, see [Directory integration between Azure MFA Server and Active Directory](https://docs.microsoft.com/azure/multi-factor-authentication/multi-factor-authentication-get-started-server-dirint).
### Installing the MFA Web Services SDK
The Web Service SDK section allows the administrator to install the Multi-Factor Authentication Web Service SDK. The Web Service SDK is an IIS (Internet Information Server) web service that provides an interface for integrating the full features of the Multi-Factor Authentication Server into most any application. The Web Service SDK uses the Multi-Factor Authentication Server as the data store.
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.
## Install Secondary MFA Servers
Additional MFA servers provided redundancy of the MFA configuration. The MFA server models uses one primary MFA server with multiple secondary servers. Servers within the same group establish communication with the primary server for that group. The primary server replicates to each of the secondary servers. You can use groups to partition the data stored on different servers, for example you can create a group for each domain, forest, or organizational unit.
Follow the same procedures for installing the primary MFA server software for each additional server. Remember that each server must be activated.
Sign in the secondary MFA server with _domain administrator_ equivalent credentials.
1. Once the Multi-Factor Authentication Server console starts, you must configure the current server’s replication group membership. You have the option to join an existing group or create a new group. When joining an existing group, the server becomes a secondary server in the existing replication group. When creating a new group, the server becomes the primary server of that replication group. Click **OK**.
**Note:** Group membership cannot be changed after activation. If a server was joined to the wrong group, it must be activated again to join a different group. Please contact support for assistance with deactivating and reactivating a server.
2. The console asks you if you want to enable replication by running the **Multi-Server Configuration Wizard**. Click **Yes**.
3. In the **Multi-Server Configuration Wizard**, leave **Active Directory** selected and clear **Certificates**. Click **Next**.
4. On the **Active Directory** page, the wizard determines what configuration is needed to enable replication. Typically, the wizard recommends adding the computer account for the current server to the **PhoneFactor Admin** group. Click **Next** to add the computer account to the group.
5. On the **Multi-Server Configuration Complete** page, click **Finish** to reboot the computer to update its group membership.
### Review
Before you continue with the deployment, validate your deployment progress by reviewing the following items:
* Confirm you downloaded the latest Azure MFA Server from the Azure Portal.
* Confirm the server has Internet connectivity.
* Confirm you installed and activated the Azure MFA Server.
* Confirm your Azure MFA Server configuration meets your organization’s needs (Company Settings, Email Settings, etc).
* Confirm you created Directory Synchronization items based on your deployment to synchronize users from Active Directory to the Azure MFA server.
* For example, you have security groups representing each collection of users that represent a phase of your deployment and a corresponding synchronization item for each of those groups.
* Confirm the Azure MFA server properly communicates with the Azure MFA cloud service by testing multifactor authentication with a newly synchronized user account.
* Confirm you installed the Web Service SDK on the primary MFA server.
* Confirm your MFA servers have adequate redundancy, should you need to promote a secondary server to the primary server.
## Installing the User Portal Server
You previously configured the User Portal settings on the primary MFA server. The User Portal web application communicates to the primary MFA server using the Web Services SDK to retrieve these settings. This configuration is ideal to ensure you can scale up the User Portal application to meet the needs of your internal users.
### Copying the User Portal Installation file
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.
3. Copy the **MultiFactorAuthenticationUserPortalSetup64.msi** file to a folder on the User Portal server.
### Configure Virtual Directory name
Sign in the User Portal server with _local administrator_ equivalent credentials.
1. Open Windows Explorer and browse to the folder to which you saved the installation file from the previous step.
2. Run the **MultiFactorAuthenticationUserPortalSetup64.msi**. The installation package asks if you want to download **Visual Studio C++ Redistributable for Visual Studio 2015**. Click **Yes**. When prompted, select **Save As**. The downloaded file is missing its file extension. **Save the file with a .exe extension and install the runtime**.
3. Run the installation package again. The installer package asks about the C++ runtime again; however, this is for the X64 version (the previous prompt was for x86). Click **Yes** to download the installation package and select **Save As** so you can save the downloaded file with a .exe extension. **Install** the run time.
4. Run the User Portal installation package. On the **Select Installation Address** page, use the default settings for **Site** and **Application Pool** settings. You can modify the Virtual directory to use a name that is more fitting for the environment, such as **mfa** (This virtual directory must match the virtual directory specified in the User Portal settings). Click **Next**.
5. Click **Close**.
### Edit MFA User Portal config file
Sign in the User Portal server with _local administrator_ equivalent credentials.
1. Open Windows Explorer and browse to C:\inetpub\wwwroot\MultiFactorAuth (or appropriate directory based on the virtual directory name) and edit the **web.config** file.
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.
### Create a DNS entry for the User Portal web site
Sign-in the domain controller or administrative workstation with _Domain Admin_ equivalent credentials.
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.
4. In the navigation pane, right-click the domain name node and click **New Host (A or AAAA)**.
5. In the **name** box, type the host name of the User Portal, such as *mfaweb* (this name must match the name of the certificate used to secure communication to the User Portal). In the IP address box, type the load balanced **IP address** of the User Portal. Click **Add Host**.
6. Close the **DNS Management** console.
### Review
Before you continue with the deployment, validate your deployment progress by reviewing the following items:
* Confirm the user portal application is properly installed on all user portal hosts
* Confirm the USE_WEB_SERVICE_SDK named value has a value equal to true.
* Confirm the WEB_SERVICE_SDK_AUTHENTICATION_USERNAME named value has the username of the web service SDK domain account previously created and that the user name is represented as DOMAIN\USERNAME
* Confirm the WEB_SERVICES_SDK_AUTHENTICATION_PASSWORD named value has the correct password for the web service SDK domain account.
* Confirm the pfup_pfwssdk_PfWsSdk named value has value that matches the URL of for the SDK service installed on the primary MFA server.
* Confirm you saved the changes to the web.config file.
### Validating your work
Windows Hello for Business is a distributed system, which on the surface appears complex and difficult. The key to a successful Windows Hello for Business deployment is to validate phases of work prior to moving to the next phase.
Using a web browser, navigate to the URL provided in the *pf_up_pfwssdk_PfWsSdk* named value in the web.config file of any one of the user portal servers. The URL should be protected by a server authentication certificate and should prompt you for authentication. Authenticate to the web site using the username and password provided in the web.config file. Successful authentication and page view confirms the Web SDK configured on the primary MFA server is correctly configured and ready to work with the user portal.
### Configuring the User Portal
The User Portal section allows the administrator to install and configure the Multi-Factor Authentication User Portal. The User Portal is an IIS Internet Information Server web site that allows users to enroll in Multi-Factor Authentication and maintain their accounts. A user may change their phone number, change their PIN, or bypass Multi-Factor Authentication during their next sign on. Users will log in to the User Portal using their normal username and password and will either complete a Multi-Factor Authentication call or answer security questions to complete their authentication. If user enrollment is allowed, a user will configure their phone number and PIN the first time they log in to the User Portal.
User Portal Administrators may be set up and granted permission to add new users and update existing users.
#### Settings
Sign in the primary MFA server with _MFA administrator_ equivalent credentials.
1. Open the Multi-Factor Authentication Server console.
2. From the Multi-Factor Authentication Server window, click the User Portal icon.
![Azure MFA Server - User Portal settings](images/hello-mfa-user-portal-settings.png)
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.
6. Select Allow users to select language.
7. Select Use security questions for fallback and select 4 from the Questions to answer list.
>[!TIP]
>For more information on these settings and the behaviors they control, see [Deploy the user portal for the Azure Multi-Factor Authentication Server](https://docs.microsoft.com/azure/multi-factor-authentication/multi-factor-authentication-get-started-portal).
#### Administrators
The User Portal Settings tab allows the administrator to install and configure the User Portal.
1. Open the Multi-Factor Authentication Server console.
2. From the Multi-Factor Authentication Server window, click the User Portal icon.
3. On the Administrators tab, Click Add
4. In the Add Administrator dialog, Click Select User… to pick a user to install and manage the User Portal. Use the default permissions.
5. Click Add.
>[!TIP]
>For more information on these settings and the behaviors they control, read the **Multi-Factor Authentication Server Help content**.
#### Security Questions
[Security questions](https://docs.microsoft.com/azure/multi-factor-authentication/multi-factor-authentication-get-started-portal#security-questions) for the User Portal may be customized to meet your requirements. The questions defined here will be offered as options for each of the four security questions a user is prompted to configure during their first log on to User Portal. The order of the questions is important since the first four items in the list will be used as defaults for the four security questions.
#### Trusted IPs
The [Trusted IPs](https://docs.microsoft.com/azure/multi-factor-authentication/multi-factor-authentication-get-started-portal#trusted-ips) tab allows you to skip Multi-Factor Authentication for User Portal log ins originating from specific IPs. For example, if users use the User Portal from the office and from home, you may decide you don't want their phones ringing for Multi-Factor Authentication while at the office. For this, you would specify the office subnet as a trusted IP entry.
## Configure the AD FS Server to use the MFA for multifactor authentication
You need to configure the AD FS server to use the MFA server. You do this by Installing the MFA Adapter on the primary AD FS Server.
### Install the MFA AD FS Adapter
Follow [Install a standalone instance of the AD FS adapter by using the Web Service SDK](https://docs.microsoft.com/azure/multi-factor-authentication/multi-factor-authentication-get-started-adfs-w2k12#install-a-standalone-instance-of-the-ad-fs-adapter-by-using-the-web-service-sdk). You should follow this instructions on all AD FS servers. You can find the files needed on the MFA server.
### Edit the MFA AD FS Adapter config file on all ADFS Servers
Sign in the primary AD FS server with _local administrator_ equivalent credentials.
1. Open Windows Explorer and browse to **C:\inetpub\wwwroot\MultiFactorAuth** (or appropriate directory based on the virtual directory name) and edit the **MultiFactorAuthenticationAdfsAdapter.config** file.
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.
### Edit the AD FS Adapter Windows PowerShell cmdlet
Sign in the primary AD FS server with _local administrator_ equivalent credentials.
Edit the **Register-MultiFactorAuthenticationAdfsAdapter.ps1** script adding `-ConfigurationFilePath <path>` to the end of the `Register-AdfsAuthenticationProvider` command where **<path>** is the full path to the **MultiFactorAuthenticationAdfsAdapter.config** file.
### Run the AD FS Adapter PowerShell cmdlet
Sign in the primary AD FS server with local administrator equivalent credentials.
Run **Register-MultiFactorAuthenticationAdfsAdapter.ps1** script in PowerShell to register the adapter. The adapter is registered as **WindowsAzureMultiFactorAuthentication**.
>[!NOTE]
>You must restart the AD FS service for the registration to take effect.
### Review
Before you continue with the deployment, validate your deployment progress by reviewing the following items:
* Confirm the user portal application is properly installed on all user portal hosts
* Confirm the USE_WEB_SERVICE_SDK named value has a value equal to true.
* Confirm the WEB_SERVICE_SDK_AUTHENTICATION_USERNAME named value has the username of the web service SDK domain account previously created and that the user name is represented as DOMAIN\USERNAME
* Confirm the WEB_SERVICES_SDK_AUTHENTICATION_PASSWORD named value has the correct password for the web service SDK domain account.
* Confirm the pfup_pfwssdk_PfWsSdk named value has value that matches the URL of for the SDK service installed on the primary MFA server.
* Confirm you saved the changes to the web.config file.
* Confirm you restarted the AD FS Service after completing the configuration.
## Test AD FS with the Multifactor Authentication connector
Now, you should test your Azure Multi-Factor Authentication server configuration before proceeding any further in the deployment. The AD FS and Azure Multi-Factor Authentication server configurations are complete.
1. In the **Multi-Factor Authentication** server, on the left, click **Users**.
2. In the list of users, select a user that is enabled and has a valid phone number to which you have access.
3. Click **Test**.
4. In the **Test User** dialog, provide the user’s password to authenticate the user to Active Directory.
The Multi-Factor Authentication server communicates with the Azure MFA cloud service to perform a second factor authentication for the user. The Azure MFA cloud service contacts the phone number provided and asks for the user to perform the second factor authentication configured for the user. Successfully providing the second factor should result in the Multi-factor authentication server showing a success dialog.
## Follow the Windows Hello for Business on premises certificate trust deployment guide
1. [Validate Active Directory prerequisites](hello-cert-trust-validate-ad-prereq.md)
2. [Validate and Configure Public Key Infrastructure](hello-cert-trust-validate-pki.md)
3. [Prepare and Deploy Windows Server 2016 Active Directory Federation Services](hello-cert-trust-adfs.md)
4. [Validate and Deploy Multifactor Authentication Services (MFA)](hello-cert-trust-validate-deploy-mfa.md)
5. [Configure Windows Hello for Business Policy settings](hello-cert-trust-policy-settings.md)

154
windows/access-protection/hello-for-business/hello-key-trust-policy-settings.md
View File

@ -1,154 +0,0 @@
---
title: Configure Windows Hello for Business Policy settings (Windows Hello for Business)
description: Configure Windows Hello for Business Policy settings for Windows Hello for Business
keywords: identity, PIN, biometric, Hello, passport
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security, mobile
author: DaniHalfin
localizationpriority: high
---
# Configure Windows Hello for Business Policy settings
**Applies to**
- Windows 10
- Windows 10 Mobile
> This guide only applies to Windows 10, version 1703 or higher.
You need a Windows 10, version 1703 workstation to run the Group Policy Management Console, which provides the latest Windows Hello for Business and PIN Complexity Group Policy settings. To run the Group Policy Management Console, you need to install the Remote Server Administration Tools for Windows 10. You can download these tools from the [Microsoft Download Center](https://www.microsoft.com/en-us/download/details.aspx?id=45520).
Install the Remote Server Administration Tools for Windows 10 on a computer running Windows 10, version 1703.
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.
On-premises certificate-based deployments of Windows Hello for Business needs three Group Policy settings:
* Enable Windows Hello for Business
* Use certificate for on-premises authentication
* Enable automatic enrollment of certificates
## Enable Windows Hello for Business Group Policy
The Enable Windows Hello for Business Group Policy setting is the configuration needed for Windows to determine if a user should be attempt to enroll for Windows Hello for Business. A user will only attempt enrollment if this policy setting is configured to enabled.
You can configure the Enable Windows Hello for Business Group Policy setting for computer or users. Deploying this policy setting to computers results in ALL users that sign-in that computer to attempt a Windows Hello for Business enrollment. Deploying this policy setting to a user results in only that user attempting a Windows Hello for Business enrollment. Additionally, you can deploy the policy setting to a group of users so only those users attempt a Windows Hello for Business enrollment. If both user and computer policy settings are deployed, the user policy setting has precedence.
## Use certificate for on-premises authentication
The Use certificate for on-premises authentication Group Policy setting determines if the on-premises deployment uses the key-trust or certificate trust on-premises authentication model. You must configure this Group Policy setting to configure Windows to enroll for a Windows Hello for Business authentication certificate. If you do not configure this policy setting, Windows considers the deployment to use key-trust on-premises authentication, which requires a sufficient number of Windows Server 2016 domain controllers to handle the Windows Hello for Business key-trust authentication requests.
You can configure this Group Policy setting for computer or users. Deploying this policy setting to computers results in ALL users requesting a Windows Hello for Business authentication certificate. Deploying this policy setting to a user results in only that user requesting a Windows Hello for Business authentication certificate. Additionally, you can deploy the policy setting to a group of users so only those users request a Windows Hello for Business authentication certificate. If both user and computer policy settings are deployed, the user policy setting has precedence.
## Enable automatic enrollment of certificates
Windows Hello for Business provisioning performs the initial enrollment of the Windows Hello for Business authentication certificate. This certificate expires based on the duration configured in the Windows Hello for Business authentication certificate template. The Windows 10, version 1703 certificate auto enrollment was updated to renew these certificates before they expire, which significantly reduces user authentication failures from expired user certificates.
The process requires no user interaction provided the user signs-in using Windows Hello for Business. The certificate is renewed in the background before it expires.
## Create the Windows Hello for Business Group Policy object
The Group Policy object contains the policy settings needed to trigger Windows Hello for Business provisioning and to ensure Windows Hello for Business authentication certificates are automatically renewed.
1. Start the **Group Policy Management Console** (gpmc.msc)
2. Expand the domain and select the **Group Policy Object** node in the navigation pane.
3. Right-click **Group Policy object** and select **New**.
4. Type *Enable Windows Hello for Business* in the name box and click **OK**.
5. In the content pane, right-click the **Enable Windows Hello for Business** Group Policy object and click **Edit**.
6. In the navigation pane, expand **Policies** under **User Configuration**.
7. Expand **Administrative Templates > Windows Component**, and select **Windows Hello for Business**.
8. In the content pane, double-click **Use Windows Hello for Business**. Click **Enable** and click **OK**.
9. Double-click **Use certificate for on-premises authentication**. Click **Enable** and click **OK**. Close the **Group Policy Management Editor**.
## Configure Automatic Certificate Enrollment
1. Start the **Group Policy Management Console** (gpmc.msc).
2. Expand the domain and select the **Group Policy Object** node in the navigation pane.
3. Right-click the **Enable Windows Hello for Business** Group Policy object and click **Edit**.
4. In the navigation pane, expand **Policies** under **User Configuration**.
5. Expand **Windows Settings > Security Settings**, and click **Public Key Policies**.
6. In the details pane, right-click **Certificate Services Client – Auto-Enrollment** and select **Properties**.
7. Select **Enabled** from the **Configuration Model** list.
8. Select the **Renew expired certificates**, **update pending certificates**, and **remove revoked certificates** check box.
9. Select the **Update certificates that use certificate templates** check box.
10. Click **OK**. Close the **Group Policy Management Editor**.
## Configure Security in the Windows Hello for Business Group Policy object
The best way to deploy the Windows Hello for Business Group Policy object is to use security group filtering. The enables you to easily manage the users that should receive Windows Hello for Business by simply adding them to a group. This enables you to deploy Windows Hello for Business in phases.
1. Start the **Group Policy Management Console** (gpmc.msc)
2. Expand the domain and select the **Group Policy Object** node in the navigation pane.
3. Double-click the **Enable Windows Hello for Business** Group Policy object.
4. In the **Security Filtering** section of the content pane, click **Add**. Type *Windows Hello for Business Users* or the name of the security group you previously created and click **OK**.
5. Click the **Delegation** tab. Select **Authenticated Users** and click **Advanced**.
6. In the **Group or User names** list, select **Authenticated Users**. In the **Permissions for Authenticated Users** list, clear the **Allow** check box for the **Apply Group Policy** permission. Click **OK**.
## Deploy the Windows Hello for Business Group Policy object
The application of the Windows Hello for Business Group Policy object uses security group filtering. This enables you to link the Group Policy object at the domain, ensuring the Group Policy object is within scope to all users. However, the security group filtering ensures only the users included in the *Windows Hello for Business Users* global group receive and apply the Group Policy object, which results in the provisioning of Windows Hello for Business.
1. Start the **Group Policy Management Console** (gpmc.msc)
2. In the navigation pane, expand the domain and right-click the node that has your Active Directory domain name and click **Link an existing GPO…**
3. In the **Select GPO** dialog box, select **Enable Windows Hello for Business** or the name of the Windows Hello for Business Group Policy object you previously created and click **OK**.
Just to reassure, linking the **Windows Hello for Business** Group Policy object to the domain ensures the Group Policy object is in scope for all domain users. However, not all users will have the policy settings applied to them. Only users who are members of the Windows Hello for Business group receive the policy settings. All others users ignore the Group Policy object.
## Other Related Group Policy settings
### Windows Hello for Business
There are other Windows Hello for Business policy settings you can configure to manage your Windows Hello for Business deployment. These policy settings are computer-based policy setting; so they are applicable to any user that sign-in from a computer with these policy settings.
### Use a hardware security device
The default configuration for Windows Hello for Business is to prefer hardware protected credentials; however, not all computers are able to create hardware protected credentials. When Windows Hello for Business enrollment encounters a computer that cannot create a hardware protected credential, it will create a software-based credential.
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.
### Use biometrics
Windows Hello for Business provides a great user experience when combined with the use of biometrics. Rather than providing a PIN to sign-in, a user can use a fingerprint or facial recognition to sign-in to Windows, without sacrificing security.
The default Windows Hello for Business enables users to enroll and use biometrics. However, some organization may want more time before using biometrics and want to disable their use until they are ready. To not allow users to use biometrics, configure the **Use biometrics** Group Policy setting to disabled and apply it to your computers. The policy setting disabled all biometrics. Currently, Windows does not provide granular policy setting that enable you to disable specific modalities of biometrics such as allow facial recognition, but disallow fingerprint.
### PIN Complexity
PIN complexity is not specific to Windows Hello for Business. Windows 10 enables users to use PINs outside of Windows Hello for Business. PIN Complexity Group Policy settings apply to all uses of PINs, even when Windows Hello for Business is not deployed.
Windows 10 provides eight PIN Complexity Group Policy settings that give you granular control over PIN creation and management. You can deploy these policy settings to computers, where they affect all users creating PINs on that computer; or, you can deploy these settings to users, where they affect those users creating PINs regardless of the computer they use. If you deploy both computer and user PIN complexity Group Policy settings, the user policy settings have precedence over computer policy settings. Also, this conflict resolution is based on the last applied policy. Windows does not merge the policy settings automatically; however, you can deploy Group Policy to provide to accomplish a variety of configurations. The policy settings included are:
* Require digits
* Require lowercase letters
* Maximum PIN length
* Minimum PIN length
* Expiration
* History
* Require special characters
* Require uppercase letters
In the Windows 10, version 1703, the PIN complexity Group Policy settings have moved to remove misunderstanding that PIN complexity policy settings were exclusive to Windows Hello for Business. The new location of these Group Policy settings is under Administrative Templates\System\PIN Complexity under both the Computer and User Configuration nodes of the Group Policy editor.
## Review
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 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)
* Add the Windows Hello for Business Users group to the Group Policy object and gave the group the allow permission for Apply Group Policy
* Linked the Group Policy object to the correct locations within Active Directory
* Deploy any additional Windows Hello for Business Group Policy setting is a policy separate from the one that enables it for users
## 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 WHFB 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 that are not members of this group will not attempt to enroll for Windows Hello for Business.
## Follow the Windows Hello for Business on premises certificate trust deployment guide
1. [Validate Active Directory prerequisites](hello-cert-trust-validate-ad-prereq.md)
2. [Validate and Configure Public Key Infrastructure](hello-cert-trust-validate-pki.md)
3. [Prepare and Deploy Windows Server 2016 Active Directory Federation Services](hello-cert-trust-adfs.md)
4. [Validate and Deploy Multifactor Authentication Services (MFA)](hello-cert-trust-validate-deploy-mfa.md)
5. Configure Windows Hello for Business Policy settings (*You are here*)

77
windows/access-protection/hello-for-business/hello-key-trust-validate-ad-prereq.md
View File

@ -1,77 +0,0 @@
---
title: Validate Active Directory prerequisites (Windows Hello for Business)
description: How to Validate Active Directory prerequisites for Windows Hello for Business
keywords: identity, PIN, biometric, Hello, passport
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security, mobile
author: DaniHalfin
localizationpriority: high
---
# Validate Active Directory prerequisites
**Applies to**
- Windows 10
> 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.
Manually updating Active Directory uses the command-line utility **adprep.exe** located at **<drive>:\support\adprep** on the Windows Server 2016 DVD or ISO. Before running adprep.exe, you must identify the domain controller hosting the schema master role.
## Discovering schema role
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)
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.
## Updating the Schema
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.
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.
3. To update the schema, type ```adprep /forestprep```.
4. Read the Adprep Warning. Type the letter **C*** and press **Enter** to update the schema.
5. Close the Command Prompt and sign-out.
## Create the KeyCredential Admins Security Global Group
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.
1. Open **Active Directory Users and Computers**.
2. Click **View** and click **Advance Features**.
3. Expand the domain node from the navigation pane.
4. Right-click the **Users** container. Click **New**. Click **Group**.
5. Type **KeyCredential Admins** in the **Group Name** text box.
6. Click **OK**.
## Create the Windows Hello for Business Users Security Global Group
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.
1. Open **Active Directory Users and Computers**.
2. Click **View** and click **Advanced Features**.
3. Expand the domain node from the navigation pane.
4. Right-click the **Users** container. Click **New**. Click **Group**.
5. Type **Windows Hello for Business Users** in the **Group Name** text box.
6. Click **OK**.
## Follow the Windows Hello for Business on premises certificate trust deployment guide
1. Validate Active Directory prerequisites (*You are here*)
2. [Validate and Configure Public Key Infrastructure](hello-cert-trust-validate-pki.md)
3. [Prepare and Deploy Windows Server 2016 Active Directory Federation Services](hello-cert-trust-adfs.md)
4. [Validate and Deploy Multifactor Authentication Services (MFA)](hello-cert-trust-validate-deploy-mfa.md)
5. [Configure Windows Hello for Business Policy settings](hello-cert-trust-policy-settings.md)

48
windows/access-protection/hello-for-business/hello-key-trust-validate-deploy-mfa.md
View File

@ -1,48 +0,0 @@
---
title: Validate and Deploy Multifactor Authentication Services (MFA) (Windows Hello for Business)
description: How to Validate and Deploy Multifactor Authentication Services for Windows Hello for Business
keywords: identity, PIN, biometric, Hello, passport
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security, mobile
author: DaniHalfin
localizationpriority: high
---
# Validate and Deploy Multifactor Authentication Services (MFA)
**Applies to**
- Windows 10
- Windows 10 Mobile
> This guide only applies to Windows 10, version 1703 or higher.
Windows Hello for Business requires all users perform multi-factor authentication prior to creating and registering a Windows Hello for Business credential. Windows Hello for Business deployments use Azure Multi-Factor Authentication (Azure MFA) services for the secondary authentication. On-Premises deployments use Azure MFA server, an on-premises implementation that do not require synchronizing Active Directory credentials to Azure Active Directory.
Azure Multi-Factor Authentication is an easy to use, scalable, and reliable solution that provides a second method of authentication so your users are always protected.
* **Easy to Use** - Azure Multi-Factor Authentication is simple to set up and use. The extra protection that comes with Azure Multi-Factor Authentication allows users to manage their own devices. Best of all, in many instances it can be set up with just a few simple clicks.
* **Scalable** - Azure Multi-Factor Authentication uses the power of the cloud and integrates with your on-premises AD and custom apps. This protection is even extended to your high-volume, mission-critical scenarios.
* **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.
## On-Premises Azure MFA Server
On-premises deployments, both key and certificate trust, use the Azure MFA server where the credentials are not synchronized to Azure Active Directory.
### Infrastructure
A lab or proof-of-concept environment does not need high-availability or scalability. However, a production environment needs both of these. Ensure your environment considers and incorporates these factors, as necessary. All production environments should have a minimum of two MFA servers—one primary and one secondary server. The environment should have a minimum of two User Portal Servers that are load balanced using hardware or Windows Network Load Balancing.
Please follow [Download the Azure Multi-Factor Authentication Server](https://docs.microsoft.com/en-us/azure/multi-factor-authentication/multi-factor-authentication-get-started-server#download-the-azure-multi-factor-authentication-server) to download Azure MFA server.
>[!IMPORTANT]
>Make sure to validate the requirements for Azure MFA server, as outlined in [Install and Configure the Azure Multi-Factor Authentication Server](https://docs.microsoft.com/en-us/azure/multi-factor-authentication/multi-factor-authentication-get-started-server#install-and-configure-the-azure-multi-factor-authentication-server) beofre proceeding. Do not use instllation instructions provided in the article.
Once you have validated all the requirements, please proceed to [Configure or Deploy Multifactor Authentication Services](hello-cert-trust-deploy-mfa.md).
## Follow the Windows Hello for Business on premises certificate trust deployment guide
1. [Validate Active Directory prerequisites](hello-cert-trust-validate-ad-prereq.md)
2. [Validate and Configure Public Key Infrastructure](hello-cert-trust-validate-pki.md)
3. [Prepare and Deploy Windows Server 2016 Active Directory Federation Services](hello-cert-trust-adfs.md)
4. Validate and Deploy Multifactor Authentication Services (MFA) (*You are here*)
5. [Configure Windows Hello for Business Policy settings](hello-cert-trust-policy-settings.md)

196
windows/access-protection/hello-for-business/hello-key-trust-validate-pki.md
View File

@ -1,196 +0,0 @@
---
title: Validate Public Key Infrastructure (Windows Hello for Business)
description: How to Validate Public Key Infrastructure for Windows Hello for Business
keywords: identity, PIN, biometric, Hello, passport
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security, mobile
author: DaniHalfin
localizationpriority: high
---
# Validate and Configure Public Key Infrastructure
**Applies to**
- Windows 10
- Windows 10 Mobile
> This guide only applies to Windows 10, version 1703 or higher.
Windows Hello for Business must have a public key infrastructure regardless of the deployment or trust model. All trust models depend on the domain controllers having a certificate. The certificate serves as a root of trust for clients to ensure they are not communicating with a rogue domain controller. The certificate trust model extends certificate issuance to client computers. During Windows Hello for Business provisioning, the user receives a sign-in certificate. Secondary certificates, such as VPN and SMIME (future feature) may also be deployed.
## Deploy an enterprise certificate authority
This guide assumes most enterprise have an existing public key infrastructure. Windows Hello for Business depends on a Windows enterprise public key infrastructure running the Active Directory Certificate Services role from Windows Server 2012 or later.
### Lab-based public key infrastructure
The following instructions may be used to deploy simple public key infrastructure that is suitable for a lab environment.
Sign-in using _Enterprise Admin_ equivalent credentials on Windows Server 2012 or later server where you want the certificate authority installed.
>[!NOTE]
>Never install a certificate authority on a domain controller in a production environment.
1. Open an elevated Windows PowerShell prompt.
2. Use the following command to install the Active Directory Certificate Services role.
```PowerShell
Add-WindowsFeature Adcs-Cert-Authority -IncludeManageTools
```
3. Use the following command to configure the Certificate Authority using a basic certificate authority configuration.
```PowerShell
Install-AdcsCertificateAuthority
```
## 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.
### Configure Domain Controller Certificates
Clients need to trust domain controllers and the best way to do this is to ensure each domain controller has a Kerberos Authentication certificate. Installing a certificate on the domain controller enables the Key Distribution Center (KDC) to prove its identity to other members of the domain. This provides clients a root of trust external to the domain—namely the enterprise certificate authority.
Domain controllers automatically request a domain controller certificate (if published) when they discover an enterprise certificate authority is added to Active Directory. However, certificates based on the Domain Controller and Domain Controller Authentication certificate templates do not include the KDC Authentication object identifier (OID), which was later added to the Kerberos RFC. Therefore, domain controllers need to request a certificate based on the Kerberos Authentication certificate template.
By default, the Active Directory Certificate Authority provides and publishes the Kerberos Authentication certificate template. However, the cryptography configuration included in the provided template is based on older and less performant cryptography APIs. To ensure domain controllers request the proper certificate with the best available cryptography, use the Kerberos Authentication certificate template a baseline to create an updated domain controller certificate template.
Sign-in a certificate authority or management workstations with _Domain Admin_ equivalent credentials.
1. Open the **Certificate Authority** management console.
2. Right-click **Certificate Templates** and click **Manage**.
3. In the **Certificate Template Console**, right-click the **Kerberos Authentication** template in the details pane and click **Duplicate Template**.
4. On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Authority** list. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Recipient** list.
5. On the **General** tab, type **Domain Controller Authentication (Kerberos)** in Template display name. Adjust the validity and renewal period to meet your enterprise’s needs.
**Note**If you use different template names, you’ll need to remember and substitute these names in different portions of the lab.
6. On the **Subject** tab, select the **Build from this Active Directory information** button if it is not already selected. Select **None** from the **Subject name format** list. Select **DNS name** from the **Include this information in alternate subject** list. Clear all other items.
7. On the **Cryptography** tab, select **Key Storage Provider** from the **Provider Category** list. Select **RSA** from the **Algorithm name** list. Type **2048** in the **Minimum key size** text box. Select **SHA256** from the **Request hash** list. Click **OK**.
8. Close the console.
### Superseding the existing Domain Controller certificate
Many domain controllers may have an existing domain controller certificate. The Active Directory Certificate Services provides a default certificate template from domain controllers—the domain controller certificate template. Later releases provided a new certificate template—the domain controller authentication certificate template. These certificate templates were provided prior to update of the Kerberos specification that stated Key Distribution Centers (KDCs) performing certificate authentication needed to include the KDC Authentication extension.
The Kerberos Authentication certificate template is the most current certificate template designated for domain controllers and should be the one you deploy to all your domain controllers (2008 or later). The autoenrollment feature in Windows enables you to effortlessly replace these domain controller certificates. You can use the following configuration to replace older domain controller certificates with a new certificate using the Kerberos Authentication certificate template.
Sign-in a certificate authority or management workstations with _Enterprise Admin_ equivalent credentials.
1. Open the **Certificate Authority** management console.
2. Right-click **Certificate Templates** and click **Manage**.
3. In the **Certificate Template Console**, right-click the **Domain Controller Authentication (Kerberos)** (or the name of the certificate template you created in the previous section) template in the details pane and click **Properties**.
4. Click the **Superseded Templates** tab. Click **Add**.
5. From the **Add Superseded Template** dialog, select the **Domain Controller** certificate template and click **OK**. Click **Add**.
6. From the **Add Superseded Template** dialog, select the **Domain Controller Authentication** certificate template and click **OK**.
7. From the **Add Superseded Template dialog**, select the **Kerberos Authentication** certificate template and click **OK**.
8. Add any other enterprise certificate templates that were previously configured for domain controllers to the **Superseded Templates** tab.
9. Click **OK** and close the **Certificate Templates** console.
The certificate template is configured to supersede all the certificate templates provided in the certificate templates superseded templates list. However, the certificate template and the superseding of certificate templates is not active until you publish the certificate template to one or more certificate authorities.
### Configure an Internal Web Server Certificate template
Windows 10 clients use the https protocol when communicating with Active Directory Federation Services. To meet this need, you must issue a server authentication certificate to all the nodes in the Active Directory Federation Services farm. On-premises deployments can use a server authentication certificate issued by their enterprise PKI. You must configure a server authentication certificate template so the host running the Active Directory Federation Service can request the certificate.
Sign-in a certificate authority or management workstations with _Domain Admin_ equivalent credentials.
1. Open the **Certificate Authority** management console.
2. Right-click **Certificate Templates** and click **Manage**.
3. In the **Certificate Template Console**, right-click the **Web Server** template in the details pane and click **Duplicate Template**.
4. On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Authority** list. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Recipient** list.
5. On the **General** tab, type **Internal Web Server** in **Template display name**. Adjust the validity and renewal period to meet your enterprise’s needs.
**Note:** If you use different template names, you’ll need to remember and substitute these names in different portions of the lab.
6. On the **Request Handling** tab, select **Allow private key to be exported**.
7. On the **Subject** tab, select the **Supply in the request** button if it is not already selected.
8. On the **Security** tab, Click **Add**. Type **Domain Computers** in the **Enter the object names to select** box. Click **OK**. Select the **Allow** check box next to the **Enroll** permission.
9. On the **Cryptography** tab, select **Key Storage Provider** from the **Provider Category** list. Select **RSA** from the **Algorithm name** list. Type **2048** in the **Minimum key size** text box. Select **SHA256** from the **Request hash** list. Click **OK**.
10. Close the console.
### Unpublish Superseded Certificate Templates
The certificate authority only issues certificates based on published certificate templates. For defense in depth security, it is a good practice to unpublish certificate templates that the certificate authority is not configured to issue. This includes the pre-published certificate template from the role installation and any superseded certificate templates.
The newly created domain controller authentication certificate template supersedes previous domain controller certificate templates. Therefore, you need to unpublish these certificate templates from all issuing certificate authorities.
Sign-in to the certificate authority or management workstation with _Enterprise Admin_ equivalent credentials.
1. Open the **Certificate Authority** management console.
2. Expand the parent node from the navigation pane.
3. Click **Certificate Templates** in the navigation pane.
4. Right-click the **Domain Controller** certificate template in the content pane and select **Delete**. Click **Yes** on the **Disable certificate templates** window.
5. Repeat step 4 for the **Domain Controller Authentication** and **Kerberos Authentication** certificate templates.
### Publish Certificate Templates to the Certificate Authority
The certificate authority may only issue certificates for certificate templates that are published to that certificate authority. If you have more than one certificate authority and you want that certificate authority to issue certificates based on a specific certificate template, then you must publish the certificate template to all certificate authorities that are expected to issue the certificate.
Sign-in to the certificate authority or management workstations with an _Enterprise Admin_ equivalent credentials.
1. Open the **Certificate Authority** management console.
2. Expand the parent node from the navigation pane.
3. Click **Certificate Templates** in the navigation pane.
4. Right-click the **Certificate Templates** node. Click **New**, and click **Certificate Template** to issue.
5. In the **Enable Certificates Templates** window, select the **Domain Controller Authentication (Kerberos)**, and **Internal Web Server** templates you created in the previous steps. Click **OK** to publish the selected certificate templates to the certificate authority.
6. If you published the Domain Controller Authentication (Kerberos) certificate template, then you should unpublish the certificate templates you included in the superseded templates list.
* To unpublish a certificate template, right-click the certificate template you want to unpublish in the details pane of the Certificate Authority console and select **Delete**. Click **Yes** to confirm the operation.
7. Close the console.
### Configure Domain Controllers for Automatic Certificate Enrollment
Domain controllers automatically request a certificate from the domain controller certificate template. However, the domain controller is unaware of newer certificate templates or superseded configurations on certificate templates. To continue automatic enrollment and renewal of domain controller certificates that understand newer certificate template and superseded certificate template configurations, create and configure a Group Policy object for automatic certificate enrollment and link the Group Policy object to the Domain Controllers OU.
1. Start the **Group Policy Management Console** (gpmc.msc)
2. Expand the domain and select the **Group Policy Object** node in the navigation pane.
3. Right-click **Group Policy object** and select **New**
4. Type *Domain Controller Auto Certificate Enrollment* in the name box and click **OK**.
5. Right-click the **Domain Controller Auto Certificate Enrollment** Group Policy object and click **Edit**.
6. In the navigation pane, expand **Policies** under **Computer Configuration**.
7. Expand **Windows Settings**, **Security Settings**, and click **Public Key Policies**.
8. In the details pane, right-click **Certificate Services Client – Auto-Enrollment** and select **Properties**.
9. Select **Enabled** from the **Configuration Model** list.
10. Select the **Renew expired certificates**, **update pending certificates**, and **remove revoked certificates** check box.
11. Select the **Update certificates that use certificate templates** check box.
12. Click **OK**. Close the **Group Policy Management Editor**.
### Deploy the Domain Controller Auto Certificate Enrollment Group Policy Object
Sign-in a domain controller or management workstations with _Domain Admin_ equivalent credentials.
1. Start the **Group Policy Management Console** (gpmc.msc)
2. In the navigation pane, expand the domain and expand the node that has your Active Directory domain name. Right-click the **Domain Controllers** organizational unit and click **Link an existing GPO…**
3. In the **Select GPO** dialog box, select **Domain Controller Auto Certificate Enrollment** or the name of the domain controller certificate enrollment Group Policy object you previously created and click **OK**.
### Validating your work
Windows Hello for Business is a distributed system, which on the surface appears complex and difficult. The key to a successful Windows Hello for Business deployment is to validate phases of work prior to moving to the next phase.
You want to confirm your domain controllers enroll the correct certificates and not any unnecessary (superseded) certificate templates. You need to check each domain controller that autoenrollment for the computer occurred.
#### 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.
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.
Certificates superseded by your new domain controller certificate generate an archive event in the CertificateServices-Lifecycles-System event. The archive event contains the certificate template name and thumbprint of the certificate that was superseded by the new certificate.
#### Certificate Manager
You can use the Certificate Manager console to validate the domain controller has the properly enrolled certificate based on the correct certificate template with the proper EKUs. Use **certlm.msc** to view certificate in the local computers certificate stores. Expand the **Personal** store and view the certificates enrolled for the computer. Archived certificates do not appear in Certificate Manager.
#### Certutil.exe
You can use **certutil.exe** to view enrolled certificates in the local computer. Certutil shows enrolled and archived certificates for the local computer. From an elevated command prompt, run `certutil -q -store my` to view locally enrolled certificates.
To view detailed information about each certificate in the store, use `certutil -q -v -store my` to validate automatic certificate enrollment enrolled the proper certificates.
#### Troubleshooting
Windows triggers automatic certificate enrollment for the computer during boot, and when Group Policy updates. You can refresh Group Policy from an elevated command prompt using `gpupdate /force`.
Alternatively, you can forcefully trigger automatic certificate enrollment using `certreq -autoenroll -q` from an elevated command prompt.
Use the event logs to monitor certificate enrollment and archive. Review the configuration, such as publishing certificate templates to issuing certificate authority and the allow auto enrollment permissions.
## Follow the Windows Hello for Business on premises certificate trust deployment guide
1. [Validate Active Directory prerequisites](hello-cert-trust-validate-ad-prereq.md)
2. Validate and Configure Public Key Infrastructure (*You are here*)
3. [Prepare and Deploy Windows Server 2016 Active Directory Federation Services](hello-cert-trust-adfs.md)
4. [Validate and Deploy Multifactor Authentication Services (MFA)](hello-cert-trust-validate-deploy-mfa.md)
5. [Configure Windows Hello for Business Policy settings](hello-cert-trust-policy-settings.md)

2
windows/access-protection/hello-for-business/toc.md
View File

@ -1,6 +1,6 @@
# [Windows Hello for Business](hello-identity-verification.md)
## [Windows Hello for Business Overview](hello-overview.md)
## [Winodws Hello for Business Overview](hello-overview.md)
## [How Windows Hello for Business works](hello-how-it-works.md)
## [Manage Windows Hello for Business in your organization](hello-manage-in-organization.md)
## [Why a PIN is better than a password](hello-why-pin-is-better-than-password.md)

5
windows/configuration/change-history-for-configure-windows-10.md
View File

@ -8,8 +8,6 @@ ms.sitesec: library
ms.pagetype: security
localizationpriority: high
author: jdeckerms
ms.author: jdecker
ms.date: 07/13/2017
---
# Change history for Configure Windows 10
@ -19,8 +17,7 @@ This topic lists new and updated topics in the [Configure Windows 10](index.md)
## July 2017
| New or changed topic | Description |
| --- | --- |
| [Manage connections from Windows operating system components to Microsoft services](manage-connections-from-windows-operating-system-components-to-microsoft-services.md) | Fixed Group Policy settings that were not correct. |
|[Windows 10, version 1703 basic level Windows diagnostic events and fields](basic-level-windows-diagnostic-events-and-fields.md) | Updated several Appraiser events and added Census.Speech. |
|[Windows 10, version 1703 basic level Windows diagnostic events and fields](basic-level-windows-diagnostic-events-and-fields.md)|Updated several Appraiser events and added Census.Speech.
## June 2017

11
windows/configuration/manage-connections-from-windows-operating-system-components-to-microsoft-services.md
View File

@ -296,7 +296,7 @@ After that, configure the following:
- Disable the Group Policy: **Computer Configuration** &gt; **Administrative Templates** &gt; **System** &gt; **Enable Windows NTP Server** &gt; **Windows Time Service** &gt; **Configure Windows NTP Client**
> [!NOTE]
> This is only available on Windows 10, version 1703 and later. If you're using a previous version of Windows 10, the Group Policy setting is **Computer Configuration\\Administrative Templates\\System\\Windows Time Service\\Time Providers\\Enable Windows NTP Client**
> This is only available on Windows 10, version 1703 and later.
-or -
@ -1423,7 +1423,7 @@ In the **Background Apps** area, you can choose which apps can run in the backgr
To turn off **Let apps run in the background**:
- For Windows 10, version 1607 and earlier, you must turn off the feature in the UI for each app.
- Turn off the feature in the UI for each app.
-or-
@ -1690,11 +1690,12 @@ If you're running Windows 10, version 1607 or later, you only need to enable the
- **User Configuration** > **Administrative Templates** > **Windows Components** > **Cloud Content** > **Turn off all Windows spotlight features**
> [!NOTE]
> This must be done within 15 minutes after Windows 10 is installed. Alternatively, you can create an image with this setting.
-or-
- Create a new REG\_DWORD registry setting in **HKEY\_LOCAL\_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows\\CloudContent!DisableWindowsSpotlightFeatures**, with a value of 1 (one).
-and-
- Create a new REG\_DWORD registry setting in **HKEY\_CURRENT\_USER\\SOFTWARE\\Policies\\Microsoft\\Windows\\CloudContent!DisableWindowsSpotlightFeatures**, with a value of 1 (one).
If you're not running Windows 10, version 1607 or later, you can use the other options in this section.

1
windows/threat-protection/block-untrusted-fonts-in-enterprise.md
View File

@ -8,7 +8,6 @@ ms.mktglfcycl: deploy
ms.pagetype: security
ms.sitesec: library
author: eross-msft
ms.author: lizross
localizationpriority: high
---

1
windows/threat-protection/windows-defender-smartscreen/windows-defender-smartscreen-available-settings.md
View File

@ -7,7 +7,6 @@ ms.mktglfcycl: explore
ms.sitesec: library
ms.pagetype: security
author: eross-msft
ms.author: lizross
localizationpriority: high
---

1
windows/threat-protection/windows-defender-smartscreen/windows-defender-smartscreen-overview.md
View File

@ -7,7 +7,6 @@ ms.mktglfcycl: explore
ms.sitesec: library
ms.pagetype: security
author: eross-msft
ms.author: lizross
localizationpriority: high
---

1
windows/threat-protection/windows-defender-smartscreen/windows-defender-smartscreen-set-individual-device.md
View File

@ -7,7 +7,6 @@ ms.mktglfcycl: explore
ms.sitesec: library
ms.pagetype: security
author: eross-msft
ms.author: lizross
localizationpriority: high
---

1
windows/threat-protection/windows-information-protection/app-behavior-with-wip.md
View File

@ -7,7 +7,6 @@ ms.mktglfcycl: explore
ms.pagetype: security
ms.sitesec: library
author: eross-msft
ms.author: lizross
localizationpriority: high
---

1
windows/threat-protection/windows-information-protection/collect-wip-audit-event-logs.md
View File

@ -6,7 +6,6 @@ ms.mktglfcycl: explore
ms.sitesec: library
ms.pagetype: security
author: eross-msft
ms.author: lizross
localizationpriority: high
---

1
windows/threat-protection/windows-information-protection/create-and-verify-an-efs-dra-certificate.md
View File

@ -7,7 +7,6 @@ ms.mktglfcycl: explore
ms.sitesec: library
ms.pagetype: security
author: eross-msft
ms.author: lizross
localizationpriority: high
---

1
windows/threat-protection/windows-information-protection/create-vpn-and-wip-policy-using-intune-azure.md
View File

@ -7,7 +7,6 @@ ms.mktglfcycl: explore
ms.sitesec: library
ms.pagetype: security
author: eross-msft
ms.author: lizross
localizationpriority: high
---

1
windows/threat-protection/windows-information-protection/create-vpn-and-wip-policy-using-intune.md
View File

@ -8,7 +8,6 @@ ms.mktglfcycl: explore
ms.sitesec: library
ms.pagetype: security
author: eross-msft
ms.author: lizross
localizationpriority: high
---

1
windows/threat-protection/windows-information-protection/create-wip-policy-using-intune-azure.md
View File

@ -6,7 +6,6 @@ ms.mktglfcycl: explore
ms.sitesec: library
ms.pagetype: security
author: eross-msft
ms.author: lizross
localizationpriority: high
---

1
windows/threat-protection/windows-information-protection/create-wip-policy-using-intune.md
View File

@ -7,7 +7,6 @@ ms.mktglfcycl: explore
ms.sitesec: library
ms.pagetype: security
author: eross-msft
ms.author: lizross
localizationpriority: high
---

1
windows/threat-protection/windows-information-protection/create-wip-policy-using-sccm.md
View File

@ -8,7 +8,6 @@ ms.mktglfcycl: explore
ms.sitesec: library
ms.pagetype: security
author: eross-msft
ms.author: lizross
localizationpriority: high
---

1
windows/threat-protection/windows-information-protection/deploy-wip-policy-using-intune-azure.md
View File

@ -7,7 +7,6 @@ ms.mktglfcycl: explore
ms.sitesec: library
ms.pagetype: security
author: eross-msft
ms.author: lizross
localizationpriority: high
---

1
windows/threat-protection/windows-information-protection/deploy-wip-policy-using-intune.md
View File

@ -8,7 +8,6 @@ ms.mktglfcycl: explore
ms.sitesec: library
ms.pagetype: security
author: eross-msft
ms.author: lizross
localizationpriority: high
---

1
windows/threat-protection/windows-information-protection/enlightened-microsoft-apps-and-wip.md
View File

@ -8,7 +8,6 @@ ms.mktglfcycl: explore
ms.sitesec: library
ms.pagetype: security
author: eross-msft
ms.author: lizross
localizationpriority: high
---

1
windows/threat-protection/windows-information-protection/guidance-and-best-practices-wip.md
View File

@ -8,7 +8,6 @@ ms.mktglfcycl: explore
ms.sitesec: library
ms.pagetype: security
author: eross-msft
ms.author: lizross
localizationpriority: high
---

1
windows/threat-protection/windows-information-protection/limitations-with-wip.md
View File

@ -7,7 +7,6 @@ ms.mktglfcycl: explore
ms.sitesec: library
ms.pagetype: security
author: eross-msft
ms.author: lizross
localizationpriority: high
---

1
windows/threat-protection/windows-information-protection/mandatory-settings-for-wip.md
View File

@ -7,7 +7,6 @@ ms.mktglfcycl: explore
ms.sitesec: library
ms.pagetype: security
author: eross-msft
ms.author: lizross
localizationpriority: high
---

1
windows/threat-protection/windows-information-protection/overview-create-wip-policy.md
View File

@ -7,7 +7,6 @@ ms.mktglfcycl: explore
ms.sitesec: library
ms.pagetype: security
author: eross-msft
ms.author: lizross
localizationpriority: high
---

1
windows/threat-protection/windows-information-protection/protect-enterprise-data-using-wip.md
View File

@ -8,7 +8,6 @@ ms.mktglfcycl: explore
ms.sitesec: library
ms.pagetype: security
author: eross-msft
ms.author: lizross
localizationpriority: high
---

1
windows/threat-protection/windows-information-protection/recommended-network-definitions-for-wip.md
View File

@ -7,7 +7,6 @@ ms.mktglfcycl: explore
ms.sitesec: library
ms.pagetype: security
author: eross-msft
ms.author: lizross
localizationpriority: high
---

1
windows/threat-protection/windows-information-protection/testing-scenarios-for-wip.md
View File

@ -8,7 +8,6 @@ ms.mktglfcycl: explore
ms.sitesec: library
ms.pagetype: security
author: eross-msft
ms.author: lizross
localizationpriority: high
---

1
windows/threat-protection/windows-information-protection/using-owa-with-wip.md
View File

@ -7,7 +7,6 @@ ms.mktglfcycl: explore
ms.sitesec: library
ms.pagetype: security
author: eross-msft
ms.author: lizross
localizationpriority: high
---

1
windows/threat-protection/windows-information-protection/wip-app-enterprise-context.md
View File

@ -7,7 +7,6 @@ ms.mktglfcycl: explore
ms.sitesec: library
ms.pagetype: security
author: eross-msft
ms.author: lizross
localizationpriority: high
---