diff --git a/windows/access-protection/hello-for-business/hello-cert-trust-adfs.md b/windows/access-protection/hello-for-business/hello-cert-trust-adfs.md index d9f542ffd7..227053e01a 100644 --- a/windows/access-protection/hello-for-business/hello-cert-trust-adfs.md +++ b/windows/access-protection/hello-for-business/hello-cert-trust-adfs.md @@ -9,7 +9,7 @@ ms.pagetype: security, mobile author: DaniHalfin ms.localizationpriority: high ms.author: daniha -ms.date: 07/07/2017 +ms.date: 09/08/2017 --- # Prepare and Deploy Windows Server 2016 Active Directory Federation Services @@ -36,7 +36,7 @@ Prepare the Active Directory Federation Services deployment by installing and up Sign-in the federation server with _local admin_ equivalent credentials. 1. Ensure Windows Server 2016 is current by running **Windows Update** from **Settings**. Continue this process until no further updates are needed. If you’re not using Windows Update for updates, please advise the [Windows Server 2016 update history page](https://support.microsoft.com/help/4000825/windows-10-windows-server-2016-update-history) to make sure you have the latest updates available installed. -2. Ensure the latest server updates to the federation server includes [KB4022723](https://support.microsoft.com/en-us/help/4022723). +2. Ensure the latest server updates to the federation server includes [KB4034658 (14393.1593)](https://support.microsoft.com/en-us/help/4034658). >[!IMPORTANT] >The above referenced updates are mandatory for Windows Hello for Business all on-premises deployment and hybrid certificate trust deployments for domain joined computers. diff --git a/windows/access-protection/hello-for-business/hello-cert-trust-validate-pki.md b/windows/access-protection/hello-for-business/hello-cert-trust-validate-pki.md index c3054a28fa..c9fc5f8eea 100644 --- a/windows/access-protection/hello-for-business/hello-cert-trust-validate-pki.md +++ b/windows/access-protection/hello-for-business/hello-cert-trust-validate-pki.md @@ -36,12 +36,12 @@ Sign-in using _Enterprise Admin_ equivalent credentials on Windows Server 2012 o 1. Open an elevated Windows PowerShell prompt. 2. Use the following command to install the Active Directory Certificate Services role. ```PowerShell - Add-WindowsFeature Adcs-Cert-Authority -IncludeManageTools + Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools ``` 3. Use the following command to configure the Certificate Authority using a basic certificate authority configuration. ```PowerShell - Install-AdcsCertificateAuthority + Install-AdcsCertificationAuthority ``` ## Configure a Production Public Key Infrastructure diff --git a/windows/access-protection/hello-for-business/hello-deployment-guide.md b/windows/access-protection/hello-for-business/hello-deployment-guide.md index c11406fb24..877770ddae 100644 --- a/windows/access-protection/hello-for-business/hello-deployment-guide.md +++ b/windows/access-protection/hello-for-business/hello-deployment-guide.md @@ -9,7 +9,7 @@ ms.pagetype: security, mobile author: DaniHalfin ms.localizationpriority: high ms.author: daniha -ms.date: 07/07/2017 +ms.date: 09/08/2017 --- # Windows Hello for Business Deployment Guide @@ -47,8 +47,10 @@ 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 Certificate Trust Deployment](hello-hybrid-cert-trust.md) * [On Premises Certificate Trust Deployment](hello-deployment-cert-trust.md) + ## Provisioning The Windows Hello for Business provisioning begins immediately after the user has signed in, after the user profile is loaded, but before the user receives their desktop. Windows only launches the provisioning experience if all the prerequisite checks pass. You can determine the status of the prerequisite checks by viewing the **User Device Registration** in the **Event Viewer** under **Applications and Services Logs\Microsoft\Windows**. diff --git a/windows/access-protection/hello-for-business/hello-hybrid-cert-new-install.md b/windows/access-protection/hello-for-business/hello-hybrid-cert-new-install.md new file mode 100644 index 0000000000..a60357cfcf --- /dev/null +++ b/windows/access-protection/hello-for-business/hello-hybrid-cert-new-install.md @@ -0,0 +1,144 @@ +--- +title: Windows Hello for Business Trust New Installation (Windows Hello for Business) +description: Windows Hello for Business Hybrid baseline deployment +keywords: identity, PIN, biometric, Hello, passport, WHFB +ms.prod: w10 +ms.mktglfcycl: deploy +ms.sitesec: library +ms.pagetype: security, mobile +author: mikestephens-MS +ms.author: mstephen +localizationpriority: high +ms.date: 09/08/2017 +--- +# Windows Hello for Business Certificate Trust New Installation + +**Applies to** +- Windows 10 + +>This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher. + +Windows Hello for Business involves configuring distributed technologies that may or may not exist in your current infrastructure. Hybrid certificate trust deployments of Windows Hello for Business rely on these technolgies + +* [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-cert-trust-devreg.md) section to prepare your Windows Hello for Business deployment by configuring Azure device registration. + +The new installation baseline begins with a basic Active Directory deployment and enterprise PKI. This document expects you have Active Directory deployed using Windows Server 2008 R2 or later domain controllers. + +## 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. + +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"] +> * Minimum Windows Server 2008 R2 domain controllers +> * Minimum Windows Server 2008 R2 domain and forest functional level +> * Functional networking, name resolution, and Active Directory replication + +## Public Key Infrastructure + +Windows Hello for Business must have a public key infrastructure regardless of the deployment or trust model. All trust models depend on the domain controllers having a certificate. The certificate serves as a root of trust for clients to ensure they are not communicating with a rogue domain controller. The certificate trust model extends certificate issuance to client computers. During Windows Hello for Business provisioning, the user receives a sign-in certificate. + +This guide assumes most enterprises have an existing public key infrastructure. Windows Hello for Business depends on a Windows enterprise public key infrastructure running the Active Directory Certificate Services role from Windows Server 2012 or later. + +### Lab-based public key infrastructure + +The following instructions may be used to deploy simple public key infrastructure that is suitable for a lab environment. + +Sign-in using _Enterprise Admin_ equivalent credentials on Windows Server 2012 or later server where you want the certificate authority installed. + +>[!NOTE] +>Never install a certificate authority on a domain controller in a production environment. + +1. Open an elevated Windows PowerShell prompt. +2. Use the following command to install the Active Directory Certificate Services role. + ```PowerShell + Add-WindowsFeature Adcs-Cert-Authority -IncludeManageTools + ``` + +3. Use the following command to configure the Certificate Authority using a basic certificate authority configuration. + ```PowerShell + Install-AdcsCertificateAuthority + ``` + +## Configure a Production Public Key Infrastructure + +If you do have an existing public key infrastructure, please review [Certification Authority Guidance](https://technet.microsoft.com/library/hh831574.aspx) from Microsoft TechNet to properly design your infrastructure. Then, consult the [Test Lab Guide: Deploying an AD CS Two-Tier PKI Hierarchy](https://technet.microsoft.com/library/hh831348.aspx) for instructions on how to configure your public key infrastructure using the information from your design session. + +### Section Review ### + +> [!div class="checklist"] +> * Miniumum Windows Server 2012 Certificate Authority. +> * Enterprise Certificate Authority. +> * Functioning public key infrastructure. + +## 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. + +The next step of the deployment is to follow the [Creating an Azure AD tenant](https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-howto-tenant) process to provision an Azure tenant for your organization. + +### Section Review + +> [!div class="checklist"] +> * Review the different ways to establish an Azure Active Directory tenant. +> * Create an Azure Active Directory Tenant. +> * Purchase the appropriate Azure Active Directory subscription or licenses, if necessary. + +## Multifactor Authentication Services ## +Windows Hello for Business uses multifactor authentication during provisioning and during user initiated PIN reset scenarios, such as when a user forgets their PIN. There are two preferred multifactor authentication configurations with hybrid deployments—Azure MFA and AD FS using Azure MFA + +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. + +### Azure Multi-Factor Authentication (MFA) Cloud ### +> [!IMPORTANT] +As long as your users have licenses that include Azure Multi-Factor Authentication, there's nothing that you need to do to turn on Azure MFA. You can start requiring two-step verification on an individual user basis. The licenses that enable Azure MFA are: +> * Azure Multi-Factor Authentication +> * Azure Active Directory Premium +> * Enterprise Mobility + Security +> +> If you have one of these subscriptions or licenses, skip the Azure MFA Adapter section. + +#### Azure MFA Provider #### +If your organization uses Azure MFA on a per-consumption model (no licenses), then review the [Create a Multifactor Authentication Provider](https://docs.microsoft.com/en-us/azure/multi-factor-authentication/multi-factor-authentication-get-started-auth-provider) section to create an Azure MFA Authentication provider and associate it with your Azure tenant. + +#### Configure Azure MFA Settings #### +Once you have created your Azure MFA authentication provider and associated it with an Azure tenant, you need to configure the multi-factor authentication settings. Review the [Configure Azure Multi-Factor Authentication settings](https://docs.microsoft.com/en-us/azure/multi-factor-authentication/multi-factor-authentication-whats-next) section to configure your settings. + +#### Azure MFA User States #### +After you have completed configuring your Azure MFA settings, you want to review configure [User States](https://docs.microsoft.com/en-us/azure/multi-factor-authentication/multi-factor-authentication-get-started-user-states) to understand user states. User states determine how you enable Azure MFA for your users. + +### Azure MFA via ADFS 2016 ### +Alternatively, you can configure Windows Server 2016 Active Directory Federation Services (AD FS) to provide additional multi-factor authentication. To configure, read the [Configure AD FS 2016 and Azure MFA](https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-ad-fs-2016-and-azure-mfa) section + +### Section Review + +> [!div class="checklist"] +> * Review the overview and uses of Azure Multifactor Authentication. +> * Review your Azure Active Directory subscription for Azure Multifactor Authentication. +> * Create an Azure Multifactor Authentication Provider, if necessary. +> * Configure Azure Multufactor Authentiation features and settings. +> * Understand the different User States and their effect on Azure Multifactor Authentication. +> * Consider using Azure Multifactor Authentication or a third-party multifactor authentication provider with Windows Server 2016 Active Directory Federation Services, if necessary. + +> [!div class="nextstepaction"] +> [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md) + +

