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

Updates and Fixes

Browse Source
This commit is contained in:
Mike Stephens 2018-05-23 17:00:56 -07:00
parent 00537ad7b7
commit f9dab62f4f
19 changed files with 85 additions and 57 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
windows/security/identity-protection/hello-for-business/feature-multifactor-unlock.md
View File

@ -14,7 +14,7 @@ ms.date: 03/20/2018
# Multifactor Unlock
**Applies to:**
- Windows 10
- Windows 10
**Requirements:**
* Windows Hello for Business deployment (Hybrid or On-premises)

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

@ -6,10 +6,10 @@ ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security, mobile
author: DaniHalfin
ms.localizationpriority: high
ms.author: daniha
ms.date: 09/01/2017
author: mikestephens-MS
ms.author: mstephen
localizationpriority: high
ms.date: 05/05/2018
---
# Validate and Configure Public Key Infrastructure
@ -60,7 +60,7 @@ Sign-in to a certificate authority or management workstations with _Domain Admin
1. Open the **Certificate Authority** management console.
2. Right-click **Certificate Templates** and click **Manage**.
3. In the **Certificate Template Console**, right-click the **Kerberos Authentication** template in the details pane and click **Duplicate Template**.
4. On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Authority** list. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Recipient** list.
4. On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2008 R2** from the **Certification Authority** list. Select **Windows 7.Server 2008 R2** from the **Certification Recipient** list.
5. On the **General** tab, type **Domain Controller Authentication (Kerberos)** in Template display name. Adjust the validity and renewal period to meet your enterprise’s needs.
**Note**If you use different template names, you’ll need to remember and substitute these names in different portions of the lab.
6. On the **Subject** tab, select the **Build from this Active Directory information** button if it is not already selected. Select **None** from the **Subject name format** list. Select **DNS name** from the **Include this information in alternate subject** list. Clear all other items.

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

@ -20,7 +20,7 @@ ms.date: 10/23/2017
Windows Hello for Business replaces username and password sign-in to Windows with strong user authentication based on asymmetric key pair. The following deployment guide provides the information needed to successfully deploy Windows Hello for Business in an existing environment.
Below, you can find all the infromation you need to deploy Windows Hello for Business in a key trust model in your on-premises environment:
Below, you can find all the information you need to deploy Windows Hello for Business in a key trust model in your on-premises environment:
1. [Validate Active Directory prerequisites](hello-key-trust-validate-ad-prereq.md)
2. [Validate and Configure Public Key Infrastructure](hello-key-trust-validate-pki.md)
3. [Prepare and Deploy Windows Server 2016 Active Directory Federation Services](hello-key-trust-adfs.md)

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

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

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

@ -14,7 +14,7 @@ ms.date: 05/05/2018
# Windows Hello for Business Frequently Ask Questions
**Applies to**
- Windows 10
- Windows 10
## What about virtual smart cards?

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

@ -15,7 +15,7 @@ ms.date: 05/05/2018
# Windows Hello for Business Features
**Applies to:**
- Windows 10
- Windows 10
Consider these additional features you can use after your organization deploys Windows Hello for Business.

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

@ -13,7 +13,7 @@ ms.date: 05/05/2018
# Windows Hello for Business and Authentication
**Applies to:**
- Windows 10
- Windows 10
Windows Hello for Business authentication is passwordless, two-factor authentication. Authenticating with Windows Hello for Business provides a convenient sign-in experience that authenticates the user to both Azure Active Directory and Active Directory resources.<br>
Azure Active Directory joined devices authenticate to Azure during sign-in and can optional authenticate to Active Directory. Hybrid Azure Active Directory joined devices authenticate to Active Directory during sign-in, and authenticate to Azure Active Directory in the background.<br>

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

@ -13,7 +13,7 @@ ms.date: 05/05/2018
# Windows Hello for Business and Device Registration
**Applies to:**
- Windows 10
- Windows 10
Device Registration is a prerequisite to Windows Hello for Business provisioning. Device registration occurs regardless of a cloud, hybrid, or on-premises deployments. For cloud and hybrid deployments, devices register with Azure Active Directory. For on-premises deployments, devices registered with the enterprise device registration service hosted by Active Directory Federation Services (AD FS).

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

