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

Hybrid key trust

Browse Source 
On-Prem key trust
Deployment Guide landing page
TOC update
minor types and fixes in existing content
This commit is contained in:
Mike Stephens
2017-10-20 18:47:59 -07:00
parent 4997d16632
commit 44916875e1
19 changed files with 230 additions and 841 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
windows/access-protection/hello-for-business/hello-adequate-domain-controllers.md
View File

@ -9,7 +9,7 @@ ms.pagetype: security, mobile
author: mikestephens-MS
ms.author: mstephen
localizationpriority: high
ms.date: 10/09/2017
ms.date: 10/20/2017
---
# Planning an adequate number of Windows Server 2016 Domain Controllers for Windows Hello for Business deployments

10
windows/access-protection/hello-for-business/hello-deployment-guide.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/08/2017
author: mikestephens-MS
ms.author: mstephen
localizationpriority: high
ms.date: 10/20/2017
---
# Windows Hello for Business Deployment Guide
@ -47,7 +47,9 @@ Hybrid deployments are for enterprises that use Azure Active Directory. On-prem
The trust model determines how you want users to authentication to the on-premises Active Directory. Remember hybrid environments use Azure Active Directory and on-premises Active Directory. The key-trust model is for enterprises who do not want to issue end-entity certificates to their users and they have an adequate number of 2016 domain controllers in each site to support the authentication. The certificate-trust model is for enterprise that do want to issue end-entity certificates to their users and have the benefits of certificate expiration and renewal, similar to how smart cards work today. The certificate trust model is also enterprise who are not ready to deploy Windows Server 2016 domain controllers.
Following are the various deployment guides included in this topic:
* [Hybrid Key Trust Deployment](hello-hybrid-key-trust.md)
* [Hybrid Certificate Trust Deployment](hello-hybrid-cert-trust.md)
* [On Premises Key Trust Deployment](hello-deployment-key-trust.md)
* [On Premises Certificate Trust Deployment](hello-deployment-cert-trust.md)

3
windows/access-protection/hello-for-business/hello-hybrid-cert-new-install.md
View File