+ +
+ +## 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 (*You are here*) +4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md) +5. [Configure Windows Hello for Business settings](hello-hybrid-cert-whfb-settings.md) +6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md) \ No newline at end of file diff --git a/windows/access-protection/hello-for-business/hello-hybrid-cert-trust-devreg.md b/windows/access-protection/hello-for-business/hello-hybrid-cert-trust-devreg.md new file mode 100644 index 0000000000..57457517cd --- /dev/null +++ b/windows/access-protection/hello-for-business/hello-hybrid-cert-trust-devreg.md @@ -0,0 +1,518 @@ +--- +title: Configure Device Registration for Hybrid Windows Hello for Business +description: Azure Device Registration for Hybrid Certificate Trust Deployment (Windows Hello for Business) +keywords: identity, PIN, biometric, Hello, passport, WHFB, hybrid, cert-trust, device, registration +ms.prod: w10 +ms.mktglfcycl: deploy +ms.sitesec: library +ms.pagetype: security, mobile +author: mikestephens-MS +ms.author: mstephen +localizationpriority: high +ms.date: 09/08/2017 +--- +# Configure Device Registration for Hybrid 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 and device write-back 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) + +> [!NOTE] +> Before proceeding, you should familiarize yourself with device regisration concepts such as: +> * Azure AD registered devices +> * Azure AD joined devices +> * Hybrid Azure AD joined devices +> +> You can learn about this and more by reading [Introduction to Device Management in Azure Active Directory.](https://docs.microsoft.com/en-us/azure/active-directory/device-management-introduction) + +## Configure Azure for Device Registration +Begin configuring device registration to support Hybrid Windows Hello for Business by configuring device registration capabilities in Azure AD. + +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 + +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 + +### Upgrading Active Directory to the Windows Server 2016 Schema + +To use Windows Hello for Business with Hybrid Azure AD joined devices, you must first upgrade your Active Directory schema to Windows Server 2016. + +> [!IMPORTANT] +> If you already have a Windows Server 2016 domain controller in your forest, you can skip **Upgrading Active Directory to the Windows Server 2016 Schema** (this section). + +#### Identify the schema role domain controller + +To locate the schema master role holder, open and command prompt and type: + +```Netdom query fsmo | findstr -i schema``` + +![Netdom example output](images\hello-cmd-netdom.png) + +The command should return the name of the domain controller where you need to adprep.exe. Update the schema locally on the domain controller hosting the Schema master role. + +#### Updating the Schema + +Windows Hello for Business uses asymmetric keys as user credentials (rather than passwords). During enrollment, the public key is registered in an attribute on the user object in Active Directory. The schema update adds this new attribute to Active Directory. + +Manually updating Active Directory uses the command-line utility **adprep.exe** located at **\:\support\adprep** on the Windows Server 2016 DVD or ISO. Before running adprep.exe, you must identify the domain controller hosting the schema master role. + +Sign-in to the domain controller hosting the schema master operational role using Enterprise Admin equivalent credentials. + +1. Open an elevated command prompt. +2. Type ```cd /d x:\support\adprep``` where *x* is the drive letter of the DVD or mounted ISO. +3. To update the schema, type ```adprep /forestprep```. +4. Read the Adprep Warning. Type the letter **C*** and press **Enter** to update the schema. +5. Close the Command Prompt and sign-out. + +> [!NOTE] +> If you installed Azure AD Connect prior to upgrading the schema, you will need to re-run the Azure AD Connect installation and refresh the on-premises AD schema to ensure the synchronization rule for msDS-KeyCredentialLink is configured. + + +### 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. + +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) + +#### 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 "" ` +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 -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, + ".+@(?.+)", + "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:///adfs/services/trust/" + ); + + +In the claim above, + +- `$` is the AD FS service URL +- `` 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, + ".+@(?.+)", + "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, ".+@(?.+)", "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=<domain> + - 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=<domain> +- Container Device Registration Service DKM under the above container + +![Device Registration](images/hybridct/device8.png) + +- object of type serviceConnectionpoint at CN=<guid>, CN=Device Registration +- Configuration,CN=Services,CN=Configuration,DC=<domain> + - 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=<domain> +- object of type msDS-DeviceRegistrationService in the above container + +>[!div class="nextstepaction"] +[Configure Windows Hello for Business settings](hello-hybrid-cert-whfb-settings.md) + +

+ +
+ +## 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 (*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) \ No newline at end of file diff --git a/windows/access-protection/hello-for-business/hello-hybrid-cert-trust-prereqs.md b/windows/access-protection/hello-for-business/hello-hybrid-cert-trust-prereqs.md new file mode 100644 index 0000000000..7c56e7ded8 --- /dev/null +++ b/windows/access-protection/hello-for-business/hello-hybrid-cert-trust-prereqs.md @@ -0,0 +1,139 @@ +--- +title: Hybrid 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, certificate-trust +ms.prod: w10 +ms.mktglfcycl: deploy +ms.sitesec: library +ms.pagetype: security, mobile +author: mikestephens-MS +ms.author: mstephen +localizationpriority: high +ms.date: 09/08/2017 +--- +# Hybrid Windows Hello for Business Prerequisites + +**Applies to** +- Windows 10 + + +>This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher. + +Hybrid environments are distributed systems that enable organizations to use on-premises and Azure-based identities and resources. Windows Hello for Business uses the existing distributed system as a foundation on which organizations can provide two-factor authentication that provides a single sign-in like experience to modern resources. + +The distributed systems on which these technologies were built involved several pieces of on-premises and cloud infrastructure. High-level pieces of the infrastructure include: +* [Directories](#directories) +* [Public Key Infrastucture](#public-key-infastructure) +* [Directory Synchronization](#directory-synchronization) +* [Federation](#federation) +* [MultiFactor Authetication](#multifactor-authentication) +* [Device Registration](#device-registration) + +## Directories ## +Hybrid Windows Hello for Business needs two directories: on-premises Active Directory and a cloud Azure Active Directory. The minimum required domain controller, domain functional level, and forest functional level for Windows Hello for Business deployment is Windows Server 2008 R2. + +A hybrid Windows Hello for Busines deployment needs an Azure Active Directory subscription. Different deployment configurations are supported by different Azure subscriptions. The hybrid-certificate trust deployment needs an Azure Active Directory premium subscription because it uses the device write-back synchronization feature. Other deployments, such as the hybrid key-trust deployment, may not require Azure Active Directory premium subscription. + +Windows Hello for Business can be deployed in any environment with Windows Server 2008 R2 or later domain controllers. Azure device registration and Windows Hello for Business require the Windows Server 2016 Active Directory schema. + +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. + +### Section Review ### + +> [!div class="checklist"] +> * 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 + +
+ +## Public Key Infrastructure ## +The Windows Hello for Business deployment depends on an enterprise public key infrastructure as trust anchor for authentication. Domain controllers for hybrid deployments need a certificate in order for Windows 10 devices to trust the domain controller. + +Certificate trust deployments need an enterprise public key infrastructure and a certificate registration authority to issue authentication certificates to users. When using Group Policy, hybrid certificate trust deployment use the Windows Server 2016 Active Directory Federation Server (AS FS) as a certificate registration authority. + +The minimum required enterprise certificate authority that can be used with Windows Hello for Business is Windows Server 2012. + +### Section Review +> [!div class="checklist"] +> * Windows Server 2012 Issuing Certificate Authority +> * Windows Server 2016 Active Directory Federation Services + +
+ +## 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 + +### Section Review +> [!div class="checklist"] +> * Azure Active Directory Connect directory synchronization +> * [Upgrade from DirSync](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-dirsync-upgrade-get-started) +> * [Upgrade from Azure AD Sync](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-upgrade-previous-version) + +
+ +## 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) + +### 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) + +
+ +## 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. + +### Section Review +> [!div class="checklist"] +> * Azure MFA Service +> * Windows Server 2016 AD FS and Azure +> * Windows Server 2016 AD FS and third party MFA Adapter + +
+ +## Device Registration ## +Organizations wanting to deploy hybrid certificate trust need thier domain joined devices to register to Azure Active Directory. Just as a computer has an identity in Active Directory, that same computer has an identity in the cloud. This ensures that only approved computers are used with that Azure Active Directory. Each computer registers its identity in Azure Active Directory. + +Hybrid certificate trust deployments need the device write back feature. Authentication to the Windows Server 2016 Active Directory Federation Services needs both the user and the computer to authenticate. Typically the users are synchronized, but not devices. This prevents AD FS from authenticating the computer and results in Windows Hello for Business certificate enrollment failures. For this reason, Windows Hello for Business deployments need device writeback, which is an Azure Active Directory premium feature. + +### Section Checklist ### +> [!div class="checklist"] +> * Azure Active Directory Device writeback +> * Azure Active Directory Premium subscription + +
+ +### Next Steps ### +Follow the Windows Hello for Business hybrid certificate 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**. + +If your environment is already federated and supports Azure device registration, choose **Configure Windows Hello for Business settings**. + +> [!div class="op_single_selector"] +> - [New Installation Baseline](hello-hybrid-cert-new-install.md) +> - [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md) +> - [Configure Windows Hello for Business settings](hello-hybrid-cert-whfb-settings.md) + +