@ -13,7 +13,7 @@ ms.date: 05/05/2018
# Windows Hello for Business Provisioning
**Applies to:**
- Windows 10
- Windows 10
Windows Hello for Business provisioning enables a user to enroll a new, strong, two-factor credential that they can use for passwordless authentication. Provisioning experience vary based on:
- How the device is joined to Azure Active Directory

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

@ -14,7 +14,7 @@ ms.date: 05/05/2018
# Technical Deep Dive
**Applies to:**
- Windows 10
- Windows 10
Windows Hello for Business authentication works through collection of components and infrastructure working together. You can group the infrastructure and components in three categories:
- [Registration](#Registration)

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

@ -13,7 +13,7 @@ ms.date: 05/05/2018
# Technology and Terms
**Applies to:**
- Windows 10
- Windows 10
- [Attestation Identity Keys](#Attestation-Identity-Keys)
- [Azure AD Joined](#Azure-AD-Joined)

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

@ -13,7 +13,7 @@ ms.date: 05/05/2018
# How Windows Hello for Business works
**Applies to**
- Windows 10
- Windows 10
Windows Hello for Business is a modern, two-factor credential that is the more secure alternative to passwords. Windows. Whether you are cloud or on-premises, Windows Hello for Business has a deployment option for you. For cloud deployments, you can use Windows Hello for Business with Azure Active Directory joined, Hybrid Azure Active Directory joined, or Azure Active Directory registered devices. Windows Hello for Business also works for domain joined devices.

32
windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-key.md
View File

@ -1,5 +1,5 @@
---
title: Configure Key trust Azure AD joined devices for authentication to Active Directory
title: Configure Azure AD joined devices for On-premises Single-Sign On
description: Azure Active Directory joined devices in a hybrid Deployment for on-premises single sign-on
keywords: identity, PIN, biometric, Hello, passport, AADJ, SSO,
ms.prod: w10
@ -11,7 +11,7 @@ ms.author: mstephen
localizationpriority: high
ms.date: 05/05/2018
---
# Configure Key trust Azure AD joined devices for authentication to Active Directory
# Configure Azure AD joined devices for On-premises Single-Sign On
**Applies to**
- Windows 10
@ -32,19 +32,31 @@ Certificates issued by a certificate authority can be revoked. When a certifica
![Domain Controller Certificate with LDAP CDP](images/aadj/Certificate-CDP.png)
The preceding domain controller certificate shows a CRL distribution path (CDP) using Active Directory. You can determine this because the value in the URL begins with **ldap**. Using Active Directory for domain joined devices provides a highly available CRL distribution point. However, Azure Active Directory joined devices and users on Azure Active Directory joined devices cannot read data from Active Directory, and certificate validation does not provide an opportunity to authenticate prior to reading the certificate revocation list. This becomes a circular problem as the user is attempting to authenticate, but must read Active Directory to perform the complete the authentication. However, the user cannot read Active Directory because they have not authenticated. To resolve this issue, the CRL distribution point must be a location that is accessible by Azure Active Directory joined devices that does not require authentication. The easiest solution is to publish the CRL distribution point on a web server that uses HTTP (not HTTPS).
The preceding domain controller certificate shows a CRL distribution path (CDP) using Active Directory. You can determine this because the value in the URL begins with **ldap**. Using Active Directory for domain joined devices provides a highly available CRL distribution point. However, Azure Active Directory joined devices and users on Azure Active Directory joined devices cannot read data from Active Directory, and certificate validation does not provide an opportunity to authenticate prior to reading the certificate revocation list. This becomes a circular problem as the user is attempting to authenticate, but must read Active Directory to complete the authentication, but the user cannot read Active Directory because they have not authenticated.
If your CRL distribution point does not list an HTTP distribution point, then you need to reconfigure the issuing certificate authority to include an HTTP CRL distribution point, preferably first in the list of distribution points.
To resolve this issue, the CRL distribution point must be a location that is accessible by Azure Active Directory joined devices that does not require authentication. The easiest solution is to publish the CRL distribution point on a web server that uses HTTP (not HTTPS).
If your CRL distribution point does not list an HTTP distribution point, then you need to reconfigure the issuing certificate authority to include an HTTP CRL distribution point, preferably first in the list of distribution points.
### Domain Controller Certificates
Certificate authorities write CRL distribution points in certificates as they are issued. If the distribution point changes, then previously issued certificates must be reissued for the certificate authority to include the new CRL distribution point. The domain controller certificate is one the critical components of Azure AD joined devices authenticating to Active Directory
### Why does Windows need to validate the domain controller certifcate?
Windows Hello for Business enforces the strict KDC validation security feature, which enforces a more restrictive criteria that must be met by the Key Distribution Center (KDC). When authenticating using Windows Hello for Business, the Windows 10 client validates the reply from the domain controller by ensuring all of the following are met:
- The domain controller has the private key for the certificate provided.
- The root CA that issued the domain controller's certificate is in the device's **Trusted Root Certificate Authorties**.
- The domain controller's certificate has the **KDC Authentication** enhanced key usage.
- The domain controller's certificate's subject alternate name has a DNS Name that matches the name of the domain.
## Configuring a CRL Distribution Point for an issuing certificate authority
Use this set of procedures to update your certificate authority that issues your domain controller certificates to include an http-based CRL distribution point.
Steps you will be performing include:
-[Configure Internet Information Services to host CRL distribution point](#configure-internet-information-services-to-host-crl-distribution-point)
- [Prepare a file share to host the certificate revocation list](#prepare-a-file-share-to-host-the-certificate-revocation-list)
- [Configure the new CRL distribution point in the issuing certificate authority](#Configure-the-new-crl-distribution-point-in-the-issuing-certificate-authority)
@ -130,7 +142,7 @@ These procedures configure NTFS and share permissions on the web server to allow
The web server is ready to host the CRL distribution point. Now, configure the issuing certificate authority to publish the CRL at the new location and to include the new CRL distribution point
#### Configure the CRL distrubution Point
#### Configure the CRL distribution Point
1. On the issuing certificate authority, sign-in as a local administrator. Start the **Certificate Authority** console from **Administrative Tools**.
2. In the navigation pane, right-click the name of the certificate authority and click **Properties**
3. Click **Extensions**. On the **Extensions** tab, select **CRL Distribution Point (CDP)** from the **Select extension** list.
@ -232,4 +244,12 @@ A **Trusted Certificate** device configuration profile is how you deploy trusted
![Intune Trusted Certificate Profile](images/aadj/intune-create-trusted-certificate-profile.png)
5. In the **Enterprise Root Certificate** blade, click **Assignmnets**. In the **Include** tab, select **All Devices** from the **Assign to** list. Click **Save**.
![Intune Profile assignment](images/aadj/intune-device-config-enterprise-root-assignment.png)
6. Sign out of the Microsoft Azure Portal.
6. Sign out of the Microsoft Azure Portal.
## Using Certificates for On-premises Single-sign On
If you plan to use certificates for on-premises single-sign on, then follow these **addtiional** steps to configure the environment to enroll certificates for Azure AD joined devices.
<hr>

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

@ -1,5 +1,5 @@
---
title: Azure Active Directory joined devices in a hybrid Deployment for on-premises single sign-on
title: Single-sign on using Windows Hello for Business on Azure Active Directory joined devices
description: Azure Active Directory joined devices in a hybrid Deployment for on-premises single sign-on
keywords: identity, PIN, biometric, Hello, passport, AADJ, SSO,
ms.prod: w10
@ -11,23 +11,21 @@ ms.author: mstephen
localizationpriority: high
ms.date: 05/05/2018
---
# Windows Hello for Business Frequently Ask Questions
# Single-sign on using Windows Hello for Business on Azure Active Directory joined devices
**Applies to**
- Windows 10
- Azure Active Directory joined
- Hybrid deployment
Windows Hello for Business combined with Azure Active Directory joined devices make it easy for users to securely access cloud-based resources using a strong, two-factor credential. Some resources may remain on-premises as enterprises transition resources to the cloud and Azure AD joined devices may need to access these resources. With additional configurations to your current hybrid deployment, you can provide single sign-on to your on-premises resources for Azure Active Directory joined devices using Windows Hello for Business, in either key or certificate trust models.
- Configure Key trust authentication to Active Directory for Azure AD joined devices
- Configure Certificate trust authentication to Active Directory for Azure AD joined devices
Windows Hello for Business combined with Azure Active Directory joined devices makes it easy for users to securely access cloud-based resources using a strong, two-factor credential. Some resources may remain on-premises as enterprises transition resources to the cloud and Azure AD joined devices may need to access these resources. With additional configurations to your current hybrid deployment, you can provide single sign-on to your on-premises resources for Azure Active Directory joined devices using Windows Hello for Business, using a key or a certificate.
## Key trust or Certificate trust
Enterprises can choose between key or certificate trust. The trust type determines how the device authenticates to Active Directory. Also, the trust type for your Azure Active Directory joined devices does not need to be the same as the trust type used for your hybrid Azure Active Directory joined devices. Your hybrid Azure AD joined devices can use a key-trust model while your hybrid Azure AD joined devices can use a certificate trust model, as long as the infrastructure supports both trust models.
## Key vs. Certificate
Both trust types provide the same security; one is not more secure than the other. The key trust model is simple and needs adequate distribution of Windows Server 2016 domain controllers relative to your existing authentication and the number of users included in your Windows Hello for Business deployment. Read the [Planning an adequate number of Windows Server 2016 Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) to learn more. The key trust deployment has fewer infrastructure requirements because it does not issue certificates to each user.
Enterprises can use either a key or a certificate to provide single-sign on for on-premises resources. Both types of authentication provide the same security; one is not more secure than the other.
The certificate trust model works with Windows Server 2008 R2 and later domain controllers, which removes the Windows Server 2016 domain controller requirement. However, it does require additional infrastructure as each user that provisions Windows Hello for Business receives a certificate issued by an enterprise issuing certificate authority. Azure AD joined devices enroll certificates using Microsoft Intune or a compatible Mobile Device Management (MDM). Microsoft Intune and Windows Hello for Business require the Network Device Enrollment Services (NDES) role and support Microsoft Intune connector.
When using a key, the on-premises environment needs an adequate distribution of Windows Server 2016 domain controllers relative to your existing authentication and the number of users included in your Windows Hello for Business deployment. Read the [Planning an adequate number of Windows Server 2016 Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) to learn more.
When using a certificate, the on-premises environment can use Windows Server 2008 R2 and later domain controllers, which removes the Windows Server 2016 domain controller requirement. However, single-sign on using a key require additional infrastructure to issue certificate when the user enrolls for Windows Hello for Business. Azure AD joined devices enroll certificates using Microsoft Intune or a compatible Mobile Device Management (MDM). Microsoft Intune and Windows Hello for Business use the Network Device Enrollment Services (NDES) role and support Microsoft Intune connector.

27
windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-pki.md
View File

@ -9,7 +9,7 @@ ms.pagetype: security, mobile
localizationpriority: high
author: mikestephens-MS
ms.author: mstephen
ms.date: 11/08/2017
ms.date: 05/05/2018
---
# Configure Hybrid Windows Hello for Business: Public Key Infrastructure
@ -19,13 +19,13 @@ ms.date: 11/08/2017
>This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
Windows Hello for Business deployments rely on certificates. Hybrid deployments uses publicly issued server authentication certifcates to validate the name of the server to which they are connecting and to encyrpt the data that flows them and the client computer.
Windows Hello for Business deployments rely on certificates. Hybrid deployments uses publicly issued server authentication certificates to validate the name of the server to which they are connecting and to encrypt the data that flows them and the client computer.
All deployments use enterprise issed certificates for domain controllers as a root of trust. Hybrid certificate trust deployments issue users sign-in certificate that enables them to authenticate using Windows Hello for Business credentials to non-Windows Server 2016 domain controllers. Additionally, hybrid certificate trust deployments issue certificate to registration authorites to provide defenese-in-depth security for issueing user authentication certificates.
All deployments use enterprise issued certificates for domain controllers as a root of trust. Hybrid certificate trust deployments issue users sign-in certificate that enables them to authenticate using Windows Hello for Business credentials to non-Windows Server 2016 domain controllers. Additionally, hybrid certificate trust deployments issue certificate to registration authorities to provide defense-in-depth security for issuing user authentication certificates.
## Certifcate Templates
This section has you configure certificate templates on your Windows Server 2012 or later issuing certificate authtority.
This section has you configure certificate templates on your Windows Server 2012 or later issuing certificate authority.
### Domain Controller certificate template
@ -42,7 +42,7 @@ Sign-in a certificate authority or management workstations with _Domain Admin_ e
1. Open the **Certificate Authority** management console.
2. Right-click **Certificate Templates** and click **Manage**.
3. In the **Certificate Template Console**, right-click the **Kerberos Authentication** template in the details pane and click **Duplicate Template**.
4. On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Authority** list. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Recipient** list.
4. On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2008 R2** from the **Certification Authority** list. Select **Windows 7.Server 2008 R2** from the **Certification Recipient** list.
5. On the **General** tab, type **Domain Controller Authentication (Kerberos)** in Template display name. Adjust the validity and renewal period to meet your enterprise's needs.
**Note**If you use different template names, you'll need to remember and substitute these names in different portions of the lab.
6. On the **Subject** tab, select the **Build from this Active Directory information** button if it is not already selected. Select **None** from the **Subject name format** list. Select **DNS name** from the **Include this information in alternate subject** list. Clear all other items.
@ -55,7 +55,7 @@ Many domain controllers may have an existing domain controller certificate. The
The Kerberos Authentication certificate template is the most current certificate template designated for domain controllers and should be the one you deploy to all your domain controllers (2008 or later).
The autoenrollment feature in Windows enables you to effortlessly replace these domain controller certificates. You can use the following configuration to replace older domain controller certificates with a new certificate using the Kerberos Authentication certificate template.
The auto-enrollment feature in Windows enables you to effortlessly replace these domain controller certificates. You can use the following configuration to replace older domain controller certificates with a new certificate using the Kerberos Authentication certificate template.
Sign-in a certificate authority or management workstations with _Enterprise Admin_ equivalent credentials.
@ -128,7 +128,7 @@ Sign-in a certificate authority or management workstations with _Domain Admin eq
**Note:** If you use different template names, you'll need to remember and substitute these names in different portions of the deployment.
6. On the **Cryptography** tab, select **Key Storage Provider** from the **Provider Category** list. Select **RSA** from the **Algorithm name** list. Type **2048** in the **Minimum key size** text box. Select **SHA256** from the **Request hash** list.
7. On the **Extensions** tab, verify the **Application Policies** extension includes **Smart Card Logon**.
8. On the **Issuance Requirements** tab, select the T**his number of authorized signatures** check box. Type **1** in the text box.
8. On the **Issuance Requirements** tab, select the **This number of authorized signatures** check box. Type **1** in the text box.
* Select **Application policy** from the **Policy type required in signature**. Select **Certificate Request Agent** from in the **Application policy** list. Select the **Valid existing certificate** option.
9. On the **Subject** tab, select the **Build from this Active Directory information** button if it is not already selected. Select **Fully distinguished name** from the **Subject name format** list if **Fully distinguished name** is not already selected. Select the **User Principal Name (UPN)** check box under **Include this information in alternative subject name**.
10. On the **Request Handling** tab, select the **Renew with same key** check box.
@ -151,7 +151,18 @@ Publish Templates
The certificate authority may only issue certificates for certificate templates that are published to that certificate authority. If you have more than one certificate authority and you want that certificate authority to issue certificates based on a specific certificate template, then you must publish the certificate template to all certificate authorities that are expected to issue the certificate.
### Unpublish Superseded Certificate Templates
#### Publish Certificate Templates to the Certificate Authority
Sign-in to the certificate authority or management workstations with an _Enterprise Admin_ equivalent credentials.
1. Open the **Certificate Authority** management console.
2. Expand the parent node from the navigation pane.
3. Click **Certificate Templates** in the navigation pane.
4. Right-click the **Certificate Templates** node. Click **New**, and click **Certificate Template** to issue.
5. In the **Enable Certificates Templates** window, select the **Domain Controller Authentication (Kerberos)**, **WHFB Enrollment Agent** and **WHFB Authentication** templates you created in the previous steps. Click **OK** to publish the selected certificate templates to the certificate authority.
7. Close the console.
#### Unpublish Superseded Certificate Templates
The certificate authority only issues certificates based on published certificate templates. For defense in depth security, it is a good practice to unpublish certificate templates that the certificate authority is not configured to issue. This includes the pre-published certificate template from the role installation and any superseded certificate templates.

8
windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-pki.md
View File

@ -9,7 +9,7 @@ ms.pagetype: security, mobile
localizationpriority: high
author: mikestephens-MS
ms.author: mstephen
ms.date: 10/23/2017
ms.date: 05/05/2018
---
# Configure Hybrid Windows Hello for Business: Public Key Infrastructure
@ -19,13 +19,13 @@ ms.date: 10/23/2017
>This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
Windows Hello for Business deployments rely on certificates. Hybrid deployments uses publicly issued server authentication certifcates to validate the name of the server to which they are connecting and to encyrpt the data that flows them and the client computer.
Windows Hello for Business deployments rely on certificates. Hybrid deployments uses publicly issued server authentication certificates to validate the name of the server to which they are connecting and to encrypt the data that flows them and the client computer.
All deployments use enterprise issued certificates for domain controllers as a root of trust.
## Certifcate Templates
This section has you configure certificate templates on your Windows Server 2012 or later issuing certificate authtority.
This section has you configure certificate templates on your Windows Server 2012 or later issuing certificate authority.
### Domain Controller certificate template
@ -42,7 +42,7 @@ Sign-in a certificate authority or management workstations with _Domain Admin_ e
1. Open the **Certificate Authority** management console.
2. Right-click **Certificate Templates** and click **Manage**.
3. In the **Certificate Template Console**, right-click the **Kerberos Authentication** template in the details pane and click **Duplicate Template**.
4. On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Authority** list. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Recipient** list.
4. On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2008 R2** from the **Certification Authority** list. Select **Windows 7.Server 2008 R2** from the **Certification Recipient** list.
5. On the **General** tab, type **Domain Controller Authentication (Kerberos)** in Template display name. Adjust the validity and renewal period to meet your enterprise's needs.
**Note**If you use different template names, you'll need to remember and substitute these names in different portions of the lab.
6. On the **Subject** tab, select the **Build from this Active Directory information** button if it is not already selected. Select **None** from the **Subject name format** list. Select **DNS name** from the **Include this information in alternate subject** list. Clear all other items.

4
windows/security/identity-protection/hello-for-business/hello-key-trust-validate-pki.md
View File

@ -9,7 +9,7 @@ ms.pagetype: security, mobile
author: mikestephens-MS
ms.author: mstephen
localizationpriority: high
ms.date: 10/10/2017
ms.date: 05/05/2018
---
# Validate and Configure Public Key Infrastructure
@ -60,7 +60,7 @@ Sign-in to a certificate authority or management workstations with _Domain Admin
1. Open the **Certificate Authority** management console.
2. Right-click **Certificate Templates** and click **Manage**.
3. In the **Certificate Template Console**, right-click the **Kerberos Authentication** template in the details pane and click **Duplicate Template**.
4. On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Authority** list. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Recipient** list.
4. On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2008 R2** from the **Certification Authority** list. Select **Windows 7.Server 2008 R2** from the **Certification Recipient** list.
5. On the **General** tab, type **Domain Controller Authentication (Kerberos)** in Template display name. Adjust the validity and renewal period to meet your enterprise’s needs.
**Note**If you use different template names, you’ll need to remember and substitute these names in different portions of the lab.
6. On the **Subject** tab, select the **Build from this Active Directory information** button if it is not already selected. Select **None** from the **Subject name format** list. Select **DNS name** from the **Include this information in alternate subject** list. Clear all other items.

18
windows/security/identity-protection/hello-for-business/hello-planning-guide.md
View File

@ -9,7 +9,7 @@ ms.pagetype: security, mobile
author: mikestephens-MS
ms.author: mstephen
localizationpriority: high
ms.date: 03/26/2018
ms.date: 05/05/2018
---
# Planning a Windows Hello for Business Deployment
@ -85,9 +85,9 @@ The in-box Windows Hello for Business provisioning experience creates a hardware
#### Multifactor authentication
The goal of Windows Hello for Business is to move organizations away from passwords by providing them a strong credential that provides easy two-factor authentication. The inbox provisioning experience accepts the user’s weak credentials (username and password) as the first factor authentication; however, the user must provide a second factor of authentication before Windows provisions a strong credential.
The goal of Windows Hello for Business is to move organizations away from passwords by providing them a strong credential that provides easy two-factor authentication. The in-box provisioning experience accepts the user’s weak credentials (username and password) as the first factor authentication; however, the user must provide a second factor of authentication before Windows provisions a strong credential.
Cloud only and hybrid deployments provide many choices for multifactor authentication. On-premises deployments must use a multifactor authentication that provides an AD FS multifactor adapter to be used in conjunction with the on-premises Windows Server 2016 AD FS server role. Organizations can use the on-premises Azure Multifactor Authentication server, or choose from several third parties (Read [Microsoft and third-party additional authentication methods](https://docs.microsoft.com/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs#microsoft-and-third-party-additional-authentication-methods) for more information).
Cloud only and hybrid deployments provide many choices for multi-factor authentication. On-premises deployments must use a multi-factor authentication that provides an AD FS multi-factor adapter to be used in conjunction with the on-premises Windows Server 2016 AD FS server role. Organizations can use the on-premises Azure Multi-factor Authentication server, or choose from several third parties (Read [Microsoft and third-party additional authentication methods](https://docs.microsoft.com/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs#microsoft-and-third-party-additional-authentication-methods) for more information).
>[!NOTE]
> Azure Multi-Factor Authentication is available through:
>* Microsoft Enterprise Agreement
@ -163,7 +163,7 @@ Choose a trust type that is best suited for your organizations. Remember, the t
One trust model is not more secure than the other. The major difference is based on the organization comfort with deploying Windows Server 2016 domain controllers and not enrolling users with end entity certificates (key-trust) against using existing domain controllers (Windows Server 2008R2 or later) and needing to enroll certificates for all their users (certificate trust).
Because the certificate trust types issues certificates, there is more configuration and infrastructure needed to accomodate user certificate enrollment, which could also be a factor to consider in your decision. Additional infrastructure needed for certificate-trust deployements includes a certificate registration authority. Hybrid Azure AD joined devices managed by Group Policy need the Windows Server 2016 AD FS role to issue certificates. Hybrid Azure AD joined devices and Azure AD joined devices managed by Intune or a compatible MDM need the Windows Server NDES server role to issue certificates.
Because the certificate trust types issues certificates, there is more configuration and infrastructure needed to accommodate user certificate enrollment, which could also be a factor to consider in your decision. Additional infrastructure needed for certificate-trust deployments includes a certificate registration authority. Hybrid Azure AD joined devices managed by Group Policy need the Windows Server 2016 AD FS role to issue certificates. Hybrid Azure AD joined devices and Azure AD joined devices managed by Intune or a compatible MDM need the Windows Server NDES server role to issue certificates.
If your organization wants to use the key trust type, write **key trust** in box **1b** on your planning worksheet. Write **Windows Server 2016** in box **4d**. Write **N/A** in box **5b**.
@ -187,17 +187,17 @@ If box **1a** on your planning worksheet reads **on-premises**, write **AD FS**
### Directory Synchronization
Windows Hello for Business is strong user authentication, which usually means there is an identity (a user or username) and a credential (typically a key pair). Some operations require writing or reading user data to or from the directory. For example, reading the user’s phone number to perform multifactor authentication during provisioning or writing the user’s public key.
Windows Hello for Business is strong user authentication, which usually means there is an identity (a user or username) and a credential (typically a key pair). Some operations require writing or reading user data to or from the directory. For example, reading the user’s phone number to perform multi-factor authentication during provisioning or writing the user’s public key.
If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **1e**. User information is written directly to Azure Active Directory and there is not another directory with which the information must be synchronized.
If box **1a** on your planning worksheet reads **hybrid**, then write **Azure AD Connect** in box **1e** on your planning worksheet.
If box **1a** on your planning worksheet reads **on-premises**, then write **Azure MFA Server**. This deployment exclusively uses Active Directory for user information with the exception of the multifactor authentication. The on-premises Azure MFA server synchronizes a subset of the user information, such as phone number, to provide multifactor authentication while the user’s credential remain on the on-premises network.
If box **1a** on your planning worksheet reads **on-premises**, then write **Azure MFA Server**. This deployment exclusively uses Active Directory for user information with the exception of the multi-factor authentication. The on-premises Azure MFA server synchronizes a subset of the user information, such as phone number, to provide multi-factor authentication while the user’s credential remain on the on-premises network.
### Multifactor Authentication
The goal of Windows Hello for Business is to move user authentication away from passwords to a strong, key-based user authentication. Passwords are weak credentials and cannot be trusted by themselves as an attacker with a stolen password could be attempting to enroll in Windows Hello for Business. To keep the transition from a weak to a strong credential secure, Windows Hello for Business relies on multifactor authentication during provisioning to have some assurances that the user identity provisioning a Windows Hello for Business credential is the proper identity.
The goal of Windows Hello for Business is to move user authentication away from passwords to a strong, key-based user authentication. Passwords are weak credentials and cannot be trusted by themselves as an attacker with a stolen password could be attempting to enroll in Windows Hello for Business. To keep the transition from a weak to a strong credential secure, Windows Hello for Business relies on multi-factor authentication during provisioning to have some assurances that the user identity provisioning a Windows Hello for Business credential is the proper identity.
If box **1a** on your planning worksheet reads **cloud only**, then your only option is to use the Azure MFA cloud service. Write **Azure MFA** in box **1f** on your planning worksheet.
@ -311,9 +311,9 @@ Windows Hello for Business does not require an Azure AD premium subscription. H
If box **1a** on your planning worksheet reads **on-premises**, write **No** in box **6c** on your planning worksheet.
If box **1a** on your planning worksheet reads **hybrid** and box **1b** reads **key trust**, write **No** in box **6c** on your planning worksheet. You can deploy Windows Hello for Business using the free Azure Active Directory account (additional costs needed for multifactor authentication).
If box **1a** on your planning worksheet reads **hybrid** and box **1b** reads **key trust**, write **No** in box **6c** on your planning worksheet. You can deploy Windows Hello for Business using the free Azure Active Directory account (additional costs needed for multi-factor authentication).
If box **5b** on your planning worksheet reads **AD FS RA**, write **Yes** in box **6c** on your planning worksheet. Enrolling a certificate using the AD FS registration authority requires devices to authenticate to the AD FS server, which requires device writeback—an Azure AD Premium feature.
If box **5b** on your planning worksheet reads **AD FS RA**, write **Yes** in box **6c** on your planning worksheet. Enrolling a certificate using the AD FS registration authority requires devices to authenticate to the AD FS server, which requires device write-back, an Azure AD Premium feature.
Modern managed devices do not require an Azure AD premium subscription. By forgoing the subscription, your users must manually enroll devices in the modern management software, such as Intune or a supported third-party MDM.

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

@ -14,7 +14,7 @@ ms.date: 05/05/2018
# Windows Hello for Business Videos
**Applies to**
- Windows 10
- Windows 10
## Overview of Windows Hello for Business and Features