@ -9,7 +9,7 @@ ms.pagetype: security, mobile
author: mikestephens-MS
ms.author: mstephen
localizationpriority: high
ms.date: 09/08/2017
ms.date: 10/20/2017
---
# Windows Hello for Business Certificate Trust New Installation
@ -23,7 +23,6 @@ Windows Hello for Business involves configuring distributed technologies that ma
* [Active Directory](#active-directory)
* [Public Key Infrastructure](#public-key-infrastructure)
* [Azure Active Directory](#azure-active-directory)
* [Directory Synchronization](#directory-synchronization)
* [Active Directory Federation Services](#active-directory-federation-services)

8
windows/access-protection/hello-for-business/hello-hybrid-cert-whfb-provision.md
View File

@ -9,7 +9,7 @@ ms.pagetype: security, mobile
author: mikestephens-MS
ms.author: mstephen
localizationpriority: high
ms.date: 09/08/2017
ms.date: 10/20/2017
---
# Hybrid Windows Hello for Business Provisioning
@ -24,9 +24,7 @@ The Windows Hello for Business provisioning begins immediately after the user ha
![Event358](images/Event358.png)
The first thing to validate is the computer has processed device registration. You can view this from the User device registration logs where the check **Device is AAD joined (AADJ or DJ++): Yes** appears. Additionally, you can validate this using the **dsregcmd /status** command from a console prompt where the value for **EnterpriseJoined** reads **Yes**.
![dsreg output](images/dsregcmd.png)
The first thing to validate is the computer has processed device registration. You can view this from the User device registration logs where the check **Device is AAD joined (AADJ or DJ++): Yes** appears. Additionally, you can validate this using the **dsregcmd /status** command from a console prompt where the value for **AzureADJoined** reads **Yes**.
Windows Hello for Business provisioning begins with a full screen page with the title **Setup a PIN** and button with the same name. The user clicks **Setup a PIN**.
@ -39,7 +37,7 @@ The provisioning flow proceeds to the Multi-Factor authentication portion of the
After a successful MFA, the provisioning flow asks the user to create and validate a PIN. This PIN must observe any PIN complexity requirements that you deployed to the environment.
<createaPin.png>
![Create a PIN during provisioning](images/createPin.png)
The provisioning flow has all the information it needs to complete the Windows Hello for Business enrollment.
* A successful single factor authentication (username and password at sign-in)

34
windows/access-protection/hello-for-business/hello-hybrid-key-new-install.md
View File

@ -9,7 +9,7 @@ ms.pagetype: security, mobile
author: mikestephens-MS
ms.author: mstephen
localizationpriority: high
ms.date: 10/09/2017
ms.date: 10/20/2017
---
# Windows Hello for Business Key Trust New Installation
@ -23,23 +23,22 @@ Windows Hello for Business involves configuring distributed technologies that ma
* [Active Directory](#active-directory)
* [Public Key Infrastructure](#public-key-infrastructure)
* [Azure Active Directory](#azure-active-directory)
* [Directory Synchronization](#directory-synchronization)
* [Active Directory Federation Services](#active-directory-federation-services)
New installations are considerably more involved than existing implementations because you are building the entire infrastructure. Microsoft recommends you review the new installation baseline to validate your exsting envrionment has all the needed configurations to support your hybrid certificate trust Windows Hello for Business deployment. If your environment meets these needs, you can read the [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md) section to prepare your Windows Hello for Business deployment by configuring Azure device registration.
New installations are considerably more involved than existing implementations because you are building the entire infrastructure. Microsoft recommends you review the new installation baseline to validate your exsting envrionment has all the needed configurations to support your hybrid certificate trust Windows Hello for Business deployment. If your environment meets these needs, you can read the [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md) section to prepare your Windows Hello for Business deployment by configuring directory synchronization.
The new installation baseline begins with a basic Active Directory deployment and enterprise PKI. This document expects you have Active Directory deployed with an adeqate number of Windows Server 2016 domain controllers for each site.
The new installation baseline begins with a basic Active Directory deployment and enterprise PKI.
## Active Directory ##
Production environments should follow Active Directory best practices regarding the number and placement of domain controllers to ensure adequate authentication throughout the organization.
This document expects you have Active Directory deployed with an _adequate_ number of Windows Server 2016 domain controllers for each site. 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.
Lab environments and isolated proof of concepts may want to limit the number of domain controllers. The purpose of these environments is to experiment and learn. Reducing the number of domain controllers can prevent troubleshooting issue, such as Active Directory replication, which is unrelated to activity's goal.
### Section Review
> [!div class="checklist"]
> * An adequate number of Windows Server 2016 R2 domain controllers
> * An adequate number of Windows Server 2016 domain controllers
> * Minimum Windows Server 2008 R2 domain and forest functional level
> * Functional networking, name resolution, and Active Directory replication
@ -73,12 +72,19 @@ Sign-in using _Enterprise Admin_ equivalent credentials on Windows Server 2012 o
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.
> [!IMPORTANT]
> For Azure AD joined device to authenticate to and use on-premises resources, ensure you:
> * Install the root certificate authority certificate for your organization in the user's trusted root certifcate store.
> * Publish your certificate revocation list to a location that is available to Azure AD joined devices, such as a web-based url.
### Section Review ###
> [!div class="checklist"]
> * Miniumum Windows Server 2012 Certificate Authority.
> * Enterprise Certificate Authority.
> * Functioning public key infrastructure.
> * Root certifcate authority certificate (Azure AD Joined devices).
> * Highly availalbe certificate revoication list (Azure AD Joined devices).
## Azure Active Directory ##
You’ve prepared your Active Directory. Hybrid Windows Hello for Business deployment needs Azure Active Directory to host your cloud-based identities.
@ -93,7 +99,7 @@ The next step of the deployment is to follow the [Creating an Azure AD tenant](h
> * Purchase the appropriate Azure Active Directory subscription or licenses, if necessary.
## Multifactor Authentication Services ##
Windows Hello for Business uses multifactor authentication during provisioning and during user initiated PIN reset scenarios, such as when a user forgets their PIN. There are two preferred multifactor authentication configurations with hybrid deployments—Azure MFA and AD FS using Azure MFA
Windows Hello for Business uses multifactor authentication during provisioning and during user initiated PIN reset scenarios, such as when a user forgets their PIN. There are two preferred multifactor authentication configurations with hybrid deployments—Azure MFA and AD FS using Azure MFA or a third-party MFA adapter
Review the [What is Azure Multi-Factor Authentication](https://docs.microsoft.com/en-us/azure/multi-factor-authentication/multi-factor-authentication) topic to familiarize yourself its purpose and how it works.
@ -136,9 +142,11 @@ Alternatively, you can configure Windows Server 2016 Active Directory Federation
<hr>
## Follow the Windows Hello for Business hybrid key trust deployment guide
1. [Overview](hello-hybrid-key-trust.md)
2. [Prerequistes](hello-hybrid-key-trust-prereqs.md)
1. [Overview](hello-hybrid-cert-trust.md)
2. [Prerequistes](hello-hybrid-cert-trust-prereqs.md)
3. New Installation Baseline (*You are here*)
4. [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md)
5. [Configure Windows Hello for Business settings](hello-hybrid-key-whfb-settings.md)
6. [Sign-in and Provision](hello-hybrid-key-whfb-provision.md)
4. [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md)
5. [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md)
6. [Configure Windows Hello for Business settings](hello-hybrid-key-whfb-settings.md)
7. [Sign-in and Provision](hello-hybrid-key-whfb-provision.md)

453
windows/access-protection/hello-for-business/hello-hybrid-key-trust-devreg.md
View File

@ -1,5 +1,5 @@
---
title: Configure Device Registration for Hybrid Windows Hello for Business
title: Configure Device Registration for Hybrid key trust Windows Hello for Business
description: Azure Device Registration for Hybrid Certificate Key Deployment (Windows Hello for Business)
keywords: identity, PIN, biometric, Hello, passport, WHFB, hybrid, key-trust, device, registration
ms.prod: w10
@ -9,25 +9,17 @@ ms.pagetype: security, mobile
author: mikestephens-MS
ms.author: mstephen
localizationpriority: high
ms.date: 10/09/2017
ms.date: 10/20/2017
---
# Configure Device Registration for Hybrid Windows Hello for Business
# Configure Device Registration for Hybrid key trust Windows Hello for Business
**Applies to**
- Windows 10
>[!IMPORTANT]
>This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
You're environment is federated and you are ready to configure device registration for your hybrid environment. Hybrid Windows Hello for Business deployment needs device registration to enable proper device authentication.
> [!IMPORTANT]
> If your environment is not federated, review the [New Installation baseline](hello-hybrid-cert-new-install.md) section of this deployment document to learn how to federate your environment for your Windows Hello for Business deployment.
Use this three phased approach for configuring device registration.
1. [Configure devices to register in Azure](#configure-azure-for-device-registration)
2. [Synchronize devices to on-premises Active Directory](#configure-active-directory-to-support-azure-device-syncrhonization)
3. [Configure AD FS to use cloud devices](#configure-ad-fs-to-use-azure-registered-devices)
You are ready to configure device registration for your hybrid environment. Hybrid Windows Hello for Business deployment needs device registration to enable proper device authentication.
> [!NOTE]
> Before proceeding, you should familiarize yourself with device regisration concepts such as:
@ -42,441 +34,18 @@ Begin configuring device registration to support Hybrid Windows Hello for Busine
To do this, follow the **Configure device settings** steps under [Setting up Azure AD Join in your organization](https://azure.microsoft.com/en-us/documentation/articles/active-directory-azureadjoin-setup/)
## Configure Active Directory to support Azure device syncrhonization
Next, follow the guidance on the [How to configure hybrid Azure Active Directory joined devices](https://docs.microsoft.com/en-us/azure/active-directory/device-management-hybrid-azuread-joined-devices-setup) page. In the **Configuration steps** section, identify you configuration at the top of the table (either **Windows current and password hash sync** or **Windows current and federation**) and perform only the steps identified with a checkmark.
Azure Active Directory is now configured for device registration. Next, you need to configure the on-premises Active Directory to support synchronizing hybrid Azure AD joined devices. Begin with upgrading the Active Directory Schema
### Setup Active Directory Federation Services
If you are new to AD FS and federation services, you should review [Understanding Key AD FS Concepts](https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/understanding-key-ad-fs-concepts) to prior to designing and deploying your federation service.
Review the [AD FS Design guide](https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/design/ad-fs-design-guide-in-windows-server-2012-r2) to plan your federation service.
Once you have your AD FS design ready, review [Deploying a Federation Server farm](https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/deploying-a-federation-server-farm) to configure AD FS in your environment.
> [!IMPORTANT]
> During your AD FS deployment, skip the **Configure a federation server with Device Registration Service** and the **Configure Corporate DNS for the Federation Service and DRS** procedures.
#### ADFS Web Proxy ###
Federation server proxies are computers that run AD FS software that have been configured manually to act in the proxy role. You can use federation server proxies in your organization to provide intermediary services between an Internet client and a federation server that is behind a firewall on your corporate network.
Use the [Setting of a Federation Proxy](https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/checklist--setting-up-a-federation-server-proxy) checklist to configure AD FS proxy servers in your environment.
### Deploy Azure AD Connect
Next, you need to synchronizes the on-premises Active Directory with Azure Active Directory. To do this, first review the [Integrating on-prem directories with Azure Active Directory](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect) and [hardware and prerequisites](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-prerequisites) needed and then [download the software](http://go.microsoft.com/fwlink/?LinkId=615771).
When you are ready to install, follow the **Configuring federation with AD FS** section of [Custom installation of Azure AD Connect](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-get-started-custom). Select the **Federation with AD FS** option on the **User sign-in** page. At the **AD FS Farm** page, select the use an existing option and click **Next**.
### Create AD objects for AD FS Device Authentication
If your AD FS farm is not already configured for Device Authentication (you can see this in the AD FS Management console under Service -> Device Registration), use the following steps to create the correct AD DS objects and configuration.
![Device Registration](images/hybridct/device1.png)
> [!NOTE]
> The below commands require Active Directory administration tools, so if your federation server is not also a domain controller, first install the tools using step 1 below. Otherwise you can skip step 1.
1. Run the **Add Roles & Features** wizard and select feature **Remote Server Administration Tools** -> **Role Administration Tools** -> **AD DS and AD LDS Tools** -> Choose both the **Active Directory module for Windows PowerShell** and the **AD DS Tools**.
![Device Registration](images/hybridct/device2.png)
2. On your AD FS primary server, ensure you are logged in as AD DS user with Enterprise Admin (EA ) privileges and open an elevated Windows PowerShell prompt. Then, run the following commands:
`Import-module activedirectory`
`PS C:\> Initialize-ADDeviceRegistration -ServiceAccountName "<your service account>" `
3. On the pop-up window click **Yes**.
> [!NOTE]
> If your AD FS service is configured to use a GMSA account, enter the account name in the format "domain\accountname$"
![Device Registration](images/hybridct/device3.png)
The above PSH creates the following objects:
- RegisteredDevices container under the AD domain partition
- Device Registration Service container and object under Configuration --> Services --> Device Registration Configuration
- Device Registration Service DKM container and object under Configuration --> Services --> Device Registration Configuration
![Device Registration](images/hybridct/device4.png)
4. Once this is done, you will see a successful completion message.
![Device Registration](images/hybridct/device5.png)
### Create Service Connection Point (SCP) in Active Directory
If you plan to use Windows 10 domain join (with automatic registration to Azure AD) as described here, execute the following commands to create a service connection point in AD DS
1. Open Windows PowerShell and execute the following:
`PS C:>Import-Module -Name "C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1" `
> [!NOTE]
> If necessary, copy the AdSyncPrep.psm1 file from your Azure AD Connect server. This file is located in Program Files\Microsoft Azure Active Directory Connect\AdPrep
![Device Registration](images/hybridct/device6.png)
2. Provide your Azure AD global administrator credentials
`PS C:>$aadAdminCred = Get-Credential`
![Device Registration](images/hybridct/device7.png)
3. Run the following PowerShell command
`PS C:>Initialize-ADSyncDomainJoinedComputerSync -AdConnectorAccount [AD connector account name] -AzureADCredentials $aadAdminCred `
Where the [AD connector account name] is the name of the account you configured in Azure AD Connect when adding your on-premises AD DS directory.
The above commands enable Windows 10 clients to find the correct Azure AD domain to join by creating the serviceConnectionpoint object in AD DS.
### Prepare AD for Device Write Back
To ensure AD DS objects and containers are in the correct state for write back of devices from Azure AD, do the following.
1. Open Windows PowerShell and execute the following:
`PS C:>Initialize-ADSyncDeviceWriteBack -DomainName <AD DS domain name> -AdConnectorAccount [AD connector account name] `
Where the [AD connector account name] is the name of the account you configured in Azure AD Connect when adding your on-premises AD DS directory in domain\accountname format
The above command creates the following objects for device write back to AD DS, if they do not exist already, and allows access to the specified AD connector account name
- RegisteredDevices container in the AD domain partition
- Device Registration Service container and object under Configuration --> Services --> Device Registration Configuration
### Enable Device Write Back in Azure AD Connect
If you have not done so before, enable device write back in Azure AD Connect by running the wizard a second time and selecting **"Customize Synchronization Options"**, then checking the box for device write back and selecting the forest in which you have run the above cmdlets
## Configure AD FS to use Azure registered devices
### Configure issuance of claims
In a federated Azure AD configuration, devices rely on Active Directory Federation Services (AD FS) or a 3rd party on-premises federation service to authenticate to Azure AD. Devices authenticate to get an access token to register against the Azure Active Directory Device Registration Service (Azure DRS).
Windows current devices authenticate using Integrated Windows Authentication to an active WS-Trust endpoint (either 1.3 or 2005 versions) hosted by the on-premises federation service.
> [!NOTE]
> When using AD FS, either **adfs/services/trust/13/windowstransport** or **adfs/services/trust/2005/windowstransport** must be enabled. If you are using the Web Authentication Proxy, also ensure that this endpoint is published through the proxy. You can see what end-points are enabled through the AD FS management console under **Service > Endpoints**.
>
> If you don't have AD FS as your on-premises federation service, follow the instructions of your vendor to make sure they support WS-Trust 1.3 or 2005 end-points and that these are published through the Metadata Exchange file (MEX).
The following claims must exist in the token received by Azure DRS for device registration to complete. Azure DRS will create a device object in Azure AD with some of this information which is then used by Azure AD Connect to associate the newly created device object with the computer account on-premises.
* `http://schemas.microsoft.com/ws/2012/01/accounttype`
* `http://schemas.microsoft.com/identity/claims/onpremobjectguid`
* `http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid`
If you have more than one verified domain name, you need to provide the following claim for computers:
* `http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid`
If you are already issuing an ImmutableID claim (e.g., alternate login ID) you need to provide one corresponding claim for computers:
* `http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID`
In the following sections, you find information about:
- The values each claim should have
- How a definition would look like in AD FS
The definition helps you to verify whether the values are present or if you need to create them.
> [!NOTE]
> If you don't use AD FS for your on-premises federation server, follow your vendor's instructions to create the appropriate configuration to issue these claims.
#### Issue account type claim
**`http://schemas.microsoft.com/ws/2012/01/accounttype`** - This claim must contain a value of **DJ**, which identifies the device as a domain-joined computer. In AD FS, you can add an issuance transform rule that looks like this:
@RuleName = "Issue account type for domain-joined computers"
c:[
Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
Value =~ "-515$",
Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(
Type = "http://schemas.microsoft.com/ws/2012/01/accounttype",
Value = "DJ"
);
#### Issue objectGUID of the computer account on-premises
**`http://schemas.microsoft.com/identity/claims/onpremobjectguid`** - This claim must contain the **objectGUID** value of the on-premises computer account. In AD FS, you can add an issuance transform rule that looks like this:
@RuleName = "Issue object GUID for domain-joined computers"
c1:[
Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
Value =~ "-515$",
Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
&&
c2:[
Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname",
Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(
store = "Active Directory",
types = ("http://schemas.microsoft.com/identity/claims/onpremobjectguid"),
query = ";objectguid;{0}",
param = c2.Value
);
#### Issue objectSID of the computer account on-premises
**`http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid`** - This claim must contain the the **objectSid** value of the on-premises computer account. In AD FS, you can add an issuance transform rule that looks like this:
@RuleName = "Issue objectSID for domain-joined computers"
c1:[
Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
Value =~ "-515$",
Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
&&
c2:[
Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid",
Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(claim = c2);
#### Issue issuerID for computer when multiple verified domain names in Azure AD
**`http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid`** - This claim must contain the Uniform Resource Identifier (URI) of any of the verified domain names that connect with the on-premises federation service (AD FS or 3rd party) issuing the token. In AD FS, you can add issuance transform rules that look like the ones below in that specific order after the ones above. Please note that one rule to explicitly issue the rule for users is necessary. In the rules below, a first rule identifying user vs. computer authentication is added.
@RuleName = "Issue account type with the value User when its not a computer"
NOT EXISTS(
[
Type == "http://schemas.microsoft.com/ws/2012/01/accounttype",
Value == "DJ"
]
)
=> add(
Type = "http://schemas.microsoft.com/ws/2012/01/accounttype",
Value = "User"
);
@RuleName = "Capture UPN when AccountType is User and issue the IssuerID"
c1:[
Type == "http://schemas.xmlsoap.org/claims/UPN"
]
&&
c2:[
Type == "http://schemas.microsoft.com/ws/2012/01/accounttype",
Value == "User"
]
=> issue(
Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid",
Value = regexreplace(
c1.Value,
".+@(?<domain>.+)",
"http://${domain}/adfs/services/trust/"
)
);
@RuleName = "Issue issuerID for domain-joined computers"
c:[
Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
Value =~ "-515$",
Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(
Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid",
Value = "http://<verified-domain-name>/adfs/services/trust/"
);
In the claim above,
- `$<domain>` is the AD FS service URL
- `<verified-domain-name>` is a placeholder you need to replace with one of your verified domain names in Azure AD
For more details about verified domain names, see [Add a custom domain name to Azure Active Directory](https://docs.microsoft.com/en-us/azure/active-directory/active-directory-add-domain).
To get a list of your verified company domains, you can use the [Get-MsolDomain](https://docs.microsoft.com/en-us/powershell/module/msonline/get-msoldomain?view=azureadps-1.0) cmdlet.
#### Issue ImmutableID for computer when one for users exist (e.g. alternate login ID is set)
**`http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID`** - This claim must contain a valid value for computers. In AD FS, you can create an issuance transform rule as follows:
@RuleName = "Issue ImmutableID for computers"
c1:[
Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
Value =~ "-515$",
Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
&&
c2:[
Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname",
Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(
store = "Active Directory",
types = ("http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"),
query = ";objectguid;{0}",
param = c2.Value
);
#### Helper script to create the AD FS issuance transform rules
The following script helps you with the creation of the issuance transform rules described above.
$multipleVerifiedDomainNames = $false
$immutableIDAlreadyIssuedforUsers = $false
$oneOfVerifiedDomainNames = 'example.com' # Replace example.com with one of your verified domains
$rule1 = '@RuleName = "Issue account type for domain-joined computers"
c:[
Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
Value =~ "-515$",
Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(
Type = "http://schemas.microsoft.com/ws/2012/01/accounttype",
Value = "DJ"
);'
$rule2 = '@RuleName = "Issue object GUID for domain-joined computers"
c1:[
Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
Value =~ "-515$",
Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
&&
c2:[
Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname",
Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(
store = "Active Directory",
types = ("http://schemas.microsoft.com/identity/claims/onpremobjectguid"),
query = ";objectguid;{0}",
param = c2.Value
);'
$rule3 = '@RuleName = "Issue objectSID for domain-joined computers"
c1:[
Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
Value =~ "-515$",
Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
&&
c2:[
Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid",
Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(claim = c2);'
$rule4 = ''
if ($multipleVerifiedDomainNames -eq $true) {
$rule4 = '@RuleName = "Issue account type with the value User when it is not a computer"
NOT EXISTS(
[
Type == "http://schemas.microsoft.com/ws/2012/01/accounttype",
Value == "DJ"
]
)
=> add(
Type = "http://schemas.microsoft.com/ws/2012/01/accounttype",
Value = "User"
);
@RuleName = "Capture UPN when AccountType is User and issue the IssuerID"
c1:[
Type == "http://schemas.xmlsoap.org/claims/UPN"
]
&&
c2:[
Type == "http://schemas.microsoft.com/ws/2012/01/accounttype",
Value == "User"
]
=> issue(
Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid",
Value = regexreplace(
c1.Value,
".+@(?<domain>.+)",
"http://${domain}/adfs/services/trust/"
)
);
@RuleName = "Issue issuerID for domain-joined computers"
c:[
Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
Value =~ "-515$",
Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(
Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid",
Value = "http://' + $oneOfVerifiedDomainNames + '/adfs/services/trust/"
);'
}
$rule5 = ''
if ($immutableIDAlreadyIssuedforUsers -eq $true) {
$rule5 = '@RuleName = "Issue ImmutableID for computers"
c1:[
Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
Value =~ "-515$",
Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
&&
c2:[
Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname",
Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(
store = "Active Directory",
types = ("http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"),
query = ";objectguid;{0}",
param = c2.Value
);'
}
$existingRules = (Get-ADFSRelyingPartyTrust -Identifier urn:federation:MicrosoftOnline).IssuanceTransformRules
$updatedRules = $existingRules + $rule1 + $rule2 + $rule3 + $rule4 + $rule5
$crSet = New-ADFSClaimRuleSet -ClaimRule $updatedRules
Set-AdfsRelyingPartyTrust -TargetIdentifier urn:federation:MicrosoftOnline -IssuanceTransformRules $crSet.ClaimRulesString
#### Remarks
- This script appends the rules to the existing rules. Do not run the script twice because the set of rules would be added twice. Make sure that no corresponding rules exist for these claims (under the corresponding conditions) before running the script again.
- If you have multiple verified domain names (as shown in the Azure AD portal or via the Get-MsolDomains cmdlet), set the value of **$multipleVerifiedDomainNames** in the script to **$true**. Also make sure that you remove any existing issuerid claim that might have been created by Azure AD Connect or via other means. Here is an example for this rule:
c:[Type == "http://schemas.xmlsoap.org/claims/UPN"]
=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value = regexreplace(c.Value, ".+@(?<domain>.+)", "http://${domain}/adfs/services/trust/"));
- If you have already issued an **ImmutableID** claim for user accounts, set the value of **$immutableIDAlreadyIssuedforUsers** in the script to **$true**.
#### Configure Device Authentication in AD FS
Using an elevated PowerShell command window, configure AD FS policy by executing the following command
`PS C:>Set-AdfsGlobalAuthenticationPolicy -DeviceAuthenticationEnabled $true -DeviceAuthenticationMethod All`
#### Check your configuration
For your reference, below is a comprehensive list of the AD DS devices, containers and permissions required for device write-back and authentication to work
- object of type ms-DS-DeviceContainer at CN=RegisteredDevices,DC=&lt;domain&gt;
- read access to the AD FS service account
- read/write access to the Azure AD Connect sync AD connector account
- Container CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=&lt;domain&gt;
- Container Device Registration Service DKM under the above container
![Device Registration](images/hybridct/device8.png)
- object of type serviceConnectionpoint at CN=&lt;guid&gt;, CN=Device Registration
- Configuration,CN=Services,CN=Configuration,DC=&lt;domain&gt;
- read/write access to the specified AD connector account name on the new object
- object of type msDS-DeviceRegistrationServiceContainer at CN=Device Registration Services,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=&lt;domain&gt;
- object of type msDS-DeviceRegistrationService in the above container
>[!div class="nextstepaction"]
[Configure Windows Hello for Business settings](hello-hybrid-cert-whfb-settings.md)
<br><br>
<hr>
## Follow the Windows Hello for Business hybrid certificate trust deployment guide
## Follow the Windows Hello for Business hybrid key trust deployment guide
1. [Overview](hello-hybrid-cert-trust.md)
2. [Prerequistes](hello-hybrid-cert-trust-prereqs.md)
3. [New Installation Baseline](hello-hybrid-cert-new-install.md)
4. Configure Azure Device Registration (*You are here*)
5. [Configure Windows Hello for Business settings](hello-hybrid-cert-whfb-settings.md)
6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md)
4. [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md)
5. Configure Azure Device Registration (*You are here*)
6. [Configure Windows Hello for Business settings](hello-hybrid-key-whfb-settings.md)
7. [Sign-in and Provision](hello-hybrid-key-whfb-provision.md)

37
windows/access-protection/hello-for-business/hello-hybrid-key-trust-dirsync.md Normal file
View File

@ -0,0 +1,37 @@
---
title: Configure Directory Synchronization for Hybrid key trust Windows Hello for Business
description: Azure Directory Syncrhonization for Hybrid Certificate Key Deployment (Windows Hello for Business)
keywords: identity, PIN, biometric, Hello, passport, WHFB, hybrid, key-trust, directory, syncrhonization, AADConnect
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security, mobile
author: mikestephens-MS
ms.author: mstephen
localizationpriority: high
ms.date: 10/20/2017
---
# Configure Directory Synchronization for Hybrid key trust Windows Hello for Business
**Applies to**
- Windows 10
>This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
You are ready to configure directory synchronization for your hybrid environment. Hybrid Windows Hello for Business deployment needs both a cloud and an on-premises identity to authenticate and access resources in the cloud or on-premises.
## Deploy Azure AD Connect
Next, you need to synchronizes the on-premises Active Directory with Azure Active Directory. To do this, first review the [Integrating on-prem directories with Azure Active Directory](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect) and [hardware and prerequisites](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-prerequisites) needed and then [download the software](http://go.microsoft.com/fwlink/?LinkId=615771).
<br><br>
<hr>
## Follow the Windows Hello for Business hybrid key trust deployment guide
1. [Overview](hello-hybrid-cert-trust.md)
2. [Prerequistes](hello-hybrid-cert-trust-prereqs.md)
3. [New Installation Baseline](hello-hybrid-cert-new-install.md)
4. Configure Directory Synchronization (*You are here*)
5. [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md)
6. [Configure Windows Hello for Business settings](hello-hybrid-key-whfb-settings.md)
7. [Sign-in and Provision](hello-hybrid-key-whfb-provision.md)

46
windows/access-protection/hello-for-business/hello-hybrid-key-trust-prereqs.md
View File

@ -1,5 +1,5 @@
---
title: Hybrid Windows Hello for Business Prerequistes (Windows Hello for Business)
title: Hybrid Key trust Windows Hello for Business Prerequistes (Windows Hello for Business)
description: Prerequisites for Hybrid Windows Hello for Business Deployments
keywords: identity, PIN, biometric, Hello, passport, WHFB, hybrid, key-trust
ms.prod: w10
@ -11,7 +11,7 @@ ms.author: mstephen
localizationpriority: high
ms.date: 10/20/2017
---
# Hybrid Windows Hello for Business Prerequisites
# Hybrid Key tust Windows Hello for Business Prerequisites
**Applies to**
- Windows 10
@ -32,9 +32,9 @@ The distributed systems on which these technologies were built involved several
## Directories ##
Hybrid Windows Hello for Business needs two directories: on-premises Active Directory and a cloud Azure Active Directory. The minimum required domain functional and forest functional levels for Windows Hello for Business deployment is Windows Server 2008 R2. The
A hybrid Windows Hello for Busines deployment needs an Azure Active Directory subscription. The hybrid key trust deployment, may not require Azure Active Directory premium subscription.
A hybrid Windows Hello for Busines deployment needs an Azure Active Directory subscription. The hybrid key trust deployment, does not need a premium Azure Active Directory subscription.
You can deploye Windows Hello for Business in any environment with Windows Server 2008 R2 or later domain controllers. Azure device registration and Windows Hello for Business require the Windows Server 2016 Active Directory schema. In addition to the Windows Server 2016 Active Directory schema, key trust deployments need an adequate number of Windows Server 2016 domain controllers at each site where users authenticate using Windows Hello for Business.
You can deploy Windows Hello for Business in any environment with Windows Server 2008 R2 or later domain controllers. However, the key trust deployment needs an ***adequate*** number of Windows Server 2016 domain controllers at each site where users authenticate using Windows Hello for Business. 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.
Review these requirements and those from the Windows Hello for Business planning guide and worksheet. Based on your deployment decisions you may need to upgrade your on-premises Active Directory or your Azure Active Directory subscription to meet your needs.
@ -44,7 +44,6 @@ Review these requirements and those from the Windows Hello for Business planning
> * Active Directory Domain Functional Level
> * Active Directory Forest Functional Level
> * Domain Controller version
> * Windows Server 2016 Schema
> * Azure Active Directory subscription
> * Correct subscription for desired features and outcomes
@ -57,6 +56,11 @@ Key trust deployments do not need client issued certificates for on-premises aut
The minimum required enterprise certificate authority that can be used with Windows Hello for Business is Windows Server 2012.
> [!IMPORTANT]
> For Azure AD joined device to authenticate to and use on-premises resources, ensure you:
> * Install the root certificate authority certificate for your organization in the user's trusted root certifcate store.
> * Publish your certificate revocation list to a location that is available to Azure AD joined devices, such as a web-based url.
### Section Review
> [!div class="checklist"]
> * Windows Server 2012 Issuing Certificate Authority
@ -67,7 +71,7 @@ The minimum required enterprise certificate authority that can be used with Wind
## Directory Synchronization ##
The two directories used in hybrid deployments must be synchronized. You need Azure Active Directory Connect to synchronize user accounts in the on-premises Active Directory with Azure Active Directory.
Organizations using older directory synchronization technology, such as DirSync or Azure AD sync need to upgrade to Azure AD Connect
Organizations using older directory synchronization technology, such as DirSync or Azure AD sync need to upgrade to Azure AD Connect.
### Section Review
> [!div class="checklist"]
@ -77,22 +81,20 @@ Organizations using older directory synchronization technology, such as DirSync
<br>
## Federation ##
Federating your on-premises Active Directory with Azure Active Directory ensures all identities have access to all resources regardless if they reside in cloud or on-premises. Windows Hello for Business hybrid certificate trust needs Windows Server 2016 Active Directory Federation Services. All nodes in the AD FS farm must run the same version of AD FS. Additionally, you need to configure your AD FS farm to support Azure registered devices.
The AD FS farm used with Windows Hello for Business must be Windows Server 2016 with minimum update of [KB4034658 (14393.1593)](https://support.microsoft.com/en-us/help/4034658), which is automatically downloaded and installed through Windows Update. If your AD FS farm is not running the AD FS role with updates from Windows Server 2016, then read [Upgrading to AD FS in Windows Server 2016](https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/upgrading-to-ad-fs-in-windows-server-2016)
## Federation with Azure ##
You can deploy Windows Hello for Business key trust in non-federated and federated environments. For non-federated envionments, key trust deployments work in environments that have deployed [Password Syncrhonization with Azure AD Connect](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnectsync-implement-password-synchronization) and [Azure Active Directory Pass-through-Authentication](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-pass-through-authentication). For federated envirnonments, you can deploy Windows Hello for Business key trust using Active Directory Federation Services (AD FS) 2012 R2 or later.
### Section Review ###
> [!div class="checklist"]
> * Windows Server 2016 Active Directory Federation Services
> * Minimum update of [KB4034658 (14393.1593)](https://support.microsoft.com/en-us/help/4034658)
> * Non-federated environments
> * Federated environments
<br>
## Multifactor Authentication ##
Windows Hello for Business is a strong, two-factor credential the helps organizations reduce their dependency on passwords. The provisioning process lets a user enroll in Windows Hello for Business using their username and password as one factor. but needs a second factor of authentication.
Hybrid Windows Hello for Business deployments can use Azure’s Multifactor Authentication service or they can use multifactor authentication provides by Windows Server 2016 Active Directory Federation Services, which includes an adapter model that enables third parties to integrate their multifactor authentication into AD FS.
Hybrid Windows Hello for Business deployments can use Azure’s Multifactor Authentication service or they can use multifactor authentication provides by Windows Server 2012 R2 or later Active Directory Federation Services, which includes an adapter model that enables third parties to integrate their multifactor authentication into AD FS.
### Section Review
> [!div class="checklist"]
@ -108,31 +110,31 @@ Organizations wanting to deploy hybrid key trust need thier domain joined device
### Section Checklist ###
> [!div class="checklist"]
> * Azure Active Directory Device writeback
> * Azure Active Directory Premium subscription
> * Device Registration with Azure Device Registration
<br>
### Next Steps ###
Follow the Windows Hello for Business hybrid key trust deployment guide. For proof-of-concepts, labs, and new installations, choose the **New Installation Basline**.
If your environment is already federated, but does not include Azure device registration, choose **Configure Azure Device Registration**.
For environments transitioning from on-premises to hybrid, start with **Configure Azure Directory Syncrhonization**.
If your environment is already federated and supports Azure device registration, choose **Configure Windows Hello for Business settings**.
For federerated and non-federated environments, start with **Configure Windows Hello for Business settings**.
> [!div class="op_single_selector"]
> - [New Installation Baseline](hello-hybrid-key-new-install.md)
> - [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md)
> - [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md)
> - [Configure Windows Hello for Business settings](hello-hybrid-key-whfb-settings.md)
<br><br>
<hr>
## Follow the Windows Hello for Business hybrid certificate trust deployment guide
## Follow the Windows Hello for Business hybrid key trust deployment guide
1. [Overview](hello-hybrid-key-trust.md)
2. Prerequistes (*You are here*)
3. [New Installation Baseline](hello-hybrid-key-new-install.md)
4. [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md)
5. [Configure Windows Hello for Business settings](hello-hybrid-key-whfb-settings.md)
6. [Sign-in and Provision](hello-hybrid-key-whfb-provision.md)
4. [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md)
5. [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md)
6. [Configure Windows Hello for Business settings](hello-hybrid-key-whfb-settings.md)
7. [Sign-in and Provision](hello-hybrid-key-whfb-provision.md)

12
windows/access-protection/hello-for-business/hello-hybrid-key-trust.md
View File

@ -30,10 +30,7 @@ The new deployment baseline helps organizations who are moving to Azure and Offi
This baseline provides detailed procedures to move your environment from an on-premises only environment to a hybrid environment using Windows Hello for Business to authenticate to Azure Active Directory and to your on-premises Active Directory using a single Windows sign-in.
## Federated Baseline ##
The federated baseline helps organizations that have completed their federation with Azure Active Directory and Office 365 and enables them to introduce Windows Hello for Business into their hybrid environment. This baseline exclusively focuses on the procedures needed to add Azure Device Registration and Windows Hello for Business to an existing hybrid deployment.
Regardless of the baseline you choose, you’re next step is to familiarize yourself with the prerequisites needed for the deployment. Many of the prerequisites will be new for organizations and individuals pursuing the new deployment baseline. Organizations and individuals starting from the federated baseline will likely be familiar with most of the prerequisites, but should validate they are using the proper versions that include the latest updates.
You’re next step is to familiarize yourself with the prerequisites needed for the deployment. Many of the prerequisites will be new for organizations and individuals pursuing the new deployment baseline. Organizations and individuals starting from the federated baseline will likely be familiar with most of the prerequisites, but should validate they are using the proper versions that include the latest updates.
> [!div class="nextstepaction"]
> [Prerequistes](hello-hybrid-key-trust-prereqs.md)
@ -46,6 +43,7 @@ Regardless of the baseline you choose, you’re next step is to familiarize your
1. Overview (*You are here*)
2. [Prerequistes](hello-hybrid-key-trust-prereqs.md)
3. [New Installation Baseline](hello-hybrid-key-new-install.md)
4. [Device Registration](hello-hybrid-key-trust-devreg.md)
5. [Configure Windows Hello for Business settings](hello-hybrid-cert-whfb-settings.md)
6. [Sign-in and Provision](hello-hybrid-key-whfb-provision.md)
4. [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md)
5. [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md)
6. [Configure Windows Hello for Business settings](hello-hybrid-key-whfb-settings.md)
7. [Sign-in and Provision](hello-hybrid-key-whfb-provision.md)

34
windows/access-protection/hello-for-business/hello-hybrid-key-whfb-provision.md
View File

@ -1,5 +1,5 @@
---
title: Hybrid Windows Hello for Business Provisioning (Windows Hello for Business)
title: Hybrid Windows Hello for Business key trust Provisioning (Windows Hello for Business)
description: Provisioning for Hybrid Windows Hello for Business Deployments
keywords: identity, PIN, biometric, Hello, passport, WHFB, hybrid, certificate-trust
ms.prod: w10
@ -9,7 +9,7 @@ ms.pagetype: security, mobile
author: mikestephens-MS
ms.author: mstephen
localizationpriority: high
ms.date: 09/08/2017
ms.date: 10/20/2017
---
# Hybrid Windows Hello for Business Provisioning
@ -24,9 +24,7 @@ The Windows Hello for Business provisioning begins immediately after the user ha
![Event358](images/Event358.png)
The first thing to validate is the computer has processed device registration. You can view this from the User device registration logs where the check **Device is AAD joined (AADJ or DJ++): Yes** appears. Additionally, you can validate this using the **dsregcmd /status** command from a console prompt where the value for **EnterpriseJoined** reads **Yes**.
![dsreg output](images/dsregcmd.png)
The first thing to validate is the computer has processed device registration. You can view this from the User device registration logs where the check **Device is AAD joined (AADJ or DJ++): Yes** appears. Additionally, you can validate this using the **dsregcmd /status** command from a console prompt where the value for **AzureADJoined** reads **Yes**.
Windows Hello for Business provisioning begins with a full screen page with the title **Setup a PIN** and button with the same name. The user clicks **Setup a PIN**.
@ -39,7 +37,7 @@ The provisioning flow proceeds to the Multi-Factor authentication portion of the
After a successful MFA, the provisioning flow asks the user to create and validate a PIN. This PIN must observe any PIN complexity requirements that you deployed to the environment.
<createaPin.png>
![Create a PIN during provisioning](images/createPin.png)
The provisioning flow has all the information it needs to complete the Windows Hello for Business enrollment.
* A successful single factor authentication (username and password at sign-in)
@ -47,29 +45,25 @@ The provisioning flow has all the information it needs to complete the Windows H
* A fresh, successful multi-factor authentication
* A validated PIN that meets the PIN complexity requirements
The remainder of the provisioning includes Windows Hello for Business requesting an asymmetric key pair for the user, preferably from the TPM (or required if explicitly set through policy). Once the key pair is acquired, Windows communicates with Azure Active Directory to register the public key. AAD Connect syncrhonizes the user's key to the on-prem Active Directory.
The remainder of the provisioning includes Windows Hello for Business requesting an asymmetric key pair for the user, preferably from the TPM (or required if explicitly set through policy). Once the key pair is acquired, Windows communicates with Azure Active Directory to register the public key. When key registration completes, Windows Hello for Business provisioning informs the user they can use their PIN to sign-in. The user may close the provisiong application and see their desktop. While the user has completed provisioning, Azure AD Connect syncrhonizes the user's key to Active Directory.
> [!IMPORTANT]
> The minimum time needed to syncrhonize the user's public key from Azure Active Directory to the on-premises Active Directory is 30 minutes. This synchronization latency delays the certificate enrollment for the user. After the user's public key has synchronized to Active Directory, the user's certificate enrolls automatically as long as the user's session is active (actively working or locked, but still signed-in). Also, the Action Center notifies the user thier PIN is ready for use.
> The minimum time needed to syncrhonize the user's public key from Azure Active Directory to the on-premises Active Directory is 30 minutes. The Azure AD Connect scheduler controls the synchronization interval.
> **This synchronization latency delays the the user's ability to authenticate and use on-premises resouces until the user's public key has synchronized to Active Directory.** Once synchronized, the user can authenticate and use on-premises resources.
> Read [Azure AD Connect sync: Scheduler](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnectsync-feature-scheduler) to view and adjust the **synchronization cycle** for your organization.
> [!NOTE]
> Microsoft is actively investigating ways to reduce the syncrhonization latency and delays in certificate enrollment with the goal to make certificate enrollment occur real-time.
After a successful key registration, Windows creates a certificate request using the same key pair to request a certificate. Windows send the certificate request to the AD FS server for certificate enrollment.
The AD FS registration authority verifies the key used in the certificate request matches the key that was previously registered. On a successful match, the AD FS registration authority signs the certificate request using its enrollment agent certificate and sends it to the certificate authority.
The certificate authority validates the certificate was signed by the registration authority. On successful validation of the signature, it issues a certificate based on the request and returns the certificate to the AD FS registration authority. The registration authority returns the certificate to Windows where it then installs the certificate in the current user’s certificate store. Once this process completes, the Windows Hello for Business provisioning workflow informs the user they can use their PIN to sign-in through the Windows Action Center.
> Microsoft is actively investigating ways to reduce the synchronization latency and delays.
<br><br>
<hr>
## Follow the Windows Hello for Business hybrid certificate trust deployment guide
## Follow the Windows Hello for Business hybrid key trust deployment guide
1. [Overview](hello-hybrid-cert-trust.md)
2. [Prerequistes](hello-hybrid-cert-trust-prereqs.md)
3. [New Installation Baseline](hello-hybrid-cert-new-install.md)
4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md)
5. [Configure Windows Hello for Business policy settings](hello-hybrid-cert-whfb-settings-policy.md)
6. Sign-in and Provision(*You are here*) 
4. [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md)
5. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md)
6. [Configure Windows Hello for Business settings](hello-hybrid-cert-whfb-settings.md)
7. Sign-in and Provision(*You are here*)

54
windows/access-protection/hello-for-business/hello-hybrid-key-whfb-settings-ad.md
View File

@ -1,7 +1,7 @@
---
title: Configuring Hybrid Windows Hello for Business - Active Directory (AD)
description: Discussing the configuration of Active Directory (AD) in a Hybrid deployment of Windows Hello for Business
keywords: identity, PIN, biometric, Hello, passport, WHFB, ad
title: Configuring Hybrid key trust Windows Hello for Business - Active Directory (AD)
description: Configuring Hybrid key trust Windows Hello for Business - Active Directory (AD)
keywords: identity, PIN, biometric, Hello, passport, WHFB, ad, key trust, key-trust
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
@ -9,41 +9,25 @@ ms.pagetype: security, mobile
localizationpriority: high
author: mikestephens-MS
ms.author: mstephen
ms.date: 09/08/2017
ms.date: 10/20/2017
---
# Configuring Windows Hello for Business: Active Directory
# Configuring Hybrid key trust Windows Hello for Business: Active Directory
**Applies to**
- Windows 10
>[!div class="step-by-step"]
[< Configure Windows Hello for Business](hello-hybrid-cert-whfb-settings.md)
[Configure Azure AD Connect >](hello-hybrid-cert-whfb-settings-dir-sync.md)
[< Configure Windows Hello for Business](hello-hybrid-key-whfb-settings.md)
[Configure Azure AD Connect >](hello-hybrid-key-whfb-settings-dir-sync.md)
>This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
The key synchronization process for the hybrid deployment of Windows Hello for Business needs the Windows Server 2016 Active Directory schema.
>[!IMPORTANT]
>This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
### Creating Security Groups
Windows Hello for Business uses several security groups to simplify the deployment and managment.
> [!Important]
> If your environment has one or more Windows Server 2016 domain controllers in the domain to which you are deploying Windows Hello for Business, then skip the **Create the KeyCredentials Admins Security Group**. Domains that include Windows Server 2016 domain controllers use the KeyAdmins group, which is created during the installation of the first Windows Server 2016 domain controller.
#### Create the KeyCredential Admins Security Group
Azure Active Directory Connect synchronizes the public key on the user object created during provisioning. You assign write and read permission to this group to the Active Directory attribute to ensure the Azure AD Connect service can add and remove keys as 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**.
Windows Hello for Business uses a security group to simplify the deployment and managment.
#### Create the Windows Hello for Business Users Security Group
@ -61,21 +45,21 @@ Sign-in a domain controller or management workstation with *Domain Admin* equiva
### Section Review
> [!div class="checklist"]
> * Create the KeyCredential Admins Security group (optional)
> * Create the Windows Hello for Business Users group
>[!div class="step-by-step"]
[< Configure Windows Hello for Business](hello-hybrid-cert-whfb-settings.md)
[Configure Azure AD Connect >](hello-hybrid-cert-whfb-settings-dir-sync.md)
[< Configure Windows Hello for Business](hello-hybrid-key-whfb-settings.md)
[Configure Azure AD Connect >](hello-hybrid-key-whfb-settings-dir-sync.md)
<br><br>
<hr>
## Follow the Windows Hello for Business hybrid certificate trust deployment guide
## Follow the Windows Hello for Business hybrid key trust deployment guide
1. [Overview](hello-hybrid-cert-trust.md)
2. [Prerequistes](hello-hybrid-cert-trust-prereqs.md)
3. [New Installation Baseline](hello-hybrid-cert-new-install.md)
4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md)
5. Configure Windows Hello for Business settings: Active Directory (*You are here*)
6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md)
2. [Prerequistes](hello-hybrid-key-trust-prereqs.md)
3. [New Installation Baseline](hello-hybrid-key-new-install.md)
4. [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md)
5. [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md)
6. Configure Windows Hello for Business settings: Active Directory (*You are here*)
7. [Sign-in and Provision](hello-hybrid-key-whfb-provision.md)

89
windows/access-protection/hello-for-business/hello-hybrid-key-whfb-settings-adfs.md
View File

@ -1,89 +0,0 @@
---
title: Configuring Hybrid Windows Hello for Business - Active Directory Federation Services (ADFS)
description: Discussing the configuration of Active Directory Federation Services (ADFS) in a Hybrid deployment of Windows Hello for Business
keywords: identity, PIN, biometric, Hello, passport, WHFB, adfs
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security, mobile
localizationpriority: high
author: mikestephens-MS
ms.author: mstephen
ms.date: 09/08/2017
---
# Configure Windows Hello for Business: Active Directory Federation Services
**Applies to**
- Windows10
## Federation Services
>[!IMPORTANT]
>This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
>[!div class="step-by-step"]
[< Configure PKI >](hello-hybrid-cert-whfb-settings-pki.md)
[Configure policy settings >](hello-hybrid-cert-whfb-settings-policy.md)
The Windows Server 2016 Active Directory Fedeartion Server Certificate Registration Authority (AD FS RA) enrolls for an enrollment agent certificate. Once the registration authority verifies the certificate request, it signs the certificate request using its enrollment agent certificate and sends it to the certificate authority.
The Windows Hello for Business Authentication certificate template is configured to only issue certificates to certificate requests that have been signed with an enrollment agent certificate.
### 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.
### Group Memberships for the AD FS Service Account
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 **Windows Hello for Business Users** group
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. Restart the AD FS server.
### Section Review
> [!div class="checklist"]
> * Configure the registration authority
> * Update group memberships for the AD FS service account
>[!div class="step-by-step"]
[< Configure PKI >](hello-hybrid-cert-whfb-settings-pki.md)
[Configure policy settings >](hello-hybrid-cert-whfb-settings-policy.md)
<br><br>
<hr>
## Follow the Windows Hello for Business hybrid certificate trust deployment guide
1. [Overview](hello-hybrid-cert-trust.md)
2. [Prerequistes](hello-hybrid-cert-trust-prereqs.md)
3. [New Installation Baseline](hello-hybrid-cert-new-install.md)
4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md)
5. Configure Windows Hello for Business settings: AD FS (*You are here*)
6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md)

58
windows/access-protection/hello-for-business/hello-hybrid-key-whfb-settings-dir-sync.md
View File

@ -1,7 +1,7 @@
---
title: Configuring Hybrid Windows Hello for Business - Directory Synchronization
description: Discussing Directory Synchronization in a Hybrid deployment of Windows Hello for Business
keywords: identity, PIN, biometric, Hello, passport, WHFB, dirsync, connect
title: Configuring Hybrid key trust Windows Hello for Business - Directory Synchronization
description: Configuring Hybrid key trust Windows Hello for Business - Directory Synchronization
keywords: identity, PIN, biometric, Hello, passport, WHFB, dirsync, connect, Windows Hello, AD Connect, key trust, key-trust
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
@ -9,7 +9,7 @@ ms.pagetype: security, mobile
localizationpriority: high
author: mikestephens-MS
ms.author: mstephen
ms.date: 09/08/2017
ms.date: 10/20/2017
---
# Configure Hybrid Windows Hello for Business: Directory Synchronization
@ -20,45 +20,21 @@ ms.date: 09/08/2017
[< Configure Active Directory](hello-hybrid-cert-whfb-settings-ad.md)
[Configure PKI >](hello-hybrid-cert-whfb-settings-pki.md)
## Directory Syncrhonization
>[!IMPORTANT]
>This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
## Directory Syncrhonization
In hybrid deployments, users register the public portion of their Windows Hello for Business credential with Azure. Azure AD Connect synchronizes the Windows Hello for Business public key to 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.
> [!IMPORTANT]
> If you already have a Windows Server 2016 domain controller in your domain, you can skip **Configure Permissions for Key Synchronization**.
### Configure Permissions for Key Syncrhonization
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.
### Group Memberships for the Azure AD Connect Service Account
The KeyAdmins or KeyCredential Admins global group provides the Azure AD Connect service with the permissions needed to read and write the public key to Active Directory.
The KeyAdmins global group provides the Azure AD Connect service with the permissions needed to read and write the public key to Active Directory.
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.
>[!IMPORTANT]
> If you already have a Windows Server 2016 domain controller in your domain, use the Keyadmins group in the next step, otherwise use the KeyCredential admins group you previously created.
3. Right-click either the **KeyAdmins** or **KeyCredential Admins** in the details pane and click **Properties**.
3. Right-click **KeyAdmins** 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 the name of the Azure AD Connect service account. Click **OK**.
6. Click **OK** to return to **Active Directory Users and Computers**.
@ -66,21 +42,21 @@ Sign-in a domain controller or management workstation with _Domain Admin_ equiva
### Section Review
> [!div class="checklist"]
> * Configure Permissions for Key Synchronization
> * Configure group membership for Azure AD Connect
>[!div class="step-by-step"]
[< Configure Active Directory](hello-hybrid-cert-whfb-settings-ad.md)
[Configure PKI >](hello-hybrid-cert-whfb-settings-pki.md)
[< Configure Active Directory](hello-hybrid-key-whfb-settings-ad.md)
[Configure PKI >](hello-hybrid-key-whfb-settings-pki.md)
<br><br>
<hr>
## Follow the Windows Hello for Business hybrid certificate trust deployment guide
## Follow the Windows Hello for Business hybrid key trust deployment guide
1. [Overview](hello-hybrid-cert-trust.md)
2. [Prerequistes](hello-hybrid-cert-trust-prereqs.md)
3. [New Installation Baseline](hello-hybrid-cert-new-install.md)
4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md)
5. Configure Windows Hello for Business settings: Directory Syncrhonization (*You are here*)
6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md)
2. [Prerequistes](hello-hybrid-key-trust-prereqs.md)
3. [New Installation Baseline](hello-hybrid-key-new-install.md)
4. [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md)
5. [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md)
6. Configure Windows Hello for Business settings: Directory Syncrhonization (*You are here*)
7. [Sign-in and Provision](hello-hybrid-key-whfb-provision.md)

111
windows/access-protection/hello-for-business/hello-hybrid-key-whfb-settings-pki.md
View File

@ -1,7 +1,7 @@
---
title: Configuring Hybrid Windows Hello for Business - Public Key Infrastructure (PKI)
description: Discussing the configuration of the Public Key Infrastructure (PKI) in a Hybrid deployment of Windows Hello for Business
keywords: identity, PIN, biometric, Hello, passport, WHFB, PKI
title: Configuring Hybrid key trust Windows Hello for Business - Public Key Infrastructure (PKI)
description: Configuring Hybrid key trust Windows Hello for Business - Public Key Infrastructure (PKI)
keywords: identity, PIN, biometric, Hello, passport, WHFB, PKI, Windows Hello, key trust, key-trust
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
@ -9,7 +9,7 @@ ms.pagetype: security, mobile
localizationpriority: high
author: mikestephens-MS
ms.author: mstephen
ms.date: 09/08/2017
ms.date: 10/20/2017
---
# Configure Hybrid Windows Hello for Business: Public Key Infrastructure
@ -18,15 +18,14 @@ ms.date: 09/08/2017
- Windows 10
> [!div class="step-by-step"]
[< Configure Azure AD Connect](hello-hybrid-cert-whfb-settings-dir-sync.md)
[Configure AD FS >](hello-hybrid-cert-whfb-settings-adfs.md)
[< Configure Azure AD Connect](hello-hybrid-key-whfb-settings-dir-sync.md)
[Configure policy settings >](hello-hybrid-key-whfb-settings-policy.md)
>[!IMPORTANT]
>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.
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.
## Certifcate Templates
@ -76,81 +75,6 @@ Sign-in a certificate authority or management workstations with _Enterprise Admi
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.
### Enrollment Agent certificate template
Active Directory Federation Server used for Windows Hello for Business certificate enrollment performs its own certificate lifecycle management. Once the registration authority is configured with the proper certificate template, the AD FS server attempts to enroll the certificate on the first certificate request or when the service first starts.
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.
> [!IMPORTANT]
> Follow the procedures below based on the AD FS service account used in your environment.
#### Creating an Enrollment Agent certificate for Group Managed Service Accounts
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.
#### Creating an Enrollment Agent certificate for typical Service Acconts
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.
### Creating 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 Templates
### Publish Certificate Templates to a Certificate Authority
@ -174,26 +98,23 @@ Sign-in to the certificate authority or management workstation with _Enterprise
> [!div class="checklist"]
> * Domain Controller certificate template
> * Configure superseded domain controller certificate templates
> * Enrollment Agent certifcate template
> * Windows Hello for Business Authentication certificate template
> * Mark the certifcate template as Windows Hello for Business sign-in template
> * Publish Certificate templates to certificate authorities
> * Unpublish superseded certificate templates
> [!div class="step-by-step"]
[< Configure Azure AD Connect](hello-hybrid-cert-whfb-settings-dir-sync.md)
[Configure AD FS >](hello-hybrid-cert-whfb-settings-adfs.md)
[< Configure Azure AD Connect](hello-hybrid-key-whfb-settings-dir-sync.md)
[Configure policy settings >](hello-hybrid-key-whfb-settings-policy.md)
<br><br>
<hr>
## Follow the Windows Hello for Business hybrid certificate trust deployment guide
## Follow the Windows Hello for Business hybrid key trust deployment guide
1. [Overview](hello-hybrid-cert-trust.md)
2. [Prerequistes](hello-hybrid-cert-trust-prereqs.md)
3. [New Installation Baseline](hello-hybrid-cert-new-install.md)
4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md)
5. Configure Windows Hello for Business settings: PKI (*You are here*)
6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md)
2. [Prerequistes](hello-hybrid-key-trust-prereqs.md)
3. [New Installation Baseline](hello-hybrid-key-new-install.md)
4. [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md)
5. [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md)
6. Configure Windows Hello for Business settings: PKI (*You are here*)
7. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md)

71
windows/access-protection/hello-for-business/hello-hybrid-key-whfb-settings-policy.md
View File

@ -1,7 +1,7 @@
---
title: Configuring Hybrid Windows Hello for Business - Group Policy
description: Discussing the configuration of Group Policy in a Hybrid deployment of Windows Hello for Business
keywords: identity, PIN, biometric, Hello, passport, WHFB
title: Configuring Hybrid key trust Windows Hello for Business - Group Policy
description: Configuring Hybrid key trust Windows Hello for Business - Group Policy
keywords: identity, PIN, biometric, Hello, passport, WHFB, Windows Hello, key trust, key-trust
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
@ -9,7 +9,7 @@ ms.pagetype: security, mobile
localizationpriority: high
author: mikestephens-MS
ms.author: mstephen
ms.date: 09/08/2017
ms.date: 10/20/2017
---
# Configure Hybrid Windows Hello for Business: Group Policy
@ -17,8 +17,7 @@ ms.date: 09/08/2017
- Windows 10
> [!div class="step-by-step"]
[< Configure AD FS](hello-hybrid-cert-whfb-settings-adfs.md)
[< Configure PKI ](hello-hybrid-key-whfb-settings-pki.md)
## Policy Configuration
@ -32,10 +31,8 @@ Alternatively, you can create copy the .ADMX and .ADML files from a Windows 10 C
Domain controllers of Windows Hello for Business deployments need one Group Policy setting, which enables automatic certificate enrollment for the newly create domain controller authentication certificate. This policy setting ensures domain controllers (new and existing) autoamtically request and renew the correct domain controller certifcate.
Domain joined clients of hybrid certificate-based deployments of Windows Hello for Business needs three Group Policy settings:
Hybrid Azure AD joined devices needs one Group Policy settings:
* Enable Windows Hello for Business
* Use certificate for on-premises authentication
* Enable automatic enrollment of certificates
### Configure Domain Controllers for Automatic Certificate Enrollment
@ -78,21 +75,9 @@ The Enable Windows Hello for Business Group Policy setting is the configuration
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.
The Group Policy object contains the policy setting needed to trigger Windows Hello for Business provisioning.
Sign-in a domain controller or management workstations with _Domain Admin_ equivalent credentials.
@ -103,21 +88,7 @@ Sign-in a domain controller or management workstations with _Domain Admin_ equiv
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 <20> 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**.
8. In the content pane, double-click **Use Windows Hello for Business**. Click **Enable** and click **OK**. Close the **Group Policy Management Editor**.
#### Configure Security in the Windows Hello for Business Group Policy object
@ -160,7 +131,10 @@ The default Windows Hello for Business enables users to enroll and use biometric
### 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.
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.
>[IMPORTANT]
> 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 **Computer Configuration\Administrative Templates\System\PIN Complexity** of the Group Policy editor.
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
@ -172,33 +146,30 @@ Windows 10 provides eight PIN Complexity Group Policy settings that give you gra
* Require special characters
* Require uppercase letters
Starting with 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 **Computer Configuration\Administrative Templates\System\PIN Complexity** of the Group Policy editor.
## Add users to the Windows Hello for Business Users group
Users must receive the Windows Hello for Business group policy settings and have the proper permission to enroll for the Wwindows Hello for Business Authentication certificate. You can provide users with these settings and permissions by adding the group used synchronize users to the Windows Hello for Business Users group. Users and groups who are not members of this group will not attempt to enroll for Windows Hello for Business.
Users must receive the Windows Hello for Business group policy settings and have the proper permission to provision Windows Hello for Business . You can provide users with these settings and permissions by adding the users or groups to the **Windows Hello for Business Users** group. Users and groups who are not members of this group will not attempt to enroll for Windows Hello for Business.
### Section Review
> [!div class="checklist"]
> * Configure domain controllers for automatic certificate enrollment.
> * Create Windows Hello for Business Group Policy object.
> * Enable the Use Windows Hello for Business policy setting.
> * Enable the Use certificate for on-premises authentication policy setting.
> * Enable user automatic certificate enrollment.
> * Add users or groups to the Windows Hello for Business group
> [!div class="nextstepaction"]
[Sign-in and Provision](hello-hybrid-cert-whfb-provision.md)
[Sign-in and Provision](hello-hybrid-key-whfb-provision.md)
<br><br>
<hr>
## Follow the Windows Hello for Business hybrid certificate trust deployment guide
## Follow the Windows Hello for Business hybrid key trust deployment guide
1. [Overview](hello-hybrid-cert-trust.md)
2. [Prerequistes](hello-hybrid-cert-trust-prereqs.md)
3. [New Installation Baseline](hello-hybrid-cert-new-install.md)
4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md)
5. Configure Windows Hello for Business policy settings (*You are here*)
6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md)
2. [Prerequistes](hello-hybrid-key-trust-prereqs.md)
3. [New Installation Baseline](hello-hybrid-key-new-install.md)
4. [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md)
5. [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md)
6. Configure Windows Hello for Business policy settings (*You are here*)
7. [Sign-in and Provision](hello-hybrid-key-whfb-provision.md)

26
windows/access-protection/hello-for-business/hello-hybrid-key-whfb-settings.md
View File

@ -1,5 +1,5 @@
---
title: Configure Hybrid Windows Hello for Business Settings (Windows Hello for Business)
title: Configure Hybrid Windows Hello for Business key trust Settings (Windows Hello for Business)
description: Configuring Windows Hello for Business Settings in Hybrid deployment
keywords: identity, PIN, biometric, Hello, passport, WHFB, hybrid, certificate-trust
ms.prod: w10
@ -11,20 +11,21 @@ author: mikestephens-MS
ms.author: mstephen
ms.date: 09/08/2017
---
# Configure Windows Hello for Business
# Configure Hybrid Windows Hello for Business key trust settings
**Applies to**
- Windows 10
> [!div class="step-by-step"]
[Configure Active Directory >](hello-hybrid-cert-whfb-settings-ad.md)
[Configure Active Directory >](hello-hybrid-key-whfb-settings-ad.md)
>[!IMPORTANT]
>This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
You're environment is federated and you are ready to configure your hybrid environment for Windows Hello for business using the certificate trust model.
You are ready to configure your hybrid key trust environment for Windows Hello for Business.
> [!IMPORTANT]
> If your environment is not federated, review the [New Installation baseline](hello-hybrid-cert-new-install.md) section of this deployment document to learn how to federate your environment for your Windows Hello for Business deployment.
> Ensure your environmenet meets all the [prerequistes](hello-hybrid-key-trust-prereqs.md) before proceeding. Review the [New Installation baseline](hello-hybrid-key-new-install.md) section of this deployment document to learn how to prepare your environment for your Windows Hello for Business deployment.
The configuration for Windows Hello for Business is grouped in four categories. These categories are:
* [Active Directory](hello-hybrid-cert-whfb-settings-ad.md)
@ -35,16 +36,17 @@ The configuration for Windows Hello for Business is grouped in four categories.
For the most efficent deployment, configure these technologies in order beginning with the Active Directory configuration
> [!div class="step-by-step"]
[Configure Active Directory >](hello-hybrid-cert-whfb-settings-ad.md)
[Configure Active Directory >](hello-hybrid-key-whfb-settings-ad.md)
<br><br>
<hr>
## Follow the Windows Hello for Business hybrid certificate trust deployment guide
## Follow the Windows Hello for Business hybrid key trust deployment guide
1. [Overview](hello-hybrid-cert-trust.md)
2. [Prerequistes](hello-hybrid-cert-trust-prereqs.md)
3. [New Installation Baseline](hello-hybrid-cert-new-install.md)
4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md)
5. Configure Windows Hello for Business settings (*You are here*)
6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md)
2. [Prerequistes](hello-hybrid-key-trust-prereqs.md)
3. [New Installation Baseline](hello-hybrid-key-new-install.md)
4. [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md)
5. [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md)
6. Configure Windows Hello for Business settings (*You are here*)
7. [Sign-in and Provision](hello-hybrid-key-whfb-provision.md)

8
windows/access-protection/hello-for-business/hello-planning-guide.md
View File

@ -6,8 +6,10 @@ ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security, mobile
author: DaniHalfin
ms.localizationpriority: high
author: mikestephens-MS
ms.author: mstephen
localizationpriority: high
ms.date: 10/20/2017
---
# Planning a Windows Hello for Business Deployment
@ -70,7 +72,7 @@ It’s fundamentally important to understand which deployment model to use for a
A deployments trust type defines how each Windows Hello for Business client authenticates to the on-premises Active Directory. There are two trusts types, key trust and certificate trust.
The key trust type does not require issuing authentication certificates to end users. Users authenticate using a hardware-bound key created during an in-box provisioning experience, which requires an adequate distribution of Windows Server 2016 domain controllers relative to your existing authentication and the number of users included in your Windows Hello for Business deployment.
The key trust type does not require issuing authentication certificates to end users. Users authenticate using a hardware-bound key created during an in-box provisioning experience, which requires an adequate distribution of Windows Server 2016 domain controllers relative to your existing authentication and the number of users included in your Windows Hello for Business deployment. Read the [Planning an adequate number of Windows Server 2016 Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) to learn more.
The certificate trust type issues authentication certificates to end users. Users authenticate using a certificate requested using a hardware-bound key created during the in-box provisioning experience. Unlike key trust, certificate trust does not require Windows Server 2016 domain controllers. Users can authentication using their certificate to any Windows Server 2008 R2 or later domain controller.

BIN
windows/access-protection/hello-for-business/images/createPin.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 28 KiB

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

@ -13,6 +13,14 @@
## [Planning a Windows Hello for Business Deployment](hello-planning-guide.md)
## [Windows Hello for Business Deployment Guide](hello-deployment-guide.md)
### Hybrid Azure AD Joined Key Trust Deployment(hello-hybrid-key-trust.md)
#### [Prerequistes](hello-hybrid-key-trust-prereqs.md)
#### [New Installation Baseline](hello-hybrid-key-new-install.md)
#### [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md)
#### [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md)
#### [Configure Windows Hello for Business settings](hello-hybrid-key-whfb-settings.md)
#### [Sign-in and Provision](hello-hybrid-key-whfb-provision.md)
### [Hybrid Azure AD Joined Certificate Trust Deployment](hello-hybrid-cert-trust.md)
#### [Prerequistes](hello-hybrid-cert-trust-prereqs.md)
#### [New Installation Baseline](hello-hybrid-cert-new-install.md)
@ -20,6 +28,13 @@
#### [Configure Windows Hello for Business policy settings](hello-hybrid-cert-whfb-settings.md)
#### [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md)
## [On Premises Key Trust Deployment](hello-deployment-key-trust.md)
#### [Validate Active Directory prerequisites](hello-key-trust-validate-ad-prereq.md)
#### [Validate and Configure Public Key Infrastructure](hello-key-trust-validate-pki.md)
#### [Prepare and Deploy Windows Server 2016 Active Directory Federation Services](hello-key-trust-adfs.md)
##### [Validate and Deploy Multifactor Authentication Services (MFA)](hello-key-trust-validate-deploy-mfa.md)
#### [Configure Windows Hello for Business Policy settings](hello-key-trust-policy-settings.md)
### [On Premises Certificate Trust Deployment](hello-deployment-cert-trust.md)
#### [Validate Active Directory prerequisites](hello-cert-trust-validate-ad-prereq.md)
#### [Validate and Configure Public Key Infrastructure](hello-cert-trust-validate-pki.md)