+ +
+ +## Follow the Windows Hello for Business hybrid certificate trust deployment guide +1. [Overview](hello-hybrid-cert-trust.md) +2. Prerequistes (*You are here*) +3. [New Installation Baseline](hello-hybrid-cert-new-install.md) +4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md) +5. [Configure Windows Hello for Business settings](hello-hybrid-cert-whfb-settings.md) +6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md) \ No newline at end of file diff --git a/windows/access-protection/hello-for-business/hello-hybrid-cert-trust.md b/windows/access-protection/hello-for-business/hello-hybrid-cert-trust.md new file mode 100644 index 0000000000..576a4d3481 --- /dev/null +++ b/windows/access-protection/hello-for-business/hello-hybrid-cert-trust.md @@ -0,0 +1,51 @@ +--- +title: Hybrid Certificate Trust Deployment (Windows Hello for Business) +description: Hybrid Certificate Trust Deployment Overview +keywords: identity, PIN, biometric, Hello, passport, WHFB, hybrid, cert-trust +ms.prod: w10 +ms.mktglfcycl: deploy +ms.sitesec: library +ms.pagetype: security, mobile +author: mikestephens-MS +ms.author: mstephen +localizationpriority: high +ms.date: 09/08/2017 +--- +# Hybrid Azure AD joined Certificate Trust Deployment + +**Applies to** +- Windows 10 + +>This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher. + + +Windows Hello for Business replaces username and password sign-in to Windows with strong user authentication based on asymmetric key pair. The following deployment guide provides the information needed to successfully deploy Windows Hello for Business in a hybrid certificate trust scenario. + +It is recommended that you review the Windows Hello for Business planning guide prior to using the deployment guide. The planning guide helps you make decisions by explaining the available options with each aspect of the deployment and explains the potential outcomes based on each of these decisions. You can review the [planning guide](https://docs.microsoft.com/en-us/windows/access-protection/hello-for-business/hello-planning-guide) and download the [planning worksheet](https://go.microsoft.com/fwlink/?linkid=852514). + +This deployment guide provides guidance for new deployments and customers who are already federated with Office 365. These two scenarios provide a baseline from which you can begin your deployment. + +## New Deployment Baseline ## +The new deployment baseline helps organizations who are moving to Azure and Office 365 to include Windows Hello for Business as part of their deployments. This baseline is good for organizations who are looking to deploy proof of concepts as well as IT professionals who want to familiarize themselves Windows Hello for Business by deploying a lab environment. + +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. + +> [!div class="nextstepaction"] +> [Prerequistes](hello-hybrid-cert-trust-prereqs.md) + +

+ +
+ +## Follow the Windows Hello for Business hybrid certificate trust deployment guide +1. Overview (*You are here*) +2. [Prerequistes](hello-hybrid-cert-trust-prereqs.md) +3. [New Installation Baseline](hello-hybrid-cert-new-install.md) +4. [Device Registration](hello-hybrid-cert-trust-devreg.md) +5. [Configure Windows Hello for Business settings](hello-hybrid-cert-whfb-settings.md) +6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md) \ No newline at end of file diff --git a/windows/access-protection/hello-for-business/hello-hybrid-cert-whfb-provision.md b/windows/access-protection/hello-for-business/hello-hybrid-cert-whfb-provision.md new file mode 100644 index 0000000000..744f4930a3 --- /dev/null +++ b/windows/access-protection/hello-for-business/hello-hybrid-cert-whfb-provision.md @@ -0,0 +1,75 @@ +--- +title: Hybrid Windows Hello for Business 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 +ms.mktglfcycl: deploy +ms.sitesec: library +ms.pagetype: security, mobile +author: mikestephens-MS +ms.author: mstephen +localizationpriority: high +ms.date: 09/08/2017 +--- +# Hybrid Windows Hello for Business Provisioning + +**Applies to** +- Windows 10 + + +>This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher. + +## Provisioning +The Windows Hello for Business provisioning begins immediately after the user has signed in, after the user profile is loaded, but before the user receives their desktop. Windows only launches the provisioning experience if all the prerequisite checks pass. You can determine the status of the prerequisite checks by viewing the **User Device Registration** in the **Event Viewer** under **Applications and Services Logs\Microsoft\Windows**. + +![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) + + +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**. + +![Setup a PIN Provisioning](images/setupapin.png) + +The provisioning flow proceeds to the Multi-Factor authentication portion of the enrollment. Provisioning informs the user that it is actively attempting to contact the user through their configured form of MFA. The provisioning process does not proceed until authentication succeeds, fails or times out. A failed or timeout MFA results in an error and asks the user to retry. + +![MFA prompt during provisioning](images/mfa.png) + +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. + + + +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) +* A device that has successfully completed device registration +* 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. + +> [!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. + +> [!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. + +

+ +
+ +## 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 policy settings](hello-hybrid-cert-whfb-settings-policy.md) +6. Sign-in and Provision(*You are here*)  + diff --git a/windows/access-protection/hello-for-business/hello-hybrid-cert-whfb-settings-ad.md b/windows/access-protection/hello-for-business/hello-hybrid-cert-whfb-settings-ad.md new file mode 100644 index 0000000000..27eba8dd44 --- /dev/null +++ b/windows/access-protection/hello-for-business/hello-hybrid-cert-whfb-settings-ad.md @@ -0,0 +1,81 @@ +--- +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 +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 +--- +# Configuring 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) + +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**. + +#### Create the Windows Hello for Business Users Security Group + +The Windows Hello for Business Users group is used to make it easy to deploy Windows Hello for Business in phases. You assign Group Policy and Certificate template permissions to this group to simplify the deployment by simply adding the users to the group. This provides users with the proper permissions to provision Windows Hello for Business and to enroll in the Windows Hello for Business authentication certificate. + +Sign-in a domain controller or management workstation with *Domain Admin* equivalent credentials. + +1. Open **Active Directory Users and Computers**. +2. Click **View** and click **Advanced Features**. +3. Expand the domain node from the navigation pane. +4. Right-click the **Users** container. Click **New**. Click **Group**. +5. Type **Windows Hello for Business Users** in the **Group Name** text box. +6. Click **OK**. + +### 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) + +

+ +
+ +## 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: Active Directory (*You are here*) +6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md) \ No newline at end of file diff --git a/windows/access-protection/hello-for-business/hello-hybrid-cert-whfb-settings-adfs.md b/windows/access-protection/hello-for-business/hello-hybrid-cert-whfb-settings-adfs.md new file mode 100644 index 0000000000..e68276a09e --- /dev/null +++ b/windows/access-protection/hello-for-business/hello-hybrid-cert-whfb-settings-adfs.md @@ -0,0 +1,89 @@ +--- +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) + +

+ +
+ +## 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) + diff --git a/windows/access-protection/hello-for-business/hello-hybrid-cert-whfb-settings-dir-sync.md b/windows/access-protection/hello-for-business/hello-hybrid-cert-whfb-settings-dir-sync.md new file mode 100644 index 0000000000..51d3af12b8 --- /dev/null +++ b/windows/access-protection/hello-for-business/hello-hybrid-cert-whfb-settings-dir-sync.md @@ -0,0 +1,86 @@ +--- +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 +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 Hybrid Windows Hello for Business: Directory Synchronization + +**Applies to** +- Windows 10 + +>[!div class="step-by-step"] +[< 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. + +In hybrid deployments, users register the public portion of their Windows Hello for Business crednetial with Azure. Azure AD Connect syncrhonizes 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. + +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**. +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**. + +### 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) + +

+ +
+ +## 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: Directory Syncrhonization (*You are here*) +6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md) diff --git a/windows/access-protection/hello-for-business/hello-hybrid-cert-whfb-settings-pki.md b/windows/access-protection/hello-for-business/hello-hybrid-cert-whfb-settings-pki.md new file mode 100644 index 0000000000..27ea8e8a47 --- /dev/null +++ b/windows/access-protection/hello-for-business/hello-hybrid-cert-whfb-settings-pki.md @@ -0,0 +1,199 @@ +--- +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 +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 Hybrid Windows Hello for Business: Public Key Infrastructure + +**Applies to** +- 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) + +>[!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. + +## Certifcate Templates + +This section has you configure certificate templates on your Windows Server 2012 or later issuing certificate authtority. + +### Domain Controller certificate template + +Clients need to trust domain controllers and the best way to do this is to ensure each domain controller has a Kerberos Authentication certificate. Installing a certificate on the domain controller enables the Key Distribution Center (KDC) to prove its identity to other members of the domain. This provides clients a root of trust external to the domain - namely the enterprise certificate authority. + +Domain controllers automatically request a domain controller certificate (if published) when they discover an enterprise certificate authority is added to Active Directory. However, certificates based on the *Domain Controller* and *Domain Controller Authentication* certificate templates do not include the **KDC Authentication** object identifier (OID), which was later added to the Kerberos RFC. Therefore, domain controllers need to request a certificate based on the Kerberos Authentication certificate template. + +By default, the Active Directory Certificate Authority provides and publishes the Kerberos Authentication certificate template. However, the cryptography configuration included in the provided template is based on older and less performant cryptography APIs. To ensure domain controllers request the proper certificate with the best available cryptography, use the **Kerberos Authentication** certificate template a baseline to create an updated domain controller certificate template. + +#### Create a Domain Controller Authentication (Kerberos) Certificate Template + +Sign-in a certificate authority or management workstations with _Domain Admin_ equivalent credentials. + +1. Open the **Certificate Authority** management console. +2. Right-click **Certificate Templates** and click **Manage**. +3. In the **Certificate Template Console**, right-click the **Kerberos Authentication** template in the details pane and click **Duplicate Template**. +4. On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Authority** list. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Recipient** list. +5. On the **General** tab, type **Domain Controller Authentication (Kerberos)** in Template display name. Adjust the validity and renewal period to meet your enterprise's needs. + **Note**If you use different template names, you'll need to remember and substitute these names in different portions of the lab. +6. On the **Subject** tab, select the **Build from this Active Directory information** button if it is not already selected. Select **None** from the **Subject name format** list. Select **DNS name** from the **Include this information in alternate subject** list. Clear all other items. +7. On the **Cryptography** tab, select **Key Storage Provider** from the **Provider Category** list. Select **RSA** from the **Algorithm name** list. Type **2048** in the **Minimum key size** text box. Select **SHA256** from the **Request hash** list. Click **OK**. +8. Close the console. + +#### Configure Certificate Suspeding for the Domain Controller Authentication (Kerberos) Certificate Template + +Many domain controllers may have an existing domain controller certificate. The Active Directory Certificate Services provides a default certificate template for domain controllers--the domain controller certificate template. Later releases provided a new certificate template--the domain controller authentication certificate template. These certificate templates were provided prior to update of the Kerberos specification that stated Key Distribution Centers (KDCs) performing certificate authentication needed to include the **KDC Authentication** extension. + +The Kerberos Authentication certificate template is the most current certificate template designated for domain controllers and should be the one you deploy to all your domain controllers (2008 or later). + +The autoenrollment feature in Windows enables you to effortlessly replace these domain controller certificates. You can use the following configuration to replace older domain controller certificates with a new certificate using the Kerberos Authentication certificate template. + +Sign-in a certificate authority or management workstations with _Enterprise Admin_ equivalent credentials. + +1. Open the **Certificate Authority** management console. +2. Right-click **Certificate Templates** and click **Manage**. +3. In the **Certificate Template Console**, right-click the **Domain Controller Authentication (Kerberos)** (or the name of the certificate template you created in the previous section) template in the details pane and click **Properties**. +4. Click the **Superseded Templates** tab. Click **Add**. +5. From the **Add Superseded Template** dialog, select the **Domain Controller** certificate template and click **OK**. Click **Add**. +6. From the **Add Superseded Template** dialog, select the **Domain Controller Authentication** certificate template and click **OK**. +7. From the **Add Superseded Template dialog**, select the **Kerberos Authentication** certificate template and click **OK**. +8. Add any other enterprise certificate templates that were previously configured for domain controllers to the **Superseded Templates** tab. +9. Click **OK** and close the **Certificate Templates** console. + +The certificate template is configured to supersede all the certificate templates provided in the certificate templates superseded templates list. However, the certificate template and the superseding of certificate templates is not active until you publish the certificate template to one or more certificate authorities. + +### 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 + +The certificate authority may only issue certificates for certificate templates that are published to that certificate authority. If you have more than one certificate authority and you want that certificate authority to issue certificates based on a specific certificate template, then you must publish the certificate template to all certificate authorities that are expected to issue the certificate. + +### Unpublish Superseded Certificate Templates + +The certificate authority only issues certificates based on published certificate templates. For defense in depth security, it is a good practice to unpublish certificate templates that the certificate authority is not configured to issue. This includes the pre-published certificate template from the role installation and any superseded certificate templates. + +The newly created domain controller authentication certificate template supersedes previous domain controller certificate templates. Therefore, you need to unpublish these certificate templates from all issuing certificate authorities. + +Sign-in to the certificate authority or management workstation with _Enterprise Admin_ equivalent credentials. + +1. Open the **Certificate Authority** management console. +2. Expand the parent node from the navigation pane. +3. Click **Certificate Templates** in the navigation pane. +4. Right-click the **Domain Controller** certificate template in the content pane and select **Delete**. Click **Yes** on the **Disable certificate templates** window. +5. Repeat step 4 for the **Domain Controller Authentication** and **Kerberos Authentication** certificate templates. + +### Section Review +> [!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) + +

+ +
+ +## 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: PKI (*You are here*) +6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md) + diff --git a/windows/access-protection/hello-for-business/hello-hybrid-cert-whfb-settings-policy.md b/windows/access-protection/hello-for-business/hello-hybrid-cert-whfb-settings-policy.md new file mode 100644 index 0000000000..2c0b6759f9 --- /dev/null +++ b/windows/access-protection/hello-for-business/hello-hybrid-cert-whfb-settings-policy.md @@ -0,0 +1,204 @@ +--- +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 +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 Hybrid Windows Hello for Business: Group Policy + +**Applies to** +- Windows 10 + +> [!div class="step-by-step"] +[< Configure AD FS](hello-hybrid-cert-whfb-settings-adfs.md) + + +## Policy Configuration + +>[!IMPORTANT] +>This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher. + +You need a Windows 10, version 1703 workstation to run the Group Policy Management Console, which provides the latest Windows Hello for Business and PIN Complexity Group Policy settings. To run the Group Policy Management Console, you need to install the Remote Server Administration Tools for Windows 10. You can download these tools from the [Microsoft Download Center](https://www.microsoft.com/en-us/download/details.aspx?id=45520). +Install the Remote Server Administration Tools for Windows 10 on a computer running Windows 10, version 1703. + +Alternatively, you can create copy the .ADMX and .ADML files from a Windows 10 Creators Edition (1703) to their respective language folder on a Windows Server or you can create a Group Policy Central Store and copy them their respective language folder. See [How to create and manage the Central Store for Group Policy Administrative Templates in Windows](https://support.microsoft.com/help/3087759/how-to-create-and-manage-the-central-store-for-group-policy-administrative-templates-in-windows) for more information. + +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: +* Enable Windows Hello for Business +* Use certificate for on-premises authentication +* Enable automatic enrollment of certificates + +### Configure Domain Controllers for Automatic Certificate Enrollment + +Domain controllers automatically request a certificate from the *Domain Controller* certificate template. However, the domain controller is unaware of newer certificate templates or superseded configurations on certificate templates. + +To continue automatic enrollment and renewal of domain controller certificates that understand newer certificate template and superseded certificate template configurations, create and configure a Group Policy object for automatic certificate enrollment and link the Group Policy object to the Domain Controllers OU. + +#### Create a Domain Controller Automatic Certifiacte Enrollment Group Policy object + +Sign-in a domain controller or management workstations with _Domain Admin_ equivalent credentials. + +1. Start the **Group Policy Management Console** (gpmc.msc) +2. Expand the domain and select the **Group Policy Object** node in the navigation pane. +3. Right-click **Group Policy object** and select **New** +4. Type *Domain Controller Auto Certificate Enrollment* in the name box and click **OK**. +5. Right-click the **Domain Controller Auto Certificate Enrollment** Group Policy object and click **Edit**. +6. In the navigation pane, expand **Policies** under **Computer Configuration**. +7. Expand **Windows Settings**, **Security Settings**, and click **Public Key Policies**. +8. In the details pane, right-click **Certificate Services Client � Auto-Enrollment** and select **Properties**. +9. Select **Enabled** from the **Configuration Model** list. +10. Select the **Renew expired certificates**, **update pending certificates**, and **remove revoked certificates** check box. +11. Select the **Update certificates that use certificate templates** check box. +12. Click **OK**. Close the **Group Policy Management Editor**. + +#### Deploy the Domain Controller Auto Certificate Enrollment Group Policy Object + +Sign-in a domain controller or management workstations with _Domain Admin_ equivalent credentials. + +1. Start the **Group Policy Management Console** (gpmc.msc) +2. In the navigation pane, expand the domain and expand the node that has your Active Directory domain name. Right-click the **Domain Controllers** organizational unit and click **Link an existing GPO�** +3. In the **Select GPO** dialog box, select **Domain Controller Auto Certificate Enrollment** or the name of the domain controller certificate enrollment Group Policy object you previously created and click **OK**. + +### Windows Hello for Business Group Policy + +The Windows Hello for Business Group Policy object delivers the correct Group Policy settings to the user, which enables them to enroll and use Windows Hello for Business to authenticate to Azure and Active Directory + +#### Enable Windows Hello for Business + +The Enable Windows Hello for Business Group Policy setting is the configuration needed for Windows to determine if a user should be attempt to enroll for Windows Hello for Business. A user will only attempt enrollment if this policy setting is configured to enabled. + +You can configure the Enable Windows Hello for Business Group Policy setting for computer or users. Deploying this policy setting to computers results in ALL users that sign-in that computer to attempt a Windows Hello for Business enrollment. Deploying this policy setting to a user results in only that user attempting a Windows Hello for Business enrollment. Additionally, you can deploy the policy setting to a group of users so only those users attempt a Windows Hello for Business enrollment. If both user and computer policy settings are deployed, the user policy setting has precedence. + +#### Use certificate for on-premises authentication + +The Use certificate for on-premises authentication Group Policy setting determines if the on-premises deployment uses the key-trust or certificate trust on-premises authentication model. You must configure this Group Policy setting to configure Windows to enroll for a Windows Hello for Business authentication certificate. If you do not configure this policy setting, Windows considers the deployment to use key-trust on-premises authentication, which requires a sufficient number of Windows Server 2016 domain controllers to handle the Windows Hello for Business key-trust authentication requests. + +You can configure this Group Policy setting for computer or users. Deploying this policy setting to computers results in ALL users requesting a Windows Hello for Business authentication certificate. Deploying this policy setting to a user results in only that user requesting a Windows Hello for Business authentication certificate. Additionally, you can deploy the policy setting to a group of users so only those users request a Windows Hello for Business authentication certificate. If both user and computer policy settings are deployed, the user policy setting has precedence. + +#### Enable automatic enrollment of certificates + +Windows Hello for Business provisioning performs the initial enrollment of the Windows Hello for Business authentication certificate. This certificate expires based on the duration configured in the Windows Hello for Business authentication certificate template. The Windows 10, version 1703 certificate auto enrollment was updated to renew these certificates before they expire, which significantly reduces user authentication failures from expired user certificates. + +The process requires no user interaction provided the user signs-in using Windows Hello for Business. The certificate is renewed in the background before it expires. + +#### Create the Windows Hello for Business Group Policy object + +The Group Policy object contains the policy settings needed to trigger Windows Hello for Business provisioning and to ensure Windows Hello for Business authentication certificates are automatically renewed. + +Sign-in a domain controller or management workstations with _Domain Admin_ equivalent credentials. + +1. Start the **Group Policy Management Console** (gpmc.msc) +2. Expand the domain and select the **Group Policy Object** node in the navigation pane. +3. Right-click **Group Policy object** and select **New**. +4. Type *Enable Windows Hello for Business* in the name box and click **OK**. +5. In the content pane, right-click the **Enable Windows Hello for Business** Group Policy object and click **Edit**. +6. In the navigation pane, expand **Policies** under **User Configuration**. +7. Expand **Administrative Templates > Windows Component**, and select **Windows Hello for Business**. +8. In the content pane, double-click **Use Windows Hello for Business**. Click **Enable** and click **OK**. +9. Double-click **Use certificate for on-premises authentication**. Click **Enable** and click **OK**. Close the **Group Policy Management Editor**. + +#### Configure Automatic Certificate Enrollment + +1. Start the **Group Policy Management Console** (gpmc.msc). +2. Expand the domain and select the **Group Policy Object** node in the navigation pane. +3. Right-click the **Enable Windows Hello for Business** Group Policy object and click **Edit**. +4. In the navigation pane, expand **Policies** under **User Configuration**. +5. Expand **Windows Settings > Security Settings**, and click **Public Key Policies**. +6. In the details pane, right-click **Certificate Services Client � Auto-Enrollment** and select **Properties**. +7. Select **Enabled** from the **Configuration Model** list. +8. Select the **Renew expired certificates**, **update pending certificates**, and **remove revoked certificates** check box. +9. Select the **Update certificates that use certificate templates** check box. +10. Click **OK**. Close the **Group Policy Management Editor**. + +#### Configure Security in the Windows Hello for Business Group Policy object + +The best way to deploy the Windows Hello for Business Group Policy object is to use security group filtering. The enables you to easily manage the users that should receive Windows Hello for Business by simply adding them to a group. This enables you to deploy Windows Hello for Business in phases. +1. Start the **Group Policy Management Console** (gpmc.msc) +2. Expand the domain and select the **Group Policy Object** node in the navigation pane. +3. Double-click the **Enable Windows Hello for Business** Group Policy object. +4. In the **Security Filtering** section of the content pane, click **Add**. Type *Windows Hello for Business Users* or the name of the security group you previously created and click **OK**. +5. Click the **Delegation** tab. Select **Authenticated Users** and click **Advanced**. +6. In the **Group or User names** list, select **Authenticated Users**. In the **Permissions for Authenticated Users** list, clear the **Allow** check box for the **Apply Group Policy** permission. Click **OK**. + +#### Deploy the Windows Hello for Business Group Policy object + +The application of the Windows Hello for Business Group Policy object uses security group filtering. This enables you to link the Group Policy object at the domain, ensuring the Group Policy object is within scope to all users. However, the security group filtering ensures only the users included in the *Windows Hello for Business Users* global group receive and apply the Group Policy object, which results in the provisioning of Windows Hello for Business. +1. Start the **Group Policy Management Console** (gpmc.msc) +2. In the navigation pane, expand the domain and right-click the node that has your Active Directory domain name and click **Link an existing GPO�** +3. In the **Select GPO** dialog box, select **Enable Windows Hello for Business** or the name of the Windows Hello for Business Group Policy object you previously created and click **OK**. + +Just to reassure, linking the **Windows Hello for Business** Group Policy object to the domain ensures the Group Policy object is in scope for all domain users. However, not all users will have the policy settings applied to them. Only users who are members of the Windows Hello for Business group receive the policy settings. All others users ignore the Group Policy object. + +## Other Related Group Policy settings + +### Windows Hello for Business + +There are other Windows Hello for Business policy settings you can configure to manage your Windows Hello for Business deployment. These policy settings are computer-based policy setting; so they are applicable to any user that sign-in from a computer with these policy settings. + +#### Use a hardware security device + +The default configuration for Windows Hello for Business is to prefer hardware protected credentials; however, not all computers are able to create hardware protected credentials. When Windows Hello for Business enrollment encounters a computer that cannot create a hardware protected credential, it will create a software-based credential. + +You can enable and deploy the **Use a hardware security device** Group Policy Setting to force Windows Hello for Business to only create hardware protected credentials. Users that sign-in from a computer incapable of creating a hardware protected credential do not enroll for Windows Hello for Business. + +Another policy setting becomes available when you enable the **Use a hardware security device** Group Policy setting that enables you to prevent Windows Hello for Business enrollment from using version 1.2 Trusted Platform Modules (TPM). Version 1.2 TPMs typically perform cryptographic operations slower than version 2.0 TPMs and are more unforgiven during anti-hammering and PIN lockout activities. Therefore, some organization may want not want slow sign-in performance and management overhead associated with version 1.2 TPMs. To prevent Windows Hello for Business from using version 1.2 TPMs, simply select the TPM 1.2 check box after you enable the Use a hardware security device Group Policy object. + +#### Use biometrics + +Windows Hello for Business provides a great user experience when combined with the use of biometrics. Rather than providing a PIN to sign-in, a user can use a fingerprint or facial recognition to sign-in to Windows, without sacrificing security. + +The default Windows Hello for Business enables users to enroll and use biometrics. However, some organization may want more time before using biometrics and want to disable their use until they are ready. To not allow users to use biometrics, configure the **Use biometrics** Group Policy setting to disabled and apply it to your computers. The policy setting disabled all biometrics. Currently, Windows does not provide granular policy setting that enable you to disable specific modalities of biometrics such as allow facial recognition, but disallow fingerprint. + +### PIN Complexity + +PIN complexity is not specific to Windows Hello for Business. Windows 10 enables users to use PINs outside of Windows Hello for Business. PIN Complexity Group Policy settings apply to all uses of PINs, even when Windows Hello for Business is not deployed. + +Windows 10 provides eight PIN Complexity Group Policy settings that give you granular control over PIN creation and management. You can deploy these policy settings to computers, where they affect all users creating PINs on that computer; or, you can deploy these settings to users, where they affect those users creating PINs regardless of the computer they use. If you deploy both computer and user PIN complexity Group Policy settings, the user policy settings have precedence over computer policy settings. Also, this conflict resolution is based on the last applied policy. Windows does not merge the policy settings automatically; however, you can deploy Group Policy to provide to accomplish a variety of configurations. The policy settings included are: +* Require digits +* Require lowercase letters +* Maximum PIN length +* Minimum PIN length +* Expiration +* History +* Require special characters +* Require uppercase letters + +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. + +### 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) + +

+ +
+ +## 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 policy settings (*You are here*) +6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md) \ No newline at end of file diff --git a/windows/access-protection/hello-for-business/hello-hybrid-cert-whfb-settings.md b/windows/access-protection/hello-for-business/hello-hybrid-cert-whfb-settings.md new file mode 100644 index 0000000000..2dbfc5fda4 --- /dev/null +++ b/windows/access-protection/hello-for-business/hello-hybrid-cert-whfb-settings.md @@ -0,0 +1,50 @@ +--- +title: Configure Hybrid Windows Hello for Business 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 +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 + +**Applies to** +- Windows 10 + +> [!div class="step-by-step"] +[Configure Active Directory >](hello-hybrid-cert-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. +> [!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. + +The configuration for Windows Hello for Business is grouped in four categories. These categories are: +* [Active Directory](hello-hybrid-cert-whfb-settings-ad.md) +* [Public Key Infrastructure](hello-hybrid-cert-whfb-settings-pki.md) +* [Active Directory Federation Services](hello-hybrid-cert-whfb-settings-adfs.md) +* [Group Policy](hello-hybrid-cert-whfb-settings-policy.md) + +For the most efficent deployment, configure these technologies in order beginning with the Active Directory configuration + +> [!div class="step-by-step"] +[Configure Active Directory >](hello-hybrid-cert-whfb-settings-ad.md) + +

+ +
+ +## 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 (*You are here*) +6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md) \ No newline at end of file diff --git a/windows/access-protection/hello-for-business/hello-identity-verification.md b/windows/access-protection/hello-for-business/hello-identity-verification.md index 6bc13714ae..59a9bb791e 100644 --- a/windows/access-protection/hello-for-business/hello-identity-verification.md +++ b/windows/access-protection/hello-for-business/hello-identity-verification.md @@ -10,7 +10,7 @@ ms.pagetype: security, mobile author: DaniHalfin ms.localizationpriority: high ms.author: daniha -ms.date: 07/07/2017 +ms.date: 09/08/2017 --- # Windows Hello for Business @@ -78,7 +78,7 @@ There are many deployment options from which to choose. Some of those options re Windows Hello for Business is two-factor authentication based the observed authentication factors of: something you have, something you know, and something part of you. Windows Hello for Business incorporates two of these factors: something you have (the user's private key protected by the device's security module) and something you know (your PIN). With the proper hardware, you can enhance the user experience by introducing biometrics. Using biometrics, you can replace the "something you know" authentication factor with the "something that is part of you" factor, with the assurances that users can fall back to the "something you know factor". ### Can I use PIN and biometrics to unlock my device? -No. Windows Hello for Business provides two-factor authentication. However, we are investigating the ability to unlock the device with multiple factors. +No. Windows Hello for Business provides two-factor authentication. However, we are investigating the ability to unlock the desktop with additional factors. ### What is the difference between Windows Hello and Windows Hello for Business Windows Hello represents the biometric framework provided in Windows 10. Windows Hello enables users to use biometrics to sign into their devices by securely storing their username and password and releasing it for authentication when the user successfully identifies themselves using biometrics. Windows Hello for Business uses asymmetric keys protected by the device's security module that requires a user gesture (PIN or biometrics) to authenticate. @@ -86,6 +86,28 @@ Windows Hello represents the biometric framework provided in Windows 10. Window ### I have extended Active Directory to Azure Active Directory. Can I use the on-prem deployment model? No. If your organization is federated or using online services, such as Office 365 or OneDrive, then you must use a hybrid deployment model. On-premises deployments are exclusive to organization who need more time before moving to the cloud and exclusively use Active Directory. +### Does Windows Hello for Business prevent the use of simple PINs? +Yes. Our simple PIN algorithm looks for and disallows any PIN that has a constant delta from one digit to the next. This prevents repeating numbers, sequential numbers and simple patterns. +So, for example: +* 1111 has a constant delta of 0, so it is not allowed +* 1234 has a constant delta of 1, so it is not allowed +* 1357 has a constant delta of 2, so it is not allowed +* 9630 has a constant delta of -3, so it is not allowed +* 1231 does not have a constant delta, so it is okay +* 1593 does not have a constant delta, so it is okay + +This algorithm does not apply to alphanumeric PINs. + +### How does PIN caching work with Windows Hello for Business? +Windows Hello for Business provides a PIN caching user experience using a ticketing system. Rather than caching a PIN, processes cache a ticket they can use to request private key operations. Azure AD and Active Directory sign-in keys are cached under lock. This means the keys remain available for use without prompting as long as the user is interactively signed-in. Microsoft Account sign-in keys are considered transactional keys, which means the user is always prompted when accessing the key. + +Beginning with Windows 10, Fall Creators Update, Windows Hello for Business used as a smart card (smart card emulation that is enabled by default) provides the same user experience of default smart card PIN caching. Each process requesting a private key operation will prompt the user for the PIN on first use. Subsequent private key operations will not prompt the user for the PIN. + +The smart card emulation feature of Windows Hello for Business verifies the PIN and then discards the PIN in exchange for a ticket. The process does not receive the PIN, but rather the ticket that grants them private key operations. Windows 10 does not provide any Group Policy settings to adjust this caching. + +### Can I disable the PIN while using Windows Hello for Business? +No. The movement away from passwords is accomplished by gradually reducing the use of the password. In the occurence where you cannot authenticate with biometrics, you need a fall back mechansim that is not a password. The PIN is the fall back mechansim. Disabling or hiding the PIN credential provider disabled the use of biometrics. + ### Does Windows Hello for Business work with third party federation servers? Windows Hello for Business can work with any third-party federation servers that support the protocols used during provisioning experience. Interested third-parties can inquiry at [whfbfeedback@microsoft.com](mailto:whfbfeedback@microsoft.com?subject=collaboration) @@ -98,3 +120,4 @@ Windows Hello for Business can work with any third-party federation servers that ### Does Windows Hello for Business work with Mac and Linux clients? Windows Hello for Business is a feature of Windows 10. At this time, Microsoft is not developing clients for other platforms. However, Microsoft is open to third parties who are interested in moving these platforms away from passwords. Interested third parties can inqury at [whfbfeedback@microsoft.com](mailto:whfbfeedback@microsoft.com?subject=collaboration) + diff --git a/windows/access-protection/hello-for-business/hello-manage-in-organization.md b/windows/access-protection/hello-for-business/hello-manage-in-organization.md index 6d8b9b37a2..52c93015e2 100644 --- a/windows/access-protection/hello-for-business/hello-manage-in-organization.md +++ b/windows/access-protection/hello-for-business/hello-manage-in-organization.md @@ -25,7 +25,7 @@ You can create a Group Policy or mobile device management (MDM) policy that will > >Beginning in version 1607, Windows Hello as a convenience PIN is disabled by default on all domain-joined computers. To enable a convenience PIN for Windows 10, version 1607, enable the Group Policy setting **Turn on convenience PIN sign-in**. > ->Use **Windows Hello for Business** policy settings to manage PINs for Windows Hello for Business. +>Use **PIN Complexity** policy settings to manage PINs for Windows Hello for Business.   ## Group Policy settings for Windows Hello for Business @@ -292,71 +292,6 @@ The following table lists the MDM policy settings that you can configure for Win >[!NOTE]   > If policy is not configured to explicitly require letters or special characters, users will be restricted to creating a numeric PIN.   -## Prerequisites - -To deploy Windows Hello for Business, in some modes you must add Windows Server 2016 domain controllers to your Active Directory environment, but you don’t have to replace or remove your existing Active Directory servers — the servers required for Windows Hello for Business build on and add capability to your existing infrastructure. You don’t have to change the domain or forest functional level, and you can either add on-premises servers or use Azure Active Directory to deploy Windows Hello for Business in your network. - -You’ll need this software to set Windows Hello for Business policies in your enterprise. - ------ - - - - - - - - - - - - - - - - - - - - - - -
Windows Hello for Business modeAzure ADActive Directory (AD) on-premises (only supported with Windows 10, version 1703 clients)Azure AD/AD hybrid (available with production release of Windows Server 2016)
Key-based authenticationAzure AD subscription
    -
  • Active Directory Federation Service (AD FS) (Windows Server 2016)
    • -
  • A few Windows Server 2016 domain controllers on-site
    • -
    -
  • Azure AD subscription
    • -
  • [Azure AD Connect](https://go.microsoft.com/fwlink/p/?LinkId=616792)
    • -
  • A few Windows Server 2016 domain controllers on-site
    • -
  • A management solution, such as Configuration Manager, Group Policy, or MDM
    • -
  • Active Directory Certificate Services (AD CS) without Network Device Enrollment Service (NDES)
    • -
Certificate-based authentication
    -
  • Azure AD subscription
    • -
  • Intune or non-Microsoft mobile device management (MDM) solution
    • -
  • PKI infrastructure
    • -
    -
  • ADFS (Windows Server 2016)
    • -
  • Active Directory Domain Services (AD DS) Windows Server 2016 schema
    • -
  • PKI infrastructure
    • -
    -
  • Azure AD subscription
    • -
  • [Azure AD Connect](https://go.microsoft.com/fwlink/p/?LinkId=616792)
    • -
  • AD CS with NDES
    • -
  • Configuration Manager for domain-joined certificate enrollment, or InTune for non-domain-joined devices, or a non-Microsoft MDM service that supports Windows Hello for Business
    • -
-  -Configuration Manager and MDM provide the ability to manage Windows Hello for Business policy and to deploy and manage certificates protected by Windows Hello for Business. - -Azure AD provides the ability to register devices with your enterprise and to provision Windows Hello for Business for organization accounts. - ->[!IMPORTANT] ->Active Directory on-premises deployment **is not currently available** and will become available with a future update of ADFS on Windows Server 2016. The requirements listed in the above table will apply when this deployment type becomes available. - ## How to use Windows Hello for Business with Azure Active Directory diff --git a/windows/access-protection/hello-for-business/hello-planning-guide.md b/windows/access-protection/hello-for-business/hello-planning-guide.md index 104805b446..54739d877a 100644 --- a/windows/access-protection/hello-for-business/hello-planning-guide.md +++ b/windows/access-protection/hello-for-business/hello-planning-guide.md @@ -68,7 +68,7 @@ It’s fundamentally important to understand which deployment model to use for a #### Trust types -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. +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. @@ -88,7 +88,7 @@ The goal of Windows Hello for Business is to move organizations away from passwo Cloud only and hybrid deployments provide many choices for multifactor authentication. On-premises deployments must use a multifactor authentication that provides an AD FS multifactor adapter to be used in conjunction with the on-premises Windows Server 2016 AD FS server role. Organizations can use from the on-premises Azure Multifactor Authentication server, or choose from several third parties (Read [Microsoft and third-party additional authentication methods](https://docs.microsoft.com/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs#microsoft-and-third-party-additional-authentication-methods) for more information). >[!NOTE] -> Azure Multi-Factor Authentication is available through a: +> Azure Multi-Factor Authentication is available through: >* Microsoft Enterprise Agreement >* Open Volume License Program >* Cloud Solution Providers program @@ -160,6 +160,10 @@ If your organization does not have cloud resources, write **On-Premises** in box Choose a trust type that is best suited for your organizations. Remember, the trust type determines two things. Whether you issue authentication certificates to your users and if your deployment needs Windows Server 2016 domain controllers. +One trust model is not more secure than the other. The major difference is based on the organization comfort with deploying Windows Server 2016 domain controllers and not enrolling users with end enetity certificates (key-trust) against using existing domain controllers (Windows Server 2008R2 or later) and needing to enroll certificates for all their users (certificate trust). + +Because the certificate trust tyoes issues certificates, there is more configuration and infrastrucutre needed to accomodate user certificate enrollment, which could also be a factor to consider in your decision. Additional infrastructure needed for certificatat-trust deployements includes a certificate registration authority. Hybrid Azure AD joined devices managed by Group Policy need the Windows Server 2016 AD FS role to issue certificates. Hybrid Azure AD joined devices and Azure AD joined devices managed by Intune or a compatible MDM need the Windows Server NDES server role to issue certificates. + If your organization wants to use the key trust type, write **key trust** in box **1b** on your planning worksheet. Write **Windows Server 2016** in box **4d**. Write **N/A** in box **5b**. If your organization wants to use the certificate trust type, write **certificate trust** in box **1b** on your planning worksheet. Write **Windows Server 2008 R2 or later** in box **4d**. In box **5c**, write **smart card logon** under the **Template Name** column and write **users** under the **Issued To** column on your planning worksheet. @@ -208,7 +212,7 @@ If your Azure AD Connect is configured to synchronize identities (usernames only You can configure your on-premises Windows Server 2016 AD FS role to use the Azure MFA service adapter. In this configuration, users are redirected to the on premises AD FS server (synchronizing identities only). The AD FS server uses the MFA adapter to communicate to the Azure MFA service to perform the second factor of authentication. If you choose to use AD FS with the Azure MFA cloud service adapter, write **AD FS with Azure MFA cloud adapter** in box **1f** on your planning worksheet. -Alternatively, you can use AD FS with an on-premises Azure MFA server adapter. Rather than AD FS communicating directly with the Azure MFA cloud service, it communicates with an on-premises AD FS server that synchronizes user information with the on-premises Active Directory. The Azure MFA server communicates with Azure MFA cloud services to perform the second factor of authentication. If you choose to use AD FS with the Azure MFA server adapter, write **AD FS with Azure MFA server adapter** in box **1f** on your planning worksheet. +Alternatively, you can use AD FS with an on-premises Azure MFA server adapter. Rather than AD FS communicating directly with the Azure MFA cloud service, it communicates with an on-premises Azure MFA server that synchronizes user information with the on-premises Active Directory. The Azure MFA server communicates with Azure MFA cloud services to perform the second factor of authentication. If you choose to use AD FS with the Azure MFA server adapter, write **AD FS with Azure MFA server adapter** in box **1f** on your planning worksheet. The last option is for you to use AD FS with a third-party adapter as the second factor of authentication. If you choose to use AD FS with a third-party MFA adapter, write **AD FS with third party** in box **1f** on your planning worksheet. @@ -267,9 +271,9 @@ If box **1a** on your planning worksheet reads **cloud only**, ignore the public If box **1b** on your planning worksheet reads **key trust**, write **N/A** in box **5b** on your planning worksheet. -The registration authority only relates to certificate trust deployments and the management used for domain and non-domain joined devices. +The registration authority only relates to certificate trust deployments and the management used for domain and non-domain joined devices. Hybrid Azure AD joined devices managed by Group Policy need the Windows Server 2016 AD FS role to issue certificates. Hybrid Azure AD joined devices and Azure AD joined devices managed by Intune or a compatible MDM need the Windows Server NDES server role to issue certificates. -If box **3a** reads **GP** and box **3b** reads **modern management**, write **AD FS RA and NDES** in box **5b** on your planning worksheet. In box **5c**, write the following certificate templates names and issuances: +If box **2a** reads **GP** and box **2b** reads **modern management**, write **AD FS RA and NDES** in box **5b** on your planning worksheet. In box **5c**, write the following certificate templates names and issuances: | Certificate Template Name | Issued To | | --- | --- | @@ -279,14 +283,14 @@ If box **3a** reads **GP** and box **3b** reads **modern management**, write **A | Web Server | NDES | | CEP Encryption | NDES | -If box **3a** reads **GP** and box **3b** reads **N/A**, write **AD FA RA** in box **5b** and write the following certificate template names and issuances in box **5c** on your planning worksheet. +If box **2a** reads **GP** and box **2b** reads **N/A**, write **AD FA RA** in box **5b** and write the following certificate template names and issuances in box **5c** on your planning worksheet. | Certificate Template Name | Issued To | | --- | --- | | Exchange Enrollment Agent | AD FS RA | | Web Server | AD FS RA | -If box **3a** or **3b** reads modern management, write **NDES** in box **5b** and write the following certificate template names and issuances in box 5c on your planning worksheet. +If box **2a** or **2b** reads modern management, write **NDES** in box **5b** and write the following certificate template names and issuances in box 5c on your planning worksheet. | Certificate Template Name | Issued To | | --- | --- | diff --git a/windows/access-protection/hello-for-business/images/SetupAPin.png b/windows/access-protection/hello-for-business/images/SetupAPin.png new file mode 100644 index 0000000000..50029cc00e Binary files /dev/null and b/windows/access-protection/hello-for-business/images/SetupAPin.png differ diff --git a/windows/access-protection/hello-for-business/images/dsregcmd.png b/windows/access-protection/hello-for-business/images/dsregcmd.png new file mode 100644 index 0000000000..85bc6491cf Binary files /dev/null and b/windows/access-protection/hello-for-business/images/dsregcmd.png differ diff --git a/windows/access-protection/hello-for-business/images/event358.png b/windows/access-protection/hello-for-business/images/event358.png new file mode 100644 index 0000000000..70376c35a1 Binary files /dev/null and b/windows/access-protection/hello-for-business/images/event358.png differ diff --git a/windows/access-protection/hello-for-business/images/hybridct/device1.png b/windows/access-protection/hello-for-business/images/hybridct/device1.png new file mode 100644 index 0000000000..2835e56049 Binary files /dev/null and b/windows/access-protection/hello-for-business/images/hybridct/device1.png differ diff --git a/windows/access-protection/hello-for-business/images/hybridct/device2.png b/windows/access-protection/hello-for-business/images/hybridct/device2.png new file mode 100644 index 0000000000..4874ca4516 Binary files /dev/null and b/windows/access-protection/hello-for-business/images/hybridct/device2.png differ diff --git a/windows/access-protection/hello-for-business/images/hybridct/device3.png b/windows/access-protection/hello-for-business/images/hybridct/device3.png new file mode 100644 index 0000000000..c6572cbd5a Binary files /dev/null and b/windows/access-protection/hello-for-business/images/hybridct/device3.png differ diff --git a/windows/access-protection/hello-for-business/images/hybridct/device4.png b/windows/access-protection/hello-for-business/images/hybridct/device4.png new file mode 100644 index 0000000000..3a72066a31 Binary files /dev/null and b/windows/access-protection/hello-for-business/images/hybridct/device4.png differ diff --git a/windows/access-protection/hello-for-business/images/hybridct/device5.png b/windows/access-protection/hello-for-business/images/hybridct/device5.png new file mode 100644 index 0000000000..c3754b5389 Binary files /dev/null and b/windows/access-protection/hello-for-business/images/hybridct/device5.png differ diff --git a/windows/access-protection/hello-for-business/images/hybridct/device6.png b/windows/access-protection/hello-for-business/images/hybridct/device6.png new file mode 100644 index 0000000000..97db24c262 Binary files /dev/null and b/windows/access-protection/hello-for-business/images/hybridct/device6.png differ diff --git a/windows/access-protection/hello-for-business/images/hybridct/device7.png b/windows/access-protection/hello-for-business/images/hybridct/device7.png new file mode 100644 index 0000000000..80f9d53d2c Binary files /dev/null and b/windows/access-protection/hello-for-business/images/hybridct/device7.png differ diff --git a/windows/access-protection/hello-for-business/images/hybridct/device8.png b/windows/access-protection/hello-for-business/images/hybridct/device8.png new file mode 100644 index 0000000000..97ad2a1bfb Binary files /dev/null and b/windows/access-protection/hello-for-business/images/hybridct/device8.png differ diff --git a/windows/access-protection/hello-for-business/images/mfa.png b/windows/access-protection/hello-for-business/images/mfa.png new file mode 100644 index 0000000000..b7086b9b79 Binary files /dev/null and b/windows/access-protection/hello-for-business/images/mfa.png differ diff --git a/windows/access-protection/hello-for-business/toc.md b/windows/access-protection/hello-for-business/toc.md index e99fabcb82..ceb776ae4e 100644 --- a/windows/access-protection/hello-for-business/toc.md +++ b/windows/access-protection/hello-for-business/toc.md @@ -1,4 +1,4 @@ -# [Windows Hello for Business](hello-identity-verification.md) +# [Windows Hello for Business](hello-identity-verification.md) ## [Windows Hello for Business Overview](hello-overview.md) ## [How Windows Hello for Business works](hello-how-it-works.md) @@ -13,6 +13,12 @@ ## [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 Certificate Trust Deployment](hello-hybrid-cert-trust.md) +#### [Prerequistes](hello-hybrid-cert-trust-prereqs.md) +#### [New Installation Baseline](hello-hybrid-cert-new-install.md) +#### [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md) +#### [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 Certificate Trust Deployment](hello-deployment-cert-trust.md) #### [Validate Active Directory prerequisites](hello-cert-trust-validate-ad-prereq.md) diff --git a/windows/device-security/security-policy-settings/password-must-meet-complexity-requirements.md b/windows/device-security/security-policy-settings/password-must-meet-complexity-requirements.md index d51142a117..29f724e680 100644 --- a/windows/device-security/security-policy-settings/password-must-meet-complexity-requirements.md +++ b/windows/device-security/security-policy-settings/password-must-meet-complexity-requirements.md @@ -30,7 +30,9 @@ The **Passwords must meet complexity requirements** policy setting determines wh - Uppercase letters of European languages (A through Z, with diacritic marks, Greek and Cyrillic characters) - Lowercase letters of European languages (a through z, sharp-s, with diacritic marks, Greek and Cyrillic characters) - Base 10 digits (0 through 9) - - Non-alphanumeric characters (special characters) (for example, !, $, \#, %) + - Non-alphanumeric characters (special characters): + (~!@#$%^&*_-+=`|\\(){}\[\]:;"'<>,.?/) + Currency symbols such as the Euro or British Pound are not counted as special characters for this policy setting. - Any Unicode character that is categorized as an alphabetic character but is not uppercase or lowercase. This includes Unicode characters from Asian languages. Complexity requirements are enforced when passwords are changed or created. diff --git a/windows/device-security/security-policy-settings/user-account-control-admin-approval-mode-for-the-built-in-administrator-account.md b/windows/device-security/security-policy-settings/user-account-control-admin-approval-mode-for-the-built-in-administrator-account.md index a298ded405..b452b3c093 100644 --- a/windows/device-security/security-policy-settings/user-account-control-admin-approval-mode-for-the-built-in-administrator-account.md +++ b/windows/device-security/security-policy-settings/user-account-control-admin-approval-mode-for-the-built-in-administrator-account.md @@ -18,9 +18,10 @@ Describes the best practices, location, values, policy management and security c ## Reference This policy setting determines the behavior of Admin Approval Mode for the built-in administrator account. -When the Admin Approval Mode is enabled, the local administrator account functions like a standard user account, but it has the ability to elevate privileges without logging on by using a different account. In this mode, any operation that requires elevation of privilege displays a prompt that allows the administrator to permit or deny the elevation of privilege. If Admin Approval Mode is not enabled, the built-in Administrator account logs on in Windows XP Mode, and it runs all applications by default with full administrative privileges. By default, this setting is set to **Disabled**. +When the Admin Approval Mode is enabled, the local administrator account functions like a standard user account, but it has the ability to elevate privileges without logging on by using a different account. In this mode, any operation that requires elevation of privilege displays a prompt that allows the administrator to permit or deny the elevation of privilege. If Admin Approval Mode is not enabled, the built-in Administrator account runs all applications by default with full administrative privileges. By default, Admin Approval Mode is set to **Disabled**. ->**Note:**  If a computer is upgraded from a previous version of the Windows operating system, and the administrator account is the only account on the computer, the built-in administrator account remains enabled, and this setting is also enabled. +> [!NOTE] +> If a computer is upgraded from a previous version of the Windows operating system, and the administrator account is the only account on the computer, the built-in administrator account remains enabled, and this setting is also enabled.   ### Possible values @@ -30,11 +31,16 @@ When the Admin Approval Mode is enabled, the local administrator account functio - Disabled - The built-in administrator account logs on in Windows XP Mode, and it runs all applications by default with full administrative privileges. + If Admin Approval Mode is not enabled, the built-in Administrator account runs all applications by default with full administrative privileges ### Best practices -- Do not enable the built-in administrator account on the client computer, but use the standard user account and User Account Control (UAC). +- It is recommended not to enable the built-in Administrator account on the client computer, but to use the standard user account and User Account Control (UAC) instead. If you want to enable the built-in Administrator account to carry out administrative tasks, for security reasons you should also enable Admin Approval Mode. See [UAC-Admin-Approval-Mode-for-the-Built-in-Administrator-account](https://docs.microsoft.com/en-us/windows/device-security/security-policy-settings/user-account-control-admin-approval-mode-for-the-built-in-administrator-account) + + To enable Admin Approval Mode, you must also configure the local security policy setting: [User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode](https://docs.microsoft.com/en-us/windows/device-security/security-policy-settings/user-account-control-behavior-of-the-elevation-prompt-for-administrators-in-admin-approval-mode) to **Prompt for consent on the secure desktop** and then click OK. + +> [!NOTE] +> After enabling Admin Approval Mode, to activate the setting, you must first log in and out. Alternatively, You may perform **gpupdate /force** from an elevated command prompt. ### Location @@ -53,27 +59,6 @@ The following table lists the actual and effective default values for this polic | Member Server Effective Default Settings | Disabled| | Client Computer Effective Default Settings | Disabled|   - -## To enable Admin Approval Mode -If you wish to use Admin Approval Mode with an active built-in administrator account, follow these steps: - -1. In the search box, type gpedit.exe. -2. From the Local Group Policy editor, navigate to **Computer Configuration** > **Windows Settings** > **Security Settings** > **Local Policies** > **Security Options**. - - ![User Account Control: Admin Approval Mode for the built-in administrator account](images/uac-admin-approval-mode-for-the-built-in-administrator-account.png) - -3. Double-click the policy **UAC-Admin-Approval-Mode-for-the-Built-in-Administrator-account**. -4. On the **Local Security Setting** tab, make sure that the **Enabled** radio button is selected and then click OK. -5. Configure the local security setting **UAC-Behavior-of-the-elevation-prompt-for-administrators-in-Admin-Approval-Mode** by setting it to **Prompt for consent on the secure desktop** and then click OK. - - ![User Account Control: behavior of the elevation prompt for administrators in Admin Approval Mode](images/uac-behavior-of-the-elevation-prompt-for-administrators-in-admin-approval-mode.png) - -As an alternative way to carry out step 5, you can also type "UAC" in the search box, and then from the User Account Control Settings dialog box, set the slider control to **Notify me only when apps try to make changes to my computer (default)**. - -![User Account Control notify me only when apps try to make changes to my pc](images/uac-notify-me-only-when-apps-try-to-make-changes-to-my-pc.png) - -6. To activate the new setting, log out and then log in again. - ## Policy management This section describes features and tools that are available to help you manage this policy. @@ -88,10 +73,7 @@ This section describes how an attacker might exploit a feature or its configurat ### Vulnerability - An attack vector for malicious programs is to discover the password of the administrator account because that user account was created for all installations of Windows. To address this risk, the built-in administrator account is disabled in computers running at least Windows Vista. In computers running at least Windows Server 2008, the administrator account is enabled, and the password must be changed the first time the Administrator logs on. In a default installation of a computer running at least Windows Vista, accounts with administrative control over the computer are initially set up in one of two ways: - -- If the computer is not joined to a domain, the first user account you create has the equivalent permissions as a local administrator. -- If the computer is joined to a domain, no local administrator accounts are created. The enterprise or domain administrator must log on to the computer and create a local administrator account if one is warranted. +One of the risks that the UAC feature tries to mitigate is that of malicious software running under elevated credentials without the user or administrator being aware of its activity. An attack vector for malicious programs is to discover the password of the Administrator account because that user account was created for all installations of Windows. To address this risk, the built-in Administrator account is disabled in computers running at least Windows Vista. In computers running at least Windows Server 2008, the Administrator account is enabled, and the password must be changed the first time the administrator logs on. In a default installation of a computer running at least Windows Vista, if the computer is not joined to a domain, the first user account you create has the equivalent permissions of a local administrator. ### Countermeasure diff --git a/windows/device-security/security-policy-settings/user-account-control-behavior-of-the-elevation-prompt-for-administrators-in-admin-approval-mode.md b/windows/device-security/security-policy-settings/user-account-control-behavior-of-the-elevation-prompt-for-administrators-in-admin-approval-mode.md index 160a34bfa4..bd001552c4 100644 --- a/windows/device-security/security-policy-settings/user-account-control-behavior-of-the-elevation-prompt-for-administrators-in-admin-approval-mode.md +++ b/windows/device-security/security-policy-settings/user-account-control-behavior-of-the-elevation-prompt-for-administrators-in-admin-approval-mode.md @@ -25,7 +25,8 @@ This policy setting determines the behavior of the elevation prompt for accounts - **Elevate without prompting** Assumes that the administrator will permit an operation that requires elevation, and additional consent or credentials are not required. - >**Note:**  Selecting **Elevate without prompting** minimizes the protection that is provided by UAC. We do not recommend selecting this value unless administrator accounts are tightly controlled and the operating environment is highly secure. + + **Note**  Selecting **Elevate without prompting** minimizes the protection that is provided by UAC. We do not recommend selecting this value unless administrator accounts are tightly controlled and the operating environment is highly secure.   - **Prompt for credentials on the secure desktop** @@ -33,7 +34,7 @@ This policy setting determines the behavior of the elevation prompt for accounts - **Prompt for consent on the secure desktop** - When an operation requires elevation of privilege, the user is prompted on the secure desktop to select **Permit** or **Deny**. If the user selects **Permit**, the operation continues with the user's highest available privilege. + When an operation requires elevation of privilege, the user is prompted on the secure desktop to select **Permit** or **Deny**. If the user selects **Permit**, the operation continues with the user's highest available privilege.* - **Prompt for credential**s @@ -47,10 +48,17 @@ This policy setting determines the behavior of the elevation prompt for accounts This is the default. When an operation for a non-Microsoft application requires elevation of privilege, the user is prompted on the secure desktop to select **Permit** or **Deny**. If the user selects **Permit**, the operation continues with the user's highest available privilege. +\*If you have enabled the built-in Administrator account and have configured Admin Approval Mode, you must also configure the option **Prompt for consent on the secure desktop**. You can also configure this option from User Account Control, by typing **UAC** in the search box. From the User Account Control Settings dialog box, set the slider control to **Notify me only when apps try to make changes to my computer (default)**. + +> [!NOTE] +> After enabling Admin Approval Mode, to activate the setting, you must first log in and out. Alternatively, You may perform **gpupdate /force** from an elevated command prompt. + ### Best practices - Selecting the option **Elevate without prompting** minimizes the protection that is provided by UAC. We do not recommend selecting this value unless administrator accounts are tightly controlled and the operating environment is highly secure. +- It is recommended not to enable the built-in Administrator account on the client computer, but to use the standard user account and User Account Control (UAC) instead. If you want to enable the built-in Administrator account to carry out administrative tasks, for security reasons you should also enable Admin Approval Mode. For further information, see [UAC-Admin-Approval-Mode-for-the-Built-in-Administrator-account](https://docs.microsoft.com/en-us/windows/device-security/security-policy-settings/user-account-control-admin-approval-mode-for-the-built-in-administrator-account) + ### Location Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options diff --git a/windows/device-security/tpm/tpm-recommendations.md b/windows/device-security/tpm/tpm-recommendations.md index 7c44d3803e..8dcde29788 100644 --- a/windows/device-security/tpm/tpm-recommendations.md +++ b/windows/device-security/tpm/tpm-recommendations.md @@ -105,7 +105,6 @@ The following table defines which Windows features require TPM support. | Passport: Domain AADJ Join | Required | Required | Supports both versions of TPM, but requires TPM with HMAC and EK certificate for key attestation support. | | Passport: MSA or Local Account | Required | Required | TPM 2.0 is required with HMAC and EK certificate for key attestation support. | | Device Encryption | Not Applicable | Required | TPM 2.0 is required for all InstantGo devices. | -| Device Guard / Configurable Code Integrity | Not Applicable | Required | Beginning with Windows 10, version 1607, Trusted Platform Module (TPM 2.0) must be enabled by default on new computers. | | Credential Guard | Required | Required | For Windows 10, version 1511, TPM 1.2 or 2.0 is highly recommended. If you don't have a TPM installed, Credential Guard will still be enabled, but the keys used to encrypt Credential Guard will not be protected by the TPM. | | Device Health Attestation | Required | Required | | | Windows Hello / Windows Hello for Business | Not Required | Recommended | Whenever possible, Microsoft recommends the use of TPM hardware. The TPM protects against a variety of known and potential attacks, including PIN brute-force attacks. [How keys are protected](https://docs.microsoft.com/en-us/windows/access-protection/hello-for-business/hello-how-it-works#how-keys-are-protected